# Whats a reasonable timestep

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

## Recommended Posts

I just changed my fixed timestep from 1/60th to 1/120th of a second and noticed a general increase in the responsiveness of my simulation. My timing is set up just like this article: http://gafferongames.com/game-physics/fix-your-timestep/. Does anyone know if this is likely to carry over on different computers. Logically I would assume that it is more likely that it will take longer than 1/120th of second to compute 1/120th of simulation time than it would be to compute 1/60th in under 1/60th of a second. Then why am I observing a more responsive simulation virtually free of stutter? What do most people use as their timestep?

btw im using bullet as my physics API.

##### Share on other sites
Both of those time-steps are unnecessary in most common cases. 1/60th is usually the highest anyone would go, and 1/30th is the most common. Not every machine can maintain a 60-FPS framerate (much less 120) and in such cases they will simply stutter down to a halt and die, never being able to catch the simulation up to the actual game time.

Define “stutter” and “responsiveness”.
I thought at first you were talking just about input but then you mentioned Bullet, so now I am wondering if you are crossing terms etc.

But let’s assume you are not, and “responsiveness” means “smooth low-delay response to input” and “stutter” means “jerky visuals”.

Smooth input responsiveness can happen at any reasonable time-step interval. If you get less-smooth motions it means there is a problem with how you poll input. Fix that instead of covering it up with a faster update.

Stutter has many explanations, none of which are related to how fast or slow the time-step is. I get perfectly smooth motions on all objects with time-steps as low as 1/5th.
If objects are jerky you will need to explain the nature of the jerkiness. There could be a million causes:
#1: All objects seem jerky all the time when in motion?
-> You aren’t interpolating the objects between updates.
#2: Following an object with the camera is jerky?
-> You are updating your camera’s look-at target only on logical updates, or on every frame but using the wrong target position (you have to look at the interpolated position, which is also updated every frame).

These are the most common, and each indicates its own problem unrelated to fixed time-step intervals. Even at 1/5th you should be seeing everything running smoothly, so changing it to 1/60th or 1/120th is just hiding the problem.

L. Spiro Edited by L. Spiro

##### Share on other sites

Both of those time-steps are unacceptable. 1/48th is usually the highest anyone would go, and 1/30th is the most common.

nonsense.

My stuff was running at 333Hz back in 2001, from 333Hz to 1000Hz now.

Run whatever physics time step you need in order to satisfy the stiffness of your physics subsystem and the requested collision fidelity. Edited by kunos

##### Share on other sites

nonsense.

My stuff was running at 333Hz back in 2001, from 333Hz to 1000Hz now.

And your “stuff” is more than a very basic 3D game or medium-sized 2D game with no physics?
These update rates are absolutely completely unacceptable. See below for why.

Run whatever physics time step you need in order to satisfy the stiffness of your physics subsystem and the requested collision fidelity.

Again, hiding the problem does not fix the problem.

The major question this brings to mind is why you seem to think you need to update logic 1,000 times per second when everyone else is fine with 30 or so.
Starsiege: Tribes is fluid and solid at 32 updates per second.
Monday Night Combat runs at either 30 or 33.3 (I forgot the specifics). So does Unreal Tournament 2003 and Gears of War.
Games using my old engine update at 33.3 times per second. Simulation Golf, Gigander X, Bakugan, etc.
All the games made by my company update at 30 times per second (60 in rare cases). Star Ocean 3, Star Ocean 4, Final Fantasy XIII-2, Final Fantasy XIII, War Corps, Valkyrie Profile, Resonance of Fate, etc.

