[ODE] swapping axes

[SJS]

For the sake of speed, I would recommend keeping this kind of thing in your
preprocessing stage if possible, but if you're in a bind:

1) as long as you're restricting yourself to a rotation that's a multiple of
90 degrees DON'T waste your time with a matrix multiply (or worse, a
quaternion).  Although these are reasonable approaches, they are overkill
(and probably slower than necessary).

Any 90 degree rotation and a handedness change can be accomplished by
swapping axes and/or changing their sign.  It's the same as using a matrix
or quaternion, but because you're limiting the change or basis to 90 degree
rotations, all of the numbers turn out to be 1 or 0, simplifying things:

90 degree rotation about x in a left-handed system:
3x3 matrix (DirectX style, multiplying row vector v*M):
[ 1  0  0 ]
[ 0  0  1 ]
[ 0 -1  0 ]

simplifies to:
x' = x
y' = z
z' = -y

What you were originally doing (swapping Y and Z) was this:
x' = x
y' = z
z' = y

which in matrix form is
[ 1  0  0 ]
[ 0  0  1 ]
[ 0  1  0 ]

this is a rotation about x (the previous matrix above) followed by a Z scale
of -1 (this changes the handedness of the system).

You COULD have used the matrix, but you intutively knew that it was much
easier to swap y and z.

For simple axes/handedness changes, you should be able to find an
appropriate transformation that is just a permutation of x,y, and z, with
possible sign changes.
(you should always end up with one x, one y, and one z, but the signs depend
on the rotation and whether there is a handedness change).

SJS


-----Original Message-----
From: ode-bounces at q12.org [mailto:ode-bounces at q12.org]On Behalf Of Nate
W
Sent: Tuesday, February 10, 2004 10:07 PM
To: ODE
Subject: RE: [ODE] swapping axes


On Tue, 10 Feb 2004, Jon Watte wrote:

> > But, wouldn't it mean a bunch of extra multiplications with
> > every timestep?  I'm a little concerned about the CPU overhead
> > that would entail... should I be?
>
> "Extra" compared to what? Compared to a "solution" that's broken?

Perhaps I wasn't clear enough.  Here's the comparison I had in mind:

1) transform positions and orientations going into ODE (yes, with
multiplications rather than just swapping values <G>), when setting up the
scene; and transform them again, for each rendered object, when rendering
each frame.

2) use a geom transform for the terrain geometry when setting up the
scene.

On second thought, the latter is probably faster if one uses
dSpaceCollide2 (terrain, other_stuff).  I hadn't thought of that.

But on third thought, I'm not sure that a geom transform would change
heightmap collision at all, since the heightmap collider doesn't use the
heightmap's R matrix.

--

Nate Waddoups
Redmond WA USA
http://www.natew.com/


_______________________________________________
ODE mailing list
ODE at q12.org
http://q12.org/mailman/listinfo/ode