This work was done for the Unity Neon Challenge, a contest challenging Unity developers to create a real-time environment using tools developed for the Unity Adam series. I developed tools to be used by the environment artist and established the workflow for the other artist's using Unity's tools.
The development with Cinemachine and Timeline were closely intertwined, learning of one through using other. I initially tried to replicate the Adam pipeline as much as possible after reading the Adam Timeline blog, since it is considered to be the ideal use case. However, after just hours into replicating this workflow, I realized that Timeline and Cinemachine weren’t created with multi-scene editing capabilities.
I committed to the multi-scene editing, since the team was working remotely and couldn’t afford to have someone perforce lock the scene, I needed to limit dependencies. After researching whether Timeline had any feature which could make it multi-scene capable, there were two forum posts in which Unity community members had suggestions to remedy this. By investigating their ideology and closely studying the Adam development blog, I accomplished multi-scene editing and by establishing a naming convention with the artists and validating the input, I allowed the artists to work independently and more efficiently.
Cinemachine was used to control the camera through the storyboard established by the artists. Early into development, I had to reevaluate the use of Cinemachine because there was over 40 separate cameras, frustums pictured above. I had to decide between allowing the artists to hand animate transistions between the camera positions or allowing Cinemachine to automate the process. The hand animation of the transitions would give the artists more control of the speed, direction, and look frustum; however the major drawback was time required to do this. There doesn’t seem like there is a convention yet with cinemachine on the approach to long cinematics, however because of the cinemachine brain I assumed that many camera’s was the approach the Cinemachine team had designed for and thus continued this approach.
For the animationm, the team wanted the environment to feel alive which meant even the static buildings needed movement. The modules of the buildings rotate independently of the building as a whole, with gears on the module and module above rotating. When the module reached the destintation angle, the doors would open via an animation curve set by the artists. The bridge extends and retracts in a russian doll-like fashion, but only extends as many sections as required to meet with the opposing building.
The elevator towers, depicted on the left, have elevators ascending and descending throughout the animation. Elevators are spawned from a pool on the faces of the tower, and the script ensures the next elevator either travels the same direction as the last on the same face or waits until the elevator is out of range for a collision. The scripts also allow for the artists to specify the number of stops for an elevator as well as the frequency of stops in a travel from start to finish.
The scope of the project required modularization of assets and generation of environment. The artists had planned to build build detailed "modules" which would be part of the stack which consisted a building. Rather than having the artists individually place each module, I developed a tool which took many modules with defined heights into a building of specified height. The module blocks were given random initial angles, so to not face all the same direction, and artists could specify the type of tower. The environment generator spaces the buildings out with the paramters given to help create larger scenes. I worked with the artists on multiple iterations of the tools, and because the project and decisions were advancing so rapidly the tool had a difficult time maintaining keeping pace. The tool was used in a fraction of what it was designed for, but helped me understand how to better develop in future projects.
Part of the tooling developed was to visualize the connections of bridges between modules. The networking of modules is a layered system, with different layers of the environment connecting to one another. The building's modules don't need to rotate in the same direction, point at the same building, or connect to all surrounding modules. Distinguishing which modules have bridge connections and which don't helped the artists continue to develop the scene.