Don Havey

In environmental planning, there’s something called a windrose which displays the intensity and frequency of the wind at a particular location, in relation to the cardinal points.

I decided the other day (after once again finding myself explaining what my workload this year has been like) to create a “workrose” that displayed my workload over a specified time period.

I built this thing pretty quickly in Processing. It loads an XML file that contains all of the projects that I’ve worked on this year and dates/events/milestones for each. The data is arranged in radial fashion, beginning with 365 days ago (located at 12:01 on the clock), and progressing clockwise to the current date (at 12:00).

I think it gives a nice overview of how projects are progressing. In addition to windroses, inspiration came from electron diagrams, with each project’s radius determined by its phase. Thus, as a project moves from concept to completion, you’ll see that it jumps from an inner position to an outer one. The specific phases are defined as follows:

1. Concept, proposal
2. Design development
3. Execution, fabrication
4. Revisions
5. Maintenance

When a project is completed or canceled, it gets a green or red dot, respectively.

So you can see that the first part of my year wasn’t bad, then things became periodically crazy, and finally reached a pretty consistent level, which (fingers crossed) show no signs of stopping… there’s a lot of work going on and a lot of work on hold as well (the dotted lines). Most of my canceled projects die in the concept phase… usually meaning that a proposal was rejected.

Right now, most of my work is web-based (or at least digital), but I can imagine this type of diagram working for all types of creative processes. See ya.

** UPDATE: I put the Processing version of this up on my newly redesigned portfolio. **

Well isn’t today just the most amazing day of self-motivation ever. This is project #3 that I’ve uploaded. It must be this new Vimeo account… I’m addicted to sharing video now. Here’s the video clip: Voronoi plateau from Don Havey on Vimeo.

This quick sketch used my Voronoi diagram class to create a landscape of plateau-like structures derived from an image. The image is “chiseled” into a Voronoi diagram, then extruded according to each cell’s brightness. The diagramming process is interesting, the result is… meh. It makes high-intensity images a little more intense… but that’s about it.

On a related note, I discovered that when overlaying a number of iterations of Voronoi-diagrammed images in Photoshop with an exclusion filter, the results approach the original image in terms of resolution. Here’s an example:

Notice that the red image is washed out a bit, but is much more resolved than the others… interesting.

Anyways, here’s the source code (get your own images this time) and a demo. Click to give the applet focus, then use the arrow keys to navigate once the diagram is finished. Enjoy.

Here’s a preview of a drawing tool that I put together recently. I hope you love it.

It basically projects the shape that you draw on to a randomly generated terrain, then creates the objects that would cast that shadow at a certain time of day. Now that I’ve finally jumped on the Vimeo bandwagon, I’ve uploaded a video of me drawing with the applet: Shadow casting strips from Don Havey on Vimeo. There’s also a link to an in-browser demo below…

I’ll explain the thing in depth some time, but the concept is pretty simple. My new Terrain class handles the projection of points on to its surface using the Plane class’s get_line_intersect_point() method. The drawing is projected downwards, then those points are in turn projected on to vertical planes that coincide with the lines that originally split the drawn shape.

Here’s the source code so far. Note that there’s still a big bug with it, which is a problem integral to the Polygon class’s split() method. If a (vertical) split line intersects a drawn polygon more than twice, it will not split it. So you can draw vertically-aligned mountains, but not horizontally-aligned ones, or awesome fish with giant mouths, as shown in the diagram.

I think the problem is fixable, but I’m probably not going to have time to revisit this one for a while.

I’ve uploaded a (small) demo here: Shadow casting strips, in progress. Click the applet to give it focus, draw with the mouse, then rotate the thing with the arrow keys. Pressing Enter/Return will clear the drawing board.

See ya.

I’m sure this has been done before, but after being inspired by Robert Hodgin’s Audio Driven Landscape, I decided to use my new Terrain class to make something sexy and moving.

I’m not sure if I ended up being successful with the sexiness… but this thing sure does move. What I’m doing here is mapping a video on to a terrain, with the terrain’s depth based on pixel brightness per frame. When you load in a movie–taken, say, from a train–you get a pretty interesting warped image. It adds a level of depth that I wasn’t expecting. It also has a interesting cloth-blowing-in-the-wind thing going on (without fancy Verlet integration)…. Looking from near ground level corner-to-corner is the most exciting.

No tutorial on this one, but the source code is here (includes the sample video)… and I’ve embedded my very first Vimeo video below.

A few notes:

