Car Physics : Constant Timestep

Hi Physics blokes, I am currently messing about with some rigid body stuff referenced from Ruud's code (Richard Chaney), problem is that what I have been doing so far is getting the timestep from the difference between the last update and the current one. This seems to suggest that it is better to have a constant timestep. How can I time this accurately so that the physics is only updated after x millisecs? Also, how do i make sure that there is useful work being done when it isnt time for the physics to be updated. Thanks guys! All the best, Ash PS. Happy New Year!

"Ashley McConnell" <[email hidden]> skrev i en meddelelse news:WMgX7.26689$6D5.233534@NewsReader...

Quoted text (10 lines)

> Hi Physics blokes, > > I am currently messing about with some rigid body stuff referenced from > Ruud's code (Richard Chaney), problem is that what I have been doing so far > is getting the timestep from the difference between the last update and the > current one. This seems to suggest that it is better to have a constant > timestep. How can I time this accurately so that the physics is only > updated after x millisecs? Also, how do i make sure that there is useful > work being done when it isnt time for the physics to be updated. >

Wouldn't it be possible to have your physics-thread high priority (so that it will not miss a calculation) and just let it sleep when not needed? /Jens

> > Hi Physics blokes, > > > > I am currently messing about with some rigid body stuff referenced from > > Ruud's code (Richard Chaney), problem is that what I have been doing sofar > > is getting the timestep from the difference between the last update andthe > > current one. This seems to suggest that it is better to have a constant > > timestep. How can I time this accurately so that the physics is only > > updated after x millisecs? Also, how do i make sure that there isuseful > > work being done when it isnt time for the physics to be updated. > > > > Wouldn't it be possible to have your physics-thread high priority (so thatit > will not miss a calculation) and just let it sleep when not needed? > > /Jens > > Ahh Multithreading :). I was wondering if that was the way to go. I havent done that sort of thing before (except at college in Java). Will need to look into it. How should it be timed - the QueryperformanceCounter functions? Thanks All the best, Ash

"Ashley McConnell" <[email hidden]> wrote in message news:WMgX7.26689$6D5.233534@NewsReader... > Hi Physics blokes, > > I am currently messing about with some rigid body stuff referenced from > Ruud's code (Richard Chaney), problem is that what I have been doing sofar > is getting the timestep from the difference between the last update andthe > current one. This seems to suggest that it is better to have a constant > timestep. How can I time this accurately so that the physics is only > updated after x millisecs? Also, how do i make sure that there is useful > work being done when it isnt time for the physics to be updated. Here's roughly the way I've implemented a constant timestep simulation: timeStep = 0.002; // Or whatever you wish to use t = getTime(); do { while (t < getTime()) { updatePhysics(timeStep); t += timeStep; } drawFrame(); } while (!done); In other words, run the simulation with a constant timestep until it catches up with real time, then draw your graphics, and repeat. This way, you get a constant timestep, the simulation will be in sync with real time when it's time to draw the frame, and you're always either updating the physics or drawing the graphics (and whatever else you add into the main loop). The only problem is if your physics calculations are too slow to be done in realtime, it'll get stuck into the physics loop, trying in vain to catch up to real time. But that's a problem with any fixed timestep simulation. Just check if the code stays too long inside the physics loop (like half a second), and handle that as you wish (like switch to a larger timestep, or throw an exception that tells the user it's time for a CPU upgrade ;-) ). > How should it be timed - the QueryperformanceCounter functions? Definitely! Petri Blomqvist

