The Right Way to Handle Physics?

[arrival]

Hi. Im having a dilemma about integrating physics with Irrlicht.
The firt thing that comes in mind is:

Code: Select all

float fixedStep = 1.0/60.0;
while(irrdev->run())
{
    physicsWorld->advance(fixedStep);
 
    scnMgr->drawAll();
    guiEnv->drawAll();
}

Fixed step set to about 1/60 is recomended in Box2d manual.
But if game is all about physics the gamplay is much different at 120fps and 40fps because of the fixed physics step and abviously not fixed rendering rate ( fps ).

If rendering takes more time, physics should be advanced with bigger step to avoid physics slowdowns?
Lets do that:

Code: Select all

float TimeStamp = timer->getTime();
float variableStep = timer->getTime() - TimeStamp;
while(irrdev->run())
{
    variableStep = timer->getTime() - TimeStamp;
    float32 TimeStamp = timer->getTime();
    
    physicsWorld->advance(variableStep);
 
    scnMgr->drawAll();
    guiEnv->drawAll();
}

Now if rendering takes more time, physics is being calculate with bigger time step. No physics slowdowns right?
But ie. Box2d manual says that physics step should be 1/60 of a second, and variable timestep leads to variable, unpredictible results and debugging problems. Its abvious that in discrete calculations with big time step objects may tunnel thru walls or miss other objects critical to gameplay.

Wait, there is a solution... Just advance physics few times with a smaller step instead of one large step right?
Ok, here it is:

Code: Select all

float fixedStep = 1.0/60.0;
float TimeStamp = timer->getTime();
float variableStep = timer->getTime() - TimeStamp;
while(irrdev->run())
{
    variableStep = timer->getTime() - TimeStamp;
    float32 TimeStamp = timer->getTime();
    
    float step = 0;
    while(step<variableStep) {
        physicsWorld->advance(fixedStep);
        step += fixedStep;
    }
 
    scnMgr->drawAll();
    guiEnv->drawAll();
}

Thats cool. If somehow framerate drops momentary from 60 to 30 fps, physics will be advanced twice to compensate not rendered frames and behave consistently as it would with 60fps. No slowdowns and no missed collisions.
But wait.. something is wrong here. If physics will be calculated twice, it will take twice as much time as in previous frame which increases this iterations time and in next frame physics will have to be calculate 3 times or more. Eventualy with each and every frame application will slow down till it will become unresponsive. (I've been there it happens)

The question (finaly) is:
What is the best way to calculate physics in game to make it stable, consistent and realistic (no slowdowns) in low and high framerates?

[codetiger]

Probably this question belongs to physics engine forums. For better understanding about internal steps, check bullet physics wiki on how to config physics.

[randomMesh]

I use this and it works perfectly.

[arrival]

Thanks randomMesh, setting maximum number of physics step in one frame is one way to avoid 'spiral of death' for sure. But its not easy to find the right threshold value right?
Another way would be moving physics calculations to a second thread, to make rendering loop iteration times independent of physics iteration times.
I'll try going this path.

[Granyte]

i find this idea quite odd i'm using an adaptative time step in my aplication and the skipping of collision only happens in catastrophic failure situation like when the framerate drop below 10 and when it does it's because i did something wrong

[arrival]

Granyte: Discrete integration gives aproximated result, and aproximation error depends on the time step you use. Your simulation may end up differentialy despite the same initial state if you use variable time step. Imagine flying your spaceship thru solar system while fighting many gravity fields. You ends up hitting one of the planets. Your game gives you replay of your spectacular death, but in the replay you're not crushing eny planet (simulation goes differentially this time). Thats wierd isn't it? If you use physics for flying boxes and ragdolls - sure, variable time step is fine.

BTW: I managed to move physics to second thread. But treating physics as part of gameplay I see no reason to decouple physics simulation rate from rendering rate as long as the game logic and IO are still being done in a single render loop. If rendering (logic, IO responses) slows down I think physics should also slow down. So far I'm getting few FPS more by calculating new physics state while rendering previous state but only for huge amount of physics objects. If scene is small synchronisation between threads become to expensive and I see no performance gain. I'll get back to this after some literature studies.

[Granyte]

ya but in the replay recording you should record the timestep

anyway threading is the way to go i run physic in one thread and rendering in an other i then use a parallel loop to synch them

also in my current project i'm using a speed cap to prevent that type of thing there is a speed cap that get lower as you get closer and closer to a planet because anyway no one could fly between mountain at relativistic speed