I have some experience with quaternions, and at the risk of repeating a bit of what you said perhaps I can clarify how they work. Quaternions are an extension of complex numbers to four dimensions. They are analogous to 4D vectors, and the set of all unit quaternions conceptually form the boundary of a hyper-sphere. You can take an angle of rotation and a 3D vector to use as an axis of rotation, and encode both into a single unit quaternion. It is possible to use quaternion multiplication to transform a 3D vector or point in order to cause that point to be rotated accordingly. The benefit of using quaternions largely has to do with interpolation between two orientations. Because all unit quaternions lie on this hypersphere boundary, there is generally a unique shortest path between two orientations which is always followed. When using matrices to attempt this, the difficulty is that not all matrices represent rotations, and you would be interpolating 9 or 16 degrees of freedom independently. The alternative method of using rotation angles about the x, y, and z axes to store orientations causes the potential problem of gimbal lock. Put simply, this means a rotation about one axis can cause two of the axes to align, resulting in the loss of a degree of freedom. Hope this helps. -Jason Giovanni P. Deretta wrote:
Andy Little wrote:
I think the clue to speed is that quaternion uses a 3x3 matrix whereas a
transform matrix to do same job would be 4x4 (which is a lot more calcs many redundant!), though 4x4 matrix can hold information about perspective and translation which a quaternion cant AFAIK. Also 1 matrix can hold an arbitarily complex transform by concatenating (multiplying) a series of matrices of simpler transforms. e.g any sequence of rotations, translations, scalings, perspective transformations, mirror etc.
I'm really *not* experienced on the argument (i've done some graphic programming just as an hobby), but this is what Allegro (a great game-oriented graphics-but-not-just-graphics library) says on the subject (from the allegro:quaternion info page):
"Quaternions are an alternate way to represent the rotation part of a transformation, and can be easier to manipulate than matrices. As with a matrix, you can encode a geometric transformations in one, concatenate several of them to merge multiple transformations, and apply them to a vector, but they can only store pure rotations. The big advantage is that you can accurately interpolate between two quaternions to get a part-way rotation, avoiding the gimbal problems of the more conventional euler angle interpolation."
A quick wikipedia search reveals that the above gimbal problem is the gimbal lock (from the wikipedia page on euler angles):
"Unit quaternions, also known as Euler-Rodrigues parameters, provide another mechanism for representing 3D rotations. This is equivalent to the special unitary group description. Quaternions are generally quicker for most calculations, conceptually simpler to interpolate, and are not subject to gimbal lock. Much high speed 3D graphics programming (gaming, for example) uses quaternions because of this."
In turn the gimbal lock is (still according to wikipedia):
"In gyroscopic devices controlled by Euler mechanics or Euler angles, gimbal lock is caused by the alignment of two of the three gimbals together so that one of the rotation references (pitch/yaw/roll, often yaw) is cancelled. This would require a reset of the gimbals using an outside reference. It may also be described as the situation when all three gyros hit the limits of their ability to move within the sensing mechanism - they hit hard stops and stop moving around."
It seems that this happens (I do not pretend to understand everythings :) not only with physical devices but also in code. BTW, allegro provides some great animated examples that show the difference of rotations done with matrices and with quaternions.
In the end, quaternions are not used just because they are faster, but because they avoid errors in corner cases.
HTH