• Advertisement
Sign in to follow this  

Typical physics engine timestep

This topic is 3310 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi, this is my first post on this forum. I'm making a full blown physics engine for fun, and everything is moving along nicely so far. My question is: What is the typical physics timestep that professional game programmers use for their realtime games? If anyone knows this please post it here. Thanks!

Share this post


Link to post
Share on other sites
Advertisement
It really varies a lot depending on what sort of physics the game is doing, and how central it is to the gameplay. I know racing games like Forza or Gran Turismo tick their physics sims at a much higher frequency than the framerate, something like one or two hundred hertz. If your game is an FPS that just uses physics for a few crates knocking about and particle effects whenever there's an explosion then it'll probably be something like 30 hertz.

Another thing to bear in mind if you're writing the internals of a physics engine, is that some physics engines (like PhysX) actually perform multiple substeps each time you "tick" them, so the end user may be ticking the physics at 30 hertz but it could be doing multiple substeps and doing more like 100 hertz internally.

Share this post


Link to post
Share on other sites
I was in a lecture on simulation last week and the lecturer mentioned a tick-rate of 100hz with regards to physics but I guess this is with regard to full-blown physics. Hope that helps :)

Share this post


Link to post
Share on other sites
Wow! A speedy reply.

Hi Hinch,
30Hz and 100Hz? Geez, I'm hopeing I don't have to make my timesteps that big to run at real-time.

What I am doing:
Currently I have 6 physics objects that act 99% to real life physics with a 10us physics timestep and no problems at all. That's 100KHz. My physics engine is based on the idea that "Nothing is solid" and that is how everything will react. What I mean is EVERYTHING can be deformed/broken, including the ground but all objects have cirtain restraints to how far they can be broken and/or deformed. This takes very good advantage of memory allocation features C++ has to offer as new verticies and physical objects are created and destroyed in realtime. This is defintaly not something you would run on a single core. LOL!

PhysX hey? I'll definatly look into that one. Can you briefly explain how it works with "multiple substeps"?

Thanks!

EDIT:
Hi chapter78! Thanks for replying. Every bit helps.

Share this post


Link to post
Share on other sites
Sounds interesting. I used to be interested in deformable worlds but never had time to work on it. Can you show any screenshots/videos?

Share this post


Link to post
Share on other sites
Hi d000hg!

Screenshits wouldn't show much at this tage since I currently only have two 2D triangles to show LOL! I've currently only got the physics working in two dimensions but tomorrow I will extend it into the third dimension. I can make a video but not right now, it's 2:00AM down here.

This stage is going to take a long time to finish. Yes, this is only a small part of a much larger goal that I want to accomplish. The physics engine and graphics are only 10% of the solution. Can you guess what the other 90% is for?

Share this post


Link to post
Share on other sites
Yeah 10us sounds pretty tiny for a timestep to me! To make sure, you *are* talking about the amount of time each "Tick" of your simulation is err... simulating? Rather than the amount of time it takes to actually perform the calculations?

If you want more detail of how substeps work in PhysX specifically, you can download the SDK for free on Nvidias website, they've got pretty decent documentation for that particular area. Basically when the user ticks the physics engine they say "simulate 33ms of physics please", and depending on it's settings PhysX might split that into a few smaller chunks of time and do multiple ticks internally. Sometimes it's cheaper to do extra steps using a cheap integrator like Euler, than just one big step using a more stable, but more expensive integrator.

Share this post


Link to post
Share on other sites
Assuming real-world sized objects, you should be able to get the simulator stacking significant numbers of boxes (etc) without jitter etc, running at 60Hz with no substepping. If you've just got simple rigid body interactions (no spring-like systems) then even 30Hz is a reasonable target.

If you've got state-dependent forces (springs, aerodynamics) then you'll perhaps need a smaller timestep unless you use a more sophisticated (implicit etc) integrator. Also if you're handling very fast moving/rotating objects, because of the dynamics.

With larger timesteps continuous collision detection will become more important too to prevent objects passing through each other.

Share this post


Link to post
Share on other sites
Quote:
Original post by Hinch
Yeah 10us sounds pretty tiny for a timestep to me! To make sure, you *are* talking about the amount of time each "Tick" of your simulation is err... simulating? Rather than the amount of time it takes to actually perform the calculations?

If you want more detail of how substeps work in PhysX specifically, you can download the SDK for free on Nvidias website, they've got pretty decent documentation for that particular area. Basically when the user ticks the physics engine they say "simulate 33ms of physics please", and depending on it's settings PhysX might split that into a few smaller chunks of time and do multiple ticks internally. Sometimes it's cheaper to do extra steps using a cheap integrator like Euler, than just one big step using a more stable, but more expensive integrator.


Hi Hinch,
I am talking about the amount of time each "Tick" of my simulation is.
When you say "expensive" and "cheap" are you talking about the amount of work the CPU has to do?
FYI this is my physics prototype:

float update(double duration, double timestep); //Simulates physics for "duration" for a physics timestep of "timestep"
//Returns Real time taken





Quote:
Original post by MrRowl
Assuming real-world sized objects, you should be able to get the simulator stacking significant numbers of boxes (etc) without jitter etc, running at 60Hz with no substepping. If you've just got simple rigid body interactions (no spring-like systems) then even 30Hz is a reasonable target.

If you've got state-dependent forces (springs, aerodynamics) then you'll perhaps need a smaller timestep unless you use a more sophisticated (implicit etc) integrator. Also if you're handling very fast moving/rotating objects, because of the dynamics.

With larger timesteps continuous collision detection will become more important too to prevent objects passing through each other.


Hi MrRowl,
I am using deformable spring-like systems.
I've read that changing the physics time step while in run-time can make the physics explode. Is that true?

Thanks!

Share this post


Link to post
Share on other sites
Quote:
Original post by wasssup1990
I am using deformable spring-like systems.


Ahhh... in that case you may want to do a better integration scheme than Euler (which will indeed likely require very small timesteps).
Quote:

I've read that changing the physics time step while in run-time can make the physics explode. Is that true?


Yes - but it depends on the implementation. Often decreasing the timestep increases the accuracy of the solution, and as things stiffen up they correct errors left over from the larger timestep, and things "explode", or at least move. The degree to which this happens depends on how things are implemented.

Share this post


Link to post
Share on other sites
Hi MrRowl,

Quote:

Ahhh... in that case you may want to do a better integration scheme than Euler (which will indeed likely require very small timesteps).


The integration scheme I'm using was created/recreated by me but the name for it is probably Euler Integration. Maybe I just reinvented something. Hehe.

So is there really a better integration scheme?

Thanks

Share this post


Link to post
Share on other sites
There is also the Runge-Kutta algorithm for integration, and tends to be much more stable for anything below 50hz.

As for me personally, I tend to run my physics at 50 or 100Hz depending on my requirements. For complex vehicle stuff, rag dolls and lots of collidable objects, I stick with 100Hz. For something simple, like two bodies that tend not to collide with much, I stick with 50.

Share this post


Link to post
Share on other sites
Quote:
Original post by BinaryDad
There is also the Runge-Kutta algorithm for integration, and tends to be much more stable for anything below 50hz.

The fourth order Runge-Kutta method is the classical numerical integration technique. If you read about the algorithm, this may be what other posts have referred to when they talked about substeps. However, since this is a physics simulation you might find that Verlet integration (link 1, link 2) can come in handy on your transition to 3-D, as it is nearly as fast as Euler but much more stable and accurate.

Share this post


Link to post
Share on other sites
Quote:
Original post by wasssup1990
The integration scheme I'm using was created/recreated by me but the name for it is probably Euler Integration. Maybe I just reinvented something. Hehe.

So is there really a better integration scheme?


If you're really writing a general purpose physics engine that uses stiff springs to represent rigid bodies, you'll probably need some kind of implicit solver.

Better still is to use rigid bodies, and keep the springs for cases where they can be quite soft. Then you might be able to get away with your current integration scheme after all.

Share this post


Link to post
Share on other sites
If you don't care too much about integration accuracy but instead want a very stable integration scheme - that is, a scheme that allows for very stiff springs without blowing up - I recommend using the velocity verlet algorithm in stead of 4th order Runkge-Kutta. In stead of doing like this:

Do
...
Runge-Kutta integration at timestep 0.01
...
Loop

Do it like this:

Do
...
for x = 1 to 4
velocity verlet integration at timestep 0.01 / 4
next
...
Loop

Both methods "cost" the same in cpu usage, since Runge-Kutta has 4 substeps, but as mentioned, the latter method is less accurate and much more stable! Besides, velocity verlet is a symplectic integrator, meaning it doesn't loose or gain energy, as opposed to RK4 which looses energy slowly.

cheers,
Mike

Share this post


Link to post
Share on other sites
There is yet another way to do it that I have not seen mentioned. I don't remember what it is called, but basically you want to adjust the time step based on the object with the fastest frequency. I think you want to be twice as fast as your fastest frequency. I am not sure if that is right. So if you take the example of a spring, the stiffer the spring, the higher the frequency and therefore the smaller the time step you should use. This prevents your physics from exploding, but also saves a lot of CPU.

Share this post


Link to post
Share on other sites
Wow some very helpful replies there. Thanks to all of you!

Quote:
Original post by h4tt3n
velocity verlet is a symplectic integrator, meaning it doesn't loose or gain energy, as opposed to RK4 which looses energy slowly.


Hi Mike,
That is what I was worried about. My simple integrator loses energy over time. So it seems velocity verlet is the way to go.

Does anyone have a comparison of the advantages and disadvantages of all the intergration schemes used for physics simulation?

Thanks

Share this post


Link to post
Share on other sites
I've made a video of my physics simulator. Not much to show right now but at least the physics seems to react well.
http://www.mediafire.com/?e2dnm3jy3zi

EDIT
AH! This is so cool. I figured out how to make it go in slow motion.

[Edited by - wasssup1990 on January 27, 2009 11:54:26 PM]

Share this post


Link to post
Share on other sites
A very common trick of the trade is running the physics simulation a two different timesteps.

Running All the suspension internals , the brushmodel(s) , pajecka and all the mess at a higher NON-DIREC-MULTIPLE frequency , and then running havok or physx at the normal 30fps.

....

ie.

for (int i =0; i< 10 ; i++)
{
const hkReal DELTA_TIME = 0.0023434293f; //<< whichever value non multiple
Vehicle->Simulate( 0.00345525 ); //<< of the "worlds' framerate
Vehicle->Integrate( 0.00345525 ); //<<
}

and then

hkWorld->Step( 1.0f / 30.0f );


You can also increase the timestep( and hence reducing the number of iterations ) by using different timesteps each iteration , AND MAKING SURE THAT THE TOTAL IS STILL THE SAME ( 1.0f/30.0f) This -if not done propperly- is very dangerous and will end up in serious radgoll/suspension jitter or explosion.

oi oi
Jcarrion

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement