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

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.

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

FWIW, I've seen commercial racing games run critical parts of their sim at 1000Hz steps and other parts at 100Hz steps.

1/48th is usually the highest anyone would go

If your visual framerate is 60Hz and you don't want to have any input lag, then you'd also have to simulate at 60Hz.

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

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.

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

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.

Your answer was "those rates are unacceptable".

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?

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]