Oh look, another person who's never tried to handle rotations in 3D and especially never tried to handle integrating the equations of motion of a rigid body in 3D (which is really about the simplest rotation model you can get). Quaternions are computationally less expensive, take up less space, and are more numerically stable than representing rotations in matrix form. Oh, and remember off the top of your head how to construct a rotation matrix based on an axis and an angle? Probably not, since it's non-trivial. Fortunately that's another thing quaternions happen to be really good at. Hell, they even make it easy to smoothly rotate from one orientation to another without hitting any of the nasty singularities you get from other representations (which also cause that whole nasty gimbal lock issue).
Given a quaternion formula of z=a+bi+cj+dk, where |z|=1, the normal representation of that rotation matrix in real math would be:
[[a^+b^-c^-d^, 2bc-2ad, 2bd+2ac ]
[2bc+2ad, a^-b^+c^-d^, 2cd-2ab ]
[2bd-2ac, 2cd+2ab, a^-b^-c^+d^]]
where '^' means squared
I will agree that it takes less space in a rotational form....but how would you calculate z=a+bi+cj+dk on a computer so that you move a rigid body to its next destination? By...using the matrix above? So you save variable space for all of a microsecond just to put it through the above calculation anyway?
Besides that, the above calculation was just to turn quaternion into orthogonal space....a rotation inside that space first without going the quaternion route doesn't yield as much complexity, it's simply:
rotation around x
[[ 1, 0, 0 ]
[ 0, cos(a), sin(a)]
[ 0, -sin(a), cos(a)]]
rotation around y
[[ cos(a), 0, -sin(a)]
[ 0, 1, 0 ]
[ sin(a), 0, cos(a)]]
rotation around z
[[ cos(a), sin(a), 0 ]
[-sin(a), cos(a), 0 ]
[0, 0, 1 ]]
Rotating around an arbitrary line, you simply normalize the vector (another matrix) and apply as such. You already get the answer right away, rather than having to use the previous transformation JUST to get out of quaternion calculations in order for the computer to get a physical x/y location to draw to.
This all seems moot anyway since d3d can do transformations for you, orthogonally, can't it? Or did I just imagine d3d_transform_set_rotation_* functions? *shrugs* oh well, I'm stupid!
edit: and about gimbal lock, who cares? If a rigid body is hit on its side to rotate around its x-axis, then gets hit again to move about the y-axis...and a third time to move around the z-axis, then it would properly rotate as per physics rules without violation of any laws, even if it "seems" to lock on a plane for 2 rotations at a time every 10 or so. That's normal for all I care, not seeing a downside here.
Edited by sabriath, 24 March 2011 - 12:59 PM.