Petri, (Caveat: I haven't done any programming simulations in a loooong time). It seems to me, that your method would result in some bad prioritizing of resources. If the drawFrame() bit (contains AI cars etc.) is significantly slower than the physics, you will have a staggered simulation, where you are either doing everything else or updating your physics repeatedly. In other words, why not do the physics as needed and "draw" around those calculations? Hope I make myself clear here. ;-) /Jens "Petri Blomqvist" <[email hidden]> skrev i en meddelelse news:a0laac$4gj$[email hidden]...

Quoted text (53 lines)

> > "Ashley McConnell" <[email hidden]> wrote in message > news:WMgX7.26689$6D5.233534@NewsReader... > > Hi Physics blokes, > > > > I am currently messing about with some rigid body stuff referenced from > > Ruud's code (Richard Chaney), problem is that what I have been doing so > far > > is getting the timestep from the difference between the last update and > the > > current one. This seems to suggest that it is better to have a constant > > timestep. How can I time this accurately so that the physics is only > > updated after x millisecs? Also, how do i make sure that there is useful > > work being done when it isnt time for the physics to be updated. > > Here's roughly the way I've implemented a constant timestep simulation: > > timeStep = 0.002; // Or whatever you wish to use > t = getTime(); > do > { > while (t < getTime()) > { > updatePhysics(timeStep); > t += timeStep; > } > drawFrame(); > } while (!done); > > In other words, run the simulation with a constant timestep until it catches > up with real time, then draw your graphics, and repeat. > > This way, you get a constant timestep, the simulation will be in sync with > real time when it's time to draw the frame, and you're always either > updating the physics or drawing the graphics (and whatever else you add into > the main loop). The only problem is if your physics calculations are too > slow to be done in realtime, it'll get stuck into the physics loop, trying > in vain to catch up to real time. But that's a problem with any fixed > timestep simulation. Just check if the code stays too long inside the > physics loop (like half a second), and handle that as you wish (like switch > to a larger timestep, or throw an exception that tells the user it's time > for a CPU upgrade ;-) ). > > > How should it be timed - the QueryperformanceCounter functions? > > Definitely! > > Petri Blomqvist > > > > >

"Jens H. Kruuse" <[email hidden]> wrote in message news:L0rX7.6577$[email hidden]...

Quoted text (7 lines)

> Petri, > > (Caveat: I haven't done any programming simulations in a loooong time). > > It seems to me, that your method would result in some bad prioritizing of > resources. If the drawFrame() bit (contains AI cars etc.) is significantly > slower than the physics, you will have a staggered simulation, where you

are > either doing everything else or updating your physics repeatedly. In other > words, why not do the physics as needed and "draw" around thosecalculations? > > Hope I make myself clear here. ;-) Ummm... yes, you do. :-) But I don't see why the staggered simulation would be a problem, as the simulation only needs to coincide with realtime when you draw the graphics (or does network play require some other way?). I'd be happy to learn other ways of handling it though (multithreading?) Petri

"Petri Blomqvist" <[email hidden]> wrote in message news:a0lhch$2m7$[email hidden]...

Quoted text (8 lines)

> > "Jens H. Kruuse" <[email hidden]> wrote in message > news:L0rX7.6577$[email hidden]... > > Petri, > > > > (Caveat: I haven't done any programming simulations in a loooong time). > > > > It seems to me, that your method would result in some bad prioritizing

of > > resources. If the drawFrame() bit (contains AI cars etc.) issignificantly > > slower than the physics, you will have a staggered simulation, where you > are > > either doing everything else or updating your physics repeatedly. Inother > > words, why not do the physics as needed and "draw" around those > calculations? > > > > Hope I make myself clear here. ;-) > > Ummm... yes, you do. :-) But I don't see why the staggered simulationwould > be a problem, as the simulation only needs to coincide with realtime when > you draw the graphics (or does network play require some other way?). I'dbe > happy to learn other ways of handling it though (multithreading?) It needs to coincide with realtime when you read the controller. Long time since I've programmed windoze code but I believe u use a multimedia timer for this, if I remember correctly. You may get away with simulating the computer cars like this however. Paul --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 24/11/01

"Paul Laidlaw" <[email hidden]> wrote in message news:a0ls86$lcf9q$[email hidden]... > It needs to coincide with realtime when you read the controller. I read the controller once per animation frame, and I update sound once per animation frame, so that's not a problem. > Long time since I've programmed windoze code but I believe u use a > multimedia timer > for this, if I remember correctly. You could, but the performance counter has a better resolution. > You may get away with simulating the computer cars like this however. I don't have any AI cars in my sim yet, and this method works perfectly for the player's car. Too bad the sim isn't in a releasable condition yet (no configuration options or error checking), otherwise you could try it for yourself and see that it works. :-) Petri

Thanks for the replies guys :) Its good to get a discussion on this sort of thing going, helps all the sim-programmers out there :) Jens, could you elaborate a little on your physics thread method? Thanks alot Ash

"Petri Blomqvist" <[email hidden]> wrote in news:a0laac$4gj$[email hidden]:

Quoted text (46 lines)

> "Ashley McConnell" <[email hidden]> wrote in message > news:WMgX7.26689$6D5.233534@NewsReader... >> Hi Physics blokes, >> >> I am currently messing about with some rigid body stuff referenced >> from Ruud's code (Richard Chaney), problem is that what I have been >> doing so far is getting the timestep from the difference between the >> last update and the current one. This seems to suggest that it is >> better to have a constant timestep. How can I time this accurately so >> that the physics is only updated after x millisecs? Also, how do i >> make sure that there is useful work being done when it isnt time for >> the physics to be updated. > > Here's roughly the way I've implemented a constant timestep simulation: > > timeStep = 0.002; // Or whatever you wish to use > t = getTime(); > do > { > while (t < getTime()) > { > updatePhysics(timeStep); > t += timeStep; > } > drawFrame(); > } while (!done); > > In other words, run the simulation with a constant timestep until it > catches up with real time, then draw your graphics, and repeat. > > This way, you get a constant timestep, the simulation will be in sync > with real time when it's time to draw the frame, and you're always > either updating the physics or drawing the graphics (and whatever else > you add into the main loop). The only problem is if your physics > calculations are too slow to be done in realtime, it'll get stuck into > the physics loop, trying in vain to catch up to real time. But that's a > problem with any fixed timestep simulation. Just check if the code > stays too long inside the physics loop (like half a second), and handle > that as you wish (like switch to a larger timestep, or throw an > exception that tells the user it's time for a CPU upgrade ;-) ). > >> How should it be timed - the QueryperformanceCounter functions? > > Definitely! > > Petri Blomqvist

I would argue for varying step updates, meaning that physics should be calculated as functional F(t0, t1): {car1, ... carN, input1, ..., inputN } -> { car1~, ... carN~} Here's why: - it will make your physics more efficient, because otherwise you might have had to call fixed step increment several times. - more important this approach will give your calculation time that is not proportional to the duration of the time passed. This will protect you against hopelessly lagging behind whatever computer (or rather Windows) did at the moment. - this does not complicate the code, because in any case you need to have your algorithms working using dt=t1-t0. - in the network code you will need to be able to have this functional to be able to recalculate cars position basing on the received input from remote computer. In regular physics updates you recalculate using input prediction algorithm instead of missing part of the input, when you get input for the particular car, you recalculate car position from the using that functional from the last known state. This will prevent cheating as the server will be responsible for physics handling. If you're thinking about threads, from my experience threads on Windows (especially Win9x) are not scheduled very good when you have intensive processing going on. Though threads for polling should be fine (polling controller input and posting it for the main thread, same for polling for network events). Alex.

"alexti" <[email hidden]> skrev i en meddelelse news:[email hidden]...

Quoted text (7 lines)

> > If you're thinking about threads, from my experience threads > on Windows (especially Win9x) are not scheduled very good when > you have intensive processing going on. Though threads for > polling should be fine (polling controller input and posting it > for the main thread, same for polling for network events). >

Good point about Windows and threads. I'm thinking a lot about network code at the present time which could explain my infatuation with multi-threading. :-) I can see how using a variable delta-t instead of a constant would make a lot of sense, assuming that the delta-t is significantly less than whatever (converging or diverging) oscilations are taking place in the mechanical bits. Insuring that could be interesting as it must take presendence over eg. graphics. /Jens

"alexti" <[email hidden]> wrote in message news:[email hidden]... > I would argue for varying step updates, meaning that physics > should be calculated as functional > F(t0, t1): {car1, ... carN, input1, ..., inputN } -> { car1~, ... carN~} > Here's why: > - it will make your physics more efficient, because otherwise > you might have had to call fixed step increment several times. Efficient, yes, but potentially also inaccurate and unstable, unless you're using simple 'canned' physics instead of an actual rigid body simulation. If your graphics are being updated at 60 FPS, your physics will also be updated at 60 Hz or less, and that's far from sufficient. > - more important this approach will give your calculation time > that is not proportional to the duration of the time passed. However, it will give you an accuracy and stability that IS dependent on the timestep. Note that I'm talking about a solution that doesn't use multithreading - using multithreading is of course a different case altogether, and one I have no experience with. If the physics thread is capable of carrying on updates while the graphics are being drawn, then the timesteps might remain sufficiently small. But how do you guarantee that? Petri Blomqvist

