Unity Rigidbody Interpolation Hero

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.

Unity Rigidbody's Interpolate
The Interpolate property has 3 possible values.

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.


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?

An example of interpolation
Is it possible to estimate where the frisbee is at 1.7 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


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?

An example of extrapolation
Is it possible to predict where the frisbee will be at 2.4 seconds?

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 frame rate line
Each black line represents a frame.

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.

Unity frame rate vs. Physics frame rate
Physics may not always be calculated in the same frames as the rest of Unity.

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.

No interpolation in a Rigidbody
See why the positional data is outdated?

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?

Rigidbody interpolation comparison
Objects that are not interpolated may have more jittery movement.

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:

Rigidbody interpolation speed comparison
Interpolate seems to fall slightly slower.

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.

Interpolation explanation with timeline
Took me 10 minutes to make this, so I had to watermark it.

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

Rigidbody interpolation speed comparison 2
Extrapolate seems to move slightly faster than None.

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

Extrapolation explanation with timeline
A picture speaks a thousand words.

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:

Extrapolation predictive error
That was a good pun, wasn’t it?

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:

There are 7 comments:

  1. This blog has some really great insights into game development and Unity. Thank you for this very well-explained post!

  2. This has tremendously helped me understand physics in Unity, it sparked that “ah-ha!” moment that I was missing – THANK YOU

    1. Hi Michael, glad we were able to help. If you like what we do, we would really appreciate if you gave us a sub on our Youtube channel, or support us on Patreon (links in our navigation panel). This helps to give us some return on what we do, so we can continue to churn out more articles like that.

Leave a Reply

Your email address will not be published. Required fields are marked *

Note: You can use Markdown to format your comments.

For security, use of Google's reCAPTCHA service is required which is subject to the Google Privacy Policy and Terms of Use.

I agree to these terms.

This site uses Akismet to reduce spam. Learn how your comment data is processed.