Gaming monitors now run at 120 and 144 Hz, so you'd want to make sure your simulation is at least at that rate.

Sending inputs at 60 Hz where snapshots is 10 Hz will save you (1/10 - 1/60 == 83.3) milliseconds of reaction latency, as long as the physics is "close enough."

You may also want to detect "important" physical events, like collisions or object pick-ups, and send them immediately. You can then define "collision" as any movable object/object contact with a force greater than X.

Another thing you can do if you don't want to re-simulate, is to keep track of pos/ori/velocity/spin at the past time frames, and when you get the correction, calculate the delta in P/O/V/S, and add those deltas to the current state, rather than re-simulate from the past. It won't be as precise, but it may be good enough, especially if combined with 60 Hz input forwarding and special-event sends.

19 hours ago, hplus0603 said:

Gaming monitors now run at 120 and 144 Hz, so you'd want to make sure your simulation is at least at that rate.

We use a fixed timestep game loop so that the sim doesn't care what the refresh rate is. We could sim at 10Hz and the rendering would still look smooth

In that example situation though, yeah the vehicles would have 0 to 100ms extra input latency (avg 50ms), but we still poll inputs once per visual frame, so some inputs such as a "buy item"  command could produce HUD changes and audio responses on the next visual frame (at 144Hz) even though the sim might not tick for another 100ms.

The main choice for the simulation tick rate is physics accuracy vs performance. Simulating at 500Hz to 1000Hz gives great vehicle physics accuracy, but means we don't have enough CPU time to predict the future. Simulating at 30Hz gives awful physics accuracy. Somewhere in 60Hz to 300Hz seems to be our sweet spot at the moment... And lower is better given the need to be able to do client side repredictions 

We also use higher rates currently for just the tire friction model - it's running at 600Hz for stability, even though the rest of the physics is at 60Hz!

19 hours ago, hplus0603 said:

Another thing you can do if you don't want to re-simulate, is to keep track of pos/ori/velocity/spin at the past time frames, and when you get the correction, calculate the delta in P/O/V/S, and add those deltas to the current state, rather than re-simulate from the past. It won't be as precise, but it may be good enough

This might be my fall back for high ping players who don't have the CPU power to repreidct a half RTT worth of future constantly. I gave it a quick go, but the error deltas would occasionally move the car into a position that intersects an obstacle, causing physics mayhem on the client! I may have to try again but with gentle kinematic velocity nudges towards the predicted position instead of moving it there instantly via teleportation... 

Quote

We use a fixed timestep game loop so that the sim doesn't care what the refresh rate is. We could sim at 10Hz and the rendering would still look smooth



Do you interpolate between simulation steps, or extrapolate from the last simulation step, when rendering?

One frequent observation is that the problem of "simulation runs de-coupled from rendering" ends up looking somewhat like the problem of "server runs de-coupled from client." Both of them need to come up with a "reasonable" thing to display to the user for any random time T, and both of them have the option of displaying correct-but-old data, or displaying guessed-but-current data.

On 5/9/2018 at 3:29 AM, hplus0603 said:

Do you interpolate between simulation steps, or extrapolate from the last simulation step, when rendering?

We interpolate, which puts the rendering thread 0-1 sim-frames behind the simulation thread, or 0 to 17ms (avg 8ms) at 60Hz. This isn't at all a problem, except for the extra frame of input latency on physics interactions.