Browse the wiki

01. Rigging fundamentals

This lesson will look at the main tools used in rigging, including parenting and hierarchies, joints, constraints, rotation order and gimbal lock, creating clean controls, and the differences between FK and IK.


The following zip file contains the model used for this course and the final rig.

Planning a rig

Before jumping in and creating a rig, I always like to take a bit of time, grab a bit of paper and plan things out before hitting the keyboard. The first thing I tend to during this planning stage is to break down the type of movement that the rig will need to perform. Do your best to get hold of the storyboards, the animatics, video reference, etc, and examine them, then you’ll be able to better create a rig that is fit for purpose. Being fit for purpose is key; why spend time creating parts of a rig that will never be used?

So you know what the rig will need to do. The next thing you’ll need to figure out is how to best create a rig that is animator-friendly. This is where you need to open up communication lines with the animators. Find out what kind of controls they like: FK or IK? Both? Do they want automated clavicles? Would they like pole vector controls for elbows and knees? Remember that while it’s your rig, it’s the animator’s who’ll be using it, so bear their needs in mind throughout the creative process.

So as the rigger, I know that the objective is for the rig to be able to handle a walk cycle. This may sound simple enough, but I want it to maintain volume in areas such as the shoulders, the elbows and the knees. I need it to give a sense of there being an anatomy beneath the surface exterior. Basically, I don’t want a walking jelly man.

For the torso, I’m sure I could stick with a simple FK spine, but I’ll want to have independent control over the pelvis and the chest regions. For the arms, as they’ll mainly be primarily swinging from back and forth, I could also stick with an FK setup. For the legs and the feet, I know they’ll need to make contact with the ground, and therefore I’ll need some kind of setup that stops them from penetrating the ground plane, which would suggest IK. For the head, I’ll want it to follow the orientation and position of the neck mainly, but I’ll also want to allow it sometimes to follow the orientation of the torso or hips.

So that’s my wish list as a rigger. We now need to examine the needs of the animator, which happily here is also me! Firstly, I’d like to work with as few controls as possible as I value being able to work as freely as I can, but I also want sufficient controls to get the animation done efficiently. Take the spine, for example. There are 5 lumbar, 12 thoracic and 7 cervical vertebrae, and if a rigger handed me a rig with 24 controls for the spine alone, I’d be a little overwhelmed. 3 or 4 FK controls would do nicely, with perhaps the added ability to translate and stretch the spine slightly.

For the arms and the legs, I like to be able to switch between FK and IK mode. This gives me a bit more freedom to decide how I can approach a shot. For the fingers, I want to be able to control each digit independently, but I also want a few controls that will allow me to quickly pose the hand so that I can, for instance, relax the fingers or create a fist without too much fuss. The same goes for the toes. And lastly for the foot, I’d like one control that allows me to roll the foot back onto its heel, rock onto the ball of the foot and then forward on to the tip of the toes.

With all this information to hand, it’s time to start designing the rig on paper. A few preliminary sketches should help define where the joints will go, the controls that we’ll be creating and the general look of the rig. As you do this, think also about where the body is most flexible and where it is more rigid. Take the spine for example: the lumbar region is extremely flexible whist the thoracic region is less so as it carries the rib cage. Moving from paper to keyboard now, it may also be worth your while to take the model, chop it up into masses such as the torso mass or the upper limb mass, and then run a few tests to see what would and what would not work. The more you think, plan and test, the less time you’ll spend having to rework should the rig fall short.

001. Introduction


Here we will take a look at the final outcome from this rigging course.

002. Parenting and hieirarchies


If you examine any rig, what we have at its core is a series of relationships and connections, much like a family tree. One way to build these connections is through parenting.

Parenting is the process of allowing one object (parent/master) to lead another object (child/slave). The useful thing about parent-child relationships is that although the child object will follow the parent object however it is transformed, the child object will still have the ability to be manipulated independently, which can come in very handy.

So by creating parent-child relationships you start to build hierarchies. A hierarchy of a few tiers is simple enough to comprehend, but when it comes to rigging, you’ll soon be creating hierarchies that resemble the family trees from The Lord of the Rings. It’s important therefore to make sure that you are fully aware of all the connections you’re making, and crucially, you name everything as you go.

Every object that you initially create in Maya (presuming you have Interactive Creation disabled) will be a child of the World and created in the World centre. If you translate that object around and then want to return it to the World centre, you can do so by simply popping values of 0, 0, 0 into the translate channels. Now let’s say you have two objects, which we’ll refer to as A and B, and you position them randomly in the scene. By default, both objects will be children of the World, but let’s say you parent object B under object A. Now, if you zero out the translate values for object B, you should notice that it pops to the same position as object A, its parent. This is significant as it means we are able to give objects a new position anywhere in the world space and it becomes their new World centre.

Having seen how we use objects, we’ll now take a look at using group nodes to build parent-child hierarchies. A polygon cube, a nurbs sphere, a camera and so on, all have shape nodes as well as transform nodes associated with them, allowing you to grab them in the viewport. If you jump into the Attribute Editor with any one of those objects selected, you’ll notice a tab with <objectName>Shape. Sometimes, however, you’ll want to perform parenting tasks with objects that you do not want selected in the viewport. This is where group nodes come in handy. To create a group node, you simply hit Ctrl+G. If you have an object selected whilst doing this, you’ll get a node called group1, and if you don’t have an object selected, you’ll get a null1 node. Both do the same thing: they are simply transform nodes with no shapes associated with them. Have a look in the Attribute Editor to see what comes with them. They are very useful as they allow you to organise and structure your rig, while they also play a crucial role when creating controls, but more on that later.

003. Constraints


Constraints are another way to build relationships within Maya. They differ from Parenting as rather than affecting the hierarchical structure, they simply create a constraint node that lives under the constrained (slave) object. Where parenting also affects all of the transform attributes, with constraints you can define which attributes they should affect. For example, an orient constraint will only affect the rotate attributes. The constraint node that gets created also comes with a weighting value that allows you to define how much influence the master object has over the slave object.

Unlike parenting, which allows you to still manipulate the child object, with constraints, the weighting value will need to be disabled for you to do so. Furthermore, and another advantage of using constraints, is that you can have multiple objects influence a single object, and then through the weighting value, decide which master object should have control over the slave object. This paves the way for creating FK/IK blending and space-switching later on.

004. Joints


Now we come to joints, which I regard as the nuts and bolts of rigging, literally and metaphorically. Joints will be the main influence on how your model deforms, so it’s important that we have a solid understanding of how joints work in Maya.

What sets joints apart from every other object in Maya is that they have a unique characteristic. Where every object, be it a cube, a camera or a light, has a transform node associated with it, allowing you to translate, rotate and scale the object, joints also have an orientation. This orientation attribute, known as jointOrient, gives joints an axis in which they can oriented. Now this may not seem mind blowing, but when you start to create your rig, you’ll see its benefits clearly as you place the joints. If you have more than one joint in a chain, this will create a parent-child hierarchy and more importantly, you should notice that the parent joint will always aim at its child joint (make sure the Move tool is set to Local). As you place your joints, if at any time you find that this is not the case, I strongly suggest that you go in and rebuild that part of the joint structure, otherwise the chances are that you’ll find the behaviour of your joint may be unpredictable or misaligned when you go to rotate it.

As joints will be the main driving force behind the rig, we’ll want to make sure their creation has been handled correctly. Here are some guidelines that I follow in order to ensure this.

Firstly, all rotate channels on all joints throughout the rig should have a default value of zero. The same will apply to the controls. This is to ensure that we can easily revert back to the original pose cleanly and simply.

Next comes positioning the joints. For the root joint of any chain, you can translate it on any axis. For all child joints, however, only translate them through one attribute, the one which relates to the length. By default, this is set to the Translate X attribute but we’ll be switching this to Translate Y, the reasons for which will be examined later. Although it may seem like this will restrict how we place the joints, I can assure you that it won’t. What it will do is ensure that you have a clean skeleton for your rig.

The last thing I’ll mention at this stage is that we need to maintain consistency throughout the rig. We can do this by making sure we follow a strict naming convention, which will be detailed in the appendix. Every joint will have a suffix of _jnt. Every IK handle will have a suffix of _ik and so on. By following this kind of pattern, you can make life easier for yourself should you need to debug anything. Plus, if there are to be multiple people working on the rig, or if some else has to finish what you started, then they can get up and running a lot faster.

So we have created consistency for the rigger, but we also want to consider the animator. With the animator in mind, we’ll need to ensure that the behaviour of the rig is uniform throughout. Flexion throughout the entire rig should be handled by the same rotate axis with positive values. Extension, on the other hand, should be handled by the same axis but with negative values.  So if the animator wished to flex the elbow joint on both sides, this could be achieved by rotating a single axis in one direction. The animation data produced by this motion can then be easily read in the Graph Editor, a tool which will be covered in the chapter looking at animation.

005. FK and IK


We now need to spend some time looking at FK (Forward Kinematics) and IK (Inverse Kinematics), which are the two main types of movement that an animator will work with. It’s important to know what they are, how they differ, and when to choose which.

In Forward Kinematics, the movement originates from the root joint, travelling down the chain using rotations. For example, when kicking a ball, the leg will rotate backwards from the hip joint, and then rotate further backwards from the knee. Following this the leg will rotate forwards from the hip, and the motion will continue from the knee, then finally from the ankle to actually bring the foot into contact with the ball. As you can see, the rotations work from root to tip. FK creates very smooth, very naturally occurring arcs of motion.

In Inverse Kinematics, on the other hand, a chain of joints is controlled using translations rather than rotations. The translations originate at a point at the tip of the chain, and are manipulated by what is known as the IK handle. As opposed to FK, where rotation moves from root to hip, in IK the rotations of the joints are calculated automatically from the IK handle up towards the root of the joint chain. Because IK movement originates from the tip and works towards the root, it is the best choice when an animator needs an asset to make contact (rather than penetrate) its environment. IK, for instance, is a good choice for the legs in walk cycles as each foot needs to hit the ground with every step. However, in that same walk cycle, it may be advantageous to use FK in the arms to take advantage of its smooth rotations for the swing needed here.

Each method of movement has its plusses and minuses from the animator’s point of view, and deciding which to use will often be based on the nature of the movement required by the animator. As we said before, open channels of communication need to exist between rigger and animator, and this is an example of when it is important.

006. Rotation order and gimbal lock


Rotation Order is something that is often overlooked in CG, when in fact, for riggers and animators it should be integral to their work. The term refers to the order of operation in which the orientations are evaluated.  As a default, all objects have a Rotate Order of XYZ (found in the Attribute Editor). When looking at this Rotation order setting, it is read most easily from right to left. XYZ means that Z will carry both Y and X, and Y will carry X. X has no effect on the other two axes. By default, when you rotate an object in Maya you are viewing the rotations in local space, so it seems as if no one axis is carrying another. However, by switching your rotate settings to Gimbal mode, you’ll be able to see a true representation of what the axes are doing. This leads us to the heartache that is Gimbal Lock.

Gimbal Lock is the term used to describe the situation when two of the rotation axes are sitting on top of each other. The result of this is that both axes will produce a similar rotational result, and you’ll have pretty much lost the ability to rotate the selected object on one axis. Of course, you’ll only see this if you are working in Gimbal mode; if you are working in Local mode, it will seem as if you always have the three axes readily available. Gimbal Lock isn’t something you’d choose to be in. So how do you best avoid it? The simple answer is that as a rigger or animator, you need to think about the kind of movement that is needed for a particular task, and then consider what rotational order is best suited to it.

To get a feel for Rotation Order and Gimbal Lock, in Maya create a primitive object such as a cube. Set your rotate mode to Gimbal and rotate the cube one axis at a time. Look at the results with the default rotate order (XYZ), then change them around and view the results once more.

007. Creating Controls


At this point we bring parenting, hierarchies, constraints and rotation order together and look at creating animation controls. On very simple rig, just animating the joints may well do the trick. However, a purely joint based set-up has considerable limitations, and therefore some controls need to be put in place to achieve greater flexibility and potential. Additionally, rigs are not always totally safe in animators’ hands, as in the process of animation, bits and bobs can be deleted – erroneously, I prefer to believe! And in general, recreating a deleted control will result in less of a headache than having to rebuild a joint, so it’s definitely worth reading on.

Using curves for animation controls is advantageous as they are non-renderable and therefore you don’t need to worry about hiding them before you begin rendering. The curve could be in the form of a custom-designed one made using the CV Curve Tool, or it could simply be a NURBS Primitive such as a Circle. Another plus point of using curves is that their shape can easily be edited, so your rig can be customized without too much hard work.  For example, I like to use circles for FK controls and squares for IK controls. Naturally, you’ll find your own way, but the important point is that using curves will simplify the process for you.

For every control, I create a small hierarchy using group (transform) nodes, which allows me to place and orient the control in the same exact location as the joint it will control. This is of great importance as it provides for secondary levels of control, while also allowing the animator to return the control back to the default position and orientation by zeroing out the translate and the rotate channels. The hierarchy should be arranged as follows: the top node in the hierarchy is purely for placement and will have a suffix of _offset to show this. The second node in the hierarchy will have the suffix of _auto to show that this can provide a secondary level of control. The final object in the hierarchy will be the animation curve, and the animator will be able to select it in the Maya viewport.

Controls can be positioned in one of the two ways detailed below. Both methods will give you the same end result, so which you choose will simply be a matter of preference. The first method is as follows: select the ‘_offset’ node, shift-select the joint it will control, and hit P on the keyboard. This parents the ‘_offset’ node under the joint. Now zero out the translate and the rotate values for the ‘_offset’ node so the whole control hierarchy snaps to the same position as the joint. You will also notice that the orientations line up. Now simply select the ‘_offset’ and hit Shift+P to unparent it from the joint. As a result, there should be some transform values back on the ‘_offset’ node. These are the co-ordinates of where this node is in World space. Leave them as they are. Select the ‘_auto’ or the ‘_ctrl’ and you will see that they both have 0 values for all the rotation and the translate channels, plus the orientations still line up to the joint. Perfect.

The second method is to select the joint that needs the control, then shift-select ‘_offset’ node and go Constraints > Parent (Options). Disable Maintain offset and hit Apply. The entire control hierarchy should snap into place. Now simply delete the parentConstraint node that lives below the ‘_offset’ node in the Outliner and again, you have a control in place.

Later on, we’ll be using a small script to automate the process of creating and positioning controls, as creating each control manually can be a very laborious process.

With the controls in place, the next thing will be to have them drive the relevant joint. We will do this with constraints. For example, we would select the Select ‘_ctrl’ object, shift-select the relevant joint and go Constrain > Orient (Options). Make sure Maintain Offset is disabled and hit Apply.

You should now be able to rotate the control and the joint should follow.

Leave a Comment