+ View large on Flickr.

+ View large on Flickr.

And tonight, got those vertex normals calculated. Much easier this time around — probably just because I understand it all conceptually now.

I’m really enjoying how this stuff is looking. Finally, I feel like this digital generative work feels as organic and alive as the source of the data itself. I can’t wait to add the UI controls for “sculpting” the composition and colors… and can’t wait to add more structural elements.

Now that I’m unpacked and settled in my new apartment — and since I have a 50 minute presentation coming up at FITC in just over a month — it was time to gain some momentum and get back on top of this stuff for Flow.

I’ll be the first to say that these definitely bear a strong resemblance to Evan Roth‘s latest Graffiti Analysis video called “Graffiti Analysis: 3D” — because they do. And because I was definitely inspired by it (just like I was inspired by the original project when I first saw it back in 2005 at FITC).

But this is just one layer of what I’ve finally settled on for my first real “pieces” to come out of this Flow project. I’m focusing on isolation of a few strokes, creating a strong composition, and building something structural — almost architectural — out of these energetic moments of frozen time.

The hurdle today was learning to draw a tube in space…this took the better part of the day. I would’ve used the GLE Tubing and Extrusion library, but unfortunately, that has dependencies on GLUT, which Cinder does not use. And I didn’t think that I’d be able to vary the thickness of the tube over its length, so I decided to try it from scratch. And we’ve got [decent] success. I do want to implement proper per-vertex normals to smooth the sucker out some more. I think I’ll be able to rip the per-vertex normals code from the old Noise Tube experiments, since it’s ultimately the same mesh structure.

And yeah, this is all OpenGL still. Once I get the other structural elements in place, I’ll be writing some sort of Cinder Block for creating a Sunflow scene / scene file and rendering this stuff out in Sunflow. The final aim is to create some prints from this thing. I’m giving myself till the end of the week to wrap up this visual direction, so I can focus on refactoring and documenting all the behind-the-scenes Flow applications for open source release around mid-August.

You can see the full set of this first bunch of renders in this Flickr set.

+ View large on Flickr.

+ View large on Flickr.

+ View large.

+ View large.

Lots of new stuff learned over the weekend. Here’s a summary:

• Really understand basic OpenGL lighting now.
• Understand how to do basic material coloring now.
• Learned how to texture a quad!
• Starting to learn some things about the Boost C++ libraries.
• Finally remembered that OpenGL is a state machine.

I think I actually (finally) have enough know-how to execute what I’ve got going on in my head. It’s going to require some refactoring of code, but I don’t feel like I’m up against an unclimbable wall anymore, which is precisely how I felt by the end of the day on Sunday.

I still think this looks boring / uninteresting, but it’s just another step closer and a lot of lessons learned.

Here’s a video render of what it looks like in realtime:

Update on 04-29-2010: The C++ framework that I’m using has just been released to the public. It’s called Cinder. Big ups to Andrew Bell, Robert Hodgin, and The Barbarian Group for all the time and effort put into releasing such a powerful and fun open source framework for creative coding!

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 a representation of the 180,000+ points of data that were captured during the processing of making my last drawing. They’re quick sketches done with Processing and the toxiclibs Processing library (specifically for the Verlet physics engine).

The first step here was to create something cumulative, just so I could see the data over time. The end goal (originally) was to create a data renderer that created a static piece (or pieces) that could stand side-by-side with the original drawing, like a diptych. But embedded in that goal is an attempt to bring forth the energy and motion that went into the original drawing. That’s why I created this whole system in the first place.

I’m not there yet, but I think you need to swim in the data for a little bit before you can get a sense of what it really is.

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.

As I prepare for my new job which starts on January 4th, I’m taking some time to learn Derivative’s TouchDesigner. It’s a realtime procedural 3D / compositing tool. Well, it’s actually so much more than that, but it’s very difficult to describe.

Anyway, I’m trying to learn it. And I’ve found the best way to learn stuff (for me) is to take something I’ve already made and try to recreate it in the new environment. So, that’s what I’ve started doing here. I’m not sure how much further I want to go with this, but it’s nice to know that I could pull this much together after about an hour’s worth of work.

This software is terribly powerful, and more and more documentation / improvements / tutorial videos are being added all the time. It’s making me very excited about 2010.

+ View the piece on Flickr.

+ View the piece on Flickr.

+ View the piece on Flickr.

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:

I’m continuing the Perlin noise saga. The last thing I did was port the Noise Column project over to Processing and openFrameworks.

This time I wanted to add some actual volume — not just perceived volume — to the form. These are just some initial tests that you see above. I’ve got a ton to learn about lighting and optimization and matrix transformations. Robert says I need to use “per-vertex normals”. I say “OKAY!” Hopefully I can start adding some of these things over the next couple weeks and really use this project as a general learning tool.

For now, I’m developing all this in Processing using the PGraphicsOpenGL renderer. I’m not using any actual OpenGL calls directly; I’m only using the Processing API. One little discovery I made yesterday: PeasyCam turns out to be a really sweet little camera library for Processing. Adds mouse control over the camera with a single line of code.

The ultimate goal of this is to create two different pieces. One will be a rendered motion piece. It probably won’t have any audio and will function as an ambient looping video. It will be submitted to this call for entries: Flow Interrupted.

The second piece would actually be interactive. I’m going to toy around with camera, audio, and touch as discreet inputs (all separately). This will give me a chance to play with the new HP TouchSmart PC I got. So you could consider the second execution to be more of an interactive installation piece. And that’s going to be submitted to this call for entries: FLUID Interactive Digital Art.

Check out some of the stills:

+ View larger Image.

+ View larger Image.

+ View larger Image.

+ View larger Image.