Key Frame Animation

Key-frame animation, as with a lot of computer animation terms, derives its name from the traditional animation equivalent.

What is a Key-Frame?

In traditional animation, the "key-frames" are exactly that: the pictures that are absolutely required in order to tell the story. For example, in the image below (© Richard Williams):

We could probably tell just from those three images that the man walks along, picks some chalk up from the ground, and writes on a board with it. In a traditional animation company, the best animators draw the key-frames. But many more pictures than this are required to make an animation. The next to be drawn are "extremes" and "breakdown" pictures (© Richard Williams):

These are sometimes done by the same animators as the key-frames, but more often by less senior animators. They include the extreme positions, e.g. the highest point that the head reaches in the walk. Finally, the "inbetweens" are put in (© Richard Williams):

This final stage tends to be done by the lowest animators, as it is generally accepted to be the boring bit: an inbetweener's work is seen as fairly mindless, making a smooth transition from one extreme to the next.

As you may have guessed, all of these images are from a book by Richard Williams called "The Animator's Survival Kit".⁰ If you are intending to do a good amount of character animation during this course, then a book that you really need to at least read (probably buy) is Richard Williams'.

Computer Animation

When we transfer to the computer, there are two distinct types of animation: keyframed and procedural. Keyframed animation involves placing objects at specific places at specific times (the keyframes), whereas procedural animation uses mathematical equations to calculate the positions of objects. A good example is when animating a tank: the position of the tank itself would be keyframed, so that it could be moved forwards, backwards and turned round when required. The tank tracks, however, could have a mathematical equation on them so that they turn at the right speed depending on how fast the tank is moving at the time.

The two different types of animation have distinctly different uses:

In this lecture series we are going to concentrate mostly on keyframed animation. The great thing about using a computer to do keyframed animation is that when it comes to the "inbetweening", the computer does this for us. Bear in mind though, that it will inbetween badly: you should always scrutinize each section of animation very carefully and check the computer's work is the same as you would have done. Note that when we refer to "keyframes" in computer animation, we mean all positions that the animator sets himself, not just the "story-telling" pictures (as in traditional animation).

Binary vs ASCII

Before we load the file that we're going to be working with today, let's investigate it in more detail. In a terminal:

Have a look at the files NotBouncingBall.mb and NotBouncingBall.ma. The major difference between them that you should notice is in the size of the file: the .mb version is smaller than the .ma version. So that means that we want to use .mb, right? Wrong. Now try doing the following (bear with me on this):

cat NotBouncingBall.mb

This spouts a load of rubbish: we can pick out the odd word, but that's about it. And let's not forget, it has also screwed up our terminal (which we can fix by going to Reset on the Terminal menu: press Enter a few times). Now try:

cat NotBouncingBall.ma

It's a text file! Plain and simple. In fact, there are bits of it you might recognize: it's one big mel script. There are many benefits to saving things in this way: if copying files between different version of Maya, for example, we can just change the "8.0" number at the top. It's worth noting, though, that this sort of thing can cause instability: it should be used only as a last resort.

Bouncing Ball

Now open the file:

You'll find a ball ready for bouncing on a surface.

The first thing we should do is check at what speed our animation will be played back. There are several different standards for playing back footage on different types of equipment. For reference, here is a list of the major standards and the settings that should be used for each:

For much more information than you want about TV standards, look at:

http://www.videointerchange.com/pal_secam_conversions.htm

As all of our work will be viewed on a television, we're going to use the PAL standard, so we want our animation to be played back at 25 frames per second.

Go to Window → Settings / Preferences → Preferences ... , then click on Settings in the list on the left. In the Time box, make sure it's set to PAL (25 fps). While we're on the subject of TV standards, go to Windows → Rendering Editors → Render Settings ... and find the Resolution section. Set it to the CCIR PAL/Quantel PAL preset.

Now let's set our animation length. At the bottom of the screen you should see the timeline:

The pink box to the right of the timeline has the current frame number in it. The four text boxes below the timeline contain the Start Time and End Time (the outer two boxes) and the Playback Start Time and Playback End Time (the inner two). Let's set the total animation end time to be 200, so we have 8 seconds to play with (it's always best to give yourself more time than you think you'll need), and the playback end frame to be 100 for now.

Select the ball. We will keyframe its horizontal movement to start with. The channel box contains the most commonly keyframed channels, so translateX (the one we want) is in there (note I will usually refer to channels by their long name, as this will be easier when you script with them). If we wanted to keyframe a different setting, we could open the Attribute Editor (ctrl-a): try it now, have a look at what's in there, then go back to the channel box by pressing ctrl-a again.

We want to keyframe translateX at frame 0, so make sure you're on frame 0, check that the ball is at <0, 4, 0> and select translateX (it should go black). Then right click on it, and choose Key Selected. Note the red line (indicating a key) at frame 0 on the timeline.

Now change the current time to be about 100, move the ball in x (I moved mine to about 8, but do what you want), and keyframe translateX again. We now have some simple animation: have a look and see. You may find that if you play it back using the playback controls, it plays back much faster than 25 frames per second (fps): go into the preferences like we did earlier, and click on Timeline in the list on the left. Under Playback Speed, select Real-time [25 fps]. This will play the animation back at the correct speed.

