Decided to let it run overnight and save out prints every 100 frames and save out the actual camera view every frame so people can see better what is going on. The image above is a detail from the final print. It consists of 34 different layers (most of which is occluded by newer layers or is blurred into grey).

View the large size

Below are some stills from the video which shows the engine responsible for making the prints. There are 2000 particles responding to the magnetic pull of 7 large black spherical magnets. Each particle has a ‘tail’ which is blown outwards from the spherical magnets.

View the Vimeo version below, or if your pipes are big enough, check out the Quicktime version which comes in at around 108 MB. The audio is ‘Kirlian Isles III’ off the album ‘Kirlian Selections’ by the Flashbulb.

Magnetic Ink, test render 01 from flight404 on Vimeo.

For a while now, I have wanted to revisit the Ink Trails project. I loved the idea of creating a system that would engage the eye with its dynamic movement but also create a piece of art as a side effect of its existance. Though I loved the original Ink Trails, I couldn’t come up with a good way to mask the perlin noise influence acting on all the painting objects. All of the final pieces looked like glorified marbleized paper. There was no getting around it.

Then it hit me: Use the magnetosphere project as the engine and see what kind of paintings it would create. The first few examples were a bit bland. Using the same technique as Ink Trails, I had the magnetic particles rain ink down onto the ‘paper’ and if any of the particles actually touched the paper, they would scrape away at the ink that had already landed. Sadly, it looked dull. No surprises. Just a random spattering of circles.

As I continued to play with the code, I realized the part I did not like was how it looked to have the ribbon trails draw onto the paper every frame. The effect was not unlike old (really old) screensavers where lines bounced around the screen leaving echoes where it travelled. So I changed the process a bit.

Now there is a three step process. For the first step, over a period of 100 frames, the gravity orbs paint their cross-section onto the paper where it intersects it. The second step, also cumulative over 100 frames, has the particle orbs raining down a mist of ink. The third step is where it gets fun. Every 100 frames, all of the geometry collapses onto the paper. Voila! Instant chaotic hair balls.

To give the piece a little extra depth, every 300 frames (every 3 geometry collapses) the paper slightly blurs the image painted on it. Over time, the old content fades and blurs as new content is placed atop it.

Check the flickr image to see it full size. I will continue playing and at some point soon, I will post a video of the painting process.

I have been using Processing for over four years. FOUR! Weird, right? Seems impossible that it has been that long. But a quick check of the old Processing forums showed that I signed up in May of 2003.

Things have changed quite a bit since I first started with what was then called P5 (btw, folk, the ‘P5′ nick has been deprecated). If my memory serves, version 60 was the one I started with. Now it is up to version 134 and is so tantalizingly close to being a 1.0 release. There are dozens of user contributed libraries, tons of reference material, and a quickly growing user base.

In the four years of my Processing experience, the question I am asked much more frequently than any other is “how do I get started with Processing”. The answer is simple enough. Practice! Like with any other new language or methodology, the more you use it, the more comfortable you become with it and the more control you gain over it.

I wish I had a better answer. Seems dismissive to say ‘practice makes perfect’, but I really don’t know how else to explain my process. Generally speaking, I try to code something that is right outside of my comfort zone. Oddly enough, these self-made tutorials are how most of my projects get started. Wanting to learn about ArrayLists led to my experiments with particle emitters. Wanting to learn about texture mapping led to my first experiments with OpenGL. Wanting to learn about arcballs led to my first experiments with Quaternions. Actually, that last one is a lie. I HATE Quaternions! I REFUSE to learn Quaternions!!! But not as much as Quaternions refuse to be learned by me. Damn things are confusing!

With the Magnetosphere project, it might help to know that I have been working with that code (and getting a ton of help from co-workers and friends) for around three years. It started simply enough. I just wanted to make particles react to each other using the laws of magnetism to define their behaviors. But I stuck with the code. I returned to it every time I learned a new trick or found better ways to do old tricks. And so the code evolved.

