On my way to developing my 3d tree script I first added a function to my basic particle system to cause the particles to branch. I went back and polished up the rendering of this as it looked interesting in 2d.
As usual, the script is built in Processing. Particles are generated by clicking on the screen and then they spread out pushing each other away. A slight perlin noise field gives the strands a more interesting motion and texture. Each frame is drawn successively on the screen, tracing the particles motion, without clearing the background. Each particle is rendered as a filled ellipse with a lighter transparent outline, creating a slightly 3d feel as the outlines get denser toward the edges.
To render the images with a higher resolution I created a global scale variable. The width and height of the applet are multiplied by this variable and then the scale function is called with that variable at the beginning of the draw loop. This lets me switch quickly between a manageable size to see what’s going on and the high res version. On my mac, entering expose fits the oversize window onto my screen. It’s far from a perfect system but it works. Exporting vectors is a much better rout, but this application is to complex for that to be feasible.
Now pictures. Click to see them bigger.
This sketch builds off one of my recent experimentations in wave motion. In the script an array of waves is created by various inputs. Each wave effects the array of ‘fluid’ and creates a rippling structure. Here the structure is rendered not just after all the waves have been calculated but after each wave is processed.
The result is a stack of rippling points flowing between each other. I first just rendered each wave as a thin bar, to make sure everything was working properly, and then added a color property to the wave class. I dropped the symmetry to avoid some unintended interpretations. The script runs much slower, as I should have expected. I’ll try and streamline things a little (although it’s already very simple) and put it onto my interactive site. I might just have to put some limits on it so people don’t crash their.
Now a bunch of pictures!
I cracked open the old Processing Particle System again and tried something a little bit different.
Beginning with particles moving through a Perlin Flow Field I moved them into 3d. Since my particle system is built on the PVector class, adding the third dimension was a simple matter of adding a third parameter to every call to a new PVector and adding either the P3D or OpenGL (used for all the images here) rendering engine. An extra force pushes the particles up through space an array stores the previous locations for each particle. As particles die an instance of another object is created, exclusively for storing and rendering these paths.
Another addition causes the growing strands to bud. The budded particles inherit the properties from the parent. Changing the forces between particles, the branching rate, and the environmental properties creates many different structures.
As the script runs, a cloud of particles drifts up through space leaving behind a colorful twisted shrubbery. Using the mouse and keyboard the camera can be moved around the structure while it generates itself.
Until recently I’ve just been saving all of my images out of Processing using a simple saveFrame command and throwing all of my images into one giant folder. Looking into this folder I see a few key problems. I’ve come up with a little system to help me keep better track of renderings of my generative works. Unfortunately it won’t work retroactively, but it’ll be useful for future work, and perhaps it can be helpful to some other Processors.
This very adding this very simple snipped to a Processing sketch will save out an png of the render window whenever the ’s’ key is pressed. #### will be replaced by the current frame number.
void keyPressed() { if (key=='s') { saveFrame("name_of_sketch-####.png"); } }
This works out pretty nicely, but if you run the sketch twice and just happen to press ’s’ on the same frame the first image will be overwritten. Another issue, which might not seem to bad until you have a huge library of images built up, is the order of the files. If the sketch is run many times, all the saved images will be mixed together. Ideally images saved from one run of the sketch should be named sequentially so all the images from one run can be seen together.
Adding an arbitrary value to the particular run and sticking it into the file name fixes these two issues. Many of my scripts include a function to reset the program so it can be run a few times without being completely restarted. In this case, incrementing this arbitrary global value maintains the order of a set of runs.
int G; void setup() { G=floor(random(10000,90000)); //noiseSeed(G); } void draw() { } void keyPressed() { if (key=='s') { saveFrame("name_of_sketch-"+G+"-####.png"); } else if (keyCode==BACKSPACE || keyCode==DELETE) { // code to reset script G++; } }
This system isn’t perfect, but is a vast organizational improvement for just a few extra lines of code
Another useful trick, if you have a script which utilizes a lot of Perlin Noise, is the set the noiseSeed to a random integer (like G in the script above), and include that in the file name. This way, if you want to rerun the script with the same parameters later, you can always set G to the integer in the file name of a particular saved image.
After playing with binary cellular automata I thought I’d expand the script a little to accommodate more than two states of a pixel. Three loops are nested and each is iterated once for each state. If the index of each loop equals the three values above the current point the function returns the current state of a counter which is incremented in the innermost loop. In a binary system this is a little more complex than just testing each of the eight possible combinations, but is almost necessary when dealing with more states. I’ll post my code at the bottom of this post. But first, some pretty pictures.




This afternoon I played around with 1d cellular automata. The program is creates an array of cells which corresponds to a row of pixels on the screen. Each new generation of the structure is represented by the next row of pixels and the value (black or white) of each pixel is based on the three directly above it. There are eight possibilities for the pattern of the three parent pixels and an array of eight values stores the results to each of these possibilities. Changing the rule-set and the values of the first generation creates vastly different images. The script I was using was very much based off of Dan Shiffman’s code.


Here’s another rendering of my line wave script iterated quite a few times. In this rendering the image is blurred before each new set of lines and also inverted to create complimentary colors. There are two desktop wallpapers one of the pictured rendering and a similar one in light blue. Click the thumbnail on the left to download a zip file containing fullscreen and widescreen versions of the wallpaper. They might be a little busy for some, but I like them. What do you think?

Another little experiment with my particle system. Each particle is rendered very large with a slightly darker stroke than fill, and each frame is drawn over the previous one. This along with the color shifts creates some nice pseudo three dimensional effects. The effect is especially interesting when particles overlap as they move.

I built this script which creates circles budding off of circles. What better to do with it than put it in a circle? I could give some lofty symbolism for circles, and some if it might even be half true, but to be frank I just like them. They look nice. Not to mention it’s much too late to be coding anyway (or blogging).
proudly powered by wordpress v2.8 & jquery javascript library.
View all resources in the colophon.
website & all work creative commons by-nc anthony mattox (2007-09)
pragmatically validated xhtml 1.0 transitional & css thanks w3c