Earlier this year, I took another swing at rigging the infamous MechaCat model by Nico Strobbe. I documented the process on Twitter with the #CuriosityRiggedTheCat hashtag, as well as five other posts on this site. The focus of the exercise was two fold – just getting it to work (the leg took seven tries), and exploring the component based rigging paradigms that Raffaele Fragapane outlined in his Cult of Rig livestream.
I succeeded on both counts – the rig works, and the components were consistent, if clunky, and hyper specialized. So after a few months I decided to take another look at the design of the components, but with an eye towards a more generic application.
And what is more generic than a biped?
Every rigger worth their salt knows how to rig a biped. We all generally agree on the basic functionality, too. If we had to, we could build a basic biped rig in vanilla Maya, without tools, in about a day. I’ve done it once. It sucked.
What goes into a biped rig? Let’s just focus on basic kinematic behaviors right now. You have the spine, the neck (basically the same thing), arms and legs (same thing), hands and feet (same thing), and fingers and toes (same thing). Five components.
Let’s look at the limb. Where do you draw the boundaries of the limb? Is the foot part of the leg? Is the clavicle part of the arm? In the rigs you have built in the past, can you cleanly point to boundaries between the three?
In a component based rigging system, each component is like a node – it has clear, well defined inputs and controls that it uses to “compute” clear, well defined outputs. Connections between components must be directional – which is where we run into trouble.
An IK/FK limb has multiple moving parts. The IK chain, the FK chain, the blend chain, the parent FK (clavicle), the reverse foot, and an FK foot. While it might be fine to put that all in one component, sometimes you don’t want/need one of the chains, the parent FK, or the feet. So let’s separate them out.
That means a fully featured limb will have seven components.
Wait, I hear you exclaim, you only listed six parts in the limb.
There’s a problem, and it’s the reverse foot. The animators I have worked with didn’t like sliders for the foot roll. They wanted controls you could grab and translate/rotate. Which means they need to follow the IK foot control, ideally staying with the ankle when the leg doesn’t stretch.
In order to make the foot optional, it must be its own component. In order to make it follow the ankle, the IK chain must be two components. In my design, the IK chain component only has a pole vector control – the segment lengths, start position, and end position (with reverse foot offset) are inputs driven by other components. The other component is the IK control. It outputs the segment lengths and the end position (without reverse foot offset).
As a result, the IK limb looks like this (each component has been simplified as a node) for clarity. The FK limb is runs in parallel; I omitted it to keep the screenshot tidy. The blend chain component is at the end of the chain, obviously.
In most limb rigs I’ve seen, the limb IK and reverse foot are counter connected. By separating the limb IK into two components, you can keep the connections forward. The animators should neither know, nor care, how the rig is put together under the hood, so long as it’s fast.
Decomposing an IK/FK limb to the smallest possible components ends up with seven components. This gives you maximum versatility in what components you use. With some tooling, the components can be bundled together in re-usable configurations for the most common use cases. Other features, like bendy/twisty segments, can be added on top with additional components.
Next time, we’ll cover how I approached component based space switches.