Frame Rate Independence

[Erwin Coumans]

Code: Select all

stepSimulation(0); //do nothing (0 steps).
stepSimulation(2);  //we just computed two seconds (20 steps).
stepSimulation(1.05); //we compute a second (10 steps). We have 0.05s left to compute in future batch calls.
stepSimulation(0.03); //nothing gets computed (0 steps). We have another 0.03s left to compute in future batch calls, totalling 0.08s.
stepSimulation(0.02); //we have 0.05 + 0.03 + 0.02 = 0.10s to compute, which is >= our timeStep, so we compute 1 step.

The current 'stepSimulation' is batch-mode and works as you described in the table above, if you only pass in one argument, the delta time.

Using btSteppingInfo , we can clarify the API and remove the confusion of the meaning of fixed internal substep, clamping the maximum number of substeps and choice to use substeps or variable single timestep (although not recommended). I never expected developers to add a variable timestep as 3rd argument.

So to use a fixed internal simulation substep of 10 hertz, the code would be:

Code: Select all

dynamicsWorld->getSteppingInfo().m_fixedSubstep=1./10.;
dynamicsWorld->stepSimulation(1.05); //we compute a second (10 steps). We have 0.05s left to compute in future batch calls.

To disable simulation substeps, we could add

Code: Select all

dynamicsWorld->getSteppingInfo().m_enableSimulationSubsteps=false;//warning, this feature is unsupported: it is responsibility of the developer to not vary the deltaTime, Bullet doesn't support simulation using varying timesteps.
dynamicsWorld->stepSimulation(deltaTime); //simulate over deltaTime, ignoring the fixed internal simulation timestep.

Erwin

[sparkprime]

Firstly, I'm really suprised you are considering breaking backwards compatability when it's not really necessary. Do you really want to have to change all those demos and documentation? At least keep the deprecated call around for a while.

Also, I think changing what stepSimulation does is even worse than just removing it outright, since a compile error is more helpful than an app that doesn't work anymore.

• If you want to break compatability, choose a name other than stepSimulation e.g. "advanceSimulation", "tickSimulation" or maybe just "simulate" (I like short names), for the top level API, and delete stepSimulation.
• Otherwise, keep both functions around, and label stepSimulation as deprecated in the doxygen html docs.

Using btSteppingInfo , we can clarify the API and remove the confusion of the meaning of fixed internal substep, clamping the maximum number of substeps and choice to use substeps or variable single timestep (although not recommended). I never expected developers to add a variable timestep as 3rd argument.

I'm happy as it looks like these things can be tweaked with a single line of code. Personally I would still use getters/setters as it's more idiomatic, but Bullet already uses the btSteppingInfo style so I guess there's a good case for that too. I just wanted it removed from the parameters, I don't really mind how this is achieved.

So to use a fixed internal simulation substep of 10 hertz, the code would be:

Code: Select all

dynamicsWorld->getSteppingInfo().m_fixedSubstep=1./10.;
dynamicsWorld->stepSimulation(1.05); //we compute a second (10 steps). We have 0.05s left to compute in future batch calls.

Perfect, so long as m_fixedSubstep is not set every frame (I am sure this is not what you were implying!)

Here's a more complete example:

Code: Select all

dynamicsWorld->getSteppingInfo().m_fixedSubstep=1./10.;
btScalar last = time();
while (alive) {
    // input, game code, render, AI, etc
    btScalar now = time();
    dynamicsWorld->stepSimulation(now-last);
    last = now;
}

To disable simulation substeps, we could add

Code: Select all

dynamicsWorld->getSteppingInfo().m_enableSimulationSubsteps=false;//warning, this feature is unsupported: it is responsibility of the developer to not vary the deltaTime, Bullet doesn't support simulation using varying timesteps.
dynamicsWorld->stepSimulation(deltaTime); //simulate over deltaTime, ignoring the fixed internal simulation timestep.

Erwin

This is pretty far from what I would like

