Ralphzilla and Moshpit

Composed of over 550,000 crowd agents, Ralphzilla of Ralph Breaks the Internet, one of the largest movie monsters ever created and presented a huge technical and artistic challenge. I introduced a new crowd solver, Moshpit, which performed high resolution inter-body collision among crowd agents. Moshpit was incorporated into Disney’s Skeleton Library (SL) and proprietary pipeline automation framework.

Ralphzilla was made up of densely packed crowds that dictate the character’s shape and movement. From the creative development, it was evident that the crowds making up Ralphzilla needed to follow specific textural movement to reflect the character’s emotion, while showing detailed collision among individual crowd agents.

At the same time, the sheer number of shots and complexity of the Ralphzilla’s task required an automation. We needed a new solver that supported higher resolution collisions between crowd agents and their limbs while keeping input reference animation. I developed a new solver, Moshpit and built up the pipeline of integrating it with Disney's Skeleton Library. I also contributed to integrate the rig with Disney's pipeline automation framework xpipe to ensure a consistent look while dealing with complexity.

Concept

Photo by Joon Song

Concept design by Jeff Merghart

Challenges

Character Definition

Ralphzilla was a character that was made out of a lot crowd agents. We should consider it both as a one character and as a huge group of crowd agents.

Scale

First challenge is the scale of the creature. Ralphzilla was the largest movie monster ever of that time. In most shots, we had to show this huge monster and human scale character - Ralph and Venellope - in the same scene. Presenting very different scale of characters and seeing them interact with each other in the same scene was a huge challenge.

The Amount of Crowd Agents

These are all Ralphzilla shots in the movie. Ralphzilla was conceptually composed of over 550,000 crowd agents. We didn't have to make it fully packed inside of his body and we applied a lot optimization solutions to deal with as small amount of crowd agents as possible. However we still had to populate and render a lot of crowd agents to present this monster. Ralphzilla showed up in 104 shots of 2 sequences. The amount of the crowd agents we had to generate, animate and render was 5,443,098 that was a lot bigger than LA's 2018 population.

Accurate Collision among Crowd Agents

Simulating accurate collision between parts of crowd agents while keeping animation fidelity is one of the most difficult problems in crowd simulation. In many scenes of our movie, we had to deal with this challenge.

Coalition of Multiple Tools

I used multiple tools - bullet solver, Disney's skeleton library, Disney's Xpipe and automation framework and I had to build up pipeline that made all these tools integrate with each other.

Cross Departmental Collaboration

More than 130 people from 12 departments collaborated. I was a lead for effects and crowd tasks.

Reference

Youtube

Creative R&D

Development

Directed Position Based Dynamics(PBD) Solver

Agents points are pre-simulated with the PBD solver. While performing the PBD simulation, a dedicated solver made points captured around the Ralphzillas's mesh surface. Since this process was a separate module from the Moshpit simulation in the pipeline, we were able to art-direct the overall motion of crowd simulation with this performant solver.

Moshpit

Moshpit was a bullet physics based "directed" rag-doll crowd solver. I made this solver for implementing physically accurate high resolution collision, preserving animation fidelity simultaneously. More detailed explanation is in the next section. Comparing the output from Moshipit with that from PBD, we can see Moshpit's output made high resolution inter-body collision.

PBD PBD + Moshpit.

Integration with SL(Skeleton Library)

Moshpit’s design provided tight integration with our proprietary crowds system called Skeleton Library (SL). Since its adoption on Zootopia, SL has been used in production on all subsequent Walt Disney Animation Studios features and shorts. SL provided a powerful and reliable mechanism for crowds and skeletal manipulation. Though platform independent at its core, it is tightly coupled inside Houdini, making it readily accessible. Integrating with SL allowed Moshpit to leverage all of its functionality (e.g. access to all crowds tools, etc.). The two systems connected in 4 key ways: (1) The performance and animation of the individual agents were controlled in an SL context, where all the crowds tools were available to the artist. (2) The initial PBD simulation used the locomotion from the SL’s playback of crowds animation cycles. (3) Target positions for bullet objects and the bullet constraint network were calculated from a wire representation of said animation generated through the SL (4) The output of the Moshipit simulation was converted into a valid SL crowds particle cache. The new animation produced by Moshpit was stored in the form of joint offsets (in essence, transformation data per joint). After this conversion process the data was fully compatible with the studio’s existing crowds pipeline.

Post-process, Instancing Rendering

Moshpit produced the data that were used for "offsetting" each joints of pre-cached crowd animation cycles. I added a filtering module to reduce the jittering. Once the conversion from the bullet solver output to SL compatible data was done, we were able to render animated crowd agents with Disney's crowd render pipeline.

Global and per agent controls

Overall system could be controlled with global controllers and per agent controllers. For example, we could apply a global speed multiplier to drive overall speed of simulation and animation cycle speed. We could also apply per agent random speed variation. These controls were very important to represent Ralphzilla's emotion. For example, when he got angry, the crowd agents had to move quicker to express aggressiveness, and when he calmed down, the speed should slow down.

Global speed multiplier

Random speed variation

FX Elements - Motif

Glow, sparks and debris were added as ingredient, to enhance the feeling of virus-y and distorted characteristic of Ralphzilla. I added a fx element creation automation rig in the Moshpit pipeline.

Motif design exploration

Moshpit

Data Preparation

Dedicated input data were needed for running the moshpit solver. A was the crowd agent for instancing. B shows the 129 customized representative ODE geometry (cylinders and capsules). These ODE geometry were grouped as 102 packed primitives as shown in C. D was the default skeleton library representation. It had 149 points (148 primitives). We didn't need that level of complexity for moshpit. So I cleaned up the skeletons, mostly around the face area. E shows the target wires that were cleaned up from D. In order to match the total number of curves to the number of the bullet representative meshes, it was simplified to be 103 points which are 102 primitives. This primitive count was same as the number of packed primitives( bullet representative meshes) of C. G and H present the position and the rotation constraints.

Solver

Ragdoll physics has long been used to simulate physically accurate collisions among crowd agents and non-crowd colliders. Ragdoll physics uses point constraints and cone-twist constraints to connect the proxy geometries of crowd agents. Crowd agents move by referencing cached animation cycles. However, when using a ragdoll system, the reference animation is disconnected from the proxy geometry. While this produces physically-accurate simulation, the result often deviates from the input animation. To ensure that crowd agents follow the input reference animation, I introduced two major modifications to the solver: (1) velocity-driven transformation of proxy geometry, and (2) dynamic axis updates of the cone-twist constraints during simulation.

Repurposed bullet solver in the Moshpit solver

Transformation with v and w targeting

Moshpit solver

The velocity and angular velocity were calculated by taking the difference of position and rotation of the proxy geometry and the reference geometry. They were then used to drive the proxy geometry during the rigid body simulation to achieve the reference animation.

The up and twist axes were calculated by taking the difference of each joint’s relative rotation to their parent joint from the previous time step and the target relative rotation from their reference geometry. The calculated up and twist axes were used to update the cone-twist constraints during the simulation to maintain the rotation of the joints from the reference animation.

Pipeline and Automation

< Back to FX > >> Next

Google Sites

Report abuse