Game Development Reference
In-Depth Information
Right now, we are focusing on the situation in which the orientation of
some object is stored as a state variable.
Let's assume that we adopt the common policy and store orientation
using the generic transformation matrix. We are forced to arbitrarily pick a
convention, so let's decide that multiplication by this matrix will transform
from object to upright space. If we have a vector in upright space and we
need to express it in object-space coordinates, we must multiply this vector
by the inverse 3 of the matrix.
Now let's see how our policy affects the code that is written and read
hundreds of times by average game programmers.
Rotate some vector from object space to upright space is translated
into code as multiplication by the matrix.
Rotate a vector from upright space to object space is translated into
code as multiplication by the inverse (or transpose) of the matrix.
Notice that the code does not match one-to-one with the high-level in-
tentions of the programmer. It forces every user to remember what the
conventions are every time they use the matrix. It is our experience that
this coding style is a contributing factor to the di culty that beginning
programmers have in learning how to use matrices; they often end up trans-
posing and negating things randomly when things don't look right.
We have found it helpful to have a special 3×3 matrix class that is used
exclusively for storing the orientation of an object, not for arbitrary trans-
forms. The class assumes, as an invariant, that the matrix is orthogonal,
meaning it contains only rotation. (We also would probably assume that
the matrix does not contain a reflection, even though that is possible in an
orthogonal matrix.) With these assumptions in place, we are now free to
perform rotations using the matrix at a higher level of abstraction. Our
interface functions match exactly the high-level intentions of the program-
mer. Furthermore, we have removed the confusing linear algebra details
having to do with row vectors versus column vectors, which space is on the
left or right, which way is the regular way and which is the inverse, and so
forth. Or rather, we have confined such details to the class internals—the
person implementing the class certainly needs to pick a convention (and
hopefully document it). In fact, in this specialized matrix class, the oper-
ations of “multiply a vector” and “invert this matrix” really are not that
useful. We would advocate keeping this dedicated matrix class confined to
operations in terms of upright space and object space, rather than multiply
a vector.
3 Actually, probably multiplication by the transpose, since rotation matrices are
orthogonal—but that is not the point here.
Search WWH ::




Custom Search