Time Stepping

[Winegums]

Hi, I've been looking at the bullet physics engine, and trying to use it as a basis for understanding physics engines on the whole. I recently attempted to write one, but it was unsuccessful (due, in part, i think to the fact that the time stepping was in the render loop >.< ).

to this end, I have come here to ask about time stepping. it seems like the smart way of doing things, but i don't know how to impliment it...

in the basic demo, from what i can see the app

gets time since last check
checks to see if thats grater than the frame rate
if it is, set the time to the current frame rate
uses this value to update objects (?)


however, from this i have a question.. what happens if your application lags? if the graphics loop takes too long and by the time you hit physics a lot of time has passed?

i think if i understand time steps then understanding everything else will be simplified. as it stands i'm hard pushed to create a simple 'balls bouncing in a box' scenario.

[Dirk Gregorius]

Maybe this helps:

http://www.mindcontrol.org/~hplus/graph ... _loop.html

[Erwin Coumans]

Bullet deals with time-stepping in several ways, up to the arguments passed in stepSimulation:

Code: Select all

btDynamicsWorld::stepSimulation(float dt, int maxNumSubSteps, float internalTimeStep)

If maxNumSubSteps > 0, then Bullet will accumulate the deltatime and perform a fixed simulation step (size 'internalTimeStep). For simulation times in-between the fixed time step, interpolation will be used. If Bullet reaches the maximum number of iterations (computer too slow, simulation too complicated to perform in real-time), you can detect that case, because Bullet will return the number of subSteps. See 'CcdPhysicsDemo' how to analyse the stepping more in detail.

If maxNumSubSteps == 0, then a variable timestep will be used. This is almost always not recommended, and not supported (== all problems due to using a variable timestep are yours).

Hope this helps,
Erwin

[Winegums]

so how do you decide how often to do physics updates each frame? I know that you need to be rendering at least 30 fps for animation to appear realistic, but how often should you be calculating physics per frame so that objects behave properly and don't appear to 'jump' or move through world geometry?

[Winegums]

oh also, something i noticed in btquickprof.h

#define mymin(a,b) (a > b ? a : b)


doesn't this return the largest value?

[Erwin Coumans]

You don't need to decide yourself, time substepping and interpolation is handled automatically by Bullet internally.

The default internal timestep is set to 60 hertz, which seems to be a good general choice.

[jackskelyton]

We're having a problem just like the one Winegums foresaw. Our physics world seems to work just fine, but if the application lags for whatever reason (rendering a lot of geometry, new program opening, whatever) the character tends to tunnels through the world mesh. The arguments we pass into stepSimulation are:

Code: Select all

mPhysicsSystem.GetPhysicsWorld()->stepSimulation(mTicksSinceLastFrame * 0.001f, 100);

Is this a problem with Bullet, or do we need to give it different arguments?

[Erwin Coumans]

We're having a problem just like the one Winegums foresaw. Our physics world seems to work just fine, but if the application lags for whatever reason (rendering a lot of geometry, new program opening, whatever) the character tends to tunnels through the world mesh. The arguments we pass into stepSimulation are:

Code: Select all

mPhysicsSystem.GetPhysicsWorld()->stepSimulation(mTicksSinceLastFrame * 0.001f, 100);

Is this a problem with Bullet, or do we need to give it different arguments?

Does the velocity of the character grow larger when the application lags? Can you clamp the velocity so it doesn't exceed a maximum value?

Thanks,
Erwin