Why quaternions?

#1 In my opinion you should try and get rid of quaternions entirely where possible. They're a bit useless, although i can understand that they're what programmers are more familiar with when it comes to 3d graphics.
They used to be fast ages ago, but almost every platform now supports SIMD instructions, and most platforms have hardware acceleration for 4-components vectors and 4x4 matrices.
Also, matrices are really easy to use... if you're using DirectX for example, you just call some functions and it does all the hardware acceleration stuff for you.
The problem with pan, tilt, roll, yaw, pitch, etc is that they're not well defined terms, from a mathematical point of view. Some people think they're relative to camera orientation, some people think that pitch is tilt or viceversa. These terms usually generate confusion in my experience.

Edit: I just realized this isn't the TGEA forum. What i said might not be so relevant here, although it's still true :)

#2 You save a few instructions using quaternions opposed to matrices.
quaternions cannot gimble lock, and are not constrained to order of operations.

quaternions are a tonless data for network sharing.

#3 @Badguy
You save a few instructions only if you're doing one scalar operation at a time with no hardware acceleration. Depending on your hardware, multiplying two vectors can easily be a single instruction
I agree on the other points though

#4 The way you wrote that you make it sound like gimbal lock is a good thing and quaternions can't do it. :)

#5 Sorry,
Gimble lock is Bad, evil.

I remember when I learned about it...
I was like wtf?
because before I learned about it, my code was experiencing it.

it took me a while to understand why I could not get around it with matrices.
I tried many things, and they would work in some cases then break in others.
Then I finally learned what and why and then found a solution, I have not looked back.

Quaternions Rule!

#6 ...

#7 Just to reinforce on this point--quaternions could be considered as an "advanced matrix" in capability. Matrix manipulation may be "easier", but it's also limited--specifically as stated correctly above: matrices have gimble lock (which is mostly bad), and successive operations (translations/rotations) are order dependent.

Also to correct the original poster's assumption: TorqueScript representations of position and rotation ("transform") are not quaternion representations--they are a combination of a 3D point (Point3F), and an Axis Angle for rotation. Each underlying class implements the internal representation of a transform based on what is most appropriate for game needs.

For example, ShapeBase and Player classes uses a matrix, while the Vehicle class (and underlying classes) use a quaternion. Each of the classes however interact with TorqueScript via "point 3F + axis angle" for consistency.

#8 @Joseph: That page helped me understand gimbol lock long ago, but the picture is kinda misleading since it rotates along X and Y simultaneously, which is exactly the thing.

The whole point of Gimbol lock is that if you sequentially rotate along X, *then* Y, *then* Z, that's what causes it;
If you rotate 90 degrees along X, then 90 degrees along Y, then your Z axis now lies along your X axis.
A translation around Z now is exactly equivalent to a translation around X before.

Gary (-;

#9 Quaternions always interpolate correctly between two rotations, while euler angles do not.

#10 Hmmm, some mis-information here (possibly).

Only Euler angles (pitch, yaw, roll) have gimle lock. Quats and Matrices (Zepp???) do not.

Matrices can store more information then just orientation, such information can include translation and scale too. Because of such they have a nice uniform way of storing all object space information.

Quaternions can only store an orientation, but they are computationally lighter. They also can be used for orientation interpolation (slerping).

Euler angles are human readable/understandable but are suspect to the order of operations which results in Gimble lock.

ie: 30 Z + 60 X + 20 Y + 10 Z + 10Y is not the same as 60 X + 30Y + 40 Z. Which is how you would store them, but the order is very essential.

Correct me if I'm wrong here.

Gabriel

#11 Matrices are also non-commutative, and therefore suspect to the order of operations.