integration step in driving sims

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. -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 "a poster is a human being or the software equivalent"

The limiting integration step is given by calculating the wheel rotations based on their interaction withthe road. It's not a matter of accuracy, but of stability, so if you want to model this aspect properly, you need to go to very high frequencies. If you can find a clever way of avoiding calculating this part through some simplifications, a few 10Hz engines are more than sufficient for a non-aero car with a reasonably soft suspension. On the other hand, I would not recommend to link the framerate and the integration timestep, unless you can guarantee a steady framerate. This would mean that, should the framerate change, so should the gameplay properties as the physics will be off mopre for a low framerate, and that is not desireable. -Gregor Gunnar Horrigmo wrote:

Quoted text (16 lines)

> > 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. > > -- > Gunnar > #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 > "a poster is a human being or the software equivalent"

Gregor Veble <[email hidden]> writes:

Quoted text (13 lines)

> The limiting integration step is given by calculating the wheel > rotations based on their interaction withthe road. It's not a matter of > accuracy, but of stability, so if you want to model this aspect > properly, you need to go to very high frequencies. If you can find a > clever way of avoiding calculating this part through some > simplifications, a few 10Hz engines are more than sufficient for a > non-aero car with a reasonably soft suspension. > > On the other hand, I would not recommend to link the framerate and the > integration timestep, unless you > can guarantee a steady framerate. This would mean that, should the > framerate change, so should the gameplay properties as the physics will > be off mopre for a low framerate, and that is not desireable.

ok. I guess it's not that much hassle anyway. thanks for the reply, Gregor. :) -- Gunnar #31 SUCKS#015 Tupperware MC#002 DoD#0x1B DoDRT#003 DoD:CT#4,8 Kibo�: 2 silence is FOO!

Gunnar Horrigmo wrote:

Quoted text (11 lines)

> > 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 [email hidden] http://www.moto1.net Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216

>Also, integration comparisons sometimes include the >"overhead" of thealgorithm 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. Wow ,thats amazing This was the topic of discussion at our dinner table last night. ;-) Actually this stuff fascinates me--even if it's over my head at times. "mjessick-Motorsims" <[email hidden]> wrote in message news:[email hidden]...

Quoted text (87 lines)

> Gunnar Horrigmo wrote: > > > > 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 > [email hidden] http://www.moto1.net > Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216

On Wed, 15 Aug 2001 15:31:31 GMT, mjessick-Motorsims <[email hidden]> wrote: >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. Hi Matt, Do you have any idea whether an RK4 (or RK2 even) integration scheme would do better for a car sim? It seems to me the body can do with 100Hz easily without getting out of control, but the tires require something far more; 1000Hz here for karts (no suspensions) and F1 cars. Perhaps with RK4 I can downsize to 100Hz again. Would help a lot with other things. Most of the time here is still spent in: 1. Spline triangle testing; if you're outside of the track, this unoptimized search processes too much. A quadtree can fix this. 2. Collision with triangles. I could reduce the frequency at which collisions are tested I guess and take larger from-to steps. Anyway, just don't know whether an RK4 integration scheme would do well for the unpredictable tire/suspsension sections. Thanks, Ruud van Gaal, GPL Rank +53.25 Pencil art : http://www.marketgraph.nl/gallery/ Free car sim : http://www.marketgraph.nl/gallery/racer/

Ruud van Gaal wrote: > Do you have any idea whether an RK4 (or RK2 even) integration scheme > would do better for a car sim? It seems to me the body can do with > 100Hz easily without getting out of control, but the tires require > something far more; 1000Hz here for karts (no suspensions) and F1 > cars. Perhaps with RK4 I can downsize to 100Hz again. Would help a lot > with other things. If you did a trade study of a good 1 derivative second order method vs RK4 you might find something like 4x100 derivatives per sec for RK4 for the edge of stability versus 1x300 derivatives for the second order method (those are my rules of thumb for x10 and x30 times dominant frequency of 10 hz for your assumed problem. This is from our experience and may not match your problem.) There would (maybe) be a small advantage for the 2nd order method, depending on exactly how your system spends its processing time.

Quoted text (10 lines)

> > Most of the time here is still spent in: > 1. Spline triangle testing; if you're outside of the track, this > unoptimized search processes too much. A quadtree can fix this. > 2. Collision with triangles. > > I could reduce the frequency at which collisions are tested I guess > and take larger from-to steps. Anyway, just don't know whether an RK4 > integration scheme would do well for the unpredictable > tire/suspsension sections.

This is kind of what I was hinting at. Ground checking may be expensive, and if it is, you might use RK4 at 10 or so times the dominant frequency rather than a second order algorithm at 30+ times the dominant frequency. (Note that because the RK4 requires 4 derivative updates it might take 33% more CPU time than the 2nd order method (just going by the number of derivatives)). BUT, depending on your exact requirements, that might match something strange like your ground checking resolution requirement better and so the overall system might take less CPU time. (Just because of complexities in the multi-rate system you have.) And you can also play around with holding various things constant during RK4 exploratory steps, etc., but that gets complicated fast ;) This all pertains to "Direct" intgration methods. Some people in game development are using/experimenting with implicit integration methods. These maintain stability better than the direct methods, but do so by washing out the dynamics when the extra stability is needed. Depending on requirements, they may well do a better overall job. -- Matthew V. Jessick Motorsims [email hidden] http://www.moto1.net Vehicle Dynamics Engineer (972)910-8866 Ext.125, Fax: (972)910-8216