I am now all set to animate my helicopter. I'll need a bunch of animations to make my tests and I'll start with a simple one : a looping animation of the rotors turning. This will be the opportunity to talk about a few of Maya's animation related features: referencing, playblasts, and the graph editor.
To create the animation file, I'm using referencing. Basically, it imports a read-only version of the animation rig file every time I open the scene, keeping it up to date with the original file. This way, any rig update will automatically get propagated to the animation files. This is done using the reference editor.
The Namespace is used to prefix the name of all objects from the referenced scene, so we can know where they come from.
Actually making those rotors move is really, really easy. All I have to do is to grab the controllers, set a key at the current position in the timeline (starting at 0), move the time slider, rotate the controller, rinse, repeat. For this animation, I've set a key at each 90° rotation, evenly over 40 frames (i.e. one key every ten frames). That number is completely arbitrary, I'll scale the keys up or down if I need to make the animation slower or faster. The result can be seen in the video below (I've made it cycle 4 times).
As you can see, there is some sort of a problem: the rotors seem to stop at the end of each cycle. But before I explain the problem, I just want to quickly explain how I've captured this video.
I didn't use any capture software, but a Maya built-in tool called "Playblast". It's simply rendering to an avi file the current frame range of the time slider.
Playbasts are useful to get timings from animations without having to open Maya. Playblasts are best watched with QuickTime Player as its time slider updates the image immediately, and to the exact frame.
Now, back to our problem. We've seen the rotors slowing down to a halt at the end of each cycle. When you set keys on a object, you're just saying "at this point, you need to be there, turned like that". But between two keys, it could interpolate in countless ways. How you define the interpolation is the bread and butter of animators, and it's done with the graph editor.
Each attribute you can set keys on is represented on a graph by a Bézier curve defining the evolution of the attribute's value over time. Each time you set a key, you add (or insert) a point on that curve. Then, by playing with the tangents (control points), you define how quickly the curve reaches that point. Let's have a look at the curves or our rotors.
Note that to display stuff in the graph editor, you need to select the keyed objects first. Then, if you want, you can filter channels by only selecting the attributes you're interested in (useful to avoid modifying the wrong attributes).
On the picture above, we're looking at the Rotate Z of the main rotor, and the Rotate Y of the tail rotor. As you can see, the lines are flattening at the beginning and the end, explaining why the rotors are slowing down. To correct this, we just need to make sure the line is perfectly straight. To do so, we have to select all the keys, and set their tangents to linear. We end up with the following curve:
When we make a playblast of the animation, it looks much better:
One nice touch from the graph editor is the ability to define how the curves behave before the first key and after the last key. These are called pre and post infinity. In our case, we can tell the post-infinity curve to cycle, making the animation loop without having to set more keys. This is the easy way of checking if an animation loops seamlessly.
|Post infinity set to cycle. The curve is dashed to show that no keys are set.|
And that's it for my first animation!