Animating Rotations, Problems and Solutions.
Uncountable rotations are the hardest of the three transforms to get a handle on. With any of the methods there are points in the animation that are hard to control. This section will describe a few of the possible solutions to the problems but not the only solution. These tutorials assume you have working knowledge of max or at least know how to use the existing help files so that I am not rewriting them.
In this example we will be covering how to make the earth spin on its axis that has 15 degrees angle to it and then rotate around the sun in an elliptical path.
The common problem occurs in the example when the animator rotates the earth 15 degrees on the X axis and then change reference coordinate system to local and then rotate the earth around its local Z axis 360 degrees and loop it. We will assume that the earth was created as a sphere in the top view port so that it's axis is aligned to world space and the default rotation controller is being used which is Euler XYZ.
We have seen the problems that Euler rotation can cause in the explanation of how they work. Rotating the earth along its local will cause the earth to wobble and not do what we want. The solution is this, create the earth from a sphere and align it to the world rotation. Create a dummy object and align its position and rotation to the earth. We well refer to these tow objects now as earth and dummy earth. Link the earth to the dummy earth. Rotate the earth 15 degrees on the X-axis so that the earth has the tilt that we want. Turn on animate and move the time slider to frame 100. Select the earth and change the reference coordinate system to parent. Because the earth is limited to dummy earth all of its transforms will be driven from it. Rotate the earth 360 degrees and the parent Z-axis and then scrub the time slider between frames 0 to 100. We don't have any problems of a wobbling earth because it is aligned to its parent object. What we have done is break down the separate rotations on to different objects and then linked them in an order that allowed this to work.
Another solution to the same problem is to change the order that the rotation axis are calculated in. To try this, reset the scene, create the earth in the top view from a sphere so that it is aligned to the world rotation axis. The default axis order for a Euler rotation is XYZ. You can also look at this as X is linked to Y, Y is linked to Z. Open the motion panel and change to the rotation tab, there is a drop down menu that has all the possible rotation orders available. Change it from XYZ to ZYX. The order is now linked in the opposite order. Rotate the earth 15 degrees on the X-axis so that it has the tilt that we are looking for. Turn on animate and move the time slider to frame 100. Change the reference coordinate system to local and animate the earth rotating 360 degrees around the Z-axis. Scrub the time slider back and forth from frame 0 to 100. You can see we don't get wobble in the rotation as we did the fist time we tried this. The reason for this is the same as the second test where we linked the earth to the dummy earth. The axis are now linked Z to Y and Y to X. When we first rotate the X-axis 15 degrees the other two axis rotate with it, this means the local Z axis is aligned the way that we want. The third solution to this problem is to use a TCB controller. This will avoid the gimble problem and will as you would expect.
|Most character are rigs created using bones. Once all the bones are created we may need to scale them to make them fit the character. This is where the problem starts. To see the problem create a two chain with a nub bone on the end so that we have BONE01 as the root, BONE02 and BONE03 as the nub bone. BONE02 inherits the transform of its parent bone in this chain. Select BONE01 and change the reference coordinate system to local. Scale BONE01 to 200% along the local X-axis. Select BONE02 and rotate it around the local Z-axis to 90 degrees. You can see BONE02 skew as it rotates. If you refer back to the section on transform matrix's you will see the rotation and scale values are contained in the same set of numbers. Once BONE01 was scaled, that scale factor is passed to its child objects, BONE02. When BONE02 rotates its parent axis it takes on the scale along the parent axis. For this reason you should never scale bones, instead you should be using the Edit Bone Mode button in the BoneTools dialog. You can then use the move tool and drag the pivot of the BONE02 to where you need it. BONE01 will appear to scale to keep the correct length but it is actually just changing the length parameter of the bone. Thos will result in a bone system that rotates correctly. Scaling any object is not a good idea just incase same thing gets linked to it. IF an object has been scaled the best thing to do is use the Reset X form utility from the Utility Panel. This took will transform all the scale and rotation data to an X form modifier and can then be collapsed into the model if desired. It is not advisable to use the Reset X form utility on a bone as it will realign the pivot to the world axis.|
|Rotating a wrist with an IK arm|
|When rigging an arm with IK it is common to have one control at the wrist that the IK solver is linked to ad the hand is orientation constrained to. Thos is a nice set up because it is very simple for the animator to work with. Positioning the arm and rotating the wrist is very easily done with one control. The draw back to this setup is the rotation of the wrist is in world space and not that of the arm. Assuming the character was created in the standard cross pose and the control at the wrist is aligned to world space, this means that the once the arms and hands are rotated down beside the character for a walk cycle you would have to rotate the Y axis 90 degrees. Just like in the euler example we no longer have an X-axis to rotate around. Making the hand swing back and forth with the walking means that we will have to deal with gimble lock. Once again there are several rotations that we can use to solve the problem. Changing the axis order might help by changing where the gimble lock will occur. Changing the order to YXZ will force the Y-axis to be evaluated first and stop the gimble lock from happening with X and Z. Once again another solution to the problem is to change the rotation controller to TCB and use quaternion instead of euler. This will stop the gimble lock problem but the animation will not have function curves to work with. A third solution is to add another control so that the position of the wrist is on one control and the rotation is on another. Doing this we can now place to rotation control in the coordinate space of the forearm. Since the wrist has a maximum rotation of about 90 degrees from the forearm we will be able to avoid gimble lock in most cases. To do this add another control and align it to the wrist. Link the hand to the new rotation control and link the control to the forearm. The rig will work a bit different at this point since the orientation of the hand will be locked to the forearm. This isn't a good setup for a character that has to have its hand lock to an object in the scene. To change this behavior just unlock the inherit rotation under the hierarchy/link info panel. Once again there are only a few solutions to the problem and every situation and character will be different.|