Fire Wolf Case Study

I just took a crack at setting up a few dynamic controls for one of Truong CG Artist rigs, the Fire Wolf and ran into a few gotchas that I’d like to touch on.

Ragdoll Version 2021.01.04

First, the result.

Whereby head and pelvis are animated, the rest is simulated with the Ragdoll Dynamic Control feature.

Now let’s have a look at some of the issues I ran into setting this up.

Tiny Scale

Ragdoll assumes you are working at 0.1x scale. That 10 cm equals 1 meter. Because most models do. But this rig is even smaller, operating at 0.01x scale; being 1.6 cm tall from ground to tip of the ears.

That shouldn’t be an issue, but there are a few places in Ragdoll that relies on the overall scale of your rig. One of those places is thickness.

Every rigid has a .thickness attribute.


It’s in centimeters, like an extrusion along the normal of any collider. It’s meant to provide stability to very thin surfaces, but if it’s too large stability turns to instability. :sleepy:

The caveat is that “too much” is relative the overall size of your colliders. These boxes are all 1 cm tall, and a thickness of 0.5 is then 50% of its height. That’s a huuuuge value. But if the box was 1,000,000 cm tall, then 0.5 suddenly isn’t much at all.

Here’s what that looked like with the Wolf rig.

The challenge I faced here was that it isn’t obvious that thickness is at fault. At first I disabled collisions which also solved the issue. That led me down the path of reducing the radius and length of the colliders, which had some effect. But even the smallest radii couldn’t completely fix the problem.

Through trial and error, turns out that simply removing all thickness - i.e. thickness = 0.0 - solved it.

I think with this in mind, what I’ll do is default thickness to 0.0, and side-step this issue altogether. It’s unclear whether it actually helps with stability in even the best of cases.

Large Defaults

The default behavior of the dynamic control is to turn each of the selected controls dynamic.

Two issues occur here.

  1. The tip shouldn’t be simulated
  2. The tip shape and orientation is wrong

We can address both of these by treating the tip as a hint for length and orientation, instead of actually simulating it.

But it doesn’t really solve the issue, it merely hides it. The issue is that we’re leaving default values for the tip shape, which are…


And at this scale, those values are huge. So for the next release, what I think I’ll do is use the previously created shape as reference for default values. In case you do actually want to simulate the tip.


Other than that, things ran smoothly; no cycles, small performance impact. The rig with simulation applied runs at 35 fps on my machine, from the original 70 fps. That’s 14 ms/frame for the simulation alone, which is fair but not great; there’s a lot of room left for optimisation in Ragdoll.

What’s especially taxing is apparent cycles blocking parallelism.

That flat middle-part is Maya waiting for the solver to finish, much of which we can parallelise.