@mariuswatz websaver awe.sm/5daM6 is a great way to use a processing.js sketch as a screensaver. Here’s mine: viz.runningwithdata.com/boids/

— Jason Sundram (@jsundram) January 28, 2012

Websaver runs on MacOS and allows the user to specify a web page to load when the screensaver is active. And since it uses Safari to render the HTML (I assume), you can use HTML5 and Processing.js to run computational sketches on that web page.

It’s a nice hack to enable easy development of screensavers based on open web standards, without having to worry about interaction with the OS etc. In fact, it’s nearly as good as my Google Chrome screensaver idea, minus an app store etc.

Here are three examples showing a simple map display and two demos using geo data from OpenPaths in CSV format: 20120127_unfolding_map_examples.zip

Update: The lecture notes about infoviz and self-ethnography are online on Scribd, it’s basically the same lecture as two years ago.

Below is a more or less complete list. In summary, the arguments are roughly as follows:

• “Screensavers are outdated / unnecessary.” Well, yes. But that has never meant much in terms of deciding whether a cultural phenomenom succeeds or is banished to the Wasteland of Forgotten Memes. Tamagotchis or animated GIFs, anyone? 90% of all iPhone / Android apps are unnecessary for everyday living, yet the smartphone app culture is a runaway train.
• “Developing screensavers is currently way too hard.” I share this sentiment and suspect it to the main culprit along with its corollary: “Installing screensavers is too hard / scary / likely to mess with the rest of my computer.”
• “It’s impossible to improve on flying toasters.” This terrifying thought is exactly why I would suggest screensavers need revisiting.

In conclusion: Between being tricky to develop and just as tricky to install and successfully use, screensavers stand no chance of recovering ground as a cultural phenomenom. Despite their close link to the app culture that is currently dominating our lives, screensavers (aka “ambient software”) will get no love.

This might not seem like such a terrible loss, but I still posit that ambient data gadgets with possible integration to web / mobile apps would’ve been a great usage scenario. There are some ways this could still happen:

• Microsoft and Apple realize the lost potential and relaunch their screensaver frameworks complete with app stores for screensavers. (Unlikely.)
• Google develops a screensaver mode for Chrome as part of their Chrome apps initiative and allows sales of screensavers through the Chrome app store. (Entirely possible if a little optimistic. My favorite option by far, though. Google, are you listening?)
• In both these scenarios, new screensavers would be based on HTML5 with WebGL, allowing them to be cross-platform and based on open standards. Because you all understand that proprietary is stupid, right?

A sad footnote: I had to uninstall the brilliant Briblo screensaver after realizing it was interfering with the taskbar on Windows 7. So I’m back to the ever popular blank screen, like so much of the world population.

Update: After this was posted it got blogged on Creative Applications and I’ve received quite a few responses via Twitter. See the separate post “Screensaver Culture – Twitter responds” for a summary, as well as some further thoughts on the demise of the screensaver.

• Your task is to come up with a concept for a screensaver that is both suitable to the screensaver format and updated to a 2012 understanding of interaction design. We are looking for ideas that go beyond the traditional screensaver format, or which reinvent that format by applying design thinking to a field full of visual cliche.
• Two general directions are suggested (but not required):
  1. Ambient data gadgets – screensavers as data aggregators and visualizers.
  2. Computational graphics – parametric visuals.
• If your idea is too ambitious to realize in a 3-day time frame we want to see convincing screen mockups of how the screensaver would work. But we would rather see a real demo that’s rough around the edges than a slick Photoshop sketch. You must submit at least one Processing sketch illustrating part of your screensaver’s functionality.

