Unity Rigidbody’s Interpolate property

If you looked at the properties available for configuration on a Unity Rigidbody and poured through the documentation for it, you’ll likely find that most of its properties are pretty easily to understand, with the exception of Interpolate and Collision Detection. We’ve explored what the Collision Detection properties do in another article on this blog, and we’re going to explore the Interpolate property in this article.

Interpolate is probably the hardest property in a Rigidbody to understand, because it requires one to understand certain intricacies in Unity’s native physics engine, as well as the mathematical concepts of interpolation and extrapolation.

Interpolation

Let’s start with the mathematical concepts first, because they are actually pretty easy to grasp. If I threw a frisbee to the right, and updated you with its position every second, would you be able to find where the frisbee is at given a time in between the seconds?

The silhouettes of the man and the frisbee are edited from an open domain image resource found here.

If we interpolated between the known positions in 1 second and 2 seconds, we can get a good estimate:

Distance travelled from 1s to 1.7s
= (5m – 2.5m) × (1.7 – 1)
= 2.5m × 0.7 = 1.75m

Total distance travelled at 1.7 seconds
= 2.5m + 1.75m = 4.25m

Extrapolation

Now, what if the positional data of the frisbee stops coming in after 2 seconds? Can we predict where the frisbee will be with the data we have?

If we extrapolated the data we have between 1 second and 2 seconds, we can get a good prediction:

Speed of frisbee between 1 to 2 seconds
= (5m – 2.5m) ÷ (2s – 1s) = 2.5 m s^-1

Distance travelled between 2 to 2.4 seconds
= 2.5 m s^-1 × 0.4s = 1m

Position of frisbee at 2.4 seconds
= 5m + 1m = 6m

---

Article continues after the advertisement:

---

Why interpolate (and extrapolate)?

Generally, as far as possible, Unity tries to run at a frame rate of 60. This frame rate is dependent on many things, however, and it is not consistent — if there are insufficient resources on the computer, the frame rate may drop as needed to compensate. Thus, if we graph out the frame rate on a line, the gaps between individual frames will be inconsistent.

Unity’s physics engine, however, runs on a fixed frame rate to make the physics simulation more stable. By default, this fixed frame rate is set to 50 (i.e. 0.02 seconds per frame), but you can set it under Edit > Project Settings > Time in the Editor.

The key thing to notice here is that, since the frame rate of the physics engine is not the same as the main Unity engine, the frames of both modules may not always align.

This can be problematic, because Unity Rigidbodies refer to the physics engine to determine where it should be positioned. If there is no physics frame coinciding on the same frame, then the Rigidbody will have to refer to the closest physics frame for positional data. This means its position will be slightly outdated whenever such a thing happens.

Is it noticeable?

Since we are talking about time steps in the order of 0.02 to 0.06 seconds, does it really matter if the position is slightly off?

To be fair, the jitter is not always this noticeable — it depends also on the device you are running on, and your project’s physics settings.

---

Article continues after the advertisement:

---

Interpolate vs. extrapolate

The best way to illustrate the differences between both interpolation modes is to see how they behave:

It is pretty clear that interpolate seems to be slightly slower than the other movement modes. This is because interpolation delays the object’s position by 1 physics frame, so that it can have 2 points to interpolate against.

If we reorganise the crates, we’ll also see something else:

It shouldn’t be too difficult to figure out this one:

Also, notice that because extrapolate uses predictive movement, it may sometimes get ahead of itself (pun entirely intended). Take a look at the animated GIF below:

Which is better?

This is the million dollar question, isn’t it? Unfortunately, there isn’t a clearcut answer here (if there was a clear better option, then the other option wouldn’t need to exist).

Generally speaking, you should only need to interpolate (or extrapolate) objects that are closely-followed by the game camera, because those are the objects where jitter will be most obvious. An example of such an object would be your player character(s). Remember that using interpolation or extrapolation means more work for the engine, so you will want to avoid using them whenever you can!

As for the choice between interpolation and extrapolation, you’ll need to decide which your game can tolerate better: collision inaccuracy, or a 1-frame time lag?

---

Article continues after the advertisement:

---