"Petri Blomqvist" <[email hidden]> wrote in news:a0njc9$n22$[email hidden]:

Quoted text (14 lines)

> "alexti" <[email hidden]> wrote in message > news:[email hidden]... > >> I would argue for varying step updates, meaning that physics >> should be calculated as functional >> F(t0, t1): {car1, ... carN, input1, ..., inputN } -> { car1~, ... >> carN~} Here's why: >> - it will make your physics more efficient, because otherwise >> you might have had to call fixed step increment several times. > > Efficient, yes, but potentially also inaccurate and unstable, unless > you're using simple 'canned' physics instead of an actual rigid body > simulation. If your graphics are being updated at 60 FPS, your physics > will also be updated at 60 Hz or less, and that's far from sufficient.

I understand what you're taking is the step of the differential net (not sure I am giving correct translation of the term, that's a method of approximation of continuous process with discrete one) and not periodicity of updates. If you're capable of resolving your model analytically, you won't have inaccuracies at all (except caused by floating point calculations). Example: to calculate position of the linearly moving point you don't need to calculate it at t1, t2, .. tN, you can calculate it exactly at tN directly. In car physics simulation you are not likely to have complete analytical solution (equations are too complex), however you may use analytical solutions in some parts, in other parts you have to calculate approximately you may use differentials net with various steps as well as other approximate methods. Stability is only applicable to approximate methods and has nothing to do with the frequence of updates. Strictly speaking instability is only an issue if you're going to implement AI drivers which will act as human (provide input and observe results). Otherwise, it is not a control system. What you are more interested in is convergence and precision. The faster your approximate methods converge, faster you will get your update made. This factor more depends on the choice of approximation method. Precision is influenced by the step of the differential net and by the approximation method selected.

Quoted text (13 lines)

> >> - more important this approach will give your calculation time >> that is not proportional to the duration of the time passed. > > However, it will give you an accuracy and stability that IS dependent > on the timestep. > > Note that I'm talking about a solution that doesn't use multithreading > - using multithreading is of course a different case altogether, and > one I have no experience with. If the physics thread is capable of > carrying on updates while the graphics are being drawn, then the > timesteps might remain sufficiently small. But how do you guarantee > that?

In principle, multithreading is not related with the issues covered above. I start to believe that you actually trying to use approximation method based on discretisation(spelling?) of time and synchronize the step of the net with the other components of the program. Let's say we're considering only one car driven by human. To display current state to the driver you need to update physics first to learn this state. Drawing will take some time and as long as you can calculate next car state from the previous one you don't need to know intermediate states. This can be done as multi-thread which I don't think is an efficient solution under Windows, or you can make it from one thread in a loop like: while (true) { t = currentTime(); nextState = updatePhysics(currentState,driverInput); currentState = nextState; displayState(currentState); } One reason why you may need another thread is to collect driver input while you're updating physics and drawing screen. I am not sure how noticable is it, but if for example, driver presses throttle smoothly or abruptly, it should be taken into account by your simulation, which may not happen if you're reading controllers only once per update. Alex.

