# Typical physics engine timestep

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

## 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 on other sites
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 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 on other sites

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 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 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 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 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 on other sites
Quote:
 Original post by HinchYeah 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 MrRowlAssuming 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 on other sites
Quote:
 Original post by wasssup1990I 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.

1. 1
Rutin
34
2. 2
3. 3
4. 4
5. 5

• 12
• 14
• 9
• 9
• 9
• ### Forum Statistics

• Total Topics
633333
• Total Posts
3011404
• ### Who's Online (See full list)

There are no registered users currently online

×