
Boost : 
From: Giovanni P. Deretta (gpderetta_at_[hidden])
Date: 20060324 12:13:26
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
gameoriented graphicsbutnotjustgraphics 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
partway 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 EulerRodrigues 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
 Giovanni P. Deretta
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk