Here are some:
1. If you use a fixed physics timestep but a variable render frame time (or a render frame time that isn't a multiple of the physics timestep), but don't interpolate the physics results, then a smoothly moving physics object will not move smoothly across the screen, as sometimes it will experience N updates, and sometimes N+1 (for a fixed render frame time).
Then interpolate. This isn’t a downside. It is just one more thing you have to do.
2.1 that's an additional cost (which might be significant if you've got a lot of objects),
The cost is far less than performing physics every frame. This should not be on the list because it is not a downside compared to the alternative. Performing full physics on every object every frame is a significant cost even without having a lot of objects.
Performing physics only once every 3 or 4 frames with interpolation of a single matrix every frame always wins.
This is actually a pro for fixed steps because they allow you to avoid waste. Performing physics with very small time steps a waste of CPU resources for most simulations since the improvement is exponentially less existent as the time step goes down.
2.2 Also there's some "uncertainty" about where the object is - so when a user shoots an object, where is the impulse applied?
I don’t know what you mean.
Interpolating objects is purely for graphical smoothness. The physical simulation is always based off their actual locations, not the interpolated locations.
There shouldn’t be uncertainty if this is understood and followed. The bullet is spawned based off the gun’s physical location. It hits the target where the physics simulation says it hits during one of those fixed-time updates, based on the physical positions of the bullet and the target.
There shouldn’t be any confusion there.
The interpolated matrix is for nothing but graphics and camera locks—if a camera follows an object it needs to follow the interpolated positions to avoid jitter, but this is still ultimately a graphics issue.
2.3 Debugging might be fun if your debug points etc don't match up with the interpolated object positions
This isn’t an issue. Interpolated positions are for graphics. It’s a single matrix that you send to the GPU. It is easily ignored during debugging sessions, where we will be focusing on nothing but the actual current physical location of the objects in question.
2.4 If the ratio between the physics timestep and render timestep is such that sometimes you run 2 physics steps, and sometimes 1 (for example), and the physics simulation time is significant, then the frame rate can jitter from frame to frame (a lower, but rock steady, framerate is likely better than a high but variable framerate). If there's a spike in the render frame time (e.g. due to disk access), then a fixed physics timestep will result in a spike in the next frame time etc.
This one is true, but not a situation that is handled better using a variable time-step. A fixed step can usually stutter back up to speed while maintaining simulation stability and consistency. A variable step will result in objects resting on tables to suddenly jump up into the air, stacks of things suddenly exploding, objects falling through floors into negative infinity.
A stutter in the framerate is an inconvenience to the player. An inconsistent simulation is a game-breaker.
Either way, fixed or variable, this actually hints at a deeper underlying problem, and the game should be redesigned to avoid potential simulations it can’t handle.
3 If the game allows running in slow motion (bullet time) you need to handle at least two, possibly very different timesteps, and the transition between them, otherwise either (a) you always update at the normal timestep, and the effects of interpolation will become obvious, or (b) you always run at the reduced timestep, with a cost that's excessive when running at the normal rate.
This isn’t how fast/slow motion is handled, and both fixed and variable steps handle this equally.
If you want your game to run at 1.5 speed, the “time since last update” is simply multiplied by 1.5 and accumulated, moving the game ahead that much faster.
The fixed-step simulation simply believes that more time has passed and thus performs updates 1.5 times more often. It still passes the same number of microseconds to the logical update/physics simulation, it is just doing it more often.
Quite elegant, yet still stable.
This was originally my quick placeholder before moving to fixed physics timestep and interpolation (which I've done before), but actually I think it works great so don't intend to change!
Then prepare for the consequences. Fixed stepping is always better than variable stepping. The only place in which variable stepping is acceptable is in small hobby projects that won’t see a lot of use by a lot of people.
I know some big commerical games use fixed, and some variable physics timesteps.
I would like to see some citations.
Given the cons of variable stepping, it is unlikely any professional game released since the 90’s is using them.
Here are the primary cons for variable steps:
#1: Physics simulation explosions.
#2: Inconsistent physics simulations leading to:
* #2.1: Players over networks seeing different things.
* #2.2: Missed collisions, things passing through other things, etc. This certainly can happen with fixed steps, but at least there it happens every time and is easy to debug/fix. The same fix for variable steps doesn’t work as well since the steps can be extra long.
#3: The simulation is done every frame, which is wasteful and decreases the FPS significantly.
It basically means that every game using physics or multiplayer over networks is using a fixed step.
Every game using CryEngine *, Unreal Engine *, id Tech Engine *, or Unity 3D is using a fixed step. That covers about every game out there except console RPG’s, but I can personally vouch for Final Fantasy games, Star Ocean, End of Eternity, Valkyrie Profile, and basically everything made between tri-Ace and Square Enix.
That essentially covers every game there is.
The only pro variable steps have over fixed is that they are easy to implement.
L. Spiro