"alexti" <[email hidden]> wrote in message news:[email hidden]... > I understand what you're taking is the step of the differential net > (not sure I am giving correct translation of the term, that's a method > of approximation of continuous process with discrete one) and not > periodicity of updates. Umm... possibly, but I'm not sure I understand what you're saying here. :-) > If you're capable of resolving your model > analytically, you won't have inaccuracies at all (except caused > by floating point calculations). True, but I can't think of any part of the equations of motion of a rigid body that could be solved analytically under randomly varying forces, so numerical integration would seem to be necessary. > Stability is only applicable to approximate methods and has > nothing to do with the frequence of updates. All the numerical integration methods I know of (euler, midstep, 4th-order runge-kutta, etc.) depend on a sufficiently small timestep for stability. If I have a tire in my simulation that has a vertical stiffness of 500,000 N/m, it'll very easily start to oscillate and eventually fly all the way to Jupiter and back, if the timestep doesn't stay sufficiently small, so stability definitely has everything to do with how often I update the physics! Or maybe I'm misunderstanding what you're saying. > What you are more interested in is convergence and precision. > The faster your approximate methods converge, faster you will get > your update made. Are you saying there's some sort of iterative way to integrate the equations of motion? Does that have something to do with implicit integration? That's something I'll have to look into, I guess. > I start to believe that you actually trying to use approximation > method based on discretisation(spelling?) of time and synchronize the > step of the net with the other components of the program. Could be, but I'm still not sure I understand what you mean by the "net" in this context. :-) > Let's say we're considering only one car driven by human. To display > current state to the driver you need to update physics first to > learn this state. Drawing will take some time and as long as you > can calculate next car state from the previous one you don't need > to know intermediate states. The problem is, how do I calculate the next car state from the previous one without those intermediate states, without inducing instability? Right now I calculate the physics at a fixed 500 Hz - if there really is some way to calculate the physics at rates as low as 30 Hz so that it remains stable, I definitely want to learn it! :-) > One reason why you may need another thread is to collect driver input > while you're updating physics and drawing screen. I am not sure > how noticable is it, but if for example, driver presses throttle > smoothly or abruptly, it should be taken into account by your > simulation, which may not happen if you're reading controllers only > once per update. Hmm. I guess that could be an issue. Petri Blomqvist

> > It needs to coincide with realtime when you read the controller. > > I read the controller once per animation frame, and I update sound onceper > animation frame, so that's not a problem. And if your frame rate is bad? or variable? > > Long time since I've programmed windoze code but I believe u use a > > multimedia timer > > for this, if I remember correctly. > > You could, but the performance counter has a better resolution. It doesn't generate an interrupt however........ > > > You may get away with simulating the computer cars like this however. > > I don't have any AI cars in my sim yet, and this method works perfectlyfor > the player's car. Too bad the sim isn't in a releasable condition yet (no > configuration options or error checking), otherwise you could try it for > yourself and see that it works. :-) You can do it the way you say, and it does work, but Jens has a valid point, it is swings and roundabouts. Paul --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.303 / Virus Database: 164 - Release Date: 25/11/01

"Petri Blomqvist" <[email hidden]> wrote in news:a0o80k$9lb$[email hidden]:

Quoted text (68 lines)

> "alexti" <[email hidden]> wrote in message > news:[email hidden]... > >> I understand what you're taking is the step of the differential net >> (not sure I am giving correct translation of the term, that's a method >> of approximation of continuous process with discrete one) and not >> periodicity of updates. > > Umm... possibly, but I'm not sure I understand what you're saying here. > :-) >> If you're capable of resolving your model >> analytically, you won't have inaccuracies at all (except caused >> by floating point calculations). > > True, but I can't think of any part of the equations of motion of a > rigid body that could be solved analytically under randomly varying > forces, so numerical integration would seem to be necessary. > >> Stability is only applicable to approximate methods and has >> nothing to do with the frequence of updates. > > All the numerical integration methods I know of (euler, midstep, > 4th-order runge-kutta, etc.) depend on a sufficiently small timestep > for stability. If I have a tire in my simulation that has a vertical > stiffness of 500,000 N/m, it'll very easily start to oscillate and > eventually fly all the way to Jupiter and back, if the timestep doesn't > stay sufficiently small, so stability definitely has everything to do > with how often I update the physics! Or maybe I'm misunderstanding what > you're saying. > >> What you are more interested in is convergence and precision. >> The faster your approximate methods converge, faster you will get your >> update made. > > Are you saying there's some sort of iterative way to integrate the > equations of motion? Does that have something to do with implicit > integration? That's something I'll have to look into, I guess. > >> I start to believe that you actually trying to use approximation >> method based on discretisation(spelling?) of time and synchronize the >> step of the net with the other components of the program. > > Could be, but I'm still not sure I understand what you mean by the > "net" in this context. :-) > >> Let's say we're considering only one car driven by human. To display >> current state to the driver you need to update physics first to >> learn this state. Drawing will take some time and as long as you >> can calculate next car state from the previous one you don't need to >> know intermediate states. > > The problem is, how do I calculate the next car state from the previous > one without those intermediate states, without inducing instability? > Right now I calculate the physics at a fixed 500 Hz - if there really > is some way to calculate the physics at rates as low as 30 Hz so that > it remains stable, I definitely want to learn it! :-) > >> One reason why you may need another thread is to collect driver input >> while you're updating physics and drawing screen. I am not sure >> how noticable is it, but if for example, driver presses throttle >> smoothly or abruptly, it should be taken into account by your >> simulation, which may not happen if you're reading controllers only >> once per update. > > Hmm. I guess that could be an issue. > > Petri Blomqvist >

