Hi Im trying to find the most efficient way of keeping track of camera rotations. At the moment i am storing 3 vectors in my camera class, which represent the x,y,z camera space axis as world space vectors. When the user rotates the camera, the rotations take place around the camera space x,y,z axis, and i cant really think of a workable method in which the x,y,z axis are not stored in the camera class. However, i keep reading that using quaternions is the most efficient method of keeping track of rotations. Im reasonably familiar with the theory behind quaternion rotation, but i dont really see how they can make it possible to avoid having to store the x,y,z axis in the class. Am i missing something? or is the method im using now the most efficient way to do rotations?

What exactly would be inside the stored matrix? Would it be the world space vectors of camera space axis? Or would it be a concatination of all the rotations applied to the camera? If its the latter then would i need to store the camera space axis as well as the matrix? otherwise how would i know the correct positioning of the camera space axis so that i could rotate the cameras around them?

Or, you could do away with the matrices entirely (at least on the surface) and do this : maintain quaternion in your camera for it's current orientation. Whenever you need to rotate the camera build a quaternion from the Euler angles that represent the rotations, concatenate the two quaternions into the current orientation one, and then convert that one to an axis-angle representation for use with glRotatef(...) (or, substitute whatever DirectX function is analogous to this if your using it). For your initial orientation, start with an identity quaternion which will have you at the origin looking down (or up) the z-axis.

peace and (trance) out

Mage

[edited by - Mage2k on December 13, 2003 12:54:44 AM]

hm.. i would agree (without being a professional). quaternions are nice and have advantages in some situations (interpolating rotations, saving a few floats compared to a matrix and probably better to compress without causing trouble). and they are also over-hyped in many others, often presented as one-and-only solution or (more often) as "better" solution because the math is so neat.

ask yourself:
-will converting back and forth negate any gain?
-if not, is the gain worth the extra work?
-isnt a 4x4 matrix where everything directly relates to stuff you need all the time a lot easier to handle?

concerning the last point:
the three vectors are always useful, together with two constants depending on your fov you can do frustum culling with them and never waste a second though about getting all those plane normals. you can simply invert it and load it as modelview to setup your camera. for objects you can just multiply their matrix with the modelview.

while youre lazy you can let opengl do the matrix math if you can ignore the possible impact on speed (once or twice a frame isnt a problem, doing it for a few hundred objects might be one).

of course, using d3d would be a little different, because it already has all the math functions to work with quaternions.