Rigging, the rigger builds the internal structure, the skeleton and creating controls the animator will use to bring the model to life by manipulating the three-dimensional object.

It needs to be animator-friendly, efficient, robust and well- organised.  It could be a character or a vehicle, firstly understanding what it is in reality, then considering how it needs to function, how it will be animated, how it works in a 3D CG environment and recreate the rig for the model to work efficiently.

Kinematics describes how joints can be moved to animate objects and characters in 3D computer graphics,

Forward kinematics refers to a situation in which each joint in the chain inherits the motion of its parent joint.  Movement orients from the root joint travelling down the chain by using rotations creating smooth and naturally occurring arcs of motion.

Inverse kinematics (IK) cause the joints in a chain to orient themselves based on the position of a goal known as the end effector.  The joints in the chain orient themselves and are controlled using translation.  The IK Handle tool is used to position the end effector.  The joint chain being manipulated by the IK handle and calculated automatically from the IK handle up towards the root of the join chain.

Euler rotation is calculated based on three angle values (X, Y and Z) plus the order in which the angles are calculated.  Euler rotation is prone to the problem of Gimbal Lock, where two of the axes overlap and lead to the same result. The standard in Maya.

Rotate order is the order of operations which orientations are evaluated.  The default is X, Y, Z  and viewing in local space.  Meaning Z carries both Y and X, Y carries X and X has no effect on the other two axes.

Gamble Lock is when two of the rotation axes are sitting on top of each other.  The result is that both axes will produce a similar rotation result losing the ability to rotate on one of the axis.

Building relationships and creating hierarchies with parenting giving the child a new world centre, the parent and affecting all transform attributes.  Group an object to itself, selecting only the object creating a group transform node and no group node.  Constraints, instead of affecting hierarchical structure, create a constraint node that lies under the constrained (slave) object and only affect the defined attributes.  Constraints also have weighting values to define how much influence the master object has over the slave object.  This can also be used for control between multiple objects that have influence on a single object.

Driven Keys are keyframes that are driven by the attributes of another object rather than time, creating a relationship between any two attributes. There is a driving object and a driven object or drive attributes on the same object.

Skinning the mesh to the joints allows us to deform the mesh for animation.  It is a process of assigning how much influence a joint has over a vertex, therefore defining how the skeleton will deform the geometry.

Some explanations from:

Amin, J., 2015. Beginner’s guide to character creation in Maya

Palamar, T., 2016. Mastering Autodesk Maya 2016

NICO SANGHRAJKA: ON BRINGING DEADPOOL TO LIFE:  Find out about how Nico Sanghrajka rigged anti-hero Deadpool, motorcycles that crash, and SUVs that explode!



When planning any rigging, it is important to have enough reference to understand how something should move, and what kind of limitations it has. With mechs, there is not as much deformation as there would be in organic characters, but there are a lot more limitations on the range of motion. As a result, the design may have to be compromised for functionality. For example, a human arm has plenty of freedom in its mobility, however this also adds complexity because shoulders have so much more range. That makes it difficult to have it deform correctly and may even require working muscles.




Research and development I have undertaken into 3D rigging during the second part of my Rigging Studio 1 subject.

This is a tutorial for a broken hierarchy character rigging system describing how to construct an FK Arm control module and an IK Arm control module, including how they are integrated with a bind skeleton with IK/FK switching functionality.

Why are we using the FK and IK modules for the arms, what is their purpose?  Our arms have different movements where they can either move freely or when touching something the movement is from the point of contact back up the body. The rig modules will be kept separate from the bind rig and the animator will have the ability to switch between these movements and incorporate them into the character’s movements.

Rigging uses Forward Kinematics or FK and Inverse Kinematics or IK to allow for this change in movement.

“FK rotates the bones directly at their top joint to assume poses.” 

“The rotation of a joint affects the position of the bones and joints beneath it in the hierarchy.  If you rotate the hip up, the knee and ankle swing up as if the character is kicking”

Derakhshani, Dariush. Introducing Autodesk Maya 2013. 9th ed. Indianapolis, Ind: John Wiley & Sons, 2012.  page 394

“IK uses a more complex, but often easier, system of IK handles that are attached to the tip of a joint system.  The corresponding base of the IK system is attached farther up the skeleton hierarchy to a joint determined to be the root of the IK segment. It need not be the root joint of the entire skeleton, though.  The bones and joints in the IK chain are affected only by movement of the IK handle.  When the handle moves, an IK solver figures out how to rotate all the joints to accommodate the new position of the IK handle.  Moving an IK handle causes the bones to rotate around their joints to accommodate a new position.”

“Moving your hand causes the bones in your arm to rotate around the shoulder, elbow and wrist.”

“…..the animation flows up the hierarchy and is therefore called inverse kinematics.”

Derakhshani, Dariush. Introducing Autodesk Maya 2013. 9th ed. Indianapolis, Ind: John Wiley & Sons, 2012. page 395

