Matrix vs Quaternion

Please don't post Bullet support questions here, use the above forums instead.
Post Reply
User avatar
Dennis
Posts: 12
Joined: Sat Jun 23, 2007 9:13 pm
Location: San Francisco
Contact:

Matrix vs Quaternion

Post by Dennis »

Hey, which is your preferred rotational representation for physics? I know most APIs use 3x3 matrices, but quaternions kind of makes more sense to me, assuming non-uniform scale, shear, etc is not supported. Especially these days, when cache misses are so expensive. Any thoughts?
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Matrix vs Quaternion

Post by Erwin Coumans »

For Bullet 3.x we will most likely store orientation as quaternions. For most platforms it is likely the best choice for performance, because it is a more compact representation. Even if you like to use matrices at some stage, you can convert from Quat to Mat fairly fast (several tens of cycles), compared to the cost of cache misses (several hundreds of cycles).

Cheers,
Erwin
bone
Posts: 231
Joined: Tue Feb 20, 2007 4:56 pm

Re: Matrix vs Quaternion

Post by bone »

My personal opinion is that it might depend on your constraints-to-bodies ratio. If you have several constraints per body, you're usually spending a lot of time doing transforms, not only in setting up the constraint for solving, but in any iterative position correction step at the end of the timestep (if you happen to be doing that). And that's not to mention the need to transform for collision detection, and to compute the inverse inertia tensor, and to transfer location info if the graphics system is hierarchy-based, plus the difficulty in integrating the gyro effect when using a quaternion representation, etc.
melax
Posts: 42
Joined: Mon Apr 24, 2006 4:55 pm

Re: Matrix vs Quaternion

Post by melax »

Admittedly there are different opinions on the subject:
http://www.gamedev.net/reference/articl ... le1199.asp

:)

my 2c:

Anything non rendering is pretty much quaternions for me. From an api perspective it might be easier to specify the placement of a joint/constraint with a matrix (such as axis binormal and normal) rather than specifying an orientation. But if i needed that I would add that in a short inline convenience function in the header file. In the physics implementation everything is quats.

Some engines even forgo using a matrix for the inertia tensor and instead maintain an internal body orientation that's aligned with the principle axis.


So what about graphics:
The graphics apis have always used 4x4 matrices. Indeed, a projective transform is a fine place to use a matrix. However, everywhere else in rendering, using quaternions is actually quite viable - including the vertex's orientation. Vertex orientation? What's that? Well, if you've ever done any bump mapping, or parallax occlusion mapping, your vertex buffers might have a normal, tangent and binormal. What you are essentially specifying is the orientation of the transformation that moves you between tangent space and local space, i.e. the vertex orientation. This orientation can be stored as a 4 float quat instead of the 9 float 3x3 tbn matrix. Admittedly, there are alternate forms of compression. And yes, i have actually implemented this (exporter, importer, vertex shader etc).

Opengl's model matrix (or d3d's world matrix) transform between local and world, the view matrix between world and eye space, etc, etc. All of these rigid transforms can be specified with a quaternion position pair. In fact they probably are already - until you hit the graphics pipeline. Trace back to the other physics and AI game systems where the values of these matrices came from. In the game code, these cameras, bones, rigid bodies, and other objects have a position and orientation that are often represented with a vector quat pair. Only when the rendering code begins is the data converted to a matrix. Conceivably you could continue to use a quaternion for orientation here. Although you *could*, in this case, i'm not suggesting that you *should* use quat. Obviously, for optimizing batch processing it does make sense to cache the quat to a matrix. i.e. use Mv instead of qvq* inside of a big loop. Although, i've noticed a good compiler can sometimes extract cache-able parts of expressions and put them outside of the loop in the generated assembly code. Within the gpu, i implemented it (bye bye world view and every other non projection matrix). It works the same as before and i didn't notice any difference in speed. All my .fx files are smaller and cleaner than they used to be. But code cleanliness is clearly subjective.

Again, let me just mention this is my 2c. Use whatever works best for you.
User avatar
Dennis
Posts: 12
Joined: Sat Jun 23, 2007 9:13 pm
Location: San Francisco
Contact:

Re: Matrix vs Quaternion

Post by Dennis »

I finally settled on using Quaternions for the bodies themselves and matrices for the shape transform, for a couple of reasons: Quaternions makes more sense for bodies, since physical object doesn't shear or scale, and most operations you do on bodies are actaully faster on quats, like applying angular velocity, computing relative orientation and renormalization. I decided to go for 4x4 matrices on shape transforms since they are static, and it makes sense to support a more generic transform here, such as non-uniform scaling, assuming collision detection can handle it. Internally for collision detection, etc, I use 4x4 exclusively for the speed.

I also like specifying moment of inertia as a 3-tuple, assuming the transform is aligned with principal axes. It makes so much more sense to do he final transform back to object space in a separate layer, and only if actually needed.
Post Reply