Game Development Reference
In-Depth Information
Table 8.2 Storing Simple versus Complicated Objects
Object
Members
Size
Simple textured and lit object
(30 bytes per vertex):
302 indices per group x 100
groups @ 30 bytes
906,000 bytes
Complicated material info
(80 bytes per vertex):
302 indices per group x 100
groups @ 80 bytes
2,416,000 bytes
models. This savings comes at a cost to the visual fidelity of the object, which affects
the player
'
s gameplay experience.
One thing you should note: The actual textures are stored separately from the mesh
data, and we haven
'
t even talked about those yet. They are orders of magnitude
larger, too.
Animations are stored as changes in position and orientation over time. You already
know that a position in 3D space takes 12 bytes
4 bytes each for X, Y, and Z coor-
dinates. Orientation is usually stored as a 12-byte or 16-byte data structure, depend-
ing on the rendering engine. This is the difference between storing the orientation as
angles of yaw, pitch, and roll (Euler angles) or a mathematical entity known as a qua-
ternion, which is a 4-vector (X, Y, Z, W). (You
—
'
ll learn all about the quaternion in
“
”
'
Chapter 14,
3D Graphics Basics.
) For now, we
ll assume the orientation takes
12 bytes.
One way to store animations is by recording a stream of position and orientation
data at fast intervals, say 30 times per second. For each second and each object, you
have the following:
12 bytes for position + 12 bytes for orientation = 24 bytes per sample
30 samples per second × 24 bytes per sample = 720 bytes/second
An object like a character is represented by a lot of discrete objects. Assuming you
have a very simple character with only 30 separate movable parts (called bones),
this gets pretty big very fast:
720 bytes/second × 30 bones = 21,600 bytes per second
Of course, there are ways to cheat. Games never store this much data for animations
—
it
is like storing an uncompressed TGA file for every frame of an entire movie. First, most
