[ODE] FDir1 and Slip for car wheels

[Jon Watte]

> > 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+