Playing with real time Cellular Automata is as much fun as putting grapes, marshmellow peeps, peppermint patties, bars of soap, and aluminum foil in the microwave, but they're much easier to clean up, and they don't smell so bad!
Cellular automata are simple rules that are applied to a grid of cells, or the pixel values of an image. The same rule is applied to every cell, to determine its next state, based on the previous state of that cell and its neighboring cells.
There are many interesting cellular automata rules, and they all look very different, with amazing animated dynamic effects. "Life" is a widely known cellular automata rule, but many other lesser known rules are much more interesting!
I've written code to play with real time animated cellular automata, that applies a bunch of rules to different parts of an image at once. You can create and delete different rules, move them around and resize them, throw them so they bounce around and leave trails, overlap them to mix their effects together, zoom into the cells and scroll around, and draw into the cells in real time with a few simple painting tools.
I've ported my cellular automata machine code to be an Adobe After Effects plug-in, called "Aether"! Now you can totally control the cellular automata over time, and combine them with alpha channeled digital video to make all kinds of amazing animated effects! Soon I'll make the plug-in and more examples available for other people to use as well, but for now here are some of the first examples of what it can do:
I hope you have a fast net connection, and can play mpeg at 640x480! If you don't, then at least check out the AetherClocks, which are small. Good luck!
These are some older cellular automata images I've created:
I found a wonderful book about Cellular Automata in the Interval library:
Everybody interested in Cellular Automata should have Toffuli and Margolis's book, "Cellular Automata Machines", MIT Press. The text covers some very interesting aspects of the subject, and the color plates are beautiful. The still color pictures can only hint at what the dynamic action is like. Cellular Automata by their very nature are dynamic, acting out over time, so a single image snapshot can't capture the dynamic effects that you experience watching them play out over time.
I've been developing my own two dimensional Cellular Automata Engine for a long time, added many features, optimized the hell out of it, and ported it to many systems.
I was inspired by the CAM-6 designed by Toffuli and Margolis, and my software started out as a simulation of their hardware CA engine, which was programmed in Forth. Pete ("Luv Chunks") Dillworth worked for T&M at MIT, and brought one of their CAMs to a science fiction convention, where I totally tripped out on it. I had such a hard time tearing myself away from the screen, that I had to write my own.
The CAM-6 rules were programmed in Forth, then run over all possible inputs to create a lookup table that was downloaded into the hardware. Since I was using Mitch Bradley's Sun Forth, I read over their Forth code and wrote my own compatible code that let me program CA rules in the same language described in T&F's book, "Cellular Automata Machines".
My CA engine was written in C, and linked into Forth as a library that could be called from Forth to simulate the hardware. Forth would read in and compile the rules, then give them to the engine and control it much in the way the CAM-6 forth system controlled the hardware. I had it write out sequences of raster files that I could play back at higher speed later.
It's really fun to play directly with evolving cellular automata. They run as fast as possible, and you can interactivally draw in the live cells without pausing, the way Mickey Mouse as the Sorcer's Apprentice could wave his hand, causing colorful sparks to fly and instantly effecting the dynamically evolving situation.
For a while, it was a batch process, computing a sequence of images then viewing them with another program, but eventually I wrote a shared memory raster interface to NeWS, and could display them on the screen in real time. Then I wrote a HyperLook component so I could display multiple editable animated views at different magnifications, and a stack for controling the engine and browsing, configuring and applying various rules and special editing effects. It was cool to be able to draw in PostScript into the evolving cells in real time! I could scale and rotate and paste in images and text and encapsulated PostScript clip art, and also copy the cellular automata image into HyperLook's PostScript graphics editor, then scale, rotate and clip that into another drawing for use as a user interface component or whatever.
When I ported SimCity to Unix, I had to write an efficient tile display engine, so when it was done, I tested it by running cellular automata in the city matrix, and displaying the cells as colorful 16x16 tiles in the map window. The SimCity tiles are grouped in interesting sequences and clusters, so the cellular automata (especially the smooth heat diffusion) make some really interesting patterns!
SimCity for Unix (both HyperLook on NeWS and TCL/Tk on X11) is one of the few commercial applications of cellular automata: you can download the fully functional SimCity program over the net, and run it for 5 minutes for free, but unless you buy a license, it melts the city with a cellular automata! But customers who bought licenses reported that they missed the melting cellular automata effect, so I added it to the "Disasters" menu. What's fun is that the normal SimCity editing tools are active even while the city is melting, so you can use the bulldozer to draw into the plasma, build roads and zones in unobstructed places that quickly dissolve into chaos, and even turn loose a monster who leaves a trail of destruction!
Then I plugged the cellular automata engine into ScriptX, so I could control it from a nice object oriented multimedia programming language. I incorporated it into the DreamScape design example, making real time image filtering tools with arbitrarily shaped clipping regions, and cool looking frames overlayed on the drawing surface that you could drag them around with. You could throw them and they would bounce around the screen, and you could even plug them and other objects together like legos, to construct bizarre painting machines!
After that, I got a Thinkpad with Windows 95 and the DirectX Game Developers Kit, and ported my code to DirectDraw. It is very fast, and lets you zoom and pan around really smoothly! I am working on it in my spare time, exploring the realm of invisible interfaces to performance art.
I am trying to develop an interface that facilitates but does not impede the performer, that doesn't sully the visual display, that is invisible or at least not distracting to the audience. This is a difficult but interesting problem. As with all user interfaces, there are no right answers, just techniques with trade-offs. So I am putting hard restrictions on what I am allowed to do, in order to force myself to develop new techniques that will have their own unique trade-offs, and hopefully I will come back from this excercise with some cool new techniques that can be integrated into a less restrictive interface. There are a lot of standard cheap and easy solutions to some of the problems I'm trying to address (like scroll bars), but I'm resisting them so I can come up with my own solutions.
One problem is how to display and edit properties of an object that are invisible, like the rules that are being applied to the cells? Property sheets and control panels are the typical solution to this problem, but they are extremely intrusive, indirect, and take up a lot of screen space, and introduce the concept of a "window", which is totally inappropriate in the direct continuous visual representation of the world that we're trying to project.
Given the rule that we're not allowed to draw stuff (like windows) on top of the subject matter (the cell pixels), where can we put affordances (a generic word for widgets, control points, or visual manipulatable things that let you view or edit something that would otherwise be invisible)?
One way out that's occurred to me is hiding the affordances *inside* the pixels! By giving the user the ability to pan and zoom, you make it possible to zoom into a single pixel, so that it's taking up much or all of the screen. Since a pixel projects to a large area of solid color, much of the screen is taken up to display the state of that pixel, so at such a large magnification, it's not so bad to bend the rule that we're not allowed to draw stuff on top of the cells, as long as we don't completely cover any one pixel up! So the user model is: you go "inside" of a pixel to edit its otherwise invisible state!
