# "Good way" to update physics ?

## Recommended Posts

Juksosah    130
Hello, is there a "good way" to update physics in the game loop ? I've heard about framerate dependent/independent methods, and honestly i'm a little lost. For example :

//Main

DWORD time1, time2;
float deltaTime;
time1 = g_timer->getTickCount();

while(message.message != WM_QUIT )
{
time2 = g_timer->getTickCount();

gameLoop((float)(time2 - time1) / 1000);

time1 = time2;
}


In gameLoop I call updatePhysics(elapsedTime) every time. Of course elapsedTime = (float)(time2 - time1) / 1000 In updatePhysics a rotation look like that :


tt->setPitch(tt->getPitch() - 25.0f * elapsedTime);

For every physic calculation I'll use elapsedTime. Is it the good way to go ? Thanks, I must know before writing too much code in a wrong way.

##### Share on other sites
Digitalfragment    1504
Why is this in "Graphics Programming and Theory"?

Look under in "Game Programming" (http://www.gamedev.net/community/forums/forum.asp?forum_id=11)

You will find this question is asked quite often.

##### Share on other sites
Here's my opinion.

Basically, if you want to avoid problems, you want physics to be updated at a roughly constant rate - say every 30ms. If you physics runs too fast (elapsedTime too small), you might run into numerical problems; some numbers being too small to be added or to be use as denominators. On the other hand, if physics runs too slow, then you will have consistency issues, such has objects going through walls, or imprecise collisions.

There are more elegant designs, but as a simple solution:

If elapsed time is too small, keep adding it up and continue with your game loop (rendering, networking, etc). Update physics when the accumulated time stamp is big enough. If its too large, you want to run the physics several times in that single loop. Think of physics as a space-time window with a determined timestamp, and let the rendering framerate vary instead.

By the way, 99.9% of your code, if well written, should be completely independant from this. Whatever you choose, its best not to start spreading "elapsed time" everywhere :)

##### Share on other sites
Quote:
 Original post by SteadtlerBasically, if you want to avoid problems, you want physics to be updated at a roughly constant rate - say every 30ms. If you physics runs too fast (elapsedTime too small), you might run into numerical problems; some numbers being too small to be added or to be use as denominators. On the other hand, if physics runs too slow, then you will have consistency issues, such has objects going through walls, or imprecise collisions.

Not necessarily true (about long elapsedTime) if your collision detection algorithms are testing a ray from the starting position to the ending position.

##### Share on other sites
Julian90    736
Quote:
 Not necessarily true (about long elapsedTime) if your collision detection algorithms are testing a ray from the starting position to the ending position.

Actually it is true, he said "numerical problems" from which I assume he means numerical stability etc. When using numerical integration based on the time, for example, simulated clothing which generally involves numerical integration you can get highly unstable results, even with a relativly small time step.

##### Share on other sites
Gagyi    192
I use two things:

1. Fixed timestep:
//Init:
time=gettickcount;

//Insert rendering stuff here
//Physics Loop:
while(time<gettickcout)
{ DoOnePhysicsStep;
time+=30};
//More stuff here

This does a physics step every 30 ms, and is very accurate. With the method you suggested, the game would run differently on different computers. (like jumping higher or lower, running faster, etc.)

2. Verlet integration:
tmp=position;
position=2*position-oldposition+acceleration/2;
oldposition=tmp;

This is more accurate than eulers integration( pos+=v; v+=a), combined with collision, much stabler (no exploding cloth).

P.S: This really should be in Maths and Physics.