elchtest mod :)

[sebiastisch]

Thanks again for the information.

The suspension approximation seems reasonable, although many nuances of suspension behavior are impossible to be simulated.
I'm thinking for example of a Weissach rear axle, where not only the deflection of the wheel influences the toe in and other parameters (sorry for the maybe wrong words, but I've learned that stuff in a different language...), as it is influenced by more than just kinematic constraints.
But even in terms of kinematic behavior this is not enough.
With a modern multi wishbone suspension (not sure on that name either) you can modify the axle behavior almost as you wish. What you need for that is a complex suspension model. And that does not make tuning the cars easier, because you need a lot of knowledge to get the parameters right..

The only real axis i can think of, which you can describe by one fixed IC is the swing axis (used in the old VW Käfer). And that axis had real bad behavior when cornering (the center of mass goes up) and the Käfer tended to fall over (makes me think of your elchtest mod . It is also very unsteady on non-flat roads, as the car reacts with negative camber when deflecting, which creates cornering force.

The problem with all the racing games is, that although they have different suspensions, the car behavior comes not very close to reality (at least I don't know a game, that does).

Could you point me to the code section where new angular velocity us used with old linear velocity.

I was just guessing, how it works (waiting for you to correct me, if it is wrong ).

What about running chassis+suspension at a slow rate. But to update chassis velocity(depending on tire forces) during tire simulation cycle(at a high rate). I am not sure if it's possible with btRigidBody though.

When using the btActionInterface, btRigidBody allows you to interfere the bullet physics pipeline once between two cycles. At that point you can f.e. add an impulse due to friction between the tires and the ground. this impulse can be calculated with a higher frequency when the updateAction callback is executed (at that point between two cycles). you are able to set any motion state (including the linear and angular velocities) you want, that is defined in your class inheriting from btActionInterface.
what could work is to calculate the friction and its effect on the wheel velocity with high frequency in your subclass and the applying the new wheel speed to the wheel motion state. suspension (modeled by constraints) would then handle the changes and calculate the influences on the chassis. therefore a timestep of 120Hz should be ok, because even a F1 chassis is pretty heavy (compared to the wheels).

One last thing in terms of frequency:
I think i remember from my lectures, that the natural oscillation frequency of an axis is about 15Hz and that the chassis frequency is about 1.5Hz. Misusing nyquist-shannon in a creative way, one could conclude, that you need 30 Hz for the suspension and 3 for the body. indeed this is encouraged by the frequency active/adaptive suspension systems have (which is 3Hz for slow and 30 Hz for fast systems. the latter being able to cope with suspension oscillation). So i guess 60Hz is ok for a suspension simulation.