Curiosity Rigged the Cat, Part V

A couple months ago, I decided to try rigging the infamous MechaCat again. Unlike previous attempts, where I followed “traditional” rigging techniques, I modeled my approach after the workflow shown in the Cult of Rig videos. In addition, I restricted myself to using “vanilla” Maya; no custom plugins.

Obviously, the vanilla approach limited how good the rig could be – especially in the spine. But the constraint forced me to be thoughtful and meticulous in my nodeling. Prior to this attempt I did not have a lot of experience with mechanical rigging paradigms. I had to discover them for myself as part of the process.

In the end, most of the rigging came down to two techniques, one of which is a derivative of the other. I touched on both approaches in Part I of this series. I call the first approach matrix re-composition. You multiply a matrix into “local” space, decompose it, and then compose a new matrix using a subset of the transform attributes, and multiply it back into world space. Usually, the matrix is decomposed with a specific rotation order to isolate or suppress a single axis.

The second technique is has the same boundaries is the first, but the rotation component is constructed using an aim constraint. The constraint’s connections are manually created. This keeps the number of connections down to the bare minimum and prevents the evaluation clusters that hamper constraint performance when created by Maya.

I am not sure I rigged the legs correctly. In broad terms, each leg has the kinematics of a feline leg – a hip, knee, ankle, and hock joint. However, the rotation of each joint is broken up across multiple single axis pivots. It took my six or seven tries to figure out how the leg could move, and how it should move. Ultimately, I got something that worked, but I don’t think it is “right” for two reasons.

First, the rotate Y of the knee does not “twist” the lower piece of the upper limb. If it did, the knee axle drifts away from the FK knee control’s pivot. As a result, the knee rotation order is XYZ, which the rotate Y affecting the piston segment of the lower leg.

The image on the left is the current knee. The meshes are colored by which axis of rotation they are driven by РRed (X), green (Y), and blue (Z). When I was rigging the leg I did not have the pistons in the scene. After finishing the leg and adding the pistons, I discovered that they greatly restrict the range that the leg can swivel in. While the rig is stable to almost 90 degrees in either direction, the pistons collide with the limb after about 30 degrees. Therefor, in order to get a full range of motion, I would need to have the knee rotate Y drive the upper leg segment. The lower leg segment would need to counter rotate in order to keep the ankle on model.

Second, the rotate Z of the ankle and knee have the same effect, which causes an IK-like behavior from the FK ankle. Every piece of the model seems to have been constructed in such a way that it can be correctly animated without restoring to a skinCluster to move separate pieces. However, the ankle that seem to break this rule.

The image on the left is the current ankle. The meshes are colored by which axis of rotation they are driven by – Red (X), green (Y), and blue (Z). The current geometry has the lower pieces locked together by the rod. This means the rotation order of the ankle is ZXY. In the image on the right, the geometry has been regrouped so that the rotation order of the ankle would be XZY.

In the current setup, rotating the FK ankle or foot in Z affects the entire limb below the knee. In the proposed setup, the same rotation would only affect the geometry below the ankle, which would be more intuitive in FK.


The other issue I have with the rig is the spine. It seems so simple – six identical mechanisms forming a chain between the chest and hips. Unfortunately, they are rigid mechanisms, so a spline IK wouldn’t work. My first iteration used a spring IK, but I found it unstable – it couldn’t or wouldn’t return to its default state when I reset the controls. My last iteration just used a rotate plane IK, but it doesn’t react to the rotate X of the IK controls the way I like. I’m sure if I spent as long on it as I did on the legs I might stumble on a better solution, though.

The spine, tail, and neck also presented a challenge of automation. There are over fifty flaps along these three chains, which quickly interpenetrate when the chains deform. Hand animating all of these flaps would be tedious. I explored ways to fake collisions, but it proved to be a difficult task, especially in the spine, where any single flap could collide with two or three spine mechanisms, and other flaps.


Tooling and guiding the components proved a good learning experience. I am intrigued by the possibilities of an auto rigger where you only have to wait on the file I/O, rather than long winded build scripts. Given the complexity of modern rigs (especially in the face) I recognize that some components might require additional tooling – such as a spine component being able to change the number of joints. Despite the complexity of the rig, I was still able to keep the guides translate only. It turns out you can infer a lot of information from what is essentially a point cloud.


I hope you all have enjoyed following along with the build. The entire adventure has been immortalized on Twitter with the hashtag Curiosity Rigged the Cat.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s