Regarding interpolation and extrapolation, you're right, if the physics frame rate is high then you won't notice much difference. One time when you will particularly notice a difference is if you arrange for your camera to move at a fixed velocity in Update(), and move a rigidbody at a fixed velocity via the physics. In this scenario, especially with a high render frame rate, you're likely to see some artefacts which would go away if you enabled interpolation.
My understanding is as follows:
The physics moves in discrete steps, e.g. at t=0.0s, t=0.5s, t=1.0s, t=1.5s. Suppose Unity is rendering a frame at time t=1.2s. It needs to decide what object positions to use.
The first option is to just use the positions calculated for t=1.0s - I believe this is the "None" option. However high the render frame rate is, the object will only visually move when the physics ticks.
The next option is extrapolation. Bear in mind that Unity hasn't calculated the t=1.5s position yet, because right now t=1.2s. But it can see the object's state at t=1.0s, including its linear and angular velocities, and extrapolate by assuming the object will continue with those velocities. So the time sinse t=1.0s is 0.2s, and it adds 0.2 times these velocities on to the linear and angular positions, and renders that location.
The last option is interpolation. Instead of guessing where the object might go, instead I believe Unity delays everything by one physics timestep. So at time t=1.0s, it would actually render the objects at their positions from t=0.5s. But it still calculates the physics for t=1.0s, it just doesn't render those positions yet. Later, at t=1.2s, it can now interpolate 0.2/0.5 of the way between the object positions at t=0.5s and t=1.0s.
Interpolation generally gives the best result, but at the expense of adding latency to the view. Extrapolation kind of works but runs the risk of objects being rendered at odd positions, e.g. penetrating each other, as it can extrapolate through a collision that it hasn't detected yet.
Again, as you said, it's often unnecessary to turn on interpolation at all, unless you've turned your physics timestep up really high. Generally the things on which you'll notice problems the most are physics objects which are moving vaguely in sync with non-physics objects that are moved in Update() rather than FixedUpdate(). The most important case is a camera tracking the player character, which is why Unity's recommendation is to turn interpolation on for the player character, but not for anything else.
↧