Archive for the 'ICM' Category

Thinking About Toys

I’ve been thinking more about games than I have about toys recently, which I intend to remedy right now. Every Tuesday for the last seven weeks, I’ve sat in a room with twelve or so other people talking very seriously about what makes a good toy. I thought I remembered all my toys and knew for sure which were my favorites, but the conversation dredged up fond memories of toys I’d all but forgotten. My blue plastic Cinexin projector, for instance:

My other favorite toys included Magia Borrás, my Exin castle, my venerable STX 4X4 Scalextric, Lego Technic, Star Wars figures and vehicles, Transformers (especially Optimus Prime and a tank/plane triple changer whose name eludes me), and the contents of my toy bucket taken as a whole. I’m sure I’m forgetting something, but those are the ones I remember playing with the most.

And they all share at least one of the following characteristics that set them apart from sucky toys:

  • They put you in control
  • They gave you a grown-up ability
  • They allowed you to hide or disguise yourself
  • They lent themselves to the invention of stories
  • They caused something to happen or move
  • They impressed or surprised your friends, mom, or other adults

Which is why, I think, there aren’t that many new toys. Sure, Toys R Us in Times Square is brimming with an amazing assortment of toys, but most of them are just repackaged, rebranded, carefully gendered versions of a dozen or so archetypal toys: the doll, the science/discovery toy, the vehicle, the teddy bear, the puzzle, the art/creative material, the noisemaker, the building block, the board game, the bicycle, the costume, the ball, the tent, the weapon, the “learning” toy, the miniature [insert adult locale or situation], and the videogame.

Which is also why I stuck close to a traditional toy when I started designing.

Bugging out, now with sound!

In preparation for my return to school on Tuesday, I wanted to ease myself back into the swing of things by playing a little with Processing, so because I never got around to playing with sound last semester, I added some sound effects to my cockroach sketch using Minim.

Check them out here.

Shoots and Leaves

The online version of Shoots and Leaves is here. It uses the mouse and keyboard instead of a Wiimote.

BranchesFor my ICM final, I teamed up with the lovely and talented Michelle Mayer, and together, we set out to create something beautiful out of something repulsive. My initial idea to cause red flowers to explode in a messy splatter all over a screen if you aimed a gun at your own head while standing in front of said screen. That seemed derivative (that t-shirt of Itamar’s with the birds flying out of the guy’s head) and more of a PComp problem, so we restated the challenge as creating life out of death.

The idea became to create an algorithmic seed that once planted, would grow on its own in an unpredictable and unique manner. We planned to project onto a mannequin wearing a white shirt and shoot at it with a Wiimote. But instead of drawing blood, our shots would draw flowering vines. Not to get too meta-geeky here, but the idea and its visualization are more than a little reminiscent of Project Genesis in Star Trek 2: The Wrath of Khan

When creating the effects for the scene, Industrial Light and Magic had to invent a bunch of graphic technologies. And good old retinal scanning, oh brave new world that has such technologies in it!

Anyway, we wanted to do something similar. Our first thought was to use input from a Wiimote to trigger a series of video elements we would have created ahead of time, but Processing’s limitations when dealing with large numbers of simultaneous video clips, the prospect of spending even more time in After Effects, and Dan Shiffman’s encouragement to seek out a programmatic solution convinced us that we might as well program life. Our initial proposal is here.

Creating Branches

The first task we tackled was branching. If our flowering vines were going to be at all realistic, they would have to unpredictably spawn other branches as they grew. This was a matter of setting a series of necessary preconditions for branching and a probability of its occurrence once those preconditions were met. Then all we had to do was pass a point on an existing branch as the origin for a new branch instance. That actually wasn’t so difficult, thought initially, all the existing branches would branch simultaneously and with ever increasing frequency until the whole screen filled up exponentially. Adding a variable in each branch to keep track of its lifetime and randomly changing it upon a successful branch solved that.

Curved Paths

The next challenge was getting the branches to move in nice curvilinear paths that were nonetheless irregular. We spent an entire day playing with sine functions but to no avail, our vines looped like drunken rollercoasters. The solution occurred to me right as I was going to bed one night. Taking my cue from Craig Kapp’s brilliant gravity simulator, I thought, why not have a bunch of balls that exert a force on the growing branches bouncing around invisibly in the background? Have three, say, and when a branch is born, assign it to follow one randomly. Make the force proportional to the square of the distance and it should yield random-looking curved paths. And it did!

Aging: A Perennial Problem

Next we decided we wanted our branches to thicken with age, as they would in real life. This we accomplished by storing each branch’s last fifty x and y positions and then drawing fifty successively larger semi-transparent ellipses at each. This creates the illusion of a thickening that follows the branch’s sprout. It also slows things down a fair amount because of the memory it requires.