Let's say you have continuos implicitly defined function F(X,t) on the [x0;x1]x[t0;t1]. For example, by equation G(F(X,t),X,t) = 0 where G is too complex to find F explicitly. X does not have to be a scalar, but for simplicity let's assume it is. In this case one of the main numeric methods is to define a "net" (sorry, english is not my first language, I don't know the right term) as a set of "nodes" (x(i),t(j)) where i=0,N, j=0,M Usually x(0)=x0, x(N)=x1, t(0)=t0, t(M)=t1. x(i+1)-x(i) and t(j+1)-t(j) do not have to be a constant, but if they're the next has fixed step. There're many numeric methods that allow to calculate F(i,j) which approximate F(X(i),t(j)) from the original equation. Steps (of the "net") in this case do not affect stability, by they're just points where you want to find the value of F. The more iterations you do the better is approximation (however this is not related to the timestep). Instability may arise is your function is defined as something like G(F(X,t),F(Y,t-dt))=0. Then if you calculated F(Y,t-dt) approximately your error may grow. You could avoid it by saving all input and recalculating from the starting point instead of previous state, however implementation of that would face problems of memory requirement to store input as well as performance issues. AFAIK there're some methods to deal with this case. I don't know this area well, but idea is that they use past states, but not the very beginning. Each of the past states participate with a weight selected some complex criteria that will ensure convergence. This way you have more calculations to do to get every next step, however this amount is fixed and is not growing, instead you can afford bigger error in your approximation because it doesn't accumulate thus saving some time. With your original idea, you will still get error accumulation, no matter how small is your step and you still need some kind of feedback to prevent simulation from breaking down. As I understant you're looking at this simulation from the point of view of physics, mechanics and math analysis, but you need more to make it work well. I am sorry I can not point to any particular place to look for answers, but here're some directions. There's a part of Applied Math that studies numerical solution for physics/mechanic equations. There's another area of Applied Math that studies control of the technical systems. At some point they overlap with each other, and this one is a good area to look into. Now I am trying to guess correct terms. They might be something like difference/differential nets or grids or schemes, stability stuff have terms like feedback and after-effect. The problem is that those methods might be difficult to get into unless you specialize in Math. Concering rigid body simulation, I think I've heard about some research done, so probably you can find ready to use methods. Alex.

"Paul Laidlaw" <[email hidden]> wrote in message news:a0od72$l6u82$[email hidden]... > > > It needs to coincide with realtime when you read the controller. > > > > I read the controller once per animation frame, and I update sound once > > per animation frame, so that's not a problem. > > And if your frame rate is bad? or variable? If the frame rate is bad, your lightning-fast steering reflexes won't do much good anyway because all you'll see is a slideshow, so what's the point of reading the controller more often? (it's not exactly a fast operation, and neither is updating sound, as far as I know, so it would seem to be best to keep those updates at a sufficient minimum). I could be wrong, of course. :-) > > You could, but the performance counter has a better resolution. > > It doesn't generate an interrupt however........ Well, if you need interrupts generated then you'd obviously use the multimedia timer. If not, as is the case with my sim, the performance counter would seem to be a better choice. > You can do it the way you say, and it does work, but Jens has a valid > point, it is swings and roundabouts. True. :-) The only reason I'm using the methods that I am is because the others I tried didn't work and these do. If it turns out some other method will work better, I'll switch to it without hesitation. :-) Petri Blomqvist

"alexti" <[email hidden]> wrote in message news:[email hidden]... > snip < Thanks for the explanation, Alex! Will have to investigate that method. :-) Petri Blomqvist

