Admittedly, the result of this equation might not be everyone’s definition of fun, so in order for you to decide whether this post is worth reading at all, I’ll start by putting up something I made using the aforementioned perlin noise, a vectorfield and some particles.
(Note: the videos in this post are actually png imagesequences compiled into swf-files, loaded by a simple player I wrote for the purpose because I didn’t succeed in converting the sequence into a video with decent quality – yet. Beware, the videos are quite a lot of MBs for quite a few seconds of imagery.)
If that was indeed fun to watch, you might want to know how that animation was made. Basically it comes down to this: create an image filled with noise, map each pixel’s colorvalue to a vector (which is something with a direction and a magnitude), and end up with a field of vectors at every location of the image. Finally, throw a lot of particles on it and let the vectors act as some kind of mysterious forces on them. Result: moving particles! To make their trajectories visible, every particle increases the brightness of every pixel it visits a little. This way, areas with a lot of traffic become very bright while other areas stay more dimmed, or completely black.
I made a little tool to play around with this concept, using 6348 particles. Just randomize the noise until you spot a nice one and then press start. You can safely toggle both the particles and the noise without anything changing in the drawing, those two layers are merely to show what’s going on. (To actually see the drawing, you have to turn both particles and noise off)
After endless hours of fun with that, I realized perlin noise had another interesting property I could use: you can render it using a set of inputvalues, and if you don’t change those values, the noise will always render the same. Not much hoorays yet, but: when you change the values (or at least some of them) slightly, the noise also changes slightly. Hmmm…
On to the final step: after an image was rendered (somewhere in the range of 150-250 iterations), I changed the noise a little bit, set the particles back to their startingpositions and let them move again. Since the noise was slightly different, the drawn endresult was slightly different as well. Restarting this process a few hundred times, collecting all the images in between, was how the animations on this page came to be.
All the rendering, storing the images, changing the noise and resetting the particles was automated (with a small php-script to post the images to, since Flash can’t write to disk). More particles and more iterations meant better results, but also longer rendertimes. The videos in this post took about 1.5 hours to render, which resulted in about 10 seconds of video.
Two more examples:
I’m not sure what the next step will be. I already started on rewriting this tool (in Flash) with a better interface and more options but I’m not sure whether that one will ever be finished; I might just skip on to rebuilding it in either Processing or XNA to make the creation of the animations go waaaaay faster.