• Yuji Adachi: Briblo – Lego style screensaver
• Twistori, visualization of tweets with certain keywords
• Smashing Magazine: Screensavers – Best Of (2007)
• Kuler Screensaver showing latest Adobe Kuler color palettes
• SETI @ Home distributed computing screensaver
• Scott Draves: Electric Sheep, massively distributed fractal image generator
• Twingly, blogosphere visualization
• Terence M. Welsh (Really Slick) – OpenGL 3D screensavers
• Stefan Trifan: Weather, City
• GeocodEarth, Flickr, GeoRSS mashup

I stupidly forgot to bring my USB stick, so please download from here. Also, download Processing 1.5.1 if you don’t have it on your computer.

Arc mesh tool created with Modelbuilder and ControlP5

I did a short lecture + workshop about digital fabrication and parametric modeling with Processing yesterday at NYU’s ITP program. Thanks to Dan Shiffman for the invite, it ended up being a lot of fun because of the great turnout of enthusiastic ITP’ers. It certainly made me even more regretful that I was unable to teach a fabbing course at ITP this semester, but with luck there will be other oppportunities.

As promised I have uploaded the pre-written examples I demo’ed as well as the code I (frenziedly) wrote live during our 1.5 hour coding session. The focus was to demonstrate the logic of the Modelbuilder library, a set of utilities and aimed at abstracting and simplifying some common tasks in computational creation of 3D meshes.

The library is really not all that sophisticated, but it shifts the focus away from OpenGL drawing logic towards a more object-oriented way of imaging 3D forms based on UVertexList objects. In a typical situation it should simplify a lot of tasks, as well as save dozens of for() loops and repetitive code. It also allows some pragmatic coding (aka “lazy”) coding practices enabling easy reuse of geometries due to the assumption that operations like “new UVertexList(vl)” should always copy input data by content rather than by reference.

I’m pleased to say that Modelbuilder performed well in the demo session, there’s nothing like live coding to reveal weaknesses or inconsistencies in code. But the Modelbuilder logic proved consistent under stress testing and we were able to do some pretty decent mesh generation in a limited amount of time.

A ZIP with all the files shown (including the Modelbuilder and ContolP5 libraries) can be downloaded from http://db.tt/5Ehmn6uz. It includes the following code examples:

• simple_geo_arc_4 A tool for creating a composition of 3D arcs (w/ valid face normal orientation and passing the “waterproof” criteria for 3D printing), generating output to STL format. This was written live in around 30 minutes.
• mb_04_gui_parametric A parametric 3D form generator created for my Makerbot residency – results look valid on screen but for some reason export to STL results in flawed models. I’ll look into debugging this example.
• mb_04_gui_heightfield An example showing how to create a heightfield mesh from an image, allowing interactive control of mesh resolution and Z scaling. Potentially useful for geographical elevation maps and Kinect depth maps.
• A set of examples demonstrating the core Modelbuilder functions

Slideshow of results from the Interactive Parametrics workshop

The Interactive Parametrics workshop with Studio Mode and MakerBot is going well, resulting in MakerBot-ready models generated from Processing sketches. Take a look at the slideshow above to get a preview.

Plenty of models have been going up on Thingiverse, tagged with intparam2011. I’ll be posting code and more pictures after we wind up the workshop tomorrow.

Workshop with Studio Mode & MakerBot: Interactive Parametrics

This weekend I’ll be teaching the Interactive Parametrics Workshop with Studio Mode (Gil Akos and Ronnie Parsons) and MakerBot (represented by Bre Pettis). We’ve been planning this for a while, but since it’s happening during my residency at MakerBot we thought it’d be fun to focus on the MakerBot as a possible output method. Our thanks to Bre and the MakerBot crew for supporting the workshop!

With a good mix of architects and code-hacking designers as our participants it should be an interesting weekend. We will be posting the resulting code examples and STL models after the workshop.

We’ll be looking at strategies for parametric modeling using Processing, outputting MakerBot-ready models as STL files and printing them on site.

Processing lacks the hardcore math engine of typical CAD packages, but is far more flexible when it comes to working interactively with dynamic realtime systems. By extending Processing’s core functionality with libraries for simulation and 3D mesh construction we can combine realtime processes with advanced geometry tools.

