The term keyframe comes from traditional animation techniques (think Disney). A skilled artist would draw a character in a series of significant positions (the key-frames) to establish a movement (e.g. sat in a chair, halfway out the chair, standing by the chair). Another artist would then performed the 'tweening', drawing the character in the positions between the keyframes to get the required number of drawings for smooth movement over the timing of the action. So if the animation is to be shown at 25frames/second, if the keyframes were half a second apart, the 'tweener' would have to supply the other 12 frames. The term keyframe has been adopted by the computer animation community, where an animation is stored as a series of keyframe poses, and the computer works out the intermediary positions to achieve smooth motion. In the diagram below, the vertical lines represent points in time where the computer will generate a display. The blue and green dots represent the required value of some parameter defined in various keyframes. The black dots represent the calculated intermediate values, and the red line is the apparent 'path' seen on the display.
There is one big difference between traditional animation and animation for
computer games. In a film animation there is a single planned sequence of
activities for the characters. In any scene, the animator always knows what the
character will be doing next, and so how the animation needs to develop. In a
game however, the action of a character is determined by the player (or by a
choice made by the computer). For example, a Sim might be standing waiting, it
could then: walk away, start dancing or start talking. The game stores these
separate activities (standing, walking, dancing, talking etc) as separate
animation files (CFPs). In order that the animation looks smooth, the end pose
of an animation must be the same as the starting pose of all the animations that
can follow it. I call these poses at start/end of an animation LinkFrames (if
anybody knows a more generally agreed term for this idea I'd be pleased to hear
from them).
The diagram above is a typical 'Translation' keyframe animation. It starts at
one Linkframe (shown in blue), then after 3 intermediary keyframes (green)
arrives at the end Linkframe (blue). In the example above, the length of the
sequence is 18 frames, with the computer calculating the 13 intermediary
positions (black). The important feature of the translation is that the start
and end Linkframes are not necessarily the same, and that no assumptions are
made about the intervening keyframes. SimPose-ium also supports keyframes for
symmetrical activities. That is those where the Sim moves through one set of
motions, then the same set of motions in reverse, to return to the same
Linkframe position. I'm calling this a 'Bounce'
action. (note: in an earlier version of this note I said that this happens in
the CFP file as well - its now clear that all CFP animations are translations).
A bounce action is defined by the end Linkframe and the keyframes between that and a keyframe at half the sequence length. For example, in the diagram below the left-hand half is defined by the user, then the computer calculates the mirrored right-hand half.
![]() | LinkFrames have to come from a pose library, but its probably also advisable to create most keyframes as static poses first and store them in a library, then add them to the animation using Add Keyframe (rather than try and perform major posing whilst the animation is running). | ||||
![]() | When a keyframe animation is saved, the names of the LinkFrane(s) are stored. When the animation is reloaded, the LinkFrame pose is taken from the pose library (assuming the same pose library has been loaded) rather than the animation file. This means that if a LinkFrame pose is changed in the library, all animations that use that pose are also changed when next loaded. | ||||
![]() | You may need to perform posing whilst the animation is running to 'fine
tune' animations.
| ||||
![]() | SimPose-ium uses a frame rate of 30 frames/second, so remember this when
you are calculating how long you want an animation to run for (though the
actual frame rate for the display may be different it doesn't affect the
length of an animation) |