Prototyping
We agreed that with WebGL, the potential was there to achieve the same fidelity as the sample stills. Deciding on ThreeJS as our framework, we began to prototype various "hello worlds" and soon realized that we were out of our depths. Completely overwhelmed, we took a step back and decided to refocus our efforts on the "lower hanging fruits" of the project.

Scaffolding
Regardless of the complexity of the animations, the project needed an architecture that would allow each of the developers to create individual scenes and then commit them to a larger sequence, very similar to modules within an application. Taking inspiration from my film education, we borrowed concepts from the editing process to create a basic JavaScript scaffold. Similar to most time-based editing suites, the underlying concept was simple. Schedule an event within a queue, then pop it off as the current time passes the marker.

Scene Creation
Still overwhelmed and a little frustrated, we realized a point of contention was how we would move geometry: animation vs emulation. Dan coming from a gaming background recommended we create real world systems that would mimic physics (gravity, collision, etc.), while I argued we could achieve better craft by "keyframing" object parameters. Through much trial and error and the creation of several "happy accidents", we were forced to realize that it would have to be a combination of both.

Sequencing
When all was said and done, the team had 21 scenes that needed to be stitched together. Unfortunately, this process was more art than code. To respect the creative Research of creating a single experience, we still strived for seamlessness between scenes and events matching the tempo of the audio. This meant going back and creating transitions between scenes and also led to a process I can only describe as "pixel pushing" code, manually incrementing timecode to register on a particular beat.