We’ll be relying on a selection of Processing libraries:

• unlekker.ModelBuilder, a new library I’ll be releasing for the workshop that supports mesh-oriented parametric modeling for 3D printing. It’s nothing fancy, but it’ll get the job done in predictable ways.
• Karsten Schmidt’s always excellent Toxiclibs library offers volumetric modelling and advanced simulation functions.
• Frederik Vanhoutte’s Hemesh library is a comprehensive set of tools for constructing and modifying meshes through procedural tools like extruding, subdividing, slicing, chamfering etc. Hemesh allows the effortless creation of hypercomplex models.
• Andreas Schlegel’s ControlP5 library will be our steady workhorse for GUI interface elements.

We’ll also be using Rhino3D and MeshLab to clean up models for fabrication.

Below is a list of links to tutorials and resources related to the tools we’ll be using:

• Processing
  Processing Primers 1-3 on modeLab.nu
  Processing.org/learning, great collection of tutorials
  OpenProcessing.org, social network for sharing Processing sketches
• Toxiclibs
  Toxiclibs home page
  Toxiclibs demos on OpenProcessing.org
• Hemesh
  Hemesh home page
  Hemesh introduction tutorial
  Hemesh Share && Tell presentation by Frederik Vanhoutte
  Hemesh post on Creative Applications
• Makerbot / Thing-O-Matic
  MakerBot Thing-O-Matic details
  Thingiverse – Open Source hub for digital design

Interactive Parametrics Workshop with Studio Mode and MakerBot, NYC Feb 19-20/21

I’m excited to announce that I will be doing a workshop in interactive parametric modelling with Studio Mode and MakerBot in New York, Feb 19-20 (with an optional extra day on Feb 21).

We will be using Processing along with CAD tools like Rhino3D to produce parametric models to output 3D models for digital fabrication. MakerBot Industries have graciously offered to lend us some MakerBot Thing-o-matics to produce models from the workshop. Participants are also free to use on-site KNK High-Force cutters.

The full announcement follows below, please visit Studio Mode’s announcement for enrollment and more details. Also check out the series of Processing primers I’ve been writing in preparation for the workshop.

Studio Mode is pleased to announce the fourth installment of the coLab workshop series: Interactive Parametrics. Interactive Parametrics is a two-day Processing workshop (with an optional third day) focusing on dynamic sketches and prototyping. The workshop will be held in New York City during the weekend of February 19.

Description: The paradigm of scripting within ubiquitous modeling platforms such as Rhino or Maya allows users to generate complex form by accessing an underlying geometry engine and performing iterative functions. This paradigm is typically based on run-once execution, making it unsuitable for designing interactive or time-based behaviors. By implementing workflows that utilize Processing to create real-time software sketches, we can design dynamic systems that can act as standalone tools for parametric design, input mechanisms to feed other platforms, or processors of existing or sensor-based data sets.

This fast-paced workshop will focus on interactive parametric design strategies. Using Processing as our base platform, we will design real-time dynamic behavior systems, implement interfacing techniques for fluid use, and iteratively prototype the solutions in physical format through rapid prototyping and digital die-cutting. Through a series of focused exercises and design tasks, each attendee will build a stand-alone parametric design sketch and work through the process of prototyping, realizing a set of solutions through computer numerically controlled equipment (Makerbot “Thing-O-Matic” and KNK High-Force Cutters). An optional third workshop day is offered to those participants desiring further time to develop individual projects or lines of research. As part of a larger online infrastructure, modeLab, this workshop provides participants with continued support and knowledge to draw upon for future learning.

Attendance will be limited to provide each participant maximum dedicated time with instructors. Participants are encouraged to be familiar with the basic concepts of parametric design and interface of Processing.

Interactive Parametrics was conceived through a collaboration between Studio Mode/modeLab and Marius Watz.