Async Physics incorrectly interpolates when multiple physics ticks pass

If a user set the transform of a Body from the game thread and physics is running multiple async ticks perf game tick, the transforms might be being calculated incorrectly.

We have encountered an issue when a primitive transitions from kinematic to simulated movement.

The FRigidBodyHandle_External accessed through GetGameThreadAPI() exposes several functions for kinematic changes to the physics state, such as SetX(), SetR(), etc. Besides overwriting the current physics state of the primitive, these functions also update FSingleParticleProxyTimestamp, which is an internal bookkeeping value used to compute the visual location of the primitive (and other things).

Under normal circumstances, the visual location is a blend between two previous simulated locations recorded by the physics solver. However, the most distant is replaced by the FSingleParticleProxyTimestamp if available at the current frame.

Now, if the game runs with asynchronous physics, and each frame has many physics steps per visual frame, the FSingleParticleProxyTimestamp is used as the most distant location even though many simulated locations are available.

Imagine setting x0 = 10 at the end of the visual frame.

Now let's say the simulation updates 4 steps for this visual frame, so x1 = 15, x2 = 20, x3 = 25, x4 = 30.

When the simulation is finished, we determine (as an example) that the visual location is between x2 and x3 with an alpha of 0.7. However, if an FSingleParticleProxyTimestamp is available, the natural result x = lerp(x2, x3, 0.7) is replaced by x = lerp(x0, x3, 0.7). So the FSingleParticleProxyTimestamp in x0 is used instead of the simulated result in x2.

This seems to be a mistake ? The 0.7 alpha could never be valid for both the [x0,x3] and [x2,x3] intervals ? And there is not reason to discard x2 in the first place.

I have attached an engine change that addresses the issue by disabling FSingleParticleProxyTimestamps if sufficient simulation steps are available. SingleParticlePhysicsProxy.cpp line 306.

Looking forward to hearing your opinion on this.