> since quite a few people here are building their own sims:
> what would you consider a minimum integration step for an arcadey
> driving game? not as arcadey as Lego Racers, but something like
> Driver. I realize you'll need quite a high frequency for a die-hard
> simulation, but I'd guess you could do with a lot less for something
> like what I have in mind.
> we're starting up a new project here, and it really would save me a
> lot of hassle if I could link the simulation to the framerate.
There are a lot of issues.
It has to be fast enough that you don't have instability
or excessive inaccuracy at low frame rates (for PC games, etc.).
How fast depends on the accuracy and lag (frequency response)
characteristics of the integration method you use.
You can use rules of thumb, but even so you will have
to do experiments on your particular problem.
A rule of thumb would be 100 to 30 or perhaps down to 10 times
faster than the important dynamics frequency of your motion.
Cars, planes, bombs etc., ;) have 1 to 3 cycles per second in their
main rigid body motions, with the more sluggish vehicles slower.
But motion of the wheels and suspension, and the rotation of wheels
if you use fancy traction and drive train models
can be quite a bit higher.
Minor changes in an integration scheme can greatly
change the frequency response characteristics of the integrator.
So designing an integration scheme that favors numerical
stability over accuracy is rather different than maximizing
accuracy per effort (which is what most reference books discuss.)
This is an important point, because it means that most of
what you will read about whther one integrator is better than
another will be useless to you because their criteria concentrates
on accuracy rather than frequency response. Also, integration
comparisons sometimes include the "overhead" of the
algorithm and this can lead to the wrong conclusions when
applied to the parts of the real world where the derivative
updates can take thousands of times more effort than the
integrator processing itself. (So that if you run an overly
simple test case you might come up with an entirely different
answer about which is best than if you ran your actual problem.)
In general, the higher the order of the integrator the larger
step you can take to maintain stability (as well as accuracy).
However you will need to do multiple derivative update calls per
integration step for higher order algorithms so that reduces the
advantages partially or completely.
Often times there will be certain parts of your overall design
that take large amounts of time and/or need to be computed
at a particular rate to have the required resolution.
For example graphics, or interacting with the graphics database
for collisions or finding the ground or pathfinding, sound, etc.
In this case, an overall best solution for the motion integration
might be an algorithm that seems "slower" but that fits better
into your overall scheme (such that you can perform certain
elements at the required rate.) An example of this is if you
are required to deal with curbs well in a racing game.
If you integrate with too large a step such that you move 10 ft
at a time at high speed, you might miss a curb entirely
depending on how you do it. Another might be sound.
Racing engines change RPM quickly and so the sound will
have a certain minimum update rate that will sound adequate.
For these cases the overall solution might be better if you
use an algorithm that requires smaller step sizes since you
have to take smaller steps anyway for this other requirement.
Another area that is harder than it seems before you try it
at low frame rates is collision avoidance by AI.
An extra 50 to 100 milliseconds can be critical in
whether or not they run into the back of the car ahead.
If you use large steps, you will have to
give them extra braking capability, perhaps.
Luck,
(have to go, my build is done! ;)
--
Matthew V. Jessick Motorsims
Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216