Switch Cases and Flowers

Our final design step involved implementing flowers and leaves (and little twirly tendrils which in our multi-day programming orgy we never quite figured out). Since the basic conditions for branching are no different from the conditions for sprouting leaves or flowering, we implemented a switch case that favored leaves:

          if (b.check()){  // If a branch hasn't just branched
            if (b.branchcount < 20) {  // and it hasn't already branched more than 20 times
              int chance = round(random(0,3)); // pick one of the following cases randomly
              switch(chance) {
              case 0:
                b.branch();  // spawn a new branch
                b.branchcount++;
                b.lifetime = -b.branchcount * 200;  // delays the time its going to take for the next new sprout from the same branch
                break;
              case 1:
                b.flower();
                b.branchcount++;
                b.lifetime = -b.branchcount * 200;
                break;
              case 2:  // two leaf cases to ensure more leaves than flowers and branches
                b.leaf();
                b.branchcount++;
                break;
              case 3:
                b.leaf();
                b.branchcount++;
                break;
              }
            }
            else {
              branches.remove(b);
            }

          }

We addressed several interesting smaller problems (rotating the leaves using the arctangent function to ensure that they grew according to the direction in which the branch was moving, implementing Wiimote control, and the eventually discarded use of real images of leaves and flowers instead of programmatically drawn ones) in Encroachment, which is documented here.

Here's Michelle showing the project on a wall at ITP:

Encroachment: The Buggiest Software on Earth!

EncroachmentEncroachment was a study for my ICM final that actually turned out to be pretty cool on its own. The online version, which uses the mouse and keyboard instead of a Wiimote is here. Play with it!

I hate cockroaches. But they do lend themselves to creepy, jerky motion, which is exactly what I needed for this particular experiment. I wanted to do two things in a simple sketch form before porting them over to Michelle and my flowering vines:

  1. Orient the cockroaches correctly along their direction of motion knowing only their current x and y positions and those one loop previous.
  2. Get the Wiimote working reliably.

Orienting the roaches was accomplished through trial and error, and there still seems to be some directional ambiguity when certain roaches are moving at ambiguous angles that given my code and slight variations yield arctangents 180 degrees from each other, causing the roach to flash and turn manically. Because the effect conveys a kind of skittishness that I associate with roaches and adds to the program’s overall creepiness, I didn’t try to correct it.

This is the code:

void display() {
    float slope = (y1-y)/(x1-x);
    float theta = atan(slope);
    pushMatrix();
    translate(x+40,y+50);
    scale(size);
    if(vx<0 && vy>0) rotate(theta-PI/4);
    if(vx>0 && vy>0) rotate(theta+PI/4);
    if(vx>0 && vy<0) rotate(theta+PI/4);
    if(vx<0 && vy<0) rotate(theta-PI/4);
    image(lilroach,-150,-197);
    popMatrix();
    x=x1;
    y=y1;
  }

 
The Wiimote

Getting the Wiimote working with Processing is not terribly difficult. It does, however, require a number of downloads and tweaks. First thing, you need to install the oscP5 library for Processing which allows it, among other things, access serial information over Bluetooth from the Wiimote, which as luck would have it is a Bluetooth device. It’s available here. Then you need to install the interface that allows the Mac and the Wiimote to speak over Bluetooth. I used darwiinosc by Andreas Schlegel which can be downloaded here.

Once both of those are installed, you simply run darwiinosc, connect the Wiimote by holding down buttons 1 and 2, and you should start to see the accelerometer readings graphed in the console. To get Processing to recognize the Wii, you need to import oscP5 library and set up the Wiimote objects you’ll be using in your sketch (buttons, tilt, IR, acceleration, etc). There is clear and exhaustive example code included with the library.

Two things that did take me a little while to figure out were the syntax for getting the buttons to work and the IR tracking. The first two lines of the following code were confusing the hell out of me until I realized that this function contains both the onPress and onRelease actions and that the eponymous boolean variable tells the function which to execute. This is how I got the Wiimote to vibrate only when you pressed the trigger:

void buttonA(int theValue) {
    buttonA = (theValue==1) ? true:false;
    if (buttonA) {
      roaches.add(new Roach(trueX-100,trueY-137));
      forcefeedback(true);
    }
    else {
    forcefeedback(false);
    }
  }

The Wiimote is an infrared camera that can track up to four separate infrared LEDs. I’m lazy and only used one, but that did give me kind of a lopsided motion that I had to account for with hard-coded and totally inelegant adjustments. The IR function stores twelve variables in an array, the x and y positions and relative size of each of four possible LEDs. I just used the x and y position of one in a battery-powered sensor bar that I think came from Game Stop, as distance from the screen was not a concern.

