Firstly, on the subject of teleportation: most interpolation systems will simply disable interpolation for an object on a frame where it's teleported.
You can see this for example in Unity, when using the interpolation options on the Rigidbody
and Rigidbody2D
components. If you move them solely with physics - forces, velocities, torques, MovePosition()
etc. - then their display position and orientation is interpolated between the two most recent physics steps.
But if you set their position or rotation via the Transform
component, the engine disables the interpolation for the object on this frame. Under the hood this could be done by setting a flag, or by overwriting both the current and previous physics step outputs with the teleported position/orientation. The position and orientation you see on the next display frame will be the fresh values from the Transform
, and rigid body simulation and interpolation will resume next frame.
So, in a well-designed system, you don't need to worry about teleporting objects showing momentary "ghosts" between their previous and new positions due to physics interpolation. You can simply turn it off when it's not valid.
I think the thornier concern here though is this: "If I interpolate with a previous simulation state, isn't my displayed state 'old' or 'lagged' behind the true game state?" - ie. are we introducing unwanted latency into our game by this method?
Let's start by bounding the maximum latency we can introduce this way.
The worst case is when our rendered frame falls just after the "previousState" timestamp, and alpha is very close to zero. At this point we're one full frame in the past, 20ms if we're stepping our game simulation 50 times per second. That's already at the low end compared to typical latencies in realtime online games, where similar techniques are used to transition smoothly between discrete updates from the server/host/peers. Response times of 80-100ms can still be perceived as instantaneous, so we're already in fairly safe territory.
But we can do better. :) When the current frame falls just before the "currentState" timestamp, alpha is very close to one and our latency is practically nothing! (If we're only counting latency due to the fixed timestep - input processing and display latencies still add on top of this)
In practice we'll vary between these extremes with no particular bias. So overall, at 50 ticks per second, we're displaying a state that's an average of 10 ms old. For most purposes, this is below the threshold for visual perception of synchronicity, and closing in on the threshold for synchronous audio perception too.
And we can still do better! Because not all game feedback is tied to the fixed timestep. When the player presses a button to fire their weapon, we can spawn the muzzle flash and play the shooting sound immediately in the same frame. Depending on when we are in our interpolated time span, the projectile (assuming it's a literal projectile and not a hitscan raycast) might be rendered closer or further from the barrel, but either way the player gets immediate feedback at the very earliest opportunity we could offer - even if our updates were in lockstep. Similarly, if the player presses jump, we can immediately start blending the character into their jump animation, even if it will take another physics step or two before the upward motion becomes apparent in their physics. UI changes too, like hit markers on a reticle, can react instantly according to the rendered frame time, keeping perceived latency as low as it can be at our rendering framerate.
This helps highlight an important distinction here: how does a player know when data is "old"? Yes, technically that box moving at 1 m/s is now at (0.01, 0, 0), since its most recent calculated state is 10 ms ahead of the frame we rendered with it at (0, 0, 0). But from the player's point of view, it's moved exactly 0.0166 m since the last rendered frame 16.66 ms ago, so it's exactly where they expect to see it. The only yardstick the player can use to judge what's "now" is how the game reacts to their own input, and as we've seen above a well-designed feedback system can begin to react immediately, without adding frames of latency. Beyond that it's second-order consequences of game systems reacting to the effects of player actions, or the consequences of players' reactions in turn, all of which gets swamped by the round trip time of perception to action, which is typically a factor of 10 slower than the latencies we're considering. So while the current state might be old in terms of the pure math of the underlying system, from a player experience standpoint it's often not appreciably different from realtime.
So, tl;dr: At a decent framerate & fixed timestep, the latency introduced by decoupling your game updates is minor and very manageable for most game types.
The idea of blending with "the next, not yet calculated, state" is a related technique called extrapolation. This has somewhat the opposite trade-offs: simple, linear motion is represented precisely, but things like collision reactions appear a full frame late (so you might observe two objects touch or even interpenetrate before any corresponding collision effects or sounds trigger). Complex motion can also appear jagged, as the naive prediction keeps overshooting & correcting next frame. Generally these artifacts are easier to perceive than the slight latency of a single frame of interpolation, so the main reason to go this route is for simplicity (since you can skip storing two steps' worth of transform data)