Game Development Reference
In-Depth Information
Format used by graphics APIs. Partly due to reasons in the previous
item, graphics APIs use matrices to express orientation. (API stands
for Application Programming Interface. Basically, this is the code
we use to communicate with the graphics hardware.) When we are
communicating with the API, we are going to have to express our
transformations as matrices. How we store transformations internally
in our program is up to us, but if we choose another representation,
we are going to have to convert them into matrices at some point in
the graphics pipeline.
Concatenation of multiple angular displacements. A third advantage
of matrices is that it is possible to “collapse” nested coordinate space
relationships. For example, if we know the orientation of object A
relative to object B, and we know the orientation of object B relative
to object C, then by using matrices, we can determine the orientation
of object A relative to object C. We encountered these concepts before
when we discussed nested coordinate spaces in Chapter 3, and then
we discussed how matrices could be concatenated in Section 5.6.
Matrix inversion. When an angular displacement is represented in
matrix form, it is possible to compute the “opposite” angular dis-
placement by using matrix inversion. What's more, since rotation
matrices are orthogonal, this computation is a trivial matter of trans-
posing the matrix.
8.2.4 Disadvantages of Matrix Form
The explicit nature of a matrix provides some advantages, as we have just
discussed. However, a matrix uses nine numbers to store an orientation,
and it is possible to parameterize orientation with only three numbers. The
“extra” numbers in a matrix can cause some problems.
Matrices take more memory. If we need to store many orientations
(for example, keyframes in an animation sequence), that extra space
for nine numbers instead of three can really add up. Let's take a
modest example. Let's say we are animating a model of a human
that is broken up into 15 pieces for different body parts. Animation
is accomplished strictly by controlling the orientation of each part
relative to its parent part. Assume we are storing one orientation for
each part, per frame, and our animation data is stored at a modest
rate, say, 15 Hz. This means we will have 225 orientations per second.
Using matrices and 32-bit floating point numbers, each frame will
take 8,100 bytes. Using Euler angles (which we will meet next in
Section 8.3) , the same data would take only 2,700 bytes. For a mere
Search WWH ::




Custom Search