Wii GunAfter that was working, all I had to do was find a gun attachment for the Wii that felt enough like a real gun to conjure the visceral emotional connotations we needed for the final project (the realism of the gun for the purpose of creating and killing roaches seems beside the point). This one, which cost about $15, has an ingenious little piece of plastic that slides along the top of the remote and depresses the A button when you pull the upper trigger and a lever on the underside to press the B button when you pull the lower trigger. Perfect!

And here it is projected up on the wall!

Organic Automata, Or Contemplating Countless Hours of Coding

For our ICM final, Michelle and I want to make organic creepers using Processing. I’ve tried to explain the idea to a number of people, but this video does a better job. Pay attention only to the black branches:


Metamorphosis from Glenn Marshall on Vimeo.

Philips also approximated the effect we were looking for in their electronic tattoos:

So what we want to do is:

IDEALLY: Create a program that will generate branching tendrils that creep over a surface like carnivorous vines in a sci-fi jungle movie, blossoming and branching organically (possibly randomly and possibly in response to some sort of environmental or programmatic stimulus). We then want to use a Wiimote or an infrared loaded gun to shoot “seeds” that will start this creeping and branching on a wall we project onto (or even onto a mannequin, so that the user experiences the full intended effect of producing life and beauty with a terribly deadly action). Think Genesis Device in everybody’s favorite Star Trek movieThe Wrath of Khan;

OR POSSIBLY: Create still, high-contrast vector images of the sorts of shapes we want and then mask them. Using Processing, we detect the edges of the various shapes and birth little alpha channel nibbling automata that follow them, turning our mask translucent as they follow the tendrils and their various branches, and rely on semi-random camera movement to mimic true organic generation;

OR MAYBE EVEN: Create many individual high-contrast creeping and branching tendrils as movies in After Effects and then remove their backgrounds and combine them dynamically in Processing (this option seems like it might not work for memory reasons once the number of simultaneous videos exceeds about four).

ICM: Gone With the Wind


After my initial experiments with virtual fans in 3D, I decided to scrap the hemispherical fan movement in favor of planar movement. I hooked up a potentiometer to an analog input on an Arduino and had it setting the fan speed in the Processing sketch over serial. Eventually, I’d like to use an actual fan rather than a pot and an onscreen fan to blow the pixels around; I’m not sure how exactly that would work, but it might make a good PComp final.

Initially, I had trouble keeping track of all the pixels; every so often, one would get lost. I made some extra hard-coded adjustments and now the pixels return to their original positions. In any case, here is a mouse-activated version of the sketch I showed in class.

I’m your biggest fan

As I am working with real fans for my PComp midterm, I thought it only fitting to extend the theme virtually into ICM. My idea is to take a picture and turn it into little colored bubbles that can then be blown around by a fan with a position determined by the mouse position and a variable speed (controlled by a real-world potentiometer). The fan speed and direction will determine the image bubbles’ movement. In addition, I hope to give them a slightly chaotic and organic “return to normal” motion.

This is a prototype of the fan (click to speed it up and slow it down).

My next task is to figure out the bubble physics. I’ll start with a single bubble and then I’ll make it a class. Then I have to figure out how to get an image to turn into an array of bubbles. [Update: Done! (Jitter added for effect)] Miles to go before I sleep!

ICM: Drawing Using Processing

So, when I was in art class in grade school, we sewed colored thread along a grid on black paper, producing smooth curves using only straight lines.  I’ve kind of been obsessed with such figures ever since.  Recreating the effect in Processing was relatively straightforward, though after entering the fortieth line coordinate by hand, I had a sneaking suspicion that there’s probably a way to write just a couple of lines of code and have Processing do all the work.  I divided the window into four equal quadrants and then copied and pasted the code from the first quadrant into each successive one, adjusting the start and endpoints of the lines accordingly.  I’m not such an innate Cartesian that I didn’t screw up along the way:

A mistake along the way

I got it to work and messed around with colors and stroke weights before finally deciding that just a plain line drawing without filled shapes wasn’t really giving me the practice I needed.

So I replaced the lines with the hypotenuses of triangles with their perpendicular vertices along the axes and tried coloring them in and playing with transparency.  The stacking order became very complicated and the transparency didn’t work as I’d predicted: I thought if I stacked 20% opaque triangles on top of each other, the places with more overlaps would be darker than the places with fewer.  This didn’t happen, I’m not entirely sure why though I suspect it had to do with stacking order.  I ended up liking a less griddish,  implicit gradient approach which is what I ended up with.  I worry that this thing might be a bitch and a half to make interactive.