‘Derezzing’ a crashing light cycle, part 5: explosion anim and sim

Feel free to share: Share on LinkedIn
Linkedin
Tweet about this on Twitter
Twitter
Share on Facebook
Facebook
Share on Google+
Google+

Now the exhaust wall stuff is done and made into a tool, attention has shifted back to the explosion animation and simulation. By now all the major systems for animating and hand-over to simulation are in place.

Let me start by showing you a test animation for that I’ve rendered out. I did a very quick multi-pass comp on the render to attenuate reflections a bit and add some glows. The animation is rendered at 8 times slow motion.

View in high resolution: trnd_crash_expl_v05.

If you’ve watched the previous test render, you’ll notice that quite a lot of things have changed. One obvious change is the inclusion of an ‘Arena’ background created by Linus Hofmann. I’ve updated the colors on the red cycle’s exhaust wall to a much more saturated orangy look. I’ve also added depth of field to the render, which adds a nice touch to the final look while not costing much in terms of render time. But the biggest change, or addition rather, is that the impact of the blue cycle into the red wall has been animated and is then passed over to two subsequent simulations.

The process I used is roughly as follows:

  • pre-fractured the impact zone of the cycle (the front half of the cycle) by hand
  • voronoi fractured the rest of the cycle
  • hand animated the impact zone fragments to crush at initial impact
  • hand animated the rest of the cycle (the voronoi fractured part) as a whole to fly upwards at impact
  • hand animated the impact zone fragments in combination with the voronoi fractured fragments for the explosion
  • hand over all the fragments to a fragment simulation
  • run the simulated fragments through the ‘disintegration’ process (also see ‘Derezzing’ a crashing light cycle, part 2: fragment disintegration)
  • hand over the disintegrated faces to a second simulation
  • run a particle simulation for the ‘sparks’

The ‘story’ idea behind the two level fragmentation of the cycle is that the cycle first crashes head-first into the wall. This leads to an initial crushing of the front side of the cycle. At some point I guess the transmission is crunched into the engine which then explodes. This is when the rest of the cycle also fractures and all pieces fly off by the explosion force. This also ‘explains’ why not all pieces have a ‘forward momentum’. Even though I think the final animation does need a bit more forward momentum to the pieces.

In order to make it easy to animate this two phased fracturing, I’ve created a new ‘pre-simulation fracture animation’ tool. This tool is based on a fairly standard solution I picked up during a Houdini course at fxPHD. I’ll probably dedicate a post on this and other dynamics tools I’ve used for this animation sequence later.

This approach works really well, but can lead to some small issues that need fixing before render. The most obvious one can be seen at around the fourth second into the animation. Here you can see the front wheel bouncing from a point above the ground plane. This is the result of the wheel being simulated while being still in one whole piece (the first simulation stage). It is rendered however as the disintegrating wheel where quite a lot of faces have flown off. This can be easily fixed before render by blending in a little bit of hand animation that moves the disintegrating wheel down so it actually hits the floor.

This might seem like something you’d want to fix by simulating the actual disintegrating fragments instead. However, that would increase the complexity and resource requirements of the simulation quite a bit as the simulation would then have to deal with geometry that is constantly changing. As the amount of fixes and the effort involved therein isn’t really a big problem, it is better to keep the simulations simple and deal with issues where they visibly arise (in this case mostly a single easy to fix instance).

All in all, I think the results so far are quite pleasing :).

The next and last big item on this projects to-do list is adding a fluid simulation for the glowing energy lines of the cycle. This is something I’ve been working on last few days and which is starting to generate some nice results. The idea behind this last part is that once the cycle starts disintegrating the glowing lines and the engine release their energy, which is represented by fluid in the Tron universe. At first my approach was ‘limited’ to a big splash of fluid coming from the engine in the center of the explosion. Then however, I though it would be cool to apply this fluid effect to all the glowing parts of the cycle. So what I ended setting up a more elaborate simulation where all the glowing faces of the model are no longer handed over to the rigid body simulation like their ‘non-glowing’ siblings.  Instead they are used as a source for a particle fluid sim. This is also why you can see the glowing faces just disappear in the render above, as part of the fluid sourcing setup was already in place when I started the render.

The basic setup of all this is finished already, most work now is tuning the parameters to get nice results. Doing so I ran into some initial problems with the flip fluid solver totally flipping out at frame 90. Turns out that for some unknown reason some particles in the sim where explosing outward to extreme distances at that frame. This caused the volume that the flip solver uses for its calculation to also expand to outrageous proportions, which in turn ate up all the memory available on my workstation. It looks like the standard location where Houdini puts a particle sink, specifically to prevent this from happening, isn’t doing the job. Now (literally while I was writing this post), I’ve moved it to a later stage in the solver setup, it seems to work as it should and is killing off these stray particles. Anyway, I’ll believe this is true when the full simulation has run its course after which it will be time for a little report to SideFX. But it looks like this little change solved this issue.
UPDATE:
I’ve tried to replicate my scenario in a very simple scene. In this scene the standard particle sink seems to be working fine. So something else must have been causing problems. I’ll have to examine this closer to find out what’s been going on in my scene file.

I hope to be able to share a first render of this last addition in the coming days.

With that out of the way, I’ll start working on finalizing the animation sequence by really polishing up on the animation part in addition to doing some more finishing touches on the shaders and multi-pass setup together with Linus.

Cheers,

Erik