[ODE] Weird collision/force problem
Clay Fowler
claytonious at cox.net
Wed Nov 13 18:45:02 2002
This is a multi-part message in MIME format.
------=_NextPart_000_003A_01C28B44.A40C1F10
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
In case anyone else runs into this, here is the solution...
The axes seemed inverted because I was incorrectly copying the =
transformation matrix from ODE into OSG. I finally looked at the code in =
the drawstuff lib to see how to fill an OpenGL-style 4x4 matrix with =
values, and I was doing it backwards. Now that I'm filling xform =
matrices properly, everything works wonderfully.
----- Original Message -----=20
From: Clay Fowler=20
To: ode@q12.org=20
Sent: Monday, November 11, 2002 6:01 PM
Subject: [ODE] Weird collision/force problem
Hello, everyone.
I have a problem with forces being applied to my rigid body. My =
vehicle's "front" is along the positive Y-Axis, its "right" is along the =
positive X-axis and it's "up" is positive-Z. When I call =
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"), =
specifying the rear-right of the vehicle as the point (so it's, for =
example, an X of 1 and a Y of -1), for some reason the FRONT LEFT of the =
vehicle gets pushed up into the air. This is the opposite corner of the =
point I am specifying! When I swap the coordinates and apply an upward =
force at the point (-1,1), the REAR RIGHT of the vehicle gets pushed up. =
I have verified that ODE and my app both have the same idea of what the =
world coordinate axes are by applying forces to the center of mass to =
move the vehicle along the world's X, Y, and Z axes and these all behave =
exactly as I would expect. But when I apply a force at a point, it seems =
like the point I'm passing is "mirrored" on the axes. I am specifying =
the mass of the vehicle with a simple dMassSetBox() and I have visually =
verified that the box is a very good fit to the vehicle. Any ideas on =
why the axes are "mirrored" this way for applying forces?
The reason this is such a big problem is because I am doing my own =
collision detection with the terrain beneath the vehicle by creating my =
own Contact joints where the vehicle touches the terrain. Of course, the =
vehicle responds incorrectly to these points because of the mirroring =
problem.
Thanks for any help!
- Clay
------=_NextPart_000_003A_01C28B44.A40C1F10
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2719.2200" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>In case anyone else runs into this, =
here is the=20
solution...</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The axes seemed inverted because I was =
incorrectly=20
copying the transformation matrix from ODE into OSG. I finally looked at =
the=20
code in the drawstuff lib to see how to fill an OpenGL-style 4x4 matrix =
with=20
values, and I was doing it backwards. Now that I'm filling xform =
matrices=20
properly, everything works wonderfully.</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dclaytonious@cox.net =
href=3D"mailto:claytonious@cox.net">Clay Fowler</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A title=3Dode@q12.org=20
href=3D"mailto:ode@q12.org">ode@q12.org</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Monday, November 11, 2002 =
6:01=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> [ODE] Weird =
collision/force=20
problem</DIV>
<DIV><BR></DIV>
<DIV><FONT face=3DArial size=3D2>Hello, everyone.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>I have a problem with forces being =
applied to my=20
rigid body. My vehicle's "front" is along the positive Y-Axis, its =
"right" is=20
along the positive X-axis and it's "up" is positive-Z. When I call=20
dBodyAddForceAtPoint() with a force vector of 0,0,1 ("straight up"),=20
specifying the rear-right of the vehicle as the point (so it's, for =
example,=20
an X of 1 and a Y of -1), for some reason the FRONT LEFT of the =
vehicle gets=20
pushed up into the air. This is the opposite corner of the point I am=20
specifying! When I swap the coordinates and apply an upward force at =
the point=20
(-1,1), the REAR RIGHT of the vehicle gets pushed up. I have verified =
that ODE=20
and my app both have the same idea of what the world coordinate axes =
are by=20
applying forces to the center of mass to move the vehicle along the =
world's X,=20
Y, and Z axes and these all behave exactly as I would expect. But when =
I apply=20
a force at a point, it seems like the point I'm passing is "mirrored" =
on the=20
axes. I am specifying the mass of the vehicle with a simple =
dMassSetBox() and=20
I have visually verified that the box is a very good fit to the =
vehicle. Any=20
ideas on why the axes are "mirrored" this way for applying=20
forces?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>The reason this is such a big problem =
is because=20
I am doing my own collision detection with the terrain beneath the =
vehicle by=20
creating my own Contact joints where the vehicle touches the terrain. =
Of=20
course, the vehicle responds incorrectly to these points because of =
the=20
mirroring problem.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thanks for any help!</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>- Clay</FONT></DIV>
<DIV><FONT face=3DArial =
size=3D2></FONT> </DIV></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_003A_01C28B44.A40C1F10--