[ODE] Mapping to OpenGL axis system: not convinced

Jani Kajala jani at sumea.com
Sun Nov 25 10:46:01 MST 2001


> Weird, I had always thought it was the opposite way. Could it have anything to

There are actually two different issues here:
1) How matrices are stored: i.e. if 4x4 matrix = float [16] array then is
X-translation element [3] or [12]?
2) How matrices are indexed when doing computations with them: m(column,row) vs.
m(row,column)? i.e. does M2*M1 mean "first transform with M1 and then with M2"
or other way around.

Both of these issues differ from library to another (which obviously sucks big
time). It is very easy make errors if you're dealing with multiple libraries all
using different conventions. Only way to be sure is to check the matrix code of
each library and then transform some points back and forth to see that the
results match what you expect.


Regards,
Jani Kajala

----- Original Message -----
From: "Ruud van Gaal" <ruud at marketgraph.nl>
To: <ode at q12.org>
Sent: Saturday, November 24, 2001 1:10 AM
Subject: RE: [ODE] Mapping to OpenGL axis system: not convinced


> Hi Norman,
>
> > I am surprised no one jumped in with an explanation here, since a reversal
> > of coordinate systems would be a rather important issue, if it indeed were
> > the case in ODE. So, I attempted to reproduce your error. I was unable to.
> ...
> > Starting with the following orientation:
> >
> > -0.000000 0.000000 1.000000
> > 0.000000 1.000000 0.000000
> > -1.000000 0.000000 -0.000000
> ...
> > I obtain after one frame the following orientation
> >
> > 0.000000 0.071051 0.997473
> > -0.000000 0.997473 -0.071051
> > -1.000000 -0.000000 0.000000
> ...
> > This is NOT in agreement with your results. You got a slightly positive
> > y component for the z axis. I got a slightly negative component for the
> > y component of the z axis (as it should be, and as you expected).
>
> That's weird. Thanks for testing this out; I'll have to invest more time,
> perhaps create a small test program derived from test_boxstack.cpp for example
> to see what's going on.
>
> > Is it possible that your torque is so large that you are causing a
> > rotation more than 360 degrees, causing an apparent rotation in the
> > wrong direction?
>
> I don't think so. Using smaller torque I hardly get any movement (say, 10), so
> I upped that to 1000. I use timesteps inbetween 0.001 and 0.004 seconds in my
> sim.
>
> ...
> > If the body's rotation matrix is represented by R, then the matrix R
> > converts FROM coordinates expressed in frame R *TO* world coordinates -
> > which is indeed the correct behavior.
>
> Weird, I had always thought it was the opposite way. Could it have anything to
> do with a premultiply vs. postmultiply thing (have read about that, but don't
> know exactly what the implications are)?
> Couldn't you also think of it the other way? I mean, take a world vector
> (1,0,0), multiply that with R (which is a projection onto the axes in R), and
> you end up with the (1,0,0) vector in R's coordinates (body coordinates). This
> would give a body->world conversion. Or would you be multiplying with the
> transpose of R to achieve that? (whoever invented the row vs column matrix
form
> to make things so confusing! ;-)).
>
> > Consider the vector (1,0,0). Assuming
> > this vector is in R coordinates, this means it is one unit along R's local
> > X axis. Multiplying this vector by R gives you the first column of R -
> > which is R's local X axis, in WORLD coordinates. So, R converts from
> > body coordinates to world coordinates.
>
> You're right, I can follow that. Strangely though, with the tranpose, I get
> everything working. I added contact points and the car behaves reasonably well
> (although on some kerbs it gets way too much impulse when hitting that (I use
> an OBB-plane intersection to generate the contact points with ODE itself).
>
> > Are you sure you don't have a mixup in your code?
>
> I might, but then my *whole* program would have been built in reverse
thinking.
> :) Amazing that it could still work that way, lol. I must do some more testing
> and see where I go wrong. Too bad I've got 30hr/day workdays coming up. :(
>
> Thanks very much for the help,
> Ruud
>
> From another post:
> ...
> > Earlier I wrote about instability after applying a torque to a floating
> > body with no gravity or other forces. I forgot to mention that I apply
> > exactly ONE torque for ONE timestep, and apply NO torque or forces
> thereafter.
>
> Depends I think on the size of the timestep. Although it seems here that with
a
> 250Hz timestepping frequency, the cars can gain energy. But haven't delved
much
> in the softness variables, so I think it's my parameters, and not ODE, since
> the boxstack example works ok-ish (and that's some 20hz!).
>
> Ruud
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>





More information about the ODE mailing list