Timestep

[John Brookes]

If you want variable timestep should it be something like
physicsWorld.step(_view.deltaTime*1000, 6, 0.012);

The only real probelm I get with that is the wheels of a vehicle judder with the chassis (fall behind and catch up).
 Only have one painfully slow pc to test with at the momment, so can't really answer. :(

[alebianco]

Didn't tried with the car simulation yet, but with a simpler simulation the dynamic timestepping works fine.
I'll share the code as soon as i lay my hands again on my laptop :)

[Yang Li]

bullet document mentioned the first parameter should always smaller than maxSubSteps*fixedTimeStep. so you passed parameter "_view.deltaTime*1000" should keep smaller than 6 * 0.012.

2011/8/6 alebianco <cyber...@gmail.com>

[John Brookes]

From the bullet docs the way I understand it is

The subStep (second parameter) is how 'real' the physics are. The lower the value the more real the physics.
So if I do
physicsWorld.step(_view.deltaTime*1000, 7, 0.012);

On a slow computer (say running 12fps) it would interpolate the physics and not look as smooth. But distance travelled, speed should be more or less the same as a fast (max 60fps flash player) computer.


In the car examples they use
physicsWorld.step(0.012, 1, 0.012);
which is a fixed timestep.
Basically the physics 'look' the same but run a lot slower on slower computers, so not good for any time challange type game


Have I got the above right?

[Alessandro Bianco]

Yes, the difference between dynamic and fixed stepping is about having
the simulation looks similar or run with comparable results, so for
any kind of challenge you need dynamic time stepping.

About the parameters, i use them in this way:
1° your frame time
2° how many sub steps are needed to achieve the frame time
3° internal step time

basically the engine will step always at its internal time (which
should remain fixed) but it will execute many steps to reach your
frame time.

also, the substep value is critical, too low and the simulation won't
reach the frame time, too much and you will waste time, getting worst
performances.

I did some tests with a simple simulation (a ball falling to the
ground) and i fine tuned my code to be like this:

const TIME_STEP:Number = 1/60;
var currentTime:Number = getTimer();

function step()
var newTime:Number = getTimer();
var frameTime:Number = (newTime-currentTime) / 1000;
var subSteps:int = 1+int(frameTime/TIME_STEP);
currentTime = newTime;
world.step(frameTime, subSteps, TIME_STEP);
}

so my simulation always run at 60fps, whichever the rendering frame
rate will be. tested across several systems and under different
situations (from 0 to 750 other objects falling) and the balls always
take the same time to fall :)

Bianco Alessandro

[John Brookes]

Right, think I get it all now.

Think I will stick to the fixed amount of max substeps. Sort of a halfway.

Just as an example crashing into a load of crates/pallets with your code the sub step can get too much
eg
6- 8 driving around
40 -70 crashing through boxs, fps crashes to 2fps and unplayable.

If I fix the substep at 6 and variable delta time crashing into pallets slows the simulation down, but its still just playable.

Thanks for the info :)