Ode Rotation Matrix Vs Houdini Rot Matrix Vs Crack

[BrianK]

I don't know how far everyone has gotten with the ODE in Houdini (still haven't checked out the latest from CVS), so I'll start with the assumption that no one has dealt with converting ODE dMatrx3's to Houdini UT_Matrix3 (or DMAtrix3).

so, (as I understand it) In ODE, a dMatrix3 is just a 1D array of elements. Rotation matrices (3 x 3 dMatrx3) are actually stored by columns of four for memory alignment issues, so a 3x3 rotation matrix has elements:

00 01 02 03

04 05 06 07

08 09 10 11

the bold indexes being the actual 3x3 matrix, the non-bold are throw away (again, as I understand it).

These matrices also appear to be oriented opposite of houdini's - the correlation I've found to work is this:

  UT_Matrix3 oderot;

      oderot(0,0) = dBodyGetRotation(bodyID)[0];
      oderot(1,0) = dBodyGetRotation(bodyID)[1];
      oderot(2,0) = dBodyGetRotation(bodyID)[2];
      
      oderot(0,1) = dBodyGetRotation(bodyID)[4];
      oderot(1,1) = dBodyGetRotation(bodyID)[5];
      oderot(2,1) = dBodyGetRotation(bodyID)[6];
      
      oderot(0,2) = dBodyGetRotation(bodyID)[8];
      oderot(1,2) = dBodyGetRotation(bodyID)[9];
      oderot(2,2) = dBodyGetRotation(bodyID)[10];

Here's my question:

Assuming the above is correct (which it may or may not be - it does work in practice, however), if I crack oderot to pull out individual rotations, I only get values from -PI/2 to PI/2. I don't know if this has something to do with the way ODE creates the matrices internally, the way crack works, or if it's just something you have to deal with somehow. Anyone care to shed some light on the subject?

[edward]

From what you describe, it looks to be that ODE's matrices are oriented the same way. Houdini's matrices are column-major as well. Thus the first index specifies the column, not the row

(http://odforce.net/wiki/index.php/HDKFrequentlyAskedQuestions). The only difference seems to be the padding per column.

As for cracking rotation matrices, that's just the way it works. If you look at the equations for rotation matrices, note that the matrix components consist of trig functions like sin(theta) and cos(theta). And so taking the inverses of these functions only give you theta values in [-PI/2,+PI/2] or depending on the algorithm, some extracted values may in [0,PI] from the use of atan2().

The thing to note is that for any given rotation matrix, it can represent multiple euler rotation angle triplets. So given a single rotation matrix, you won't be able to (in general) recover the original euler rotations.

[BrianK]

As for cracking rotation matrices, that's just the way it works.

20497[/snapback]

I figured as much. Do you (or anyone else, for that matter) have a suggestion for a workaround?

Currently, I save last frame's eulers & if I see a change that's too big, I add in a PI/2 for PI/2 rotations. That works fine and all, until, of course, the object starts rotating really fast.

[edward]

If you're willing (or can) take a history based approach, then take your newly cracked rotation (in radians) as a UT_Vector3 and call roundAngles() on it with the previous rotation values (in radians).

[BrianK]

Fantastic! Thanks.