50
edits
m (→Hotel Hell: added the test chamber where it’s found. I am doing this for every node, might take a while) |
m (→Introduction Destruction: added the test chamber where it’s found. I am doing this for every node, might take a while) |
||
Line 73: | Line 73: | ||
=== Introduction Destruction === | === Introduction Destruction === | ||
{{Quotation | Gray Horsfield | {{Quotation | Gray Horsfield, Container Ride | ||
| The container ride destruction sequence provided some unique technical challenges. The dynamics you experience are actually computed as two separate but nested simulations. The first is a coarse scale simulation designed as a stress element analysis pass. This pass computes the overall gross motion of the container itself, and computes the collisions and break points based on path keyframe data and a network of constraints. As the container bumps and crashes along, the constraints start breaking, and the room progressively starts to come apart. There are over three hundred rigid bodies and nine hundred constraints in this rig, all individually configured for properties like tensile, friction and collision response. The coarse simulation portrayed gross motion that captured the main dynamics of the ride, but not the fine details. The product of the coarse simulation was then used to deform spline-based surfaces representing the container geometry, which in turn were parents to fine debris as anchored rigid bodies. As the surface deformations increase, anchors are broken and the fine debris rigid bodies are released into the simulation. The fine simulation also includes the interior furniture, and the model detailing. The two simulations were then connected using cache data and were driven together by a series of scripts. Due to the computational complexities of having two nested simulations, we had to come up with some solutions to some interesting mathematical problems. One problem was that the nested nature of the simulations resulted in some instability in the fine debris calculations due to floating point computing limits. The solution employed for this was to compute the fine debris on a stage where the root transform of the coarse simulation was essentially cancelled out and stored for later use. This allowed us to more accurately detect the fine interactions between the debris and the environment. Post simulation, the root transform position and inertia were reapplied to the details. We solved the problem of trying to compute the player within this highly dynamic environment by putting them in a virtual room that has all the base shapes of the rendered container, but is simply used to compute player navigation. (It’s hidden somewhere else in the map.) The viewpoint of the player is then parented to coarse simulation transform, resulting in the final rendered frame. At the end of the ride the player is teleported into the actual game space. The simulations were iterative, enabling us to sculpt the dynamics in parallel with the gameplay design. In the final product there are over 1200 rigid bodies, 900 constraints, and 1000 joints. With all the iterations combined, the actual run time spent computing the simulation was 92.4875 days. | | The container ride destruction sequence provided some unique technical challenges. The dynamics you experience are actually computed as two separate but nested simulations. The first is a coarse scale simulation designed as a stress element analysis pass. This pass computes the overall gross motion of the container itself, and computes the collisions and break points based on path keyframe data and a network of constraints. As the container bumps and crashes along, the constraints start breaking, and the room progressively starts to come apart. There are over three hundred rigid bodies and nine hundred constraints in this rig, all individually configured for properties like tensile, friction and collision response. The coarse simulation portrayed gross motion that captured the main dynamics of the ride, but not the fine details. The product of the coarse simulation was then used to deform spline-based surfaces representing the container geometry, which in turn were parents to fine debris as anchored rigid bodies. As the surface deformations increase, anchors are broken and the fine debris rigid bodies are released into the simulation. The fine simulation also includes the interior furniture, and the model detailing. The two simulations were then connected using cache data and were driven together by a series of scripts. Due to the computational complexities of having two nested simulations, we had to come up with some solutions to some interesting mathematical problems. One problem was that the nested nature of the simulations resulted in some instability in the fine debris calculations due to floating point computing limits. The solution employed for this was to compute the fine debris on a stage where the root transform of the coarse simulation was essentially cancelled out and stored for later use. This allowed us to more accurately detect the fine interactions between the debris and the environment. Post simulation, the root transform position and inertia were reapplied to the details. We solved the problem of trying to compute the player within this highly dynamic environment by putting them in a virtual room that has all the base shapes of the rendered container, but is simply used to compute player navigation. (It’s hidden somewhere else in the map.) The viewpoint of the player is then parented to coarse simulation transform, resulting in the final rendered frame. At the end of the ride the player is teleported into the actual game space. The simulations were iterative, enabling us to sculpt the dynamics in parallel with the gameplay design. In the final product there are over 1200 rigid bodies, 900 constraints, and 1000 joints. With all the iterations combined, the actual run time spent computing the simulation was 92.4875 days. | ||
}} | }} |
edits