• It reuses stepSimulation to do non-substepped simulation, the parameter means something different depending not just on the other parameters but the state of the member variable!
• It conflates disabling of interpolation with disabling of substeps
• It doesn't allow the deferring of btMotionState callbacks until after a synchronisation point

Why not just let people call the internal substep themselves? It's really simple (12 instead of 8 lines) and much more powerful giving indepedent control over all of the above + per internal tick callbacks for free. To me, there seem to be endless advantages. I know it's more detailed than the current implementation, but that's the point. Beginners and the demos can just use the simple loop provided behind stepSimulation (or whatever it ends up being called). Advanced users have the power they need, with a more low-level but still perfectly intuitive API.

Code: Select all

btScalar fixed_sub_step=1./10.;
btScalar last = time();
while (alive) {
    // input, game code, render, AI, etc
    btScalar now = time();
    dynamicsWorld->simulationBegin(); // apply gravity, whatever else needs doing
    while (now-last >= fixed_sub_step) {
        dynamicsWorld->internalStep(fixed_sub_step);
        last += fixed_sub_step;
    }
    dynamicsWorld->simulationEnd(now-last); //btMotionState stuff including interpolation
}

[jezek2]

I have not much problem with current stepSimulation. But reading these posts I think it could be improved this way:

1) change stepSimulation to have only timeStep (1st param)

2) make maxSubSteps (2nd param) and fixedTimeStep (3rd param) set once (setter or the SteppingInfo), especially when it's not meant to be variable per step

3) add a new function stepSimulationFixed (or some other name), which would do exactly one step of given time, or alternatively without parameter and using fixedTimeStep (in case you don't want to provide an easy way for variable time step, even if it's not supported officially)

4) make boolean flag in SteppingInfo (or setter) to explicitly enable/disable any interpolation in MotionStates

[Erwin Coumans]

I have not much problem with current stepSimulation. But reading these posts I think it could be improved this way:

1) change stepSimulation to have only timeStep (1st param)

2) make maxSubSteps (2nd param) and fixedTimeStep (3rd param) set once (setter or the SteppingInfo), especially when it's not meant to be variable per step

3) add a new function stepSimulationFixed (or some other name), which would do exactly one step of given time, or alternatively without parameter and using fixedTimeStep (in case you don't want to provide an easy way for variable time step, even if it's not supported officially)

4) make boolean flag in SteppingInfo (or setter) to explicitly enable/disable any interpolation in MotionStates

I fully agree. I would rename stepSimulationFixed to singleStepSimulation. This would be without any argument, we don't want to easily allow for stepping the simulation using variable timesteps.

Firstly, I'm really suprised you are considering breaking backwards compatability when it's not really necessary. Do you really want to have to change all those demos and documentation? At least keep the deprecated call around for a while.

Also, I think changing what stepSimulation does is even worse than just removing it outright, since a compile error is more helpful than an app that doesn't work anymore.

This is not a change to what stepSimulation does. Most demos and users just pass in one parameter to stepSimulation, so there is no impact due to this API change. Remember that the 2nd and 3rd argument are optional parameters with default values.

Thanks for the feedback,
Erwin

[sparkprime]

4) make boolean flag in SteppingInfo (or setter) to explicitly enable/disable any interpolation in MotionStates

I think if you have singleStepSimulation then you need to also have beginSimulation and endSimulation to provide the other funtionality (applyGravity, clearForces, motion state + interpolation, kinematic state, etc) that needs to happen. We don't want to wrap all that up in every internal step, since that doesn't make sense, and I don't like the idea of not providing it in the singleStepSimulation case either. The advanced interface is meant to provide more functionality, not less

Note that it's pretty natural to put such code in functions like that anyway, I'm just proposing making them part of the official documented API rather than some internal utility thing.

Also if you have an endSimulation() function that does the interpolation, you need to give it (via a parameter) the time to interpolate forward. Isn't it really extrapolation rather than interpolation anyway? The future transform is not known yet

This is not a change to what stepSimulation does. Most demos and users just pass in one parameter to stepSimulation, so there is no impact due to this API change. Remember that the 2nd and 3rd argument are optional parameters with default values.

Ah yes, you're absolutely right. Those that use the default 60hz and max_sub_steps will not notice any change and those that use 2 or all 3 parameters will get a compile error because the function no longer has that many parameters. It's all good.

[abaraba]

i dont understand how every single one of my questions that started this discussion ended up ignored, together with almost everything else i said later on?

chunky,

Code: Select all

Abaraba: OK, one last attempt before I quit responding to this.

what does that mean? ..you dont really have to, and i wish there was much less talk about basic stuff that gets repeated over and over again even tho the very names of these variables are sufficient to explain what each of these 3 parameters for stepSimulation() mean

Code: Select all

int btSimpleDynamicsWorld::stepSimulation( btScalar timeStep,int maxSubSteps, btScalar fixedTimeStep)

lets hear whether it WORKS and point out which Bullet demo we should be looking at? ...also, you could choose to respond to other 99% of my questions that were not addressed in any way, even tho in most cases can be answered by simple yes/no or choose a) / b)

i did answer to your comment, let me quote myself:
"i have no idea about that function i just copy/pasted it as it was already used as example" - meaning i use proper timing or/AND BULLET DEMOS code - "i also used CcdPhysicsDemo as example.." - it was clear, that stepSimulation(dt, 0) works for me, that i CAN calculate and fix framerates on fast(er) computer - AND nothing would really properly work in millsec. ...and again i used BULLET DEMOS as example... so forget milliseconds already, ok?

Code: Select all

1) Have. You. Tried. Dividing. Your. First. Parameter. By. 1000.0f? If so, what results did you see?. It's a total of eight characters to add to your code and a recompile.

whats wrong, why are you talking like that?
milliseconds, eh ...yes, i have time in seconds - lets just talk about *CcdPhysicsDemo*, or any other Bullet demo to keep this simple, ok? so, in what Bullet demos is "Frame Rate Independence" implemented or, if not, choose one Bullet demo and show me?

i demonstrated how to achieve the effect by using stepSimulation(dt, 0), can you demonstrate the correct, supported way? .. note that i compared that with how stepSimulation(dt, 100) or similar DO NOT work, can you explain that?

Code: Select all

2) You need to show some actual code here. Spark, I, Erwin, all have working code that displays framerate-independance. That your code doesn't implies that your code is doing something different to mine. Therefore I need to see your code before I can help with more than wild guesses

are you kidding me??
there are 7 snippets of code i am trying to discuss here... lets just talk about *CcdPhysicsDemo*, or any other Bullet demo so everyone can follow, ok?

and if you missed them then, here are some code again:

//during idle mode, just run 1 simulation step maximum
int maxSimSubSteps = m_idle ? 1 : 1;
if (m_idle)
dt = 1.0/420.f;

int numSimSteps = 0;
numSimSteps = m_dynamicsWorld->stepSimulation(dt,maxSimSubSteps);

/----
change to this:
m_dynamicsWorld->stepSimulation(dt, 0);

show me how to achieve the same effect i get with stepSimulation(dt, 0), but your way?
(stepSimulation(dt, 1000) does not work... nothing even similar to former)

have.you.tried.overloading.your.scene.or.you.just.ignorant.as.you.have.500FPS.to.spare.on every.render-pass.so.in.effect.you're.blind.to.be.noticing.this.problem.in.a.first.place.. maybe?


more code,
that was invisible 1st time around

are you guys saying that all of these are frame rate independent ?
1.)
Code:
//*** fixing fps at 60, knowing we will always have time to spare
while( dTime < 1/60 )
getDeltaTime( dTime ) // dTime = time in seconds since last frame was rendered
stepSimulation(1/60, 1);
or even maybe
stepSimulation(dTime, 5); // note that dTime is not exactly 1/60
2.)
Code:
//*** fixing fps at 10, knowing we will always have time to spare
while( dTime < 1/10 )
getDeltaTime( dTime ) // dTime = time in seconds since last frame was rendered
stepSimulation(1/10, 10);
3.)
Code:
getDeltaTime( dTime ) // dTime = time in seconds since last frame was rendered
stepSimulation(dTime, 100);

yes/no?



cheers


p.s.
1.)
for all people that have no problem achieving "Frame Rate Independence", but still for some reason wanna go around changing everything - please open new thread to discuss API changes, please

2.)
for all people that want to discuss basics usage of stepSimulation and what each parameter means please just read documentation and then join in, please

3.)
please, try to address questions with answers not assumptions, if possible ..or at least try to 1st answer the questions that are most simple for you and skip the ones you have nothing new to say or know about.. thanks

[Erwin Coumans]

i dont understand how every single one of my questions that started this discussion ended up ignored, together with almost everything else i said later on?

It is your arrogant attitude that make us ignore you. Change your attitude to be more friendly, or get banned. The CcdPhysicsDemo 'stepSimulation' is framerate independent.

I think if you have singleStepSimulation then you need to also have beginSimulation and endSimulation to provide the other funtionality (applyGravity, clearForces, motion state + interpolation, kinematic state, etc) that needs to happen. We don't want to wrap all that up in every internal step, since that doesn't make sense, and I don't like the idea of not providing it in the singleStepSimulation case either. The advanced interface is meant to provide more functionality, not less

The singleStepSimulation would include the applyGravity, clearForces, motion state+interpolation etc., and call the existing protected "internalSingleStepSimulation", just like our current special case of passing 0 as second argument does.

Thanks,
Erwin

[sparkprime]

The singleStepSimulation would include the applyGravity, clearForces, motion state+interpolation etc., and call the existing protected "internalSingleStepSimulation", just like our current special case of passing 0 as second argument does.

Hmm, I don't think I appreciate the usefulness of that. It would require one to call applyForce for every internal tick, consequently it would be hard to decouple the game logic from the physics engine. It would also synchronise the motion states more often than necessary. I can't imagine how interpolation would work in such a situation, since the timing information simply isn't there. I think there would be no choice but to make interpolation unavailable.

What I had in mind for this call is to be able to control the various features of the stepSimulation loop more tightly but it seems from your responses that you don't think this is very valuable? Either that or I haven't been clear enough

As far as my personal needs go I can just extend the class and provide whatever I like so I'm not going to petition hard for this... I just feel it would be a very powerful API and the only cost would be to add a couple more functions that pretty much already exist.


Thanks for your quick replies by the way.

[abaraba]

It is your arrogant attitude that make us ignore you. Change your attitude to be more friendly, or get banned. The CcdPhysicsDemo 'stepSimulation' is framerate independent.

English is not my 1st language, i made clear that im stupid, that i do not understand and merely seek explanation - but it did occur to me that my overexplanations could appear wrong, so i did say this:

hope i didnt give wrong impression - i do like Bullet a lot and i didnt mean to sound as if i question the way things are done, im simply too stupid for that, im truly asking all these questions and looking forward to hear answer to as many as possible, i hope i explained enough the way i misunderstand things so i can be more easily corrected... and most of all i hope this is not some stupid driver/hardware problem

i thought i was helping everyone else too, to understand this and also helping you to improve the library...i can demonstrate, i can video CcdPhysicsDemo and everything im talking about ..are you not interested?

btw,
many people do agree that Bullet demos slow-down, something like slow-motion or "moon-like" effect, i asked that question in another thread when i still wasnt aware it could be because of stepSimulation() - "why Bullet demos feel like happening on the moon?"
http://www.bulletphysics.com/Bullet/php ... f=9&t=2511

i invite, if i may, everyone else who experiencing the same problem to say so - i hope its obvious this is constructive and bona fide invitation .. i have no idea why this feels like a "taboo", but you can see everyone kind of hesitates to confirm it, even tho its obvious there is something wrong or, at least, not clear about how it is all supposed to be or "look" like


please,
if possible, tolerate my bad English and terrible communication skills.. thank you

[Erwin Coumans]

i can demonstrate, i can video CcdPhysicsDemo and everything im talking about ..are you not interested?

By default, Bullet uses a fixed internal simulation timestep of 60 hertz. This is independent of the delta time or graphics frame rate.

The stepSimulation will simulate up several internal substeps, until clamping happens. If the computer is too slow to perform the simulation substeps in real-time, this has nothing to do with failing 'Frame Rate Independence', but the simulation is too intensive for your computer. The CcdPhysicsDemo will report the number of dropped simulation frames, when you define VERBOSE_TIMESTEPPING_CONSOLEOUTPUT. It might help to increase the maximum number of maximum substeps (second argument for stepSimulation), but more likely the computer is too slow to simulate your simulation using Bullet.

Here are some options one last time: if your computer is dropping simulation frames:

• upgrade your PC
• simplify the simulation
• improve Bullet performance

Hmm, I don't think I appreciate the usefulness of that. It would require one to call applyForce for every internal tick, consequently it would be hard to decouple the game logic from the physics engine. It would also synchronise the motion states more often than necessary. I can't imagine how interpolation would work in such a situation, since the timing information simply isn't there. I think there would be no choice but to make interpolation unavailable.

What I had in mind for this call is to be able to control the various features of the stepSimulation loop more tightly but it seems from your responses that you don't think this is very valuable? Either that or I haven't been clear enough

When simulating a full timestep using this proposed "singleStepSimulation" there would be no interpolation indeed. Why don't we provide such singleStepSimulation in a similar way to the ODE API?

Thanks,
Erwin

[sparkprime]

Hmm, I don't think I appreciate the usefulness of that. It would require one to call applyForce for every internal tick, consequently it would be hard to decouple the game logic from the physics engine. It would also synchronise the motion states more often than necessary. I can't imagine how interpolation would work in such a situation, since the timing information simply isn't there. I think there would be no choice but to make interpolation unavailable.

What I had in mind for this call is to be able to control the various features of the stepSimulation loop more tightly but it seems from your responses that you don't think this is very valuable? Either that or I haven't been clear enough

When simulating a full timestep using this proposed "singleStepSimulation" there would be no interpolation indeed. Why don't we provide such singleStepSimulation in a similar way to the ODE API?

I wasn't anticipating that use at all (I've not used ODE). I was anticipating having direct control over the components of the simulation.

Surely the ODE approach is equivalent to just calling

stepSimulation(dynamicsWorld->getSteppingInfo().m_fixedTimeStep);

so I'm not sure it provides anything at all now.

[stenyak]

a) Why is maxSubSteps ever needed, shouldn't it be automatically calculated?

Because then when you accidentally passes milliseconds instead of seconds, or your laptop goes to sleep in the middle of simulation, the whole app doesn't lock up for 5 minutes

If i've understood it correctly, that's obviously a bug, and allowing or even encouraging the developer to dampen it so that the simulation still somehow "works" with wrong data is not a good practice, IMHO.
Otherwise, wouldn't programming languages surely have a maxLoops variable for all for/while/do loops, just in case the developer uses milliunits instead of units in the loop counter by mistake?
Maybe i haven't correctly understood its purpose.

stepSimulation();

Ew, no. stepSimulation needs to take *something* as a value, else you get framerate-dependance.

It takes the defined timeStep as value, as explained. It always steps the simulation by one timestep.
Whether that has to do with your graphics engine framerate or not, is up to the developer. Also, using a constant timestep is encouraged, since you don't need to provide the timestep length at the same time; you have to call setTimeStep separately.
I admit the parameter-less "stepSimulation" i proposed may be a little confusing, let's assume i named it "singleStepSimulation" or something.

Ps: i can't keep up with the amount of recent replies, i'll try to find time to read it all later, so sorry if my reply is already discussed or doesn't make sense

[sparkprime]

If i've understood it correctly, that's obviously a bug, and allowing or even encouraging the developer to dampen it so that the simulation still somehow "works" with wrong data is not a good practice, IMHO.

It's more complicated than that. Depending on the number of sleeping objects, and the number of pairs generated by the broadphase, individual simulation substeps can take lots of cycles or hardly any cycles at all.

It's quite easy to get yourself into a situation where steps take a long time, e.g. if a complex compound shape tunnels into another compound shape, and proceeds to get "jammed", generating a lot of collision pairs.