• The Terrain class is still pretty young… and not optimized for this type of thing. It uses a relatively slow iterative smoothing function to avoid spikes.
• The points that define the terrain should be eased between new coordinates, rather than just moved. That would make this whole thing a lot less ADHD. It would be easy to do… the easing functionality is already built into the Point class.
• If you download and run the thing, click on the applet to give it focus, then use the arrow keys to rotate the terrain. Holding down any mouse button toggles the display of the movie as a texture map.

Video terrain from Don Havey on Vimeo.

Let me know what you think!

This post is a follow up to Reverse engineered metamorphosis – Part I.

I managed to spend a little time getting the background effects in line yesterday while on the train. I’m up to just over 3 hours work time on this, so I think I’m on track to wrap it up in under 6. It’s been a good exercise because it’s forced me to focus on creating something specific – not just another component.

Once again, I’m not going to talk much about the progress made. The background images have their own class: the aptly named Graphic class. All they do is fade in and out and render themselves. The constructor function is passed a “frames to live” value, which determines how long to wait before fading it out.

Here are some more bullets:

• Before positioning and rendering each Graphic, we make sure to check that they are still visible… otherwise we’d be spending lots of resources on images that can’t be seen. Transparency is handled with the tint() built-in.
• Once every few frames, the graphics are placed behind the vine using the vine’s current xy-coordinates. So the graphics always appear to be exploding into existence just behind the vine.
• The images themselves were mashed together quickly from Photoshop’s “nature” pattern fills, given a layer mask each, then saved as transparent pngs. Which image is loaded is determined by a simple “if(random(chance)<1)". You'll notice that I'm favoring the green image.

That’s about it for now. The applet is still running at an easy 30 fps on my 3-year-old laptop, so that’s good. Here’s the source code. View the results in Processing. I don’t feel like uploading them today, plus, the image loading really drags in P3D and OpenGL still hates being run within an inline applet. If you’re desperate to see this in action, take a look at the live example from the previous post.

See ya.

So Glenn Marshall’s metamorphosis video has been getting some rave reviews lately. The video consists of a 2d recursive vine-like growth, lots of butterflies, and some nice finishing effects. It is very pretty.

Unfortunately, Glenn’s been a little – hmm – reluctant to share his code. That’s a pity, because, well, Processing is open source, and it’s helpful to the development community when the results generated with Processing are fed back into the system, allowing beginners to grab some pre-built examples, and veterans to compare notes and techniques. In Glenn’s defense, this seems to be his livelihood, and I imagine he’s hesitant to go open source with us because he’d like to ensure that he gets his just rewards.

Well of course you know where I’m going with this. What better challenge than to reverse engineer such a lovely animation. Glenn is a self-proclaimed beginner in Processing (although you certainly wouldn’t guess it from the results). I am a (now) self-proclaimed non-beginner-non-veteran in Processing, so to add to the fun of reverse engineering this thing, I’m going to up the ante and say that the final result must:

1. Run in real time. Let’s say a minimum of 15 fps on my good desktop. (Glenn notes that it took 4 hours to render the HD version.)
2. Not look like Glenn’s creation. I don’t want to infringe on anyone, so no lookalikes, but the result must have the same basic elements: a meandering camera, a recursive vine-like growth sequence (not unlike my Lettertree tutorial), some layering, maybe a particle system or two, and some interesting background noise. No butterflies… I’m not a big fan.
3. Be OOPed on top of my existing base classes.
4. 6 hours total work time on this.

Today I’m posting my first dabble. The source code is structured similarly to the rest of my tutorials. I was able to quickly get the springy camera and “stalk” of the vine working, which by the way is not unlike Yellowtail, minus the user input and cool motion.

I’ll get into depth and code at a later date. For now, here are some bullet points:

• The stalk is essentially just a springy Polyline, eternally chasing a random Point, which moves every time the stalk comes within a certain distance (see the variables at the top of the Vine class). The Polyline is limited to a configurable number of sub-Segments… thus the disappearance of its tail.
• The trickiest bit to this first attempt was simply to make the stalk’s “tails” to look nice, and do that cute little growth thing. The variables relating to that are of the “th” variety in the Vine class.
• Notice that there’s no recursion yet, but that will just be a matter of adding children to the Vine class.
• The camera movement is super basic: a very-low-dampening spring with a very slow chase rate… giving it that “oh my god, I can’t believe I have to keep chasing this point, I’m so tired” feeling.
• Remember that since most of my core classes rely on 3d coordinates, I’m limited to rendering in OpenGL or P3D… which means that the smoothing won’t be quite as slick as in the original.

Here’s the source code. And finally… the results!

Enjoy. Feedback welcome. Stay tuned for part two. Oh an I wasn’t lying the other day about a good Particle tutorial coming up… I’ve got it written up, but am working on a few examples to accompany it.