# Boost :

From: Jason Hise (chaos_at_[hidden])
Date: 2006-03-24 12:58:01

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
>
>"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
>
>