In this situation, it's possible that the simulation is clocked at 60hz but each simulation substep is taking double that time to actually complete. The result is that each graphics frame, twice as many simulation substeps are performed, and therefore the time delta keeps doubling. This is a positive feedback loop and eventually the FPS will drop to 0.

The max substeps parameter prevents this from happening.

I admit the parameter-less "stepSimulation" i proposed may be a little confusing, let's assume i named it "singleStepSimulation" or something.

That's pretty much the consensus that was reached, except that I'm still discussing what other stuff this call should do

[stenyak]

If i've understood it correctly, that's obviously a bug, and allowing or even encouraging the developer to dampen it so that the simulation still somehow "works" with wrong data is not a good practice, IMHO.

It's more complicated than that. Depending on the number of sleeping objects, and the number of pairs generated by the broadphase, individual simulation substeps can take lots of cycles or hardly any cycles at all.

It's quite easy to get yourself into a situation where steps take a long time, e.g. if a complex compound shape tunnels into another compound shape, and proceeds to get "jammed", generating a lot of collision pairs.

In this situation, it's possible that the simulation is clocked at 60hz but each simulation substep is taking double that time to actually complete. The result is that each graphics frame, twice as many simulation substeps are performed, and therefore the time delta keeps doubling. This is a positive feedback loop and eventually the FPS will drop to 0.

The max substeps parameter prevents this from happening.

Uhm, i still fail to understand how maxSubSteps solves any problem. The newbie developer already knows how much time he wants to simulate, and what the timeStep is (1/60 by default).
Therefore, he knows *in advance* how many steps will be taken to compute the simulation he asked for (and how that number compares to a possible "maxSubSteps" parameter). Is that correct?

What use is maxSubSteps then, if the developer already knows how many steps will be computed? Also, what problem does capping the number of steps solve?

You mentioned two problems:
1) That "too many" steps may have to be computed in order to simulate the desired delta.
2) That steps can take a "too long" time to compute.
Both can lead to locking the physics thread (or the whole program, if it's not multithreaded) until the physics are computed.

The 1) problem can (and IMO should) be addressed by the developer, as explained above. A helper function can be provided by Bullet, but is in no way necessary for the working of Bullet.
The 2) problem can also be solved by Bullet (by returning from stepSimulation if certain time (specified by the user) has elapsed and not all steps, or even not a single step, have been able to be computed), but again IMO it's better addressed by the developer (by profiling the different subsystems of his program, guesstimating the time it'll take to compute things, and acting consequently, for example reducing physics quality, or decreasing graphics detail, or visually warning the user but still allowing sub-realtime gameplay, or stopping the simulation, or sending the multiplayer server an "out of sync due to lack of computing power" message, or whatever).

In my opinion, the 2) problem is the worst of all, and is what would really help the most to the newbie end user.

[abaraba]

If the computer is too slow to perform the simulation substeps in real-time, this has nothing to do with failing 'Frame Rate Independence', but the simulation is too intensive for your computer

ok, thats wonderful, i thank you
...allow me to take something out of that i havent come across so far and it may be a KEYWORD to understand and separate terminology and confusion, let me call them like this:

1.)
"FALLING-framerate" Independence
(thats what i want, eg change your stepping to stepSimulation(dt, 0), load heavily your scene and watch fps drops while *Bullet physics still runs in real-time*)
2.)
just "frame-rate Independence" as in - "one does not influence another"
(overload your scene and *everything* will slow down, unless...)

thats great,
so, my new understanding is now this:
a.)
Bullet features 2nd kind of "frame-rate Independence", which gives you FREEDOM to sync your timer and animation with Bullet's internal 60fps as you see fit
b.)
it can do 1st - "FALLING-framerate" Independence by using stepSimulation(dt, 0), but it is not deterministic

and now, best of all,
this would resolve and explain everything for me
c.)
stepSimulation(dt, 10or100or1000or5000..) should be doing something 'visually similar' to what stepSimulation(dt, 0) in practice does or not?


it helped and is appreciated..