[ODE] FDir1 and Slip for car wheels
Jon Watte
hplus-ode at mindcontrol.org
Tue Dec 7 19:49:48 MST 2004
> > Lower center of gravity
> looks unnatural when rotating
Have you actually seen real cars rotating in the air? Most of their
mass is in the bottom plate, the engine, and the gearbox. All of this
is biased towards the bottom of the car. I'd have no problem putting
the center of gravity in line with the bottom of the chassis of the
car.
And, if you want car rotation in the air, then chances are you aren't
really after really physical cars; you want "arcade" or "stunt" cars,
at which point entirely different mechanisms could be used.
> >Sway bars -- when the left strut compresses, add a compression force on
> >the right strut, and a corresponding de-compression force on the left
> >strut.
> This is not too real, is it? I would like to stick to reality as much as
> possible. However it sounds like it helps a lot in stabilizing the car so
> I'll probably give it a try.
Crawl under a performance car some day. There are probably sway bars
clearly visible there, so I'd say they're real :-)
> I still think (hope) FDir1 can help with this. Has anybody used it?
Yes; carworld uses it (it's in mywheeledcar.cpp, for example). However,
I've only ever used the same mu for both directions.
Another two things I forgot about:
1) Add aerodynamic load. A constant times your forward velocity squared
should push the main body of the car in the car's down direction (not
the gravity direction!). This will help with stability at high speeds.
2) The "front" of the wheel isn't necessarily the "front" of the car,
as the wheel both turns and rotates. I extract "front" and "up" of the
wheel, and then, to calculate fdir1, I do this:
// The theory is that it doesn't matter if "front" points "up"
// because we want fdir2 to be orthogonal to "front" and contact
// normal. Of course, if "front" points in the direction of the
// contact, this can be a problem. In that case, choose "up".
if( fabsf( dDot( contact.geom.normal, &front.x, 3 ) ) > 0.5f ) {
((Vector3 &)contact.fdir1) = up;
}
else {
((Vector3 &)contact.fdir1) = front;
}
This means that I use a vector that's lowly correlated with the collision
normal as my "fdir1" vector, which means that the cross product is always
well defined. If you just hard-code it to use one (say, "front"), you
will find that in some orientations, the cross-product to generate fdir2
goes haywire.
Cheers,
/ h+
More information about the ODE
mailing list