Let's look at our animation in more detail. Click on Window → Animation Editors → Graph Editor, and see what comes up. You can navigate round it with Alt and the mouse buttons (like an orthogonal view). You'll find you get a line graph, with time (in frames) going along the bottom, and translateX going up the side.

Drag a box over the last keyframe to select it, and click the Move Nearest Picked Key Tool (at the top left, the button that looks like a key with an arrow on it). Now drag the key around using the middle mouse button (MMB). You'll notice that the sphere updates in real-time as you move the keyframe. If we want to be precise, we can enter the frame number and the value into the pair of text boxes at the top.

The line at the moment is perfectly straight. In real-life nothing is this perfect: in fact, our ball should slow down to a stop, meaning that what we want is a curve. We could add lots of keyframes in order to change this straight line to a curve, but there is a better way. The line we have is actually a spline curve, it's just set up to be a straight line. Select the last keyframe, then find the Flat Tangents button (about halfway along the top of the graph editor). You should see the graph change to a curve that flattens out at the end. This is visible in playback by the ball slowing to a stop.

But currently we just have a rolling ball^*: that's a bit boring, so let's move our table down. Select the table, and change its translateY value to 0 in the channel box. If you play it back, it's clear that the ball is not affected at all, its movement is exactly the same as when the table was there. We have to animate the effect that gravity would normally have.

Now set the following keys on translateY of the ball: remember to change the timeline first, then move the object, then set the key.

Now play it back, and you'll notice it looks rubbish. It's a bit slow (that's something you can change in your own time), but mostly it's the fact that the ball slows down as it reaches the ground (this is shown by the fact that the line curves at the bottom of its path as well as the top). We need to change that.

Let's put our graph editor in a view port. On the viewport you choose, click the Panels menu, then choose Panel → Graph Editor. Click on translateY in the left of the graph editor, and press f to frame all the keys (use Alt to move around as well if necessary).

We want to make the points where the ball hits the ground much sharper: it is currently very smooth. Select one of the "ground" keys, and try altering its tangent. This is done by selecting one of the control handles (the little lines out of the side of each node), clicking the Move Nearest Picked Key Tool (top left) and MMB dragging the handle. You'll find that the opposite handle moves too, because by default the nodes are set to be "unified". Click the Break Tangent button (right), and then try again. Make all the "ground" keys sharp (as in the image), and you should be left with something which looks better than before.

Note that this is far from perfect: the second bounce is much too long, and the ball still doesn't roll. You could try changing either or both of these faults. To get the timing right, just move the keys around in the graph editor. Making the ball roll will be a little trickier; animating the rotate channels of it should work. Remember the w, e and r short-cuts to the translate, rotate and scale tools? If you press shift-w, shift-e and shift-r, it will keyframe all of the translate, rotate or scale channels for the selected object. Or you could try adding something completely new: e.g. in a traditionally animated cartoon, the ball would squash as it hit the ground and stretch as it left it. You could try to implement this using the scale tool.

If you find your animation looks completely wrong, there is a way to remove all of the animation from a channel: select it in the channel box, right-click, and choose Delete Selected. Try it with translateX (but be ready with ctrl-z).

Robotic Arm

Now it's time to animate the robotic arm from last week, using the techniques that we learnt today. Before you load your own (if you have them), load up my one briefly:

Here are a few more tips:

• You can stop a particular parameter being animated

  Select the lower arm, press w, and try to translate it. The three arrows are greyed out, and it won't move. This is very useful when giving a model to someone else to animate, so that they don't accidentally animate bits of it that they shouldn't. Simply select the parameters you want to lock in the channel box, right-click and go to Lock Selected. Try doing this with the upper arm.

• The dope sheet is your friend when adjusting timing

  Play the animation. You'll notice that the ball (armRotation) already has some very simple animation on it. Select armRotation, and then click on Window Animation → Editors → Dope Sheet. The dope sheet is useful for viewing your entire animation at a glance: it has all the keys on it as coloured blocks. If you zoom out (using the Alt key) you'll find there are two keyframes on rotateY of armRotation. If you drag over any of them you can select them, then you can click on the Move Keys button (like in the graph editor) and drag them around with the MMB. This is an easy way to adjust your timing. Try moving the end key (which is at about 200ish) back to 100 to speed up the animation.

• A Playblast is the best way to view your animation

  Though the viewport is a good way to view your animation at this stage, by the time you get hundreds of thousands of polygons in your scene it won't be: the computer will not be able to draw that many polygons 25 times every second, so it will skip frames to keep up. If you do a Playblast, it will record every frame of the animation as seen from the viewport (at a slower speed), so that you can watch it in real-time. Right-click on the timeline, and select the options box of Playblast. Adjust the scale if you like, but make sure that it's set to Save to File: this will allow us to look back at it later. Note, though, that it will play back exactly as the viewport currently looks: if you have an object selected (so that it's bright green) it will be bright green in the playblast. This also gives you a brief introduction to fcheck (type "fcheck &" into a terminal), which is a piece of software that comes with Maya for viewing sequences of images.

  Some of you may have noticed that if you put another window on top of Maya while it is recording a Playblast, or you minimize it, then it will record whatever is in that section of the screen anyway. Therefore it is best to leave the computer while it is recording a Playblast: it is also good for your eyes to give them a rest regularly.

© Henry Bush, 2008

These notes were last updated on Tuesday 12 February, 2008 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.