On Mon, 31 Dec 2001 00:55:07 -0000, "Paul Laidlaw" <[email hidden]> wrote:

Quoted text (7 lines)

>> > It needs to coincide with realtime when you read the controller. >> >> I read the controller once per animation frame, and I update sound once >per >> animation frame, so that's not a problem. > >And if your frame rate is bad? or variable?

You can do the same what you do with graphics to the controller reading. Get a fixed timestep for the controller reads, and put an extra 'if(curSimTime>=nextControllerReadTime)ReadControllers(),nextControllerReadTime+=0.01' in there. I believe GPL does this. BTW I use the same swingy method; update controllers and sound just every gfx frame. Seems ok. Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

Quoted text (15 lines)

>Instability may arise is your function is defined as something like >G(F(X,t),F(Y,t-dt))=0. Then if you calculated F(Y,t-dt) approximately >your error may grow. You could avoid it by saving all input and >recalculating from the starting point instead of previous state, >however implementation of that would face problems of memory requirement >to store input as well as performance issues. > >AFAIK there're some methods to deal with this case. I don't know this >area well, but idea is that they use past states, but not the very >beginning. Each of the past states participate with a weight selected >some complex criteria that will ensure convergence. This way you >have more calculations to do to get every next step, however this >amount is fixed and is not growing, instead you can afford bigger >error in your approximation because it doesn't accumulate thus saving >some time.

I think I tried something like this awhile back when trying to stabilize my tires' rotation without decreasing the integration time step. I averaged the last 10 or so time steps' slip ratios together, then averaged that value with the current calculated value, and used that for the slip ratio (it worked a little like using relaxation lengths). Is this at least a very basic example of what you're talking about here, or am I misunderstanding the idea? Actually, I think I allowed the current calculated value to have as much effect as the previous 10 (or something like that), before averaging them and using this final value (weighting?). Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

[email hidden] (J. Todd Wasson) wrote in news:[email hidden]:

Quoted text (41 lines)

>>Instability may arise is your function is defined as something like >>G(F(X,t),F(Y,t-dt))=0. Then if you calculated F(Y,t-dt) approximately >>your error may grow. You could avoid it by saving all input and >>recalculating from the starting point instead of previous state, >>however implementation of that would face problems of memory >>requirement to store input as well as performance issues. >> >>AFAIK there're some methods to deal with this case. I don't know this >>area well, but idea is that they use past states, but not the very >>beginning. Each of the past states participate with a weight selected >>some complex criteria that will ensure convergence. This way you >>have more calculations to do to get every next step, however this >>amount is fixed and is not growing, instead you can afford bigger >>error in your approximation because it doesn't accumulate thus saving >>some time. > > > I think I tried something like this awhile back when trying to > stabilize my > tires' rotation without decreasing the integration time step. I > averaged the last 10 or so time steps' slip ratios together, then > averaged that value with the current calculated value, and used that > for the slip ratio (it worked a little like using relaxation lengths). > Is this at least a very basic example of what you're talking about > here, or am I misunderstanding the idea? Actually, I think I allowed > the current calculated value to have as much effect as the previous 10 > (or something like that), before averaging them and using this final > value (weighting?). > > > Todd Wasson > --- > Performance Simulations > Drag Racing and Top Speed Prediction > Software > http://PerformanceSimulations.Com > > My little car sim screenshots: > http://performancesimulations.com/scnshot4.htm > >

In principle yes, though usually those methods are much more complicated. Your method adds a lot of damping, but I am not really familiar with tire rotation modelling, so I can't comment on this particular usage. Essentially you approximate function slip_ratio(t) with some function constant on [t0;t1). Alex.

On Wed, 09 Jan 2002 05:34:08 GMT, [email hidden] (alexti) wrote:

Quoted text (7 lines)

