# Representing 3D Rotations

This topic is 4065 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I'm trying to start working on a 3D physics library. I have all the linear velocities and forces figured out (because they're pretty standard), but what about rotational velocities and torques? As I see it there are three ways to represent them: 1) Quaternions 2) Matrices 3) 3 component vectors I'm trying to figure out which one will be easiest to work with. Quaternions are nice because I don't have to worry about Gimbal lock (at least not as much from what I've read), but will most physics texts cover rotational forces and impulses with quaternions? My current physics book is primarily about concepts and, while it discusses all the needed topics, it doesn't give a good idea of how to represent these mathematically. It's pretty much all in 2D, only mentioning 3D when there is a difference. I'm saving up to get one of the many books on game physics but I wanted to jump in anyway. Any suggestions, advice, or articles on this? Thanks in advance.

##### Share on other sites
Quote:
 Quaternions are nice because I don't have to worry about Gimbal lock (at least not as much from what I've read)...
You don't have to worry about gimbal lock with matrices or basis vectors either, so this should not be a factor in your choice of rotation representation.

Beyond that, I think you can safely narrow the choices down to quaternion vs. matrix (since working with the orientation in terms of basis vectors is going to result in the same operations, essentially, as will working with the orientation in matrix form).

Of these two, I don't think it matters much which you use. If you use a quaternion to represent the orientation, you'll probably have to convert to matrix form at some point for rendering purposes, and if you use a matrix, you may end up wanting to convert to quaternion form for interpolation purposes (e.g. for interpolating between physics snapshots for rendering).

Note that you can interpolate (e.g. slerp) orientations in matrix form as well; it's just a little more awkward and a little less efficient than with quaternions.

As far as the equations of motion go, the quaternion forms of these equations are readily available online if you want to go that route (for example, they can be found in the Baraff papers on rigid body dynamics).

##### Share on other sites
Personally, I stick with matrices. They are basically the simplest and most useful form of a rotation. A matrix represents implicitly a transformation from one coordinate system to another. Another benifit is that you don't have to do anything to them to transform vertices, etc. You just mulitply the point through the matrix to get your new point. With quaternions, you still have to convert the quaternion to a matrix to transform points.

And also, you don't use matrices to represent angular velocities, only orientations. Torque, angular velocity, etc are represented by simple {x,y,z} vectors.

when integrating, you create a skew-symmetric matrix from the angular velocity vector and add that *dt to the orientation.

##### Share on other sites
The reason there are so many systems in circulation is that different situations demand different representations.

In a flight simulator, it is desirable to have three axes of rotation with 2p-periodicity in each. Euler-angles or quaternions are the natural choice. On another hand, there may be a situation where the program needs to check if two orientations are equivalent. Quaternions and Euler-angles will fail here due to their extra degree of freedom. Polar coordinates or unit-3-vectors are a better choice.

In any case, you can't accommodate everyone. There will always be a case where the grass is genuinely greener on the other side. For this reason, I suggest you hang onto Euler angles (as they are the most general), and be prepared to convert to any other form when necessary.

##### Share on other sites
Quote:
 Original post by TheAdmiralIn any case, you can't accommodate everyone. There will always be a case where the grass is genuinely greener on the other side. For this reason, I suggest you hang onto Euler angles (as they are the most general), and be prepared to convert to any other form when necessary.

In my opinion this is terrible advice. I strongly suggest not using Euler angles.

Matrices and quaternions are 6 of one and half a dozen of the other...:

Pro-quaternion: Quaternions take less memory (so may result in faster execution due to better cache use). Multiplying quat by quat is faster (fewer instructions anyway) than matrix by matrix (but this operation may be rare in a physics engine, but it might well come up in the collision system where you have heirachies). Quaternion normalisation is easier/faster than matrix ortho-normalisation (but it doesn't actually have to be done much anyway).

Pro-matrix: Transforming a vector by a matrix is faster (fewer instructions) than using a quaternion (btw you don't have to go via a matrix when transforming with a quaternion, as suggested by Aressera). Debugging may be easier, since it's quite easy to visualise a 3x3 rotation matrix by just looking at the numbers.

You might even be able to abstract it out and just have a rotation transform class. Then you could build two versions of your library and compare the performance.

##### Share on other sites
Quote:
 Original post by TheAdmiralOn another hand, there may be a situation where the program needs to check if two orientations are equivalent. Quaternions and Euler-angles will fail here due to their extra degree of freedom. Polar coordinates or unit-3-vectors are a better choice.

va = rot(a,b,c)
vb = rot(a2,b2,c2)
diffVec = va - vb
diff2 = diffVec DOT diffVec

if(diff2 < granularity){
return THE_SAME
} else {
return diff2;
}

It looks quite straightforward.

##### Share on other sites
Quote:
Original post by Raghar
Quote:
 Original post by TheAdmiralOn another hand, there may be a situation where the program needs to check if two orientations are equivalent. Quaternions and Euler-angles will fail here due to their extra degree of freedom. Polar coordinates or unit-3-vectors are a better choice.

va = rot(a,b,c)
vb = rot(a2,b2,c2)
diffVec = va - vb
diff2 = diffVec DOT diffVec

if(diff2 < granularity){
return THE_SAME
} else {
return diff2;
}

It looks quite straightforward.

Okay, sure. But judging from the level of confusion about rotations on this forum (and everywhere else), I'm not convinced it's safe to assume that the user isn't going to attempt to test the rotation's coordinates for equality.

1. 1
Rutin
42
2. 2
3. 3
4. 4
5. 5

• 9
• 27
• 20
• 14
• 14
• ### Forum Statistics

• Total Topics
633384
• Total Posts
3011598
• ### Who's Online (See full list)

There are no registered users currently online

×