The modular rig is not about transferring the control systems, the modules are independent of the bind skeleton, controls are not being mixed together.  The only values that are transferred to the bind joints are the values of the joints themselves not the control systems, thus being integrated by transferring the end result of the joint’s movement into the bind skeleton.  There can be many module systems, it does not matter how they are made, it is all about transferring the rotate values of one set of joints to the rotate values of another set of joints.

It is about setting up two different sets of controls for the arms, having different sets of joints that are controlling the system in a particular way when they are connected.  They are linked to the original bind skeleton by connecting the rotate values of one set of joints to the rotate values of another set of joints, the input values to the bind skeleton.  This is how the FK and the IK control rig systems will drive the bind skeleton, allowing the animator to blend between the arm modules with a switch. The controls can transfer from one system to another without popping, flipping or spinning.


The bind skeleton has been built by connecting joints in a hierarchically system with each joint’s default orientation being aligned with its bone. The x-axis of the rotation is aimed along the length of the joint, pointing down toward the child joint.

Before binding the geometry to the rig we need to consider a couple of things because what is chosen now with the orientation will affect how the weights are painted around these areas.  We can change the rotate order after binding, the orientation does matter before binding.   Joint orientation contains information about the direction and angle of the X, Y and Z axis and the range of motion.

Firstly we are looking at the orientation of the clavicle.  The default orientation of this joint is not giving the motion that is required from the shoulders, it is not ideal for the up and down and the forward and backward motions of the shoulder. When using the orient tool it always relates to something, their parent, world, hierarchy and will not give us the custom movement the joint needs.

The rigged shoulder does not working the same way as the shoulder in our bodies, there are multiple influences in the body, the muscles are pulling in different ways.  In a rig we are not using muscles to drive the bones and the custom orientation will help to simulate that part of the body by giving a more natural movement.

We can set up a custom orientation of the clavicle joint by slightly offset it to give a motion that relates better to the way we move the shoulder.  It is manually changing the default orientation.  There is not a value here, there will be an offset which we cannot copy, we need to pay attention to be able to do the same on the other clavicle joint. What is the joint going to be used for in the finished rig? Will something be plugged into it as part of the multi-module rig? Using broken hierarchies means having multiple skeletons, separate pieces that can control different joints. When multiple things control the joints they need the same orientations.  It is not using this joint to connect multiple systems.


Orientation from the top view as the default and custom joint orientation. The bottom image is a front view of the custom orientation.

To adjust custom orientation before binding

  • go to component mode
  • select the question mark and choose local rotation axis
  • set the rotation tool to local rotation, will not work in Gimbal

Another area of the arm that need consideration before binding is the wrist and the action of the forearm. There is a clear twisting action with the wrist that is being driven by the twisting of the forearm, in fact the wrist is not doing the twisting. Again in our bodies the muscles are responsible for the twisting and with our rig and the bind there are no muscles.

This has been achieved by including an extra joint on the bind skeleton, the foreArm between the elbow and the wrist joints. When looking at how the wrist works the wrist and forearm rotate at different rates, independently of each other or what could be called a graded twist. If the wrist is twisted 90 deg then the forearm needs to twist 45 deg. How can this be automated?

There are several ways this can be considered and we looked at the following:

  •  Using two locator controllers to control the orientation of the joints, one for the wrist and one for the 005_twoLocatorTwistforearm. When it is rotated the child is not left behind, the hierarchy is overriding the rotation from the controller. This rotation will also affect the bound skin, a double twist. If they are rotated separately then they work like a hierarchy and not really doing the graded twist.
  • Set Driven Keys using the Wrist as the driver and the forearm as the driven and working off Rotate X. 006_classSlideSDKex008This can be set up so when the Wrist is rotated 90 deg the forearm will rotate 45 deg. The problem arises when needing to go to the Graph Editor to adjust the tangents and these other factors come into the calculations. It is cumbersome and a potential problem when animating. Also what is the hierarchy doing? When I rotate, it is back with cyclic error potential, an infinite loop with the wrist telling the forearm to rotate and then the forearm telling the wrist to rotate. There is a curve in-between the two set driven keys which is affecting the calculations.


  • If there is a controller with an Orient Constraint to the wrist and forearm telling them both to rotate, there is still the cyclic error problem and they are both rotating at the same rate. Adding another controller to tell the forearm twist, what to do, there are two weights in the Orient Constraint which will split the input which is averaged down to 1. Could adjusted to 0.4 and 0.6,  though still getting the cyclic error using things inside the hierarchy. Constraints have flipping issues because of using the shortest path.
  • Another option that is considered is Blended Constraints, it needs an expression to affect the expressioninfluence.  An expression is not the best option because when running an expression it can slow down the process, especial when the rigs become more complicated. foreArm.rx=loctaor1.rx/2.  It does work as the locator has nothing to do with the Wrist rotation, it is influencing the forearm joint via the script, bypassing the cyclic error issue and giving half the rotation to the forearm. Can then use an Orient Constraint directly to the wrist.

This is leading to the solution that was used. Instead of using the expression Maya has a multiplyDivide Node that does this. This gives a solution that is stable by controlling the forearm and wrist outside the hierarchy and independently of each other. The same controller is driving them independently. This is how it is set up.

  • create a locator and rename l_wrist_loc, V snap to the left wrist, freeze the transforms and scale to 0.2.  The locator has this custom scale as it does not have a proper shape node.
  • duplicate the locator, snap to the right wrist and repeat the above
  • buffer group for each locator to take the values, name it r_loc_buffer.
  • the right side has different orientations, move the buffer group Pivot Point to the wrist joint before changing the orientation of the buffer group to match the joint. Do the same on the left side so they are consistent and match, even though the orientations are not an issue here.
  • select the joint then select the locator buffer group and Parent Constraint with maintain offset off and delete the constraint. Could use the Right Hand Rule thought the constraint does it for us.
  • can use the Move Tool set to Object mode to check that the orientations for the buffer and the joint are the same or turn on Local Rotation Axis

This is now set up to do the automated wrist twist using the multiplyDivide node.  One of the main reasons for using this is the maths behind it, it is a direct connection and integrated into the system, being more stable over the long term, more robust.


To set this up we can use either the Hypershade, which connects using the Connection Editor,


or the Node Editor, which opens the nodes directly using a drop down list to make the connections, with no need to use the Connection Editor.

Using the Node Editor

  • select locator and the Forearm joint and load into the Node Editor. Do not need the Shape or Elbow nodes, only the transform and the object that is being controlled.
  • create a multiplyDivide node and put between the locator and forearm nodes, rename it l or r-twist_
  • from the drop down options in the nodes select the Locator’s Rotate X Output and connect to the multiplyDivide’s Input1, Input1 X option.
  • take the multiplyDivide’s output, Output X and connect to the input of the Forearm’s Rotate X. Only twisting in X.
  • select the multiplyDivide node in the Attribute Editor and select the Divide operation. Then in Input 2’s first box enter 2, the bottom value.


What is happening with the multiplyDivide Node is it is using the value from Input 1 and is dividing by the value in Input 2.  When Input 1 is = n then n divided by 2 = half of n. If I divide by 0.5 it will double the value. The node is outputting the result of the calculation which is what was happening with the expression earlier.

To finish the automated wrist rotation

  • select the wrist locator and the wrist joint and in the node editor make a direct connection between the locator’s Rotate Output and the wrist joints Rotate Inputs. With a direct connection if something goes wrong it can be changed so long as the locator and the joint always line up.

The automating part of the forearm twisting functionality was applied to the bind skeleton rather than the control modules, then the control modules do not need to worry about it.

Check that it works, rotate the locator 90 deg and in the Channel Box the Forearm joint will be 45 deg.  Rotating the wrist gives a half rotation on the Forearm.

Check that it works, rotate the locator 90 deg and in the Channel Box the Forearm joint will be 45 deg.  Rotating the wrist gives a half rotation on the Forearm.

Now there is the issue of the Controller (the locator) not following the skeleton. Need to look at what is being used, what is being controlled, what it is affecting and what can be done to solve the problem. Will not use a parent because it needs to be kept separate form the hierarchy, translate is not being used for the wrist rotation, it can be used to have the controller follow the skeleton. A direct connection will not work because translates on joints cannot be frozen. A constraint uses the pivot points in local space, the direct connection uses the numbers.

  • select the joint then the controller and use a Parent Constraint.



Select the root joint and the Proxy Geo Layer

  • Skin
  • Smooth Bind Options:  Joint Hierarchy, Geodesic Voxel, Weight Blended, Post, Select Allow multiple Bind Poses, Max Influence 3, Maintain Max Influences OFF, Remove Unused OFF, Colorize Skeleton OFF Include Hidden Selections on Creation OFF, Falloff at 0.2, Resolution 256, Validate Voxel State SELECTED. Only select one skin.


The setting up of the two different sets of arm modules. Using three joints, there is no need to include the forearm joint as this has been set up for the wrist twist with the bind skeleton using the wrist locator. The wrist twist is being driven by the wrist locator which is driving the forearm joint.  If a rig was being made where the wrist might need to be changed than this would need to be set up differently, consider an independent wrist system though we are not doing that for this rig.


The locators are set were the joints are for the bind skeleton for the FK and IK arm modules to match and use a FK/IK switch between them.  Joints have translate information on them and cannot be zeroed out.

  • Skeleton > Joint Tool > default settings
  • V snap joints to the locators creating three joints and two systems, one for the each the right and left arms.
  • Check the orientations of the joints by selecting the top node and right click and select hierarchy to select the joint chain. Then Display > Transform Display > Local Rotation Axis and do for both sides.


The left side is ok as it matches world space, the right side is working differently because the end joint is not matching the other orientations, X is facing the opposite direction. The end joint is at world space and needs to be oriented up the chain to match the other joints in the hierarchy, relative to its parent, the child needs to point to its parent not the environment or world space.


  • Select the end joint on the right hand side, can use the right hand rule which is open to error when setting in different systems in how the rotations may be calculated. It maybe +180 in one and -180 in another and they are actually 360 deg apart, or have Maya do it for me. Go to Skeleton > Orient Joint Options > rest > Orient Joint to World, its world.
  • Check the orientation of the bind skeleton and make sure they match.
  • Rename the joints to l_shoulder_FK_jnt,  do for the elbow and wrist and on both sides, r_shoulder_FK_jnt.
  • Put the locators in a Layer, would normally delete, going to use for the IK module.

Setting up the control curves for the FK arms, the rotate, translate and pole vector controllers.

  • V snap the first rotate controller and rotate to line up. Duplicate for the other joints and adjust the size so it can be seen outside the model and selected by the animator.
  • Name, Freeze Transformations, Delete History. l_shoulder_FK_ctrl, do for the others and both sides.

How are the controllers going to be set up, as a mirror or parent hierarchy with the joints? Need to consider how it will work when the rig is finished and integrated. What do I want the joints to be doing? The joints that the curves control will be driving the bind joint and how this is set up will affect how the modules go together. Keep it independent, do not want something like the controller telling the joint to rotate and this joint is telling the bind joint to rotate, doing it twice. Seting up a system where there is a switch between one set of controls and another set of controls and keep them independent – a standard rotational hierarchy or mirror hierarchy. The controls are separate from the joints, in separate hierarchies, independent of each other.

  • First set up the buffer groups or a null group. Control G with nothing selected and V snap to the first shoulder curve, freeze and move the pivot point.
  • Name the buffer l_shoulder_buffer.
  • A Parent Constraint is not necessary on the left side because the orientations match. When doing the right side then the orientations will need to match.
  • Put the shoulder curve into the buffer, which is already oriented correctly.
  • Repeat for the other controllers, group the elbow controller to itself, move the pivot point to the elbow, rename, freeze. Again repeating for the wrist. Shifting the pivot points incase something need to be done later and it is know where the pivot point is.
  • There are three controllers in three buffer groups on the left side with the joints in their parent hierarchy and want to do the same for the controllers. The buffer is on the top of the hierarchy such as the wrist buffer into or parented to the elbow controller, the elbow buffer parented to the shoulder controller. The buffer groups do not move, do not appear on the interface, they are not animated, they parent objects to hold values. The controllers are what is changing. Do the buffers on the left so it is consistent, looks and works the same as the right.
  • Connect all the joints up by selecting the control then the joint > Constrain > Orient Constrain options with maintain offset off. Do for all the controllers on the left. Select the control, the joint, G.
  • Point Constraint for translate, select the shoulder joint then the shoulder controller > Constrain > Point Constrain with maintain offset off. If the joint moves everything will follow. A constrain to hold it all together, not a parent constraint as it has rotate and translate with an independent pivot. Already have an orient constraint on the joint from the controller, the curve is telling the joint to rotate and then there is a joint telling the curve to rotate ending up with a cyclic error with both controlling each other.
  • Create a Left Arm Module Group by selecting the l_shoulder_FK_jnt and the l_shoulder_buffer_group.


For the Right Hand Side do the same except for the buffer groups. It is important because the orientations do not match. The left worked because they are the same direction as world space.

  •  – Deselect everything and create a Null Group. Will build the group hierarchy first then put the curves into the correct groups then there is no need to reorient all of them, they will automatically have the offsets.
  • Rename r_shoulder_buffer, move the pivot point to the shoulder
  • Duplicate and rename elbow and move the pivot point to the elbow joint and do the same for the wrist.
  • Parent the buffer groups, the wrist to the elbow, elbow to the shoulder.
  • Orient the buffers
  • Select the shoulder joint and the shoulder buffer, Constrain > Orient Constrain with Maintain offset off. There will be a 180 deg offset on the shoulder and will not be there for the elbow and wrist because of the hierarchy, not need to constrain the rest of the hierarchy as the hierarchy has done it with the child oriented to the parent.
  • Delete the Orient Constraint, only used to orient the buffer.
  • Put the shoulder into the shoulder buffer, elbow into the elbow buffer and wrist into the wrist buffer getting the control curves into the hierarchy.
  • Make sure the controllers have the right names, freeze and delete history. Check the controllers can be zeroed out. The top buffer group will have the 180 deg offset.

Fix up the hierarchy to match the left arm.


  • Each buffer goes into the controller of the one above it and can see this in the outliner. The shoulder buffer has the shoulder controller as its child, then the shoulder controller has the elbow buffer as its child, then the elbow buffer has the elbow controller, the elbow controller has the wrist buffer as its child with the wrist buffer as the parent of the wrist controller.  The controller needs to affect its buffer as the buffer is there to hold the offsets values, with the buffer being the child of the controller with is up in the hierarchy.
  • Check here because they have not been connected to the joints, make sure it works and can be zeroed out.
  • Connect the joints up with an Orient Constraint. Select the controller then the joint > Orient Constrain with Maintain Offset Off for the shoulder, elbow and wrist.
  • Finally a Point Constraint from the joint to the shoulder controller so everything follows.

Check and make sure it all works, can zero it off, then group together and name R_FK_arm_module

Make a layer and call it FK_arm_module_layer  and  SAVE


  • Bring back the locators, turn on the locator layer and make a new set of joints.
  • V snap to locators, rename l_shoulder_IK_ jnt. Do for each joint and both sides.
  • Check the orientation, the same as we did for FK. Reorient the right wrist joint to Orient Joint to World so it follows the parent and check orientations with the FK module.
  • Set the preferred angle by selecting the elbow and rotate in one direction, the direction it is going to move.
  • Hide the locators
  • V snap the controllers into place on the wrist, duplicate and V snap to the other wrist and rename them l/r_IK_translate_ctrl. Freeze Transforms, delete history and make sure it can be zeroed off.
  • Pole Vector Controls in Place, V snap to the elbow, duplicate for the other elbow then move behind where the object will move to. Freeze, rename, l/f_IK_poleVector_ctrl.

IK is translate and for this there is no need to be concerned about offsets, does not need world space. Translate has no orientation issues, it is a point in space, no rotate orders as there is nothing going on in-between.

Do need to rotate the wrist and for this IK rig, either another controller that rotates the wrist with the IK system or use this controller to rotate the wrist as the IK stops at the wrist.    For this rig there will be a buffer for the controller to rotate the wrist as the orientation of the controller and wrist needs to be the same with no offset values.  Only need to do on one end, the wrist controller as it is the only one with rotation. There are two controllers that can be used to rotate the wrist with buffer groups to take the offsets. Do not need to do for the left as its orientation is in the right direction, do both so they look the same.

  • Create a buffer for the right wrist controller and rename r_IK_buffer.
  • Select the joint and the buffer and use a Parent Constraint, Maintain Offset off. Instead of moving the pivot it has been done with the orient with the Parent Constraint.
  • Do the same on both sides, even though the left does not need to be oriented need the same system on both sides. Make a group, centre the pivot and rename.


  • Skeleton > IK Handle tool options, will do the same for both arms. Choose Rotation-Plain Solver and select the joints on either end of the hierarchy. The direction does not matter, it knows the hierarchy’s direction and will always go the right way. Rename l/r_IK_handle

Now to hook up the controls, the IK Handle is constrained to the Pole Vector and the IK Controller

  • Select the Pole Vector Control then the IK Handle > Constrain > Pole Vector for both arms.
  • Attach the IK Handle to the controls, Select the Controller then the IK Handle > Constrain > Point.

To set up the rotation, the IK has no rotational influence.

  • Select the Controller then the wrist > Constrain > Orient with Maintain Offset off. To check the rotations work on the wrist when rotation the controller the values will change on the joint. To see this select the joint and look in the Channel Box.


Group into a r_IK_arm_module and a l_IK_arm_module


Need to tidy up before bringing into the bind skeleton file and start putting it all together.

Do not want any left overs such as locators, materials, nodes and history. Can always redo in the other file. Named correctly, organised so everything can be found easily and get rid of anything that does not need to be in the scene.

  • Delete the geo, tempGrop and tempGeo and display layers, they can be set up again later and turn off the rotation order displays on the joints. Make sure the Pole Vector Controllers are out of the tempGroup.
  • Layers, delete all of them.
  • Hyper shade > edit > delete unused nodes. Any node that is not plugged in.
  • Outliner, nothing there we do not want.

Save as a new name with clean or import ready as part of the name

Open the scene with the bind and wrist twist that are ready and set up.

Do not want to be binding when these modules are attached, there maybe some tiny values and even when everything is straight the tiny value somewhere can cause some issues with the bind and by the end of the fingers things may not line up properly.   Sort out the bind rig first and make sure that is all working properly. The modules are build based on that rig, the locators line up.


Import the file, turn off name spaces, tick group and the file will come in as a group to help with any naming conflicts. Tick remove duplicate shading network. Namespace options to classing nodes and this string as _a.



The joints rotate, so hook up the rotations of the joints, the control joints to the rotation of the bind joints. Not using a direct connection as there is more than one control system and they need to work at the same time and also where the values can be changed so I can tell the system which one to follow. Will be using constraints. Could use the multiplyDivide node but this will not give me one or the other, it would do both at the same time.


There was a problem with the wrist twist and hand flipping later on in this tutorial when connecting the FK and IK modules. Direct connections and constraints do not play well together even though there appears to be no reason why not.  An extra node has been created, a unit conversion and with the direct connection as soon as other things get involved it needs to get a value from somewhere and it starts pulling the value from the hierarchy, especially on the right side, dragging the offset from hierarchy instead of inheriting it. There starts to be issues with the constraints because of the way constraints and direct connections use their information, it is different. The direct connection needs to be deleted and rebuild with a constraint so the direct connections and constraints are not being used together. Constraints are always independent, they do not get involved in the hierarchy. Delete the direct connection before connecting the FK and IK modules because once everything is connected deleting  the direct connection will not work. The connection has already been created, it stays in the background and continues to create problems.


  • this was created when setting up the bind skeleton and needs to be deleted:  select the wrist locator and the wrist joint and in the node editor make a direct connection between the locator’s Rotate Output and the wrist joints Rotate Inputs
  • now delete this connection between the rotate to rotate of the wrist locator and the wrist joint in the node editor
  • Getting rid of the yellow value in the channel box. The connection with the multiplyDivide node is still there. Once it has been removed it needs to be added back in with an orientConstraint.
  • select the locator then the wrist > Orient Constraint and maintainOffset OFF.
  • Turn on the FK layer and do not need to see the controllers so put them in a layer and turn off.

Remember about the wrist twist, the locator is twisting the wrist, its rotations which are controlling the forearm. To control the wrist twist there needs to be a connection to what is rotating the wrist, it is not the joint. The joint is being influenced by the locator. Need to attach the control system to the locator on the wrist.

  • Select the left wrist FK joint and then the left wrist locator on the bind joint > constrain > orient. If something flips or moves then something was oriented incorrectly.
  • There rest are joint to joint orient constraint and do the same on the other side.
  • turn on the controls

The bind skeleton wrist already has something controlling it, the locator.  When connecting the FK controls to it select the locator on the Bind Skeleton for the wrist, not the joint. Using the FK control system to drive the Bind joints system.

Check as you go, test at each stage, the rotate values are at zero, the controls work, check the hierarchy so that the buffers have the offsets, the controllers can be zeroed off, rotation set to gimbal, the wrist twist is still working.


The FK is now working on the bind, there is a problem, the wrist is turning the hand. The rotation is travelling down the hierarchy from the shoulder to the locator. This is meant to be happening through the hierarchy, it is a mirror hierarchy. It is getting the rotate value from the shoulder. There is a yellow value in the channel box for the bind wrist joint, a direct connection and direct connections and constraints do not mix well.  This needed to be broken before connecting the FK and IK modules as described at the beginning of this section and following here.


  • break the direct connection between the rotate to rotate of the wrist locator and the wrist joint in the node editor.  Get rid of the yellow value in the channel box. The connection with the multiplyDivide node is still there. Once it has been removed it needs to be added back in with an orientConstraint.
  • select the locator then the wrist > Orient Constraint and maintainOffset OFF.


The constraint is doing the same thing with the locator controlling the joint. Using a constraint instead of a direct connection. The FK and IK arm modules are being integrated using orient constraints when they are hooked up and direct connections cannot be blended.

The FK control system is only controlling the rotation, the joint is being controlled with the rotate of the controller, translate is not being affected which means it is not travelling with the bind skeleton.

Select the clavicle bind joint then the arm FK module and constrainParent, the module does not have the orientation values to match the clavicle bind joint. By taking the joints and the control system out of the group it makes a null group. This can then be oriented to the clavicle joint and it will gain all the orientation and translate values of the clavicle joint. Because the joints and control hierarchies have been taken out they are not directly affected as they would have been had they been left in the group. The group matches the orientation of the clavicle joint. Put the two mirrored hierarchies back in the group and as it is already constrained they go in with the offset already in place. A buffer group has been created. The group is receiving all the orient and translate offsets and not transferring anywhere past the shoulder buffer.

  • take both out of the group and then there is at the module null group so they do not inherit the offsets
  • put the pivot point on the clavicle
  • parent constrain the armFK module to the clavicle to reorient it to the clavicle joint Select the clavicle joint then the armFKmodule Null Group
  • put back the shoulder and buffer hierarchy
  • do for both sides



Make sure the direct connection has been broken, as described at the beginning of the section, before connecting the FK module.  The IK shoulder joint hierarchy needs to be in the buffer group with the controller.

IK joints are rotated based on the position of a goal called an end effector.  To connect the IK module to the Bind Skeleton, start the same as done for the FK by

  • select the joint, left_shoulderIK_joint then the left_ShoulderBind_joint and orient constraint
  • do the same for the elbow and wrist locator
  • on both sides

For the bind joint in the channel box there will be two inputs, FK joint and IK joint.

There is the same problem as the FK module, it is not following the bind skeleton. The difference between the two modules is that, the IK is translated based while FK is rotations. The IK has nothing controlling the rotate, no rotate inputs and there is no mirror hierarchy from the arm control module so it cannot be connected the same way. The IK handle is involved and it is not needed to follow the skeleton, needs to stay behind. Cannot do the same thing with the IK, it is a reverse system.

  • point constrain the shoulders so they follow, the IK shoulder to the bind shoulder.

There was a problem in our class with this, some people were getting unwanted values with the rotations. Make sure there are no values on the joints either FK or IK rig, rotate values or offsets values on the joints. If so there is a problem. Ignore translate as joints always work in world space.  Couple of zeros is ok only on IK, not so much on FK.

Again this is a problem caused when the direct connection that was not deleted before starting to add the FK and IK modules. When the direct connection is deleted from the bind skeleton first this problem does not occur and the work around below is not required. How to do this is explained at the beginning of setting up the section for connecting the FK module.


Needed to undo because when more than one orient has been mixed together they do not make another constraint node, it adds the weight to get the two inputs on the one node. Other than undoing the only other way is to delete the constraint node and reconnect both the FK and the IK. Check the bind joints and the locator that they have FK inputs and no IK inputs.

Will do the same thing that was done on the FK system, use a buffer on the clavicle and retain the custom orientation on the clavicle. Do not have this problem on the left because we do not have the 180 deg offsets.

  • pull everything out of the IK arm module group, the IK control buffer and the IK handle starting with an empty IK group
  • parent constrain the IK module null group to the clavicle joint. The null group will gain all the offsets from the clavicle, inherit the offsets
  • put the pv control and shoulder joint back into the arm module group, leaving out the IK handle and the IK handle control, make sure the default values of the pv controller have been reset to zero
  • connect the rotate values of the IK joints to the bind joints, shoulder to shoulder, elbow to elbow and wrist to wrist locator

The bind skeleton moves the IK follows from the shoulder and the rest of the IK system stays behind.



Creating a switch that the animator can use to move between the FK and IK arm modules. There are three joints, the shoulder, elbow and wrist locator and two sets of controls the IK and the FK telling the bind joints what to do.  The IK is driving the bind and the FK is driving the bind and the SDK is a switch between which system is driving the arms joints of the bind skeleton.

The switch will move character’s arm from Forward Kinematics, which is Rotations, to Inverse Kinematics, which is Position, by changing the added attribute in the channel box from 0 to 1.

The IK handle bends with translate even though it is still rotating the joints, it is doing it in the background. These joints are telling the bind skeleton to match those rotations and there is the the switch saying which system to follow.


  • create a controller to use for the switch for both the left and right sides and add the switch attribute
  • in the channel box > edit > add attribute. Call it IK_FK_switch, float, min = 0 and max = 10 and default = 0.
  • IK = 0 and FK = 1


  • animate > set driven key > set
  • the driver is the left/right switch controller
  • the driven are the orient constrains that have been set up between the modules




In the Channel Box set the IK_FK Switch depending on which module is being connected for each of the driven attributes. When at zero follow that one and at at one follow the other one.

– hand controller channel box is set to 0 for IK.

– select the r_elbow_orientConstraint want FK off and IK on = 0 and 1

– make sure to select the two values for the driven and KEY

Repeat for all the constraints and both sides.

Two check turn on the two systems and when switching in the channel box it will follow one and not the other, using the IK_FK switch to blend between them. If it is at zero it is only following the IK, if it is set to one it is only following the FK

Remember to make sure the animation curves are set to linear. It is an animation between keyframes and the blending will not work smoothly otherwise, it is up to the animator to decide how the blending will be animated.



Cabrera, Cheryl. An Essential Introduction to Maya Character Rigging with Dvd. Boston, MA: Elsevier, 2008.

Derakhshani, Dariush. Introducing Autodesk Maya 2013. 9th ed. Indianapolis, Ind: John Wiley & Sons, 2012.

O’Hailey, Tina. Rig It Right!: Maya Animation Rigging Concepts. New York: Focal Press, Taylor & Francis Group, 2013.

Palamar, Todd. Mastering Autodesk Maya 2014: Autodesk Official Press. 1st ed. Indianapolis, IN: John Wiley & Sons, 2013.

Ritchie, Kiaran, Kiaran Ritchie, and CG Toolkit (Firm). The Art of Rigging. Vol. 1, A Definitive Guide to Character Technical Direction with Alias Maya. [United States]: CG Toolkit, 2005.

Rodriguez, David. Animation Methods: Rigging Made Easy : Rig Your First 3D Character in Maya. Lexington, KY: CreateSpace, 2013.


Brian Escribano

Michael Comet, a modeling/rigging artistic/technical director at Pixar Animation Studios and the original creator of Maya Muscle, has bottled these tools’ functionalities to take them a step further. He offers an easy-to-use script called cometRename that can handle all of your renaming needs.

Author: Scott Ziong


Introduction to rigging in Maya – The shoulder and the arms, Author: Jahirul Amin


Maya Rigging – Rigging a biped character for animation  Author: Steven Murdoch



Last but not least, Michael Allison’s classes, all his knowledge that was shared and that has made this what it is.

What is rotate order, why is it important

and how can it help or hinder the animator?

Rotate order is how Maya calculates the rotation of three axis in 3D space, XYZ, in order to come up with the final position or end point.

The rotation is worked out based on rules using either a Quaternion or Euler Rotation method.  In Maya Euler Angles are favoured using a combination of the three angles to calculate the rotations in three dimensions, based on the rotation of the three axis.

The first rotation is a single vector or straight line ‘Real Line’ calculating the distance from the start to the end point. The second point or dimension has two vectors perpendicular to a common axis point creating a plane to calculate the point in space, ‘Cartesian Plane’. The third dimension or ‘Coordinate Space’ is using three cartesian planes, three numbers to calculate a position within a volume in all three dimensions.

Every point in three-dimensional Euclidean space is determined by three coordinates. 

The rotations in XY and Z rotate are on their own axes in a hierarchical sequence with one following the other. When the first axis is rotated the other two do not move, when the second axis in the hierarchy is rotated the first one rotates with it and the third does not follow. The third axis is rotated and both the others rotate, all three axes are rotated.

Each of these rotations are defined by their own axis and because of the hierarchical nature of the calculations, the order of the calculation, the final position of the object being rotated changes in Euclidean Space.

The default rotation order is XYZ, where Z is the parent, Y is the first child and X is the second child.  Y will move the X and Z moves all of them, with X being the twisting axis, Z rotating up and down and Y side-to-side. This is the hierarchical way they relate to each other.


When I use the default rotate order, XYZ, in the Attribute Editor and move the joint 90 deg in X first, then Y then Z in the Channel Box, the above shot is the result.


When I change the rotate order, the order of the hierarchy, to YZX for example and enter the same values, in the same order, in the Channel Box as for the previous example, the resulting differ.  The order or the way the calculation has been done has changed the final position. Maya is looking at the end result based on the rules for the calculation, Eular Rotation.

Another issue to consider with how rotation is calculated is Gimbal Lock, the loss of one degree of freedom due to parallel orientation. It is when two rotation axis are doing the same thing, the axes are overlapping and preventing the joint from rotating in three dimensions, losing an axis of rotation.  This is important because the rotation order affects how the object is going to move or behave giving different results.


O’Hailey, Tina. Rig It Right!: Maya Animation Rigging Concepts. New York: Focal Press, Taylor & Francis Group, 2013. page224

I have used this shot from Rig It Right because I think it show this very clearly.

This middle axis is rotating the child, the first axis, but not its own parent (last axis) and always causes gimbal lock. The middle axis is lining up its child with its parent. The first axis rotates freely not affecting the other two and the last axis, the parent of the other two, rotates both axis so they do not ever line up. When the rotate order is changed the parent, child hierarchy changes and the order of calculation has changed.

There can also be flipping issues, Maya does not know the difference between 0 and 360 deg. It is how the curves are calculated, not how many rotations. Maya is calculating the interpolation between two numbers deferring to the smallest value as opposed to the shortest path.


When two axis are overlapping Maya does not know what axis to rotate, the general rule is to put the middle axis where there is little movement. What movement is important, the twisting, the side to side or the up and down?

The lease important movement is most likely the best place for the middle value which causes Gimbal Lock with the most important rotation last as it is the parent of the other two.

The rotate order is important for the animator with the best rotation order for a particular joint or control varying depending on the range of movement and action.

Selecting a workable rotate order allows for the rotation of the joints to move the character or object with the least amount of compromise in the rotations and causing minimal interference when gimbal lock occurs. Changing rotate order does not eliminate gimbal lock, it moves it to a different position.


Gimbal Lock Video: Silke, Andrew. (2009) Eular (Gimbal Lock) Explained, The Gurerilla CG Project, https://www.youtube.com/watch?v=zc8b2Jo7mno


Setting a suitable rotate order stops strange rotation pops in the graph editors curves, the animator needs predictable results. It is difficult to animate the node when the axis cross making the animation curves difficult to manage.

Having gimbal lock in a place where the character or object is lease likely to need extremes in rotation, still giving the control needed for the required actions and reducing the possibilities for getting gimbal lock and flipping is important for the animator. Having the object move unexpectedly affects the stability of the character.


Rig it Right! Maya Animation Rigging Concepts – Tina O’Hailey

advanced chapters


Euler (gimbal lock) Explained

Animation Methods Scripts Link

Cabrera, Cheryl. An Essential Introduction to Maya Character Rigging with Dvd. Boston, MA: Elsevier, 2008.

O’Hailey, Tina. Rig It Right!: Maya Animation Rigging Concepts. New York: Focal Press, Taylor & Francis Group, 2013.

Palamar, Todd. Mastering Autodesk Maya 2014: Autodesk Official Press. 1st ed. Indianapolis, IN: John Wiley & Sons, 2013.

Ritchie, Kiaran, Kiaran Ritchie, and CG Toolkit (Firm). The Art of Rigging. Vol. 1, A Definitive Guide to Character Technical Direction with Alias Maya. [United States]: CG Toolkit, 2005.

Rodriguez, David. Animation Methods: Rigging Made Easy : Rig Your First 3D Character in Maya. Lexington, KY: CreateSpace, 2013.

Other References:

Welcome to Michael Comet’s Homepage
and Maya Downloads


Creating a Character Rig – Part 10: Basic IK, FK, and result leg joints

Creating a Character Rig – Part 12: Leg FK control


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: