Sign in to follow this  
Juksosah

"Good way" to update physics ?

Recommended Posts

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 :

//rotate tt 25 radians

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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by Steadtler
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.


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

Share this post


Link to post
Share on other sites
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this