Loading and Caching Game Data - Game Coding Complete - page 201

'

motions don t need 30 samples per second to look good. Actually, even complicated

motions can usually get by with 15 samples per second or less, and not every bone is
typically in motion at the same time, at maximum speed. Your mileage may vary with
different motions, so your code might need to store different motions sampled at differ-
ent rates. One thing you can be sure of, not every animation can look good with the
same sampling rate, so your engine should be sophisticated enough to use animation
data at different sampling rates.
Sometimes objects don

'

t need to change position and orientation every frame. This
implies you could store a stream of changes in position or orientation when they
happen and store nothing at all but a time delay when the object or bone is still.
Starting in the middle of or reversing an animation can be a little tricky, since you
have to start at a known position and reapply the position and orientation deltas
until you get to the position you want — something like finding the right spot in a
track on a DJ s turntable. Every second or so, you should store the full position and

orientation information. These snapshots are usually called keyframes. They can be
very useful for jumping quickly to somewhere in the middle of an animation, and
they can also reduce small errors that can accumulate.
Finally, since the position and orientation changes are small, you can usually get
away with storing them in something other than floating-point numbers. You can
convert them to 2-byte integers, for example. The Unreal Engine does exactly this —
storing Euler angles as mapped values from 0 to 65536. You might wonder if this is a
good idea, but think about how humans perceive angles. I

'

d defy most people to dis-
cern the difference between a 127-degree angle and a 128-degree one

'

— '

s just
1/360 th of a circle. Take those deltas down to 1/65536 th of a circle, and you ' ll see the
Unreal engineers were pretty clever indeed. These compression techniques can dra-
matically reduce the size of animation data down to a few tens of kilobytes per sec-
ond for an animated character. For example, the animation data for a main character
like Garrett in Thief: Deadly Shadows, who can use different weapons, climb on walls,
crouch, crawl, and perform other activities, should be in the 5MB to 7MB range. The
size of these animations increases linearly with the number of bones and the nature
of their movement, so as characters get more complicated and active, the size of the
animations increases, too.
Assuming that your game has a big storyline and you want to store lots of in-game cine-
matics, you can estimate the size of your in-game movies, minus the audio, like this:

and that

n Assume the average of two characters moving simultaneously per cinematic
n Each cinematic averages 30 seconds
n 50KB per second (25KB per character per second) × 30 seconds = 1.53MB