When I think about how it looked when I started and how it looks now, I can’t believe how far its come. It just reaffirms the notion that practice does make perfect. Not that magnetosphere is perfect in any respect. I still see tons I want to do with it and there are plenty of tangents off magneto that are waiting to be explored.

So to answer the question of how to get started with a more concrete answer:

• Spend some time with the examples that come with Processing. If any of those examples intrigue you, figure out why they work. And then use them as a base for further study.
• Poke around in the forums. Many of your questions have already been answered. Search the forums for the right (or better) way to do something that you cant quite figure out.
• Get either of the following Processing books. Both have enough variety of content to get the beginner up to speed and keep the advanced user engaged.

Processing: A Programming Handbook for Visual Designers and Artists

Processing: Creative Coding and Computational Art

Starting to code in an unfamiliar environment can be a bit overwhelming at first. But thats the beauty of Processing. Getting started is surprisingly easy. My only programming experience before starting with Processing was Actionscript 1.0. I found that taking a Flash project and translating it to Processing was a fairly easy task. Here is a little Processing.org list about how Processing and Actionscript handle things slightly differently.

So thats it for now. Hopefully this will help orient those who are new to Processing. And in closing, please remember those tired clichés that became such overused phrases for a reason: there is truth in those little nuggets.

Practice makes perfect.
Rome wasnt built in a day.
If at first you dont succeed, try, try again.
The longest journey begins with a single step.
If wishes were horses, beggars would ride.

Okay, maybe not that last one so much.

Barbarian Group + Nervo = Awesome!

More often than not, the pipeline for a project gets overshadowed by the end result. The process of getting from point A to B is often overlooked because point B is just sooo damn sexy. But it doesn’t have to be that way. No really, it doesn’t.

A couple months ago, Nando Costa approached Barbarian Group and asked if we would help out with a project his new motion graphics company Nervo was working on for Fox Movies Japan. He showed us the boards and instantly we knew we wanted to collaborate because his vision for this project was quite beautiful and surreal.

What he needed from us was videos of flocking behavior. He had seen the previous experiments I have done with perlin noise flocking and thought it would work well for this project. All he wanted was a couple videos of flocking using a 3D crow (or is it a raven) he would provide. Simple enough. But given the tight deadline, the thought of doing a render and posting it and waiting for approval or changes and then implementing the changes then rerendering and reposting, etc… Well, it just didn’t make sense for this project. So we decided to try something different.

“Let’s deliver them an application.”

Using Processing, we started playing around with the flocking behavior to make it more customizable. The original version of the flocking experiment had very few controls and they had to be hard-coded. There was no run-time adjustment. This was the first thing addressed. Several new parameters were added. They included population density, gravity, drag, collision avoidance, flight range, camera position and tracking, and a few toggles such as tethering strings, floor plane, and bezier curves. Once the parameters were tweaked to the user’s liking, they need only to hit the spacebar and an image sequence of PNGs would start saving to the harddrive.

Processing made the delivery process as easy at it can get. Once completed, all we had to do was hit the ‘Export to Application’ button and Processing would generate Linux, Windows, and Mac applications. We delivered the application to Nervo, gave them some basic instructions, and waited.

The resulting work was fantastic!

The videos are posted at Nervo.tv. Look for the second and third from the bottom to see the spots that included the flocking renders.

After two days of rest and relaxation, I can now say with a clear and rested mind that Flash on the Beach 2007 was a great success. Many thanks to John Davey and his family and staff for putting on what seemed to be a very successful conference. The speakers were top notch, the atmosphere was welcoming and drinks were plentiful (thanks to Natzke and Elliot helping me embrace my Scottish roots one scotch at a time).

I was very impressed with the quality of talks at this conference. People seemed to, if you will pardon the out-of-character cliché, bring their A game. And there were a few of the usual folk whose talks I haven’t had the pleasure of seeing in the past. I was impressed and walked away feeling very inspired and happy to be friends with such a wide variety of talent.

Thanks again, John.