Half of the games I listed use Bullet for physics, so there is absolutely no excuse for the original poster to be cranking his or her logical updates that high. It’s proved thoroughly that Bullet can run just fine and solid on 30 updates per second.

Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 meters-per-second (or easily 1,000,000 meters-per-second if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.
If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.
With the proper fix in place, not only can you stick with the lower and less CPU-consuming update rate, but you have actually truly solved the problem.

Please do not suggest that such an update rate has no drawbacks just because the things you have done with it weren’t enough to expose those drawbacks. You aren’t making “real” games such as Battlefield 3.
If you want to expose those drawbacks even on your small projects, set the update rate to 3,000,000 times per second. Proof that there is such a thing as an update rate that is too high.

Again and again I have to repeat: Increasing your update rate to avoid artifacts is nothing but hiding the problem. There is no problem that can’t be solved by any other means, and a higher update rate than what is absolutely needed is always a bad thing.
Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.

L. Spiro Edited by L. Spiro

##### Share on other sites

Virtually every game on the market stays within the 30-48 range, and they all have no problem. If you have a problem with that range, you are doing it wrong, and you have some other part of your engine to fix.

maybe virtually every FPS or any game with slow moving actors.

Physics integration rate, again, is a function of system stiffness (ie. if you have spring/damper systems like the one needed for race cars, you need to solve them at high rate to avoid explosions) but this is only part of the problem.. you need to take into consideration the speed the game objects move: if you have a race car cornering at 150kmh and you are integrating at 30Hz as you suggest, you'll have your tyres traveling 1.38 meters between each iteration! Missing every bump and information available in those 1.38 meters by simply "flying" over. That's simply unacceptable for a huge number of game styles... such as racing and flying sims.

Since the OP doesn't give any details about his game, and he calls it "simulation".. your claim that 48Hz should be enough for everybody is simply not true... maybe it's enough for the kind of games that you are used to work on.. but that's where your claim starts and end.

EDIT: One more note about input responsiveness. Again, for game such as driving simulators, running at >100Hz is essential for control and feel of the car... driving controller input at 30Hz or at 100Hz is like NIGHT and DAY from the driver feeling point of view.

EDIT 2: You refer to my software as "small game", so it doesn't count. Would Forza Motorsport be considered a "big game" by Mr. Spiro? Well,guess what? It clocks at 360Hz for the physics. Link:

http://www.virtualr.net/tech-stuff-physic-engine-rates
Edited by kunos

##### Share on other sites
I think there's a racing game out there (Gran Turismo perhaps? I forgot) that runs its physics at 120Hz (on console too) because of the high speeds involved and accuracy requirements.

##### Share on other sites

maybe virtually every FPS or any game with slow moving actors.

Since the OP doesn't give any details about his game, and he calls it "simulation".. your claim that 48Hz should be enough for everybody is simply not true... maybe it's enough for the kind of games that you are used to work on.. but that's where your claim starts and end.

*cough* I think you missed something *cough*

Here is the thing. Starsiege: Tribes is the fastest-paced game listed. It is easy to get speeds up to 2,000 meters-per-second (or easily 1,000,000 meters-per-second if you are the admin typing commands into the console), yet my tiny guy no matter how fast never passes through solids.
If my guy went too fast and passed through solids, perhaps your solution would be to increase the logical updates so that he can’t move enough between updates to pass through the object, but you really haven’t solved the problem. The problem is in the physics engine, and the solution is continuous or swept collision detection.

*cough*
Slow-moving actors? Actors in Starsiege: Tribes commonly move faster than any actors in any other game of which I can think off the top of my head, including any racing games, including F-Zero and similar. It’s easy to go 700 kilometers-per-hour in Starsiege: Tribes, nearly double the speed of the average F-Zero racers.

Again, simulation was running 32 times per second.

your claim that 48Hz should be enough for everybody is simply not true

No, just truer than saying that upping the update resolution without actually identifying the problem is the correct solution.
The math is something like this:
In being super generous, we can estimate that 5% of games, often exclusively simulation-based such as racers or flight simulations, require going over 60, and they have a good well understood reason for doing so (note again that only a small number of this class of games actually does—Mario Kart 7 is still either 30 or 60 at all times, never higher).
So if your argument is that we don’t know what his needs are, why would you suggest he go the path least likely to be suitable for him statistically speaking?
Even if my estimates are wrong (and being estimates, they surely are, but probably not too much), it is in any case far more likely that his problem lies elsewhere.
It’s your advice that actually applies to rare special-case instances, and if you are going to give him said advice you should make sure it is actually relevant to his situation. Make sure that actually is the correct solution before you spout off about how bad others’ advice is.

L. Spiro

##### Share on other sites
huh? He is asking if it is normal to see a more responsive game running at twice the physical rate and the answer can only be YES.

You have been already pointed at 2 MAJOR AAA titles (arguably, the 2 killer application in the respective console business) that contradict your "it's unacceptable" claim.. there isn't much to add to the debate neh?

##### Share on other sites

You have been already pointed at 2 MAJOR AAA titles (arguably, the 2 killer application in the respective console business) that contradict your "it's unacceptable" claim.. there isn't much to add to the debate neh?

Not until you point out why you would tell someone to just increase his update rate without actually knowing what the underlying cause is.
I also pointed out many major titles in which an update rate of only 32 times per second provided non-stuttering and stable physics, and many games with nice smooth responsive input at similar rates.

The difference is, I am trying to demonstrate that he shouldn’t be having stutter or non-responsive inputs at lower update frequencies and trying to impress upon him that he should investigate the real cause to this, whereas you are simply trying to win an argument over the Internet.

If you were more concerned with actually trying to help than with trying to win some debate, you would see that there is no way to deny that an overwhelming number of games run responsively and jitter-free at update rates near 30, and that this is an obvious sign that there must be something else wrong with his pipeline.

I’d rather be helpful to the original topic poster than to win some argument online. People keep posting about examples of games that use update rates I said were unacceptable, but they are missing the point.
The point was that increasing the update rate prematurely is likely to do nothing more than hide an underlying problem, since so many games can run fine at ~30 ticks per second, no jitter, smooth response to input. Since this much is obvious, and he never said anything about racing games.
Which do you think is more likely? He is advanced enough to be making a high-end racing game but doesn’t know common update rates, or that he is an average guy learning game programming with an average-case project and has an average problem with his update rates?

Seriously, enough posts about racing games. I am not here to argue semantics; I am here to help this guy.

L. Spiro

[EDIT]
Wow, 3 negative votes; that’s what I get for trying to help instead of trying to win an argument.
I modified my first post to satisfy pedantic readers.
[/EDIT] Edited by L. Spiro

##### Share on other sites

Logically I would assume that it is more likely that it will take longer than 1/120th of second to compute 1/120th of simulation time than it would be to compute 1/60th in under 1/60th of a second. Then why am I observing a more responsive simulation virtually free of stutter? What do most people use as their timestep?

It's not really clear from your description what kind of stutter there was before. How many frames per second are you rendering? If your physics update rate is less than your rendering rate there will be some stutter unless you employ interpolation to hide the discrete physics updates. Which will introduce some latency itself.

As for what most people use as their timestep: It really depends. If you have a really simple simulation with slow moving, big objects you can get away with a much bigger timestep than you would use for complex simulations involving stiff springs, like in a car suspension for example.

##### Share on other sites
you can solve this by not running at a fixed timestep
i run everything using floating point timesteps
then it HOPEFULLY doesnt matter what your "update speed", or any speed is
all that matters is the precision level you choose to use, and the precision of the timer
you'll still have to cap the difference between previous and next to avoid jumps in physics when the system stalls for whatever reason
but you can't get smoother than floating point...
 if (_localtime - _lasttime(0) > timing_max_difference) _lasttime(0) = _localtime - timing_max_difference time_d_factor = 1.0 + (_localtime - (_lasttime(0) + movement_scale)) / movement_scale _lasttime(0) = _localtime 
now you can just multiply everything (including floating point counters) with time_d_factor
movement_scale isn't a good name for a variable.. it's just a measure of how big you want your multiplier to be (so that it makes sense in your physics department)
for example if its 0.01 you'll measure things in 10ms and so on

so, i'm just posting it here in hopes someone will discount or confirm my idea..
this has worked well for me for a month or two now, and it's been very smooth
Edited by Kaptein

##### Share on other sites
Just to emphasize what Hodgman said, variable time-steps are discouraged at all costs due to instability and inconsistency issues.
Generally every physics simulation can roughly handle variable time steps, but in the world of computers there is literally no way to prove neither network consistency nor replay consistency with variable timesteps.
The only way to ensure this is with certain limitations imposed on both the update time and the floating-point model currently active, and in regards to the update timings a fixed number must be assigned.

L. Spiro

##### Share on other sites

[quote name='Kaptein' timestamp='1353674224' post='5003467']you can solve this by not running at a fixed timestep
Variable-length time-steps are an option -- pretty much all of the commercial games that I've worked on have actually used variable-length time-steps -- however, they do have some downsides.

* The delta-time value that you're using for this frame is actually the amount of time that it took to process the previous frame. You're using this as a guess for how long this frame will take, but this guess is wrong in the case where the frame-rate changes.
If your frame-rate isn't constant, then when it jumps up and down, your animation will become jittery. This is because your estimation was wrong, so you presented an image to the screen where the virtual distance moved doesn't actually match up with the physical time passed. You can alleviate this somewhat by smoothing your delta-time measurements.

* Numerical integration techniques (such as [font=courier new,courier,monospace]pos += velocity * delta[/font]) gives different results depending on your time-step. This means that, for example, you may be able to jump a particular obstacle at 60FPS, but not at 30FPS, or vice versa! You can actually see this in some COD games, where you can jump to supposedly inaccessible places if you boost your frame-rate to 500FPS...
You can alleviate this by using better integration techniques, such as RK4 instead of Euler's method. However, if you're doing accurate physics, you pretty much have to choose a fixed time-step in order to get reliable results...

IIRC Bullet supports variable time-steps, but sternly warns against using them. However, it's possible to have some parts of your game run at a variable time-step, and other parts (such as your physics) run at some fixed time-step.
[/quote]

wow nice writeup! thanks.. i had no idea other people used this
everything i found on the internet was fixed timestep, and yes i had a huge nagging feeling that i was measuring the previous frame
but i couldn't find any reading material on it

##### Share on other sites
Also what may be important is that you give impression responsiveness. For example, if your FPS character is controlled by mouse, it is quite important that the mouse events are processed as soon as the arrive to change the characters orientation to get the feeling of responsiveness. Even if your simulation is running at 30 fps for example, you can update your player directions as often as you draw a frame.

Just my 2 cents, best regards!

##### Share on other sites
I think I really need to clarify how my timestep works for example at 60 fps the physics engine will simulate 1/120th of a second twice per frame. The time required to render the last frame is divided up into intervals of 1/120th of a second and it processes 1/120th of a second that many times. So at 30fps it will do 4 updates per frame. What I'm really looking for is a better model for updating my physics. As for a definition of responsiveness it is how quickly the simulation reacts to input from the user. Stutter is when the framerate remains constant but motion appears to stop or slow down for fractions of a second I assume this is caused by the physics engine taking longer than the timestep to compute the update. Edited by ic0de

##### Share on other sites
It may be worth having a look into Bullet's documentation:

By default, Bullet physics simulation runs at an internal fixed framerate of 60 Hertz [...] application might have a different or even variable framerate. To decouple the application framerate from the simulation framerate, an automatic interpolation method is built into stepSimulation[/quote]

So it appears that the Bullet guys do not deem 60 Hz inacceptable at all. The Wiki seems to assume that something 5 to 10 times slower and interpolating is mighty fine for most people to use, though.

##### Share on other sites

if your FPS character is controlled by mouse, it is quite important that the mouse events are processed as soon as the arrive to change the characters orientation to get the feeling of responsiveness. Even if your simulation is running at 30 fps for example, you can update your player directions as often as you draw a frame.

I disagree. Handling input can’t be done asynchronously this way. In order to maintain logical flow, there is a very specific time and place where input is handled, and it is always within the logical loop.

Since it is inside the logical loop, people such as kunos are correct in pointing out that increasing the resolution of your logical update is one way to get increased “response” from your input handler, but it is the wrong way.
Of course increasing your logical resolution will invariably help to smoothen your input flow, but excessively sensitive input flow is only necessary in the most extreme cases, such as racing games or fighting games. Since 95% of all games are not this sensitive to input, stutter 95% of the time indicates that there is some kind of underlying problem with the input handler.

I didn’t want to go into this measure of detail until the topic-poster needed it, but the basic idea (again I am leaving out details until proved necessary) is that the logical process will happen every “certain amount of logical time” which has no correlation to real time, except that it can not go faster than real-time.
Because of that constraint, the amount of input that can be processed in a single logical update is also supposed to be limited.
For example, you see your game lagging and you start waving your mouse around. The mouse commands sent to the engine are as recent as real-time—that is there are enough mouse commands to handle from the start of the logical update (whatever time-stamp that is) until the actual real-world time-stamp.
It doesn’t make sense though to actually eat that whole buffer if the logical update is only a fraction of the way from its starting point to the real-world time.
Each input needs to have a timestamp, and each logical update should only consume as many inputs as were created during the span of that input.
In other words, it must be as follows:
-> Last frame ended at t=90, but the real-world time now is t=2,000.
The update interval is 30, so I need to perform 63 updates.
My first update goes from t=90 to t=120, but the input queue has inputs from t=90 to t=2,000.
If I eat them all in one update, I am obviously doing it wrong.
-> -> Request and process only inputs from t=90 to t=120. This is correct.
Within this same cycle I will be processed 62 more times, and I can eat inputs incrementally until then, at which point I will have gotten them all.

The resulting output is virtually the same no matter what your update speed is. Notice that I said “virtually” here. Every update speed will yield a new result, but humans can’t notice the difference in those results except in extreme situations such as racing simulations and in fighting games.
On the other hand, computers can notice these differences, so any networking games must absolutely ensure the same strict simulation on all platforms, which is again why it is bad to pick an update resolution that is any larger than it must be, and also one that is variable.

The update resolution should always be the absolute minimum necessary for proper functioning of the game (aside from my own suggestion, there is a citation on this, but I am annoyed to report that I can’t find it right now).
This was the basis behind my original controversial sentence that such-and-such update timings are not acceptable. You should always think critically as to whether or not you actually need X resolution, and generally you should have both smooth input and stutter-free graphics at almost any update resolution, so if you experience stutter or friends at any resolution you should probably be looking at other parts of your engine. Of course there are cases where the only solution really is to increase your update resolution, but these are fairly special-case and advanced, and anyone whose solution really is this should already know the concept of update interval very well, so this is not the case here.

L. Spiro Edited by L. Spiro

##### Share on other sites
This is why I have been frustrated with this topic. People arguing just to win a retarded debate about semantics (gosh, does L. Spiro mean “unacceptable” literally?) have made it hard to find the important posts, and as a result I overlooked the original poster’s reply in my last reply.

I think I really need to clarify how my timestep works for example at 60 fps the physics engine will simulate 1/120th of a second twice per frame. The time required to render the last frame is divided up into intervals of 1/120th of a second and it processes 1/120th of a second that many times. So at 30fps it will do 4 updates per frame. What I'm really looking for is a better model for updating my physics. As for a definition of responsiveness it is how quickly the simulation reacts to input from the user. Stutter is when the framerate remains constant but motion appears to stop or slow down for fractions of a second I assume this is caused by the physics engine taking longer than the timestep to compute the update.

Firstly, I want to pose the question: Why do you think you need to update logic 120 times per second? Once again countless games can offer a responsive and jitter-free experience without having to update this often. Including Starsiege: Tribes, the fastest game mentioned by anyone so far, which only updates 32 times per second.
Do you have a specific reason for this update resolution?
If your reason is just that “It makes things run more smoothly” then your problem lies elsewhere.
You should be experiencing fine control and physics at a mere 30 updates per second, and you should be using this as a base-line anyway because, since numerous other games are fine at this speed, yours should be too unless you are doing something wrong.

What you said about stutter is basically related to my #1 in my first post. The objects are jerky because you are not interpolating them between frames.
If you don’t interpolate the objects, your framerate won’t matter as much because you will be displaying the same objects in the same positions as last frame about 30% of the time or so.
I covered this topic here: http://lspiroengine.com/?p=378
Hit Ctrl-F and type “But How Can”
You will find a drawing that explains this concept, and the entire logic behind interpolation is within the same post as well.

Firstly, try to address this issue, because once again a higher update rate is usually just going to hide underlying problems.
Start with an update rate at 30 and try to solve this issue. As mentioned before, most games are able to get perfectly fine performance out of 30-ish update rates as long as the rest of their pipeline is solid, so getting yourself a nice smooth input rate and lack of jitter at 30 updates per second is a nice way to check that you are doing everything else fine.

Only increase your update rate once everything else checks out and it is only the option left. It does serve a use, but don’t do it prematurely or else all you are doing is hiding bugs.

L. Spiro Edited by L. Spiro

##### Share on other sites
I figured I may as well post my code so people know exactly whats going on. I modified it to do some interpolation but I'm still getting some stutter.

physics code:

 float dt = 1.0f/60.0f; float prevtime, accumulator, frameTime; int substeps; void integrate(int pausedtime) { gameTimeInMS = SDL_GetTicks() - pausedtime; //find out how much time has been spent "in game" and not paused frameTime = (gameTimeInMS - prevtime)/1000.0f;//compute the amount of time required for the last frame also convert from ms to seconds accumulator += frameTime; //this is the amount of time that needs to be simulated while ( accumulator >= dt ) //compute the amount of substeps { substeps += 1; accumulator -= dt; } prevtime = gameTimeInMS; //store this time for the next update } void physstep(int pausedtime = 0) { integrate(pausedtime); //find out how much time needs to be simulated dynamicsWorld->stepSimulation(dt, substeps); //do the physics computation for(int i = 0; i < substeps; i++) { //update the player player->update(); rocket.update(); for(int i = 0; i < numents; i++) //update all the movable entities in the game { ents->update(); collectGarbage(i); //recycle inactive ents } } substeps = 0; } 

main loop:

 if(paused) //if paused don't simulate physics { guiProcessInput(&SDLev); } else //we aren't paused so lets simulate physics { physstep(pausedtime); //pass the amount of time spent paused to the physics engine so it can be compensated for } render(); //draw the scene 

EDIT: fully commented now. Edited by ic0de

##### Share on other sites
A few comments would help. They don’t bite.
Trying to figure out what your code’s goal is will take me a lot of time I am afraid I don’t have. A comment by each if/else and for () would be helpful.
Not just for me but for you in 10 years.

L. Spiro

[EDIT]
[/EDIT] Edited by L. Spiro

##### Share on other sites
This is not specifically related to your current problem, but may be helpful overall.
You currently have a branch for when the physics simulation should update at X time or not.
It would instead be better to have the simulation update at X time, where X is either a full frame time or 0 if paused. This avoids a high-level branch. At this level, it is better to avoid such special-case conditions and instead just pass what is called a “virtual” time to the physics simulation.
I have mentioned it here: http://lspiroengine.com/?p=378
It is basically a timer that does not get updated with the real-world timer, and as long as its time-since-last-frame remains at 0, no objects using it will move. Hence pause is pause.

L. Spiro

##### Share on other sites
First thing I noticed is that you're only using a millisecond accurate timer. For high speed animations at high frame rates, the error from that quantization will be significant (4% of a frame at 60Hz).

Someone mentioned earlier that bullet has interpolation built in, so that if you tell it to advance 1 and a half frames worth of time (e.g. 16.666*1.5 if @ 60Hz stepping), then it will perform one sim frame and produce correct visual results that have been interpolated an exta half a frame.