[ODE] How to use the rotation matrix returned by dGeomGetRotation

[Duncan Frostick]

Cheers for all the helpful replies guys,

I've tried many things suggested all to no avail. I thought the rotation 
matrix was very strange, I'm glad someone else does too. The rotation 
matrix I get returned for any of my meshes, regardless of whether I've 
stepped the world or not is:

[0]	0.00000000
[1]	1.8750000
[2]	0.00000000
[3]	0.00000000
[4]	0.00000000
[5]	0.00000000
[6]	0.00000000
[7]	0.00000000
[8]	0.00000000
[9]	0.00000000
[10]	0.00000000
[11]	1.8750000

Now, I'm using d*Geom*GetRotation as opposed to d*Body*GetRotation, 
because I haven't yet set dMass properties to assign it a dBody, but 
that should be no problem right?

And I was having trouble with converting my meshes from DX to ODE, but 
that seems to be resolved. I was going to try rendering the meshes I've 
converted from DX in drawstuff to see if they're still the same (using 
the test_trimesh code) but now whenever I compile and run trimesh test 
code I'm getting an access violation in windows threading that stops 
execution (but that might be because I changed to the latest CVS ODE so 
I'll try that again with just plain 0.5). But could dodgy 
vertices/indices be causing ODE to output a non-sensical matrix? What 
other things could be causing this behaviour in ODE?

Cheers, Duncan


Jon Watte wrote:
> If you're using dReal == float, then the code I suggested
> should not leave the end of the matrix un-touched -- that's
> what copying the position and setting the 15th element to
> 1 is all about.
> 
> It may be that ODE internally ignores the extra fourth element
> in the rotation matrix, and you get garbage in the fourth
> column -- it seems that element 11 in your debug dump shows
> something like that.
> 
> There was a typo in my suggested code, too: the second
> memcpy() of position, should clearly say:
> 
>   memcpy( &matrix[12], P, sizeof(float)*3 );
> 
> Note the missing offset by 12 on the destination :-)
> 
> 
> However, the screen shot you posted has too many zeros to be
> healthy. I think you're getting something else wrong. If you
> inspect the R value you get out of dBodyGetRotation() as an
> array of 12 floats, what does the debugger say before you
> try to copy the elements in the first place?