Game Development Reference
In-Depth Information
Some readers 16 might think that we are belaboring the point. Maybe
you figured out how to use that rotation matrix from that book or website,
and now it's totally obvious to you. But we've seen this be a stumbling
block for too many programmers, so we have chosen to dwell on this point.
One common example will illustrate the confusion we've seen.
Consider a typical real-time situation with objects moving around. As-
sume that the orientation of each object is maintained in Euler angle format
as a state variable. One of these objects is the camera, and naturally we
use the same system of Euler angles to describe the orientation of the cam-
era as we do for any other object. Now, at some point we are going to
need to communicate those reference frames to the graphics API. This is
where the confusion occurs: the matrix we use to describe the orientation
of the objects is not the same matrix we use to describe the orientation of
the camera! The graphics API needs two types of matrices. (We'll discuss
them in more detail in Section 10.3.1.) The model transform is a matrix
that transforms vectors from object space to world space. The view trans-
form transforms vectors from world space to the camera's object space.
The rotation portion of the model transform matrix is an object-to-upright
matrix, but the rotation portion of the view transform matrix is an upright-
to-object matrix. So to speak of the Euler rotation matrix leaves out some
important practical details.
Now to derive the matrices. We start by deriving the object-to-upright
matrix, which rotates points from object space to upright space. We will
be using the simple rotation matrices developed in Section 5.1.2, and those
were developed using the perspective of active transformation (see Sec-
tion 3.3.1 if you don't remember the difference between activate and passive
transformations). Thus, to visualize the task at hand, imagine an arbitrary
point on our object. The object starts out in the “identity” orientation, and
the body coordinates for our point, which are the coordinates we know, also
happen to be the upright coordinates at this time because the two spaces
are aligned. We perform the sequence of Euler rotations on the object,
and the point moves in space until, after the third rotation, the object has
arrived in the orientation described by the Euler angles. All the while, our
upright coordinate space used to measure the coordinates remains fixed.
So the final result of these calculations is the upright coordinates for the
point in its arbitrary orientation.
There's one last catch. The elementary rotation matrices that we wish to
use as building blocks each rotate about a cardinal axis. With Euler angles,
the axes of rotation are the body axes, which (after the first rotation) will
be arbitrarily oriented. So instead of doing the Euler rotations about the
16 Probably those who already know this stuff. Hey, what are you doing in the kiddie
pool—don't you have some backflips off the diving board you should be doing right about
now?
Search WWH ::




Custom Search