

Additionally, matrices are prone to "drifting," a situation that arises when one of the six constraints is violated and the matrix introduces rotations around an arbitrary axis. However, nine DOF (assuming 3x3 matrices) are required to constrain the rotation - clearly more than we need. Rotations involve only three degrees of freedom (DOF), around the x, y, and z coordinate axes.

I also highly recommend that you re-read Chris Hecker's article in the June 1997 issue of the Game Developer ("Physics, Part 4: The Third Dimension," pp.15-26), since it tackles the problem of orienting 3D objects. Therefore, I will assume that most game programmers are very familiar with this technique and I'll just comment on its shortcomings. To date, I haven't seen a single 3D graphics book that doesn't talk about rotations using 4x4 or 3x3 matrices. If you are not familiar with some of these techniques, I recommend picking up a graphics book and studying them. I'll touch upon methods such as rotation matrices, Euler angles, and axis and angle representations and explain their shortcomings and their relationships to quaternions. You can also dynamically adjust the number of interpolated positions to correspond to a particular frame rate.īefore we begin with quaternion theory and applications, let's look at how rotations can be represented.

This is a good time to use quaternions, a method that requires only two or three orientations to represent a simple rotation of an object, such as our revolving door. However, one can never be sure how many such orientations are enough, since the games run at different frame rates on different computers, thereby affecting the smoothness of the rotation. Trying to correct this problem using matrices or Euler angles, an animator might simply increase the number of predefined (keyed) orientations. If you chose to store the door's orientations as rotation matrices or Euler angles, you'd find that smoothly interpolating between the rotation matrices' values would be computationally costly and certainly wouldn't appear as smooth to a player's eye as quaternion interpolation. Imagine an object that is not user controlled, but which simply rotates freely in space (for example, a revolving door). Each of these solutions works fine until you try to smoothly interpolate between two orientations of an object. Most programmers use 3x3 rotation matrices or three Euler angles to store this information. There are many ways to represent the orientation of an object. If you store orientations as quaternions, it is computationally less expensive to add angular velocities to quaternions than to matrices. Many games coming out this year will also feature real-world physics, allowing amazing game play and immersion. Instead of manipulating a plane's orientation using three angles (roll, pitch, and yaw) representing rotations about the x, y, and z axes, respectively, it is much simpler to use a single quaternion. This is one area where quaternions come to rescue.Īnother common use for quaternions is in military and commercial flight simulators. Because this camera goes through different motions (that is, through arcs of a different lengths) than the character, camera motion can appear unnatural and too "jerky" for the player to follow the action. Every third-person game has a virtual camera placed at some distance behind or to the side of the player's character. Several third-person games, including both TOMB RAIDER titles, use quaternion rotations to animate all of their camera movements. Many game programmers have already discovered the wonderful world of quaternions and have started to use them extensively. Some of those extra cycles can be applied to tasks such as smoothing rotations and animations, thanks to quaternions. As a result, we game developers now have a lot of CPU cycles to spare for physics simulation and other features. Much of the work rasterizing and texture-mapping polygons was off-loaded to dedicated hardware. Last year may go down in history as The Year of the Hardware Acceleration.
