‘Derezzing’ a crashing light cycle, part 6: explosion fragments & fluids

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

It’s time for another update on the explosion. It’s been silent for a while now, as I’ve been working on some other stuff while running simulations and renders in the background.

As a side note: I’m really pleased with the way HQueue is working on my little farm. It makes simulations and renders much easier to schedule and manage, so its was well worth a little investment in time to set it up. I’m thinking of writing a little post on my experiences with HQueue so far some day soon.

Anyway, on with the fragments and fluids. I’ll start with a render as usual:

View in high resolution: trnd_crash_expl_v07.

This is a render of the latest simulation that I have run on both the ‘faces’ and ‘energy fluid’, it also includes the ‘sparks’ particle sim. As with the previous renders, I ran the render passes through my very basic multi pass setup to tune it a little and add some glows.

Fragment and ‘faces’

I’m quite happy with the results except for two little things I need to fix: the front wheel doesn’t quite touch the ground around frame 74, and around frame 20 there is a fragment that intersects with the red exhaust wall.

Normally the second problem would definitely be a candidate for a quick fix in the comp. However, the first issue is best fixed in 3D, so I can just as well fix both issues in Houdini. My scene already has a ‘pre-sim animation tool’ setup for dealing with the front wheel after the initial fragment sim (the bigger pieces), so I just have to update the animation there (I guess the name ‘pre-sim animation tool’ isn’t quite accurate, considering its just as easily used for ‘in-between-simulation-animation’). The results of the tweaked simulation is already passed into the ‘faces’ simulation of the disintegrated fragments and the fluid simulation.

While simulating the ‘faces’ simulation, I ran into some serious crashes. The simulation would run fine until say frame 100 and then it would crash with a ‘segmentation fault’. It quickly became clear that a handful of the faces accelerated to almost relativistic velocities in 1/192th of a second and thus flew incredible distances in the same time. It turns out Houdini doesn’t like this very much…

My first attempt at stopping this madness was that I threw together a boundary force using a ForceVop. This thing basically let’s you specify a box around your sim out and a ‘inwards’ force. Whenever objects fly outside of this box they get slowed down until they have no more velocity in the direction they left the boundary from. I was quite happy with myself and set off another sim, only to see it crash and burn the same way as before as if the boundary force was not doing anything. Obviously no mere boundary force can do much against almost relativistic velocities, which I should have picked up on from the get-go.

Anyway… Next attempt was a velocity cap. I added a ‘RBD State’ op in which the velocity is clamped to a minimum and maximum amount in each dimension. Again, after a short pre-victory celebration, my sim still crashed and burned.

This time I was a little more puzzled how this could be. Luckily I found Jeff Wagner online and told him about my light speed sim. After a bit of discussion he came up with the actual problem and a solution. Turns out that the mass is the problem. These little ‘faces’ that fly off are really small and thus have a very small volume after they have been extruded. The volume in combination with a specified density is used to calculated the mass of the objects. Some of the pieces, the ones achieving almost light speed, have such small masses in fact that the sim runs into some serious precision issues in calculating forces on them. This is why these pieces showed extreme reaction to any interaction with a force in the simulation. So the actual solution to the problem was as simple as adding a lower limit to the mass of each object using the same ‘RBD State’ op, I already had in place. This time I thought it was better not to celebrate until I knew for sure it worked. And low and behold, the sim started running beyond the problematic frames without a hitch.

‘Energy Fluid’

As you can see in the animation, I added the ‘energy fluid’ simulation (I discussed the idea behind the ‘energy fluid’ in the previous post in this series: ‘Derezzing’ a crashing light cycle, part 5: explosion anim and sim). To create the fluid, the glowing ‘faces’ are isolated from the other pieces when they pass a certain disintegration threshold (in stead of being passed into the RBD sim for the non-glowing parts). Points are scattered on them which get passed into the fluid sim as the source.

The fluid simulation uses the flip solver that’s new in Houdini 11. The fluid source is setup as a ‘particle fluid emitter’ source which emits a number of particles each frame based on the source points mentioned above. My first thought was to create the fluid inside the ‘fluid object’ itself, but it turns out this doesn’t work with my changing source points. So instead, I just have the particle emitter generate points at each frame where the amount is calculated as an expression in the parameter that specifies the amount of particles for each sim step.

As the sim quickly becomes fairly heavy, I’ve sliced it in two segments that can be simulated in parallel on two machines (the amount of batch licenses I currently have). This works really well and is surprisingly easy to setup. It basically simulates the two halves of the fluid sim separately while figuring out the influence the two sims should have at the boundary. I wish the same was possible for RBD simulations!

For the fluid sim the biggest challenge turned out to be the interaction with all the fragments and faces that are flying around in the simulation. I quickly found that it was not workable to run the RBD and the fluid in a single simulation setup. There are just too many objects flying around to also have the fluid sim at the same time. This left me with the challenge of getting some interaction happening while still running two separate sims.

In the end, I’ve decided to have the RBD sim of all the fragments influence the fluid sim. This still had some issues with the shear amount of RBD objects. In order for the interaction to work each object needs to be represented by a volume and generating all these volumes of both the bigger fragments and the small ‘faces’. This just leads to too much overhead.

What I ended up doing is generate proxy geometry of the bigger fragments that changes over time as more ‘faces’ disintegrate from them. This proxy geometry is pulled into the fluid sim as a ‘fractured rbd object’, with ‘Use Deforming Geometry’ turned on (so each separate fragment becomes an object in the sim, which makes generating collision volumes much more efficient). The This allows for fairly accurate collision geometry that at least represents the part of the fragments that has not yet fallen apart. It also does mean that the small ‘faces’ flying around are not included in the fluid sim, but I find that there is so much going on with thousands of pieces and blobs of fluid it is really hard to see the missing interaction there. In the render at the beginning of this post you can see that the collision geometry is not doing its job well enough yet as there are still some fluid passing through fragments without collision, so this is something I need to fix for the final version.

Anyway, as always there are all kinds of trait-offs between realism and what’s actually possible to achieve (and noticeable).