+ 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.

Spent a little time today on another tangent. One thing I didn’t like about those faux-cityscape renders was the fact that you completely lost all sense of the originating data. This isn’t necessarily a bad thing, but part of the reason I developed this whole system was to bring forth the energy and motion that actually went into creating the “seed” drawing.

So I took a step back and created a new renderer that let me isolate the individual “strokes” that were captured during the drawing session. In these renders, I’ve isolated three strokes; each has a unique color. The peaks in the height are derived from the relative velocity of a stroke at a given snapshot in time.

In Cinder, I created a GL scene that has a positionable camera and lets me page through each stroke. Then I can tap a key and dump out that stroke’s Sunflow scene data to the console. Along the way, I learned how to use the TriMesh class in Cinder. It made dumping the Sunflow scene data easier, since it really parallels Sunflow’s “generic-mesh” type.

The render at the top uses three sphere lights, a basic diffuse shader for each object, and Sunflow’s path-tracing global illumination system. The render below uses the Sunflow sunsky light, a foggy Phong shader on the three strokes, and the “fake” global illumination setting in order to get some vague ambient light. I started discovering that there are a lot of possible combinations for lighting in Sunflow — almost an overwhelming number.

Next I’m gonna try a different drawing technique for rendering these strokes.

+ View large.

So, you guys saw a still like this from the last time I posted. Basic OpenGL stuff with a couple lights and some simple cube-like structures. Immediately after getting that far, I wanted to get this stuff rendered in Sunflow. Now, Sunflow is an open-source global illumination renderer built with Java. But at it’s core it’s a ray tracer, which basically means you’ve can make stuff that looks real because it simulates real light rays. Moreover, it has different kinds of cameras… and one of those cameras can render a pretty realistic depth of field and even bokeh.

Here’s the thing, I’m working in Cinder, which means I needed to write something that took my geometry and dumped out a Sunflow Scene File (.sc). But first, I had to figure out how the hell to get the OpenGL viewport projection matrix mapped correctly to the Sunflow camera — and moreover, I had to figure out how to take all these OpenGL transformations (rotate, translate, etc.) and turn them into something Sunflow understood.

Today, I finally wrapped my head around the two main OpenGL matrices. I’ll go into the specifics for folks that are interested in a later post, but the point is this: I can write code and render stuff using OpenGL in Cinder, press a key, and dump out all my Sunflow Scene File data (to the console for now).

Here’s what the above image looks like when it’s rendered with a couple point lights and a pinhole camera:

+ View large.

And here’s what it looks like with ambient occlusion (and no point lights)!

+ View large.

But that stuff’s not too interesting. What’s interesting is what happens when you start playing with the sunsky light and the thinlens camera:

+ View large.

And here’s what happens when you play with the Phong shader and too many lights and don’t want to tweak things until they actually look good!

+ View large.

All of this has me excited because now I can move quickly with framing and general colors and textures and such in OpenGL, then get super-nice renders from Sunflow. Yay open-source!

Spent most of today trying to pull off an idea that I had in my head since the last time I wrote. The idea came to me as soon as I saw a piece called Ephimicropolis by contemporary artist Peter Root. Most of his work is pretty compelling, visually dense, and labor-intensive.

But I thought, hey, I love doing stuff that creates visual rhythm with similar shapes and iteration (see here and here and here and here). And I’m really into this idea that my captured motion data can be turned into something structural, becoming an input stream for a different set of dimensions. I’m almost literally painting an entire world here.

Anyway, now I need to actually start playing with how this thing looks. With lighting and the camera and texture and distribution of elements. Oh, and all of this was built using Cinder.

Here’s a time-lapse render, so you can see it build up:

Here are some of the in-progress renders that happened along the way as I was stumbling my way through all this:

+ 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 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: