We'll start this week by finishing off with our character from last week. Open up the following file:
This contains the place we got to last week. Now let's investigate the feet of our character.
Our method for controlling the feet leaves a lot to be desired. When a person walks, their toe is the last part of their foot to leave the ground. At the moment, in order to animate this, we would have to move the ikHandle up and rotate the foot joints so that the toe is back in the same place as it was before. It would be better if we could rotate the foot at the toe. Even better, if we could rotate the foot at the toe or at the heel. Or even better, if we could decide whether to rotate at the toe, the heel or the ball of the foot. Is this asking a little too much? Not with a little hierarchy shenanigans.
First of all, we want to get four control objects: one to control the heel, one for the ball, one for the toe, and one for the ankle; rename them as such. We also want to have another IK chain, going from the ankle to the toe.
Now we want to parent the ikHandles to the correct control objects: the handle at the ankle should be parented to the ankleControl; the handle at the toe to the toeControl.
As for the controls themselves, the heelControl should be at the top of the hierarchy (this is the one we shall generally use for translating the foot), then the toeControl, then ballControl, then the ankleControl.
The ankleControl is not very useful (I usually work with it hidden), but try translating the ankleControl and rotating all of the others. You should find that the foot is now very easy to control.
Essentially we have created a second hierarchical system: in addition to our joint chain, which travels down the leg from knee to toe, we now also have a chain (courtesy of our control objects) which travels from toe up to the ankle that we use to control the IK handles. If, at this stage, you don't understand why it works, don't worry. When you eventually do, the rest of rigging will drop neatly into place.
In case you didn't know, pressing
Set Key) keyframes all keyable parameters of the current object. By default, those are all of the rotation, translation and scale parameters, as well as visibility. We can change these defaults though. Select the heelControl, and go to
Window → General Editors → Channel Control. This brings up a box which has keyable parameters on the left, and those which are not keyable on the right: we can just move them over from one list to the other. Try this now: for the heelControl, we only want to be able to keyframe rotateX and all of the translate parameters, so move the others over to the
Non Keyable side.
The first thing that you will notice is that the undesired parameters disappear from the channel box. At the moment the parameters can still be changed, just not keyframed: the object can still be scaled if we press
r, for example. We can also lock the parameters so that they can't be changed using the
Locked tab of the same window.
s, and you should find that the rotateX and translate parameters are keyframed. These are the only parameters of this object that need keyframing, so we can happily press
s to keyframe the object. It would be good, though, if we could keyframe the whole foot or even the whole character by pressing
s. Well we can, using character sets.
Character sets are an easy way to group multiple parameters together and keyframe them all at the same time. Here I shall show you how to create a character set for one foot: the same principles apply throughout the character.
The first thing to do is set which channels should be keyable in each object that you want to key. This should be done using the channel control, as I demonstrated earlier. You can easily get to the channel control, by the way, by right-clicking on the channel box.
Set the correct channels to be keyable for each of the foot controls, then select them all. Now click on
Character → Create Character Set ❐. Type in a better name for the set, make sure it's on
All Keyable, then click
Create Character Set.
The first thing you should notice is that little down arrow near the bottom right corner of the screen has gone red: this is because the LeftFootCharSet (or whatever you called it) is now active. We can change which character set is active using the drop down arrow, or select
Character Sets ... to open up a handy pop up window (the relationship editor in character editing mode) that lets us edit our character sets. Pressing
s when there is a character set active will keyframe all of the parameters in the current character set. Try doing a little animation using this character set.
Open the scene
You should find a crane with several boxes scattered around it. Your task is to animate the crane so that it stacks the boxes on top of each other: use constraints to make the crane pick up the boxes and lay them on top of each other. I have made some control objects to control the crane:
One for the rotation of the arm (above the main pillar)
One for the position of the grabber along the arm (above the grabber)
One for the height of the grabber (next to the grabber).
The control objects are correctly parented to each other, and have sensible limits set (if you don't know how to set limits for an object, have a look at the
Limit Information area of the attribute editor), but do not currently control anything. Your first task is to make them control the correct things. Hint: use a direct connection for the arm rotation, and driven keys for the other two controls.
When you have done this, start the animation by keying the crane in its current position, then moving the crane so that the grabber is on top of the blue box at frame 30 or so. Now we want to add a position constraint so that the box stays in the same place relative to the grabber when we move it. Remember, click on the object to constrain to first, then the object that you want to constrain. For the constraint, go to
Constrain → Point ❐. We'll leave the settings at their default to start with. When you click
Add, the box jumps over the magnet so that their pivot points are in the same place. If you move the magnet (using the controls), the box will follow it: if you look in the channel box, you'll see that the boxes translate parameters have gone green, indicating that they are being controlled by a constraint.
If you drop down the pointConstraint input, you'll see several parameters including three offset parameters. Try changing these and you'll see that it means we don't need to have the pivot points directly on top of each other, we can have them offset (but the constraint still applies: try moving the magnet). We could change the offset values so that our cube didn't jump on top of the magnet at the start. Or, even better, we could get Maya to set the offset values for us. Use
z (in Maya,
ctrl-z can both be used as undo) until the box moves back to its original position (i.e., until before we applied the constraint). Now try re-applying the constraint, but this time, in the options box, click
Maintain Offset to be on. This, as expected, maintains the current distance between the two objects, but still constrains them together. Try it. Leave the box hanging somewhere.
Once we have our constraint, we need to be able to turn it on and off at will. If you look at the channel box of the cube, it has a new channel:
blendPoint1. Try varying this: you should find that when it's set to 1, the cube is constrained, and when it's set to 0, the cube is unconstrained. This parameter is keyable, so before the magnet "picks up" the cube we should key it off, and afterwards it should be keyed on. Notice that we can blend smoothly between these states, as the parameter can be set to a fractional value.
Use this type of position constraint to animate the crane so that it picks up each box in turn, and places them on top of each other.
Open the file:
You will find the canyon fly-through that we made a few weeks ago. What I want you to do is constrain the orientation of the cone to the camera. This will result in the cone always pointing in the same direction as the camera is pointing. Select the object that we are constraining to first, then the object we are constraining, then click
Constrain → Orient.
Sometimes we want to stop something being parented to another mid-animation, for some reason. This is why parent constraints are good: rather than actually being a child of the other object, we can simply add a parent constraint. This makes the object act like it is parented, but we can turn the constraint on and off at will.
© Henry Bush, 2013
These notes were last updated on Friday 10 May, 2013 and are designed for the use of students at the NCCA, but remain the property and responsibility of Henry Bush. They are available for free for personal or academic use, but with no guarantees of the quality or reliability of the material involved. Please give appropriate credit where used.