Last post I talked about the static scene setup for the above video, this post focuses on the RBD preparation and setup for the explosion.
It’s pretty much Houdini from this post onwards, here is the top level layout of my scene:
Complete with a “TODO” section on the left that I forgot to clear out 😉
The grenades nodes in the middle are where most of the prep work for the RBD is done, so the internals of those will be the focus for this post.
Import once, fracture twice
Although I probably should have just manually rotated and placed the chains, I decided to do an RBD sim to hang the chains in place, and over the wooden shelf.
I couldn’t get Concave collision to work with the chains.
They would sim ok for a handful of frames, and then generally start intersecting, or explode apart, or do any number of annoying things.
I had a chat to one of our VFX Artists at work, Mandy Morland, who does all sorts of cool things in Houdini.
She suggested I could fracture the chains, and then simulate the chain links as clusters of Convex Hulls, which was a super awesome idea.
As long as each new fracture piece in a single chain link has the same value in the name attribute, it can be assembled and passed to DOPs as a single object.
So, for example, all of the highlighted sections above would have the same name attribute value “piece2”.
However, the name attribute is created before the fracture, and the fracture creates new internal faces which will not have the correct name attribute!
The above image visualises this problem with colour as a primitive attribute.
The pieces have a green colour applied to them before fracture, and after fracture the internal pieces can’t know what colour to have, so they get initialized to default (I’ve then coloured them blue to make it more obvious).
To avoid this issue, I’m looping over chain pieces, promoting the piece attribute to Detail, then fracturing the chain, then promoting the piece attribute back to Primitive:
(The piece attribute is just temp storage for Name).
This is a Houdini trick I do a lot of, in general form:
- Loop over geometry pieces that I want to share an attribute value
- At the start of the loop, promote an attribute to Detail.
Only the current piece of geometry will be affected by this, Detail is essentially per piece at this point.
- Do the things I want to do in the loop that generate new geometry, or invalidate the attribute in some way I don’t want
- Promote the attribute back from Detail to whatever context it was before (primitive, point, etc)
Side note on fracturing in a loop…
Fracturing inside a loop isn’t the best idea, it’s going to be slower than running fracture once on a single geometry object.
When fracturing geometry that represents combined objects, and that has per-object attributes you want to keep (eg: a string attribute called “chainID”), a better way might be:
- Fracture the geometry (new faces will have a blank chainID).
- Use Connectivity on Primitives to get a attribute (let’s call it Bob)
- Do a foreach loop on Bob:
- Promote chainID to Detail (using “maximum”)
- Promote chainID back to Primitive.
Very similar, but at least it gets the fracture out of the loop.
In the end, node network performance wasn’t too big an issue for me: I go crazy with cache nodes (184 GB for this project), so I only had to wait for it to finish once, and it was still pretty quick for such simple geometry.
With that done, the chains were ready for the hanging sim, I just needed to make sure the bullet sim was creating convex hulls for connected prims:
Back in my Grenades_fractured network, I’m importing the base un-fractured geometry, and then importing the hanging simulation with a dopimport node, with an Import Style set to “Transform Input Geometry”, and using timeshift to pick a frame I like.
So now I have the base un-fractured geometry in a good starting pose:
With the grenades now in the right pose, I fracture them again, ready to be blown up!
They don’t get made active straight away, but more on that, explosions and fluids in the next blog post 🙂