Ghost Hack

A few months ago I was asked to make some visuals for Google IO , something I’ve done in the past with these procedural circuit-board diagrams. I spent a good few weeks experimenting with a ton of different things, in both THREE.JS and Processing, and slowly gravitated towards one concept.

This post will be image heavy, so I’ll skip on the failed experiments and get right to it.

Generative Machines

The idea of a procedural exploding view diagram was very attractive to me. It had all the right elements: a bunch of techy looking mechanical shapes, diagrammatic, and all of these lines criss crossing everywhere as if to suggest motion of a kind that automatically assembles.

It wasn’t enough that I simply had rivets and slots coming together, I also wanted to make an overall structure that looked as if, when assembled, became a machine that forms a whole that was more than the sum of its parts. 

This got me thinking about creating procedural shapes that I can cut up. My first exploration into this was creating a one dimensional exploding axis, where elements can fly forward or back, and adding a radial dimension where elements could be chopped up and exploded outwards.

This involved in a lot of geometry splitting, helped by this wonderful THREE.JS library by Chandler Prall, based on a Constructive Solid Geometry (or CSG) javascript library by Evan Williams. 

Example usage of this library.

Normally the library allows you to subtract geometry, add geometry, or intersections, however what I really needed was a cutting plane that slices any arbitrary geometry that I give it. I whipped up this hacky solution where I defined a plane, and a solver would create two gigantic boxes on either side. These two boxes are then used for two intersect operations on the geometry, one on each side of the plane.

This allowed me to have geometries with N number of slices, each forming individual mesh pieces that I can then animate.

While this got me somewhere, it still didn’t feel like it was creating a machine. It looked too abstract. What I needed was something that carefully straddles the line between hand-made geometry design and something that was procedural.

The next experiment involved procedurally generating shapes that were somewhat recognizable. Capsules lined with shells, screws, and wiring in this example.

Then I needed a skeletal base on which to generate the geometry. This would allow me to do replication (important in a machine-looking thing!) and some form of hierarchical generation. 

I divided the code into three main layers.

The highest level was the skeleton, which would be a procedurally generated series of nodes (each using an Object3D, abusing THREE’s scene graph for my own purpose, more on this later). 

The strategy I ended up with was to generate a “spine” from which radial and branching skeletons would emerge. After the skeleton was decided on, a function traverses each joint and generates the “meat” on the bones, called “assemblies”.

The next layer is what I call assemblies. Each assembly lives on a single joint length in the skeleton. They exist as functions that are hand tailored to procedurally generate something recognizable, such as a jet engine or a battery compartment (I wasn’t too focused on realism at this point). The assemblies get information about the joint length, and where the next joint is, but that’s about it. Inside each assembly are some randomized parameters, and sometimes conditions based on length, so each assembly will look slightly different based on initial conditions.

Finally at the ‘lowest’ level were components. These were essentially recyclable geometry generating tools I would use in each assembly to create the recognizable pieces, such as struts, lattices, wires, etc. For what it’s worth these were pretty quickly hacked up and not really meant to be reusable for the future, but they accomplished their job admirably.

Deciding on a color palette was interesting. I wanted the palette to be generated, but any ol’ random colors will not do. I needed sets of colors that work well with each other, but randomly distributed to the components.

I drew inspiration from these Mirror’s Edge 1080p wallpapers that I had laying around. The artists for this game really love color, and the palettes these images are blessed with are beautiful. So why not just borrow them?

I ended up creating these palette sets, based on sampling each image with approximate distributions. When the machine is first generated, a randomly chosen palette is picked. Each machine component type is then randomly assigned a color ID from the palette. This creates a look of ‘organized random’, since each assembly has these uniformity to them, even though the process for picking them was totally random.

Some more color palette examples…

Creating animation for these was one of the main features I wanted to try, essentially producing something that looked like it was assembling or dis-assembling based off of the exploding diagram they were inspired by. 

I heavily abused these two wonderful tools, THREE.SceneUtils.traverseHierarchy, which crawls through the scene graph calling a function on each, and Javascript’s ability to give a function to any object.

Each Mesh that I want animated was given an update function, like so:

shell.update = function( percentage ){
	this.position.z = this.start + (this.end - this.start) * percentage;
};

The percentage would represented a normalized value between 0 and 1, 0 being a state of total disassembly, and 1 being total assembly.

Each mesh would then be responsible for taking care of their own translate or rotate values based on the input percentage, so I could easily set the initial and end state for the mesh. All meshes were procedurally generated with their end state, but their update function with a value of 0 would cause them to be at a disassembled state. For example at 0, a screw would be far off to the side, and by increasing it to 1 it would rotate and spin inwards towards its generated, final position.

I then used TWEEN.js to create interpolation to each animation. To create the staggered animating effect, I instructed the TraverseHeiarchy to go outwards from the lowest chain in the scene graph, animate those, and skip animating the parents (and their parents) until the children are completed with their animation. This causes the smallest, lowest bits of the assembly / component system to be animated first before animating larger entities. 

There are some finishing touches that needed to be considered. I’ve experimented with putting the structure on black and dark gray, both of which gave an interesting look, but I still settled on white because of the black diagram lines, keeping the aesthetic more in line with the exploding view diagrams this was inspired by.

I added an ambient light color wash which took out a bit of the “CG Phong” look which plagued that shader when used by default, though admittedly it’s now become very instagr.am-looking.

I’ve also added some randomized specular lighting which gave it a metallic sheen. Finally, I experimented a bit more with the skeletal layout system to create some radial-symmetry, hopefully to create more orderly-looking constructs from a higher level, something like a Large Hadron Collider.

The finishing touches on UI and styling are by Geoerge Michael Brower.

Here are some more images from the final piece. 

This project didn’t end up getting used for Google IO this year for reasons unknown to me, but I’m happy it’s seeing the light of day as a Chrome Experiment.