timesteps

[leo]

Hi there!

I have some questions concerning the use of time steps in bullet.
As I could read in the forum and manual, bullet is working with 60 frames per second (fixedTimeStep). But there is the possibility to set time steps in the class btDiscreteDynamicsWorld with the function stepSimulation(...).

1) What is it used for?
2) Is there the possibility of calculate the physics with shorter time interval to get smother movements? Or are 60 frames enough because graphics only uses (at least) 24 frames a second?
3) If the time steps are fixed and the calculation takes longer than that step time what happens?
<edit>
4) What happens if the calculation finishes faster than 1/60 of a second - does the simulation just wait until the time step finished?
</edit>
Hope to get some answers soon.

Cheers Leo

[ejtttje]

But there is the possibility to set time steps in the class btDiscreteDynamicsWorld with the function stepSimulation(...).

1) What is it used for?

Internal step size, so you call periodically based on your graphics framerate (which might be variable) and have the simulation do a number of internal steps where each step uses a higher temporal resolution for better accuracy (and enforces a fixed simulation increment, which helps simulation stability)

2) Is there the possibility of calculate the physics with shorter time interval to get smother movements? Or are 60 frames enough because graphics only uses (at least) 24 frames a second?

Yes, simply decrease the simulation time. I'm currently using 10 ms steps (100Hz) since I currently have a relatively simple environment.

3) If the time steps are fixed and the calculation takes longer than that step time what happens?

Your simulation will run in slow-motion.

4) What happens if the calculation finishes faster than 1/60 of a second - does the simulation just wait until the time step finished?

No, it will return so your thread can go back to doing graphics or AI or whatever. So if everything else is running faster than the time step too, e.g. nothing else is sleeping to maintain the realtime synchronization, then your simulation will "fast-forward" (run faster than realtime).

[leo]

Hi ejtttje,

Thanks for your answers!
One more question: when my simulation runs slow motion (Q3) or faster (Q4), what exactly is the idea of fixed time steps?

Cheers Leo

[ejtttje]

For objects to settle/balance properly, the simulation needs to move them for the same amount of time in each update cycle ("step"). Otherwise, if you had a variable timestep, if an object is oscillating slightly, it might move further on one side of the oscillation with a larger timestep, and then not move back again with a subsequent series of smaller timesteps. This produces a unpredictable asymmetries, and possibly resonate vibrations. Similarly, some actions are performed per-step such as constraint resolution, and if it different amount of time passes for each of these steps, then can cause analogous problems.

So none of this has anything to do with "wall clock" time, the time needed to perform the calculations. The physics simulation doesn't care about the real time at all, beyond profiling code for efficiency. But it does care about realistic and repeatable simulation. It's up to you whether you want to run faster or slower than realtime depending on how you set the temporal resolution (timestep) and whether you sleep between steps. (e.g. you could run in slow motion just by sleeping "too much" between steps, you don't *have* to burn CPU in simulation with a super high temporal resolution.)