Below is a 60 second render from the data set captured from this drawing.

Aesthetically, this is completely off the mark from what I’ve got in my mind’s eye. But in doing each of these exercises, I’m getting more familiar with C++ programming and openFrameworks and the various add-ons that exist out there.

And I’m also refining my general goals for the first set of “pieces” I want to create with this Flow system:

1. Show the energy and motion of each stroke. This needs to be visible even in a static render.
2. Avoid random as much as possible. The work needs to exhibit clear intention.
3. Create something dimensional, structural.
4. Work within “moments” of the data set, not its entirety.

I’m going to try to make sure whatever it is I come up with adheres to these main goals for now.

This is so stupid.

But it’s like a black triangle for me. It represents the following:

• I’ve somehow actually retained all I learned about C++. In fact, I see the language even clearer now, bizarrely.
• I can now make pointers to pointers to pointers of things and still get to the most deeply-nested data in that relationship (something I absolutely could not wrap my head around a couple months ago).
• I successfully started using memo’s MSAPhysics library for openFrameworks, which isn’t so different from toxi’s Verlet physics engine in his library.
• I can make stuff look like sperm.

But seriously, this sperm thing is moving based on the data captured in the drawing from a few nights ago.

So, I’ve got the data. I’ve got the basic framework for traversing and manipulating the data. And I’ve got an idea of what I want to focus on (finally). And no, I’m not focusing on making stuff that looks like this.

But tonight was a good start in a solid direction.

Continuing from yesterday’s progress, this time around I’m visualizing the data set as actual strokes (ribbons) and trying to show amplify their velocities by increasing stroke width. It’s a basic drawing trick that you see all over the place.

I guess I’m trying to wrap my head around the data set right now. I have a lot of ideas about where I could take this, but I’m not quite sure which one to pick.

Today I finished up a drawing — a bad self portrait. This is the first piece I’ve used as a data source for the new Flow Receiver capture system. It was drawn over a couple days / sessions. As soon as I finished it, I immediately exported the captured data, a 9MB XML file consisting of about 150,000 points.

Then I made the simplest visualization of the data I could. Using openFrameworks and the TinyXML C++ library, I plotted a semi-transparent circle for each point in the data set. You can see the output rendered here:

Well, that itch has resurfaced, and I realized I was making things way too complicated. This time, I’ve turned to using some open source tools for the data capture portion of the project. Components include:

• Computer
• Webcam
• Community Core Vision (CCV)
• Color Tracking Patch for CCV
• Processing TUIO Client API

It’s actually really simple to get set up. Here’s a little demo of how it all comes together.

Next steps include making a client to listen for the TUIO data generated by CCV. I’m probably going to opt for an AS3 AIR client, since it’ll be fastest for me to create. Then create a web application that captures and stores this data. This I’ll build in CodeIgniter, again, since it’ll be fastest for me to create in this environment.

I’ve got a lot of stuff on my plate this month, and I want to participate in this month’s NaNoDrawMo on top of it. So, we’ll see where things net out.

Some progress has occurred. C++ is becoming clearer. Here’s what progressed in the first couple images:

1. I created a Tween class for animating values. It’s modeled after CASA Lib’s Tween class. I’ll probably be releasing it to the community soon.
2. I hooked up my MIDI controllers to the piece, so I could have more control over tweaking values. I’m using a great add-on for openFrameworks called ofxMIDI.
3. Along the way, I learned how to implement openFrameworks event dispatchers and listeners. (Hint: search for “poco events” in the openFrameworks Wiki if you want to learn how.)

In doing all this, I was able to trigger light movements with a MIDI controller. I used my M-Audio Trigger Finger’s velocity-sensitive pads to animate two lights. Hard tap = fast movement.

+ View hi-res on Flickr.

Here’s a video of the animated lights in action. Please excuse the stutters; while this does run at 30fps in realtime, SnapzPro isn’t able to keep up because of the CPU usage of the piece.

Now after all this, I came to realize that I really wanted to be able to loop the Perlin noise that was creating the height map of the tube. Because, though you can’t see it, there’s an awful seam on the side facing away from the camera. By looping the noise, I could reliably look at it from all angles.

After some research, I came across a great library called libnoise. Took me a little while to get it to compile, only to realize that while it did the job, it dropped my framerate from a respectable 45fps to 9fps. Definitely not suitable for realtime noise generation.

So I went back to the fastest Perlin noise generator I could find (this class from John Ratcliff), and I decided to live with the seam in the back.

Amidst all this, I also stumbled upon this awesome blog post about Twisted Architecture. I thought it would be cool to implement something like that in my piece. So I did. But then I forgot about it.

It was only when I started twisting the “twist-associated” knob on my MIDI controller that the damn seam actually came to life. So, you can see how it starts to play out in the rest of the images here:

+ View hi-res on Flickr.

+ View hi-res on Flickr.

+ View hi-res on Flickr.

+ View hi-res on Flickr.

Also, in those last couple renders, I added a convex mesh to the background so that I could start incorporating background colors properly. Moreover, so I could get some light-generated gradients happening. More to come… more to come.

+ View higher res image.

For those of you following me on Twitter today, you witnessed the pain I endured under the cruel, icy grip of OpenGL.

That pain: learning how to compute vertex normals.

But eight hours later, I managed to pull it off with the help of the OpenGL SuperBible, this thread, and this article. Oh, and this amidst porting it to C++ (openFrameworks) for maximum control and speed.

Along the way, I learned how OpenGL lighting works. I was having such a hard time with it before because my form didn’t have its surface normals nor its vertex normals correctly calculated. So light wasn’t bouncing off it the way I expected. Now it’s all making good sense.

My next steps will be adding interactivity. I’m going to try to use my HP TouchSmart for touch input along with its webcam for vision input. Separately, I’ll try to make some sort of music visualizer out of this — or at least make it audio-responsive.

Check out a video from today: