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

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.

I had a crotchety old man as a 2nd-year studio instructor. He was very adamant about the usage of the word space. He tried to tell us that space cannot be created (sometimes architects say that they “create spaces”), but all I learned was that it was very difficult to learn anything from crotchety old men.

It’s a matter of semantics, if you ask me. Creating space, defining space… whatever. Today, I am concentrating on fillling space. There should be no controversy there. Even while he was yelling about space, my professor was certainly occupying some.

I’ve been thinking of trying a space-filling algorithm for some time now. They’re quite simple, and quite useful. Jared Tarbell made a nice one a few years ago: Emotion Fractal. In the world of data analysis, they are commonly referred to as Treemaps.

Here’s what it will look like: The final result (click to activate, then press the spacebar to add boxes)

And here’s the source code: Space-filling classes

Let’s get started…

Read more…

Alright I’m back. Still got a couple of other projects going on that are sucking me away from the tutorials, but I figured that I should get at least one tutorial up this week to let everyone know that I’m still alive. As I mentioned, I’m going to dive into the topics of video capture and computer vision in Processing.

Today I’ll present three variations on a theme (it’s like This American Life!). Today’s theme: Mapping video on to irregular polygons. Or, as I like to put it, cutting out pieces of video as if you’re using scissors and paper.

Since these applets will all require a webcam, I’m not going to post them inline on the page. I’ll scatter some images about the page and point you towards the required classes (they’re after the jump today).

You’ll have to paste the thing into Processing to see live results. Note that you may need to configure the line that finds your webcam, although this should work for most situations:
//initialize camera
String[] cams = Capture.list();
println(cams);
//you may need to change which camera in the list it chooses below
cam2 = new Capture(this,w/2,h/2,cams[0],fr);

What you’ll learn

• Filling a polygon with an image instead of a color.
• Drawing polygons and removing them with a right-click.
• Using an image’s pixels[] array.
• A few other tips and tricks to working with video capture in Processing… like using two video streams simultaneously.

Ready?

Read more…

It seems that everyone who has ever programmed in Java has, at some point, created a variation on John Conway’s Game of Life. Well I wouldn’t want to break with tradition. Here’s mine.

This is just a code dump, but the applet is so simple that it doesn’t really require a tutorial anyway. I’ll paste the code directly into the post below, but if you must download a zip file, you can click here.

Here’s the demo: With motion blur / Without motion blur
(Press spacebar to pause, toggle cells by clicking them with your mouse, then press spacebar again to animate.)

My take on it

Like I’ve mentioned before, the motion blur trick is a little tired. But the idea I had with this applet was to use the automaton to generate some interesting 8-bit-esque texture maps. Since we’re wrapping the cells around the edges of the applet, a screen capture of any frame can be tiled seamlessly. The example above was made from a 40 cell x 40 cell square, reduced to be a 40px x 40px tile, which was in turn defined as a pattern in Photoshop and used to fill the image.

Although the example above is made from a tiny tile, I think it looks pretty nice. Interesting wallpaper, if only conceptually. Certainly not meant to be used for realistic bump mapping or anything.

Want the code?

Read more…

Sunday is looking a little overcast, a little gloomy, and a lot like a good day to tackle a complicated tutorial: Voronoi diagrams.

I’m sure you’ve seen them before. Given a set of points, a Voronoi diagram defines a series of cells surrounding each point. Each cell contains all points that are closer to its defining point than to any other point in the set. Subsequently, the “borders” of the cells are equidistant between the defining points of adjacent cells. I’ll give you a diagram later.

I haven’t used my Voronoi class in an exciting applet yet, but it has plenty of uses… mostly functional, some aesthetic. Golan Levin did a series of portraits using Voronoi diagrams. More commonly, they’re used in mapping applications.

But first, the moment you’ve all been waiting for: The final result

And how we get there: Voronoi classes

More introduction

Say you have a map of your city, and on it you have located a set of points representing every fast food restaurant. Creating a Voronoi diagram from these points would enable you (on your walk through the city) to know which restaurant you’re closest to at any given time. Of course, an application that simple could be solved more efficiently via other methods, but let’s raise the stakes a bit. What if you want to know the percentage of your walk that will be closest to one particular McDonalds. Suddenly, without a Voronoi diagram, this is tricky. With a Voronoi diagram, however, it’s a simple matter of intersecting the line that represents your walk with the cell that surrounds that particular restaurant.

Voronoi diagrams can also be used to make maps, not just analyze them. Say you have a set of points that represent air quality sample locations. To quickly generalize the sample points into a local map… bam! Voronoi diagram!

There are other more abstract information processing uses for the diagrams as well, but I’m not going to get into them here.

A few more notes

• The most efficient way to create a Voronoi diagram is via Fortune’s sweepline method, which reminds me of how police departments use lines of people to do a walking search of an open area. We’re not going to use that method here. The math is less intuitive.
• The dual graph of the Voronoi diagram for a set of points is called a Delaunay triangulation. It’s a pretty great way of generating a mesh from a set of points, because it allows for an efficient non-uniform distribution of detail.
• All Voronoi cells are convex hulls, assuming that the boundary we are working within is a convex hull. This will be important.

Still alive?

Read more…