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

[Jon Watte]

A dGeom has its own rotation matrix if you haven't yet 
assigned it to a body.

Latest CVS ODE should not crash your machine; there's probably 
something else that corrupts the heap. Add "assert(_CrtCheckMemory())" 
to the beginning, middle, and end of all your routines to trap 
memory corruption early. (Remove the calls when you're done for 
highest performance :-)

You should not need to convert meshes between ODE and DirectX, 
except possibly the winding order of the triangle list. If you 
touch the vertices, you're probably doing something you don't 
have to, and which will confuse more than it'll help.

Last suggestion: I build ODE as part of my project (a sub-project 
that generates a library). This makes it ultra easy to step into 
ODE and figure out what's going on; for example where the data 
is coming from when getting the matrix of a Geom. You can also 
easily set data breakpoints at that point to figure out where 
specific pieces of data are being changed.

If you are sure that you put good rotations INTO the geom in the 
first place, then it's pretty clear that the geom matrix is 
getting corrupted somewhere, somehow -- possibly in your mesh 
conversion code? 1.875 seems too "good" a floating point value 
to be just random data, so it has to come from somewhere...

Cheers,

			/ h+


-----Original Message-----
From: Duncan Frostick [mailto:duncanf at f2s.com]
Sent: Monday, October 11, 2004 11:54 AM
To: Jon Watte; 'ODE mailing list'
Subject: Re: [ODE] How to use the rotation matrix returned by
dGeomGetRotation


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?