>[email hidden] (J. Todd Wasson) wrote in >news:[email hidden]: > >> I think I tried something like this awhile back when trying to >> stabilize my >> tires' rotation without decreasing the integration time step. I >> averaged the last 10 or so time steps' slip ratios together,

... >In principle yes, though usually those methods are >much more complicated. Your method adds a lot of damping, Which is normally the thing to go for, at low speed. As long as you turn it off when the thing starts rotating. And that's fortunately what racing's all about. :) It seems a more regular filter where there's some kind of inertia attached to the changing of the value may be simpler and effective enough for most car simulations (handling at low speed is generally of lesser importance there). Ruud van Gaal Free car sim : http://www.marketgraph.nl/gallery/racer/ Pencil art : http://www.marketgraph.nl/gallery/

"J. Todd Wasson" wrote:

Quoted text (26 lines)

> > >Instability may arise is your function is defined as something like > >G(F(X,t),F(Y,t-dt))=0. Then if you calculated F(Y,t-dt) approximately > >your error may grow. You could avoid it by saving all input and > >recalculating from the starting point instead of previous state, > >however implementation of that would face problems of memory requirement > >to store input as well as performance issues. > > > >AFAIK there're some methods to deal with this case. I don't know this > >area well, but idea is that they use past states, but not the very > >beginning. Each of the past states participate with a weight selected > >some complex criteria that will ensure convergence. This way you > >have more calculations to do to get every next step, however this > >amount is fixed and is not growing, instead you can afford bigger > >error in your approximation because it doesn't accumulate thus saving > >some time. > > I think I tried something like this awhile back when trying to stabilize my > tires' rotation without decreasing the integration time step. I averaged the > last 10 or so time steps' slip ratios together, then averaged that value with > the current calculated value, and used that for the slip ratio (it worked a > little like using relaxation lengths). Is this at least a very basic example > of what you're talking about here, or am I misunderstanding the idea? > Actually, I think I allowed the current calculated value to have as much effect > as the previous 10 (or something like that), before averaging them and using > this final value (weighting?).

An averaging filter like that will have very high variations in frequency response at different frame rates also. At the high frame rates you are using it the change won't be significant, but at normal PC game frame rates it could be very serious. I saw someone using that for a joystick filter once which would be very bad. - Matt

Quoted text (7 lines)

>In principle yes, though usually those methods are >much more complicated. Your method adds a lot of damping, >but I am not really familiar with tire rotation modelling, >so I can't comment on this particular usage. Essentially >you approximate function slip_ratio(t) with some function >constant on [t0;t1). >

Ok, at least I'm following the basic idea. High level math isn't my best area :0) Stuff like this makes no sense to me: >>>Instability may arise is your function is defined as something like >>>G(F(X,t),F(Y,t-dt))=0. Then if you calculated F(Y,t-dt) approximately >>>your error may grow. Huh?? lol Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Quoted text (13 lines)

>>In principle yes, though usually those methods are >>much more complicated. Your method adds a lot of damping, > >Which is normally the thing to go for, at low speed. As long as you >turn it off when the thing starts rotating. >And that's fortunately what racing's all about. :) > >It seems a more regular filter where there's some kind of inertia >attached to the changing of the value may be simpler and effective >enough for most car simulations (handling at low speed is generally of >lesser importance there). > >Ruud van Gaal

I'm mostly just curious for stability reasons and to make sure the car stops properly. My low speed torsion spring model works pretty well for this, but it's tough to adjust properly. My little 4WD radio controlled cars can have exploding drivetrains rather quickly, and that's with the center diff locked... Was curious about other approaches (as always.) Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm

Quoted text (10 lines)

>An averaging filter like that will have very high variations >in frequency response at different frame rates also. > >At the high frame rates you are using it the change >won't be significant, but at normal PC game frame >rates it could be very serious. >I saw someone using that for a joystick filter once >which would be very bad. > >- Matt

Oh, ok.. Will keep an eye out for that. I'm not using the filter now, this was before the low speed torsion spring was put in.. Todd Wasson --- Performance Simulations Drag Racing and Top Speed Prediction Software http://PerformanceSimulations.Com My little car sim screenshots: http://performancesimulations.com/scnshot4.htm