How to use Fixed Update in Unity

Even if you’re new to scripting in Unity, you’re probably already familiar with the Update function.

Update is an event function in Unity that’s called every frame. It’s one of the first functions you’re likely to use and, typically, it’s where most of your game’s logic will go.

However…

As you start to work with other parts of Unity you may also notice another type of update function, called Fixed Update.

Compared to Update, which is called every frame, Fixed Update is called independently of framerate, at measured intervals, in sync with the game’s physics system.

As a result, Fixed Update is usually used for physics-based functions, such as applying force to a Rigidbody.

While choosing when to use Update or Fixed Update can be simple, it can sometimes be difficult to understand exactly what’s going on behind the scenes.

Which can make it tricky to know for sure if you’re using Fixed Update in the right way.

But don’t worry,

In this article, you’ll learn exactly how Fixed Update works, the right time to use it instead of Update, and when to avoid it entirely.

Here’s what you’ll find on this page:

• The difference between Update and Fixed Update in Unity
• How Fixed Update works
• When to use Fixed Update in Unity

Let’s get started.

What’s the difference between Update and Fixed Update in Unity?

Update is a special function in Unity that’s called on every script, during every frame.

Meaning that Update is called at a variable rate, depending on how fast the game is running.

Fixed Update on the other hand, is called at measured intervals, meaning that fixed update is always called at a consistent rate, which, by default, is 50 frames per second.

Typically, most of the logic in your game will happen in Update, either directly inside the Update loop or triggered by an event that is, itself, powered by Update.

While Fixed Update, which is called in sync with Unity’s physics system, is usually reserved for physics-based functions only.

So, as a general rule, it’s best to place logical code in Update and physics-based functions in Fixed Update.

However… unfortunately, it’s not always that simple.

For example, to move an object in Fixed Update, you’ll probably need to make input checks that, in order to work correctly, will need to be in Update.

Likewise, there will often be times when you’ll want to access the physics system, which includes Raycasts and Colliders, from an Update based function.

Which is why just putting physics in Fixed Update and everything else in Update, isn’t always as simple as it sounds.

For that reason, it can help to understand what’s actually happening behind the scenes when Fixed Update is called.

So, how does Fixed Update work?

How Fixed Update Works

Fixed Update runs on a fixed timestep that will almost always be different to Update’s variable rate.

Which means that Fixed Update might be called once during a frame, twice, or not at all, depending on the speed of the game.

For example, by default, Fixed Update is called once every 0.02 seconds, which is a rate of 50 frames per second.

Which means that, when the game is running at 60 frames per second, Fixed Update is called once per frame for most frames but not all.

When the framerate of the game is higher than the physics rate, there will be some frames where Update is called, but Fixed Update isn’t.

However, if the framerate of the game is lower than the physics rate, Fixed Update could be called more than once in a single frame.

Simple, right?

There’s just one problem…

While this chart is representative of how Unity is calculating the rate of Fixed Update calls compared to Update, it can be misleading.

Based on this chart, you might think that Fixed Update could be called early in a frame, or late, depending on the relative frequencies of the two event functions.

However, that’s not how Fixed Update works.

So when, exactly, is Fixed Update called during a frame?

When is Fixed Update called?

Unity’s event functions are triggered in a specific order.

For example, Awake is called before On Enable, On Enable is called before Start and, in the Update Loop, Fixed Update is always called before Update.

• Start vs Awake in Unity

This is because, while the frequency of Update and Fixed Update are different, they’re not asynchronous, Fixed Update is always called first, before Update.

So how does Unity know when to call Fixed Update and when to not?

Here’s how it works…

1. At the beginning of the frame, Unity calculates Delta Time, which is the amount of time between the current frame and the one before it, and adds that amount to the total Time value, bringing it up to date.
2. Next, Unity will check to see if the total Fixed Time is behind Time by at least the length of a physics step (0.02 seconds by default).
3. If it is behind, a physics step is processed, Fixed Update is called and the Fixed Delta Time, the length of a physics step, is added to the Fixed Time total.
4. At that point, if Fixed Time is still behind Time, another physics step will be processed, and so on, looping around until Time and Fixed Time are within a physics step of each other.
5. After which, the Fixed Update phase ends and Unity moves on to Update, Late Update and, finally, rendering to finish the frame.

What this means is that, if multiple Fixed Updates are required to take place during a frame, they will all be processed, one by one before Update.

Exactly how many times Fixed Update is called in a frame depends on the amount of time since the last frame and the Fixed Update Rate.

How does the Fixed Update Rate in Unity work?

The rate at which Fixed Update is called is based on the duration of the Fixed Timestep, which is the amount of time between each Fixed Update call.

By default, the Fixed Timestep value is 0.02 seconds, which is equivalent to a rate of 50 frames per second.

However, it’s possible to change the Fixed Timestep value in the Time panel of the Project Settings menu.

Or in code, by setting the Fixed Delta Time value of the Time class.

Like this:

// Sets the fixed delta time to 50fps.
Time.fixedDeltaTime = 1 / 50;

The Fixed Timestep value determines how frequently the physics engine and, with it, Fixed Update calls, are processed.

This means that objects under physics simulation will often move at a different rate to the framerate of the game.

For example, an object that’s being moved under physics will appear to move at the same rate as Fixed Update.

Which, at the default 50fps, may look choppy or jittery compared to the same movement in Update, particularly if the game is actually running much faster.

This happens because the movement calculations that place a physics object in each new position will only take place in each physics step so, even if the actual framerate of the game is significantly faster, the position of the physics object won’t change until the next Fixed Update call.

No matter how fast the game runs.

Which can be especially frustrating for physics-powered first-person character controllers, or when physics controlled players are followed by Update controlled cameras, where the effect of a lower framerate will be obviously noticeable.

So what’s the answer?

How can you move physics objects smoothly?

How to fix choppy movement in Fixed Update

Jittery, choppy movement is caused by the Fixed Timestep value of the physics engine, and occurs when the framerate of the game is higher than the physics rate.

Generally, there are two options for creating smooth physics-based movement in Unity.

The first option is to enable Interpolation on the object’s Rigidbody.

Interpolation is a feature of the Rigidbody component that will blend the visual display of physics steps together.

While the accuracy of the physics system will be the same, it will appear to move much more smoothly, at the same framerate as the rest of the game.

It’s generally recommended to enable Interpolation on objects where the, usually, slower rate of the physics engine is felt the most, such as the player object or a camera controller.

However, interpolation doesn’t change how often the physics system is updated.

It only smooths the appearance of selected objects and their movement between frames.

Meaning that, if you want every physics object in the game to move more smoothly, without interpolating their Rigidbody components, you’ll need to increase the Fixed Timestep value instead.

Which will cause the physics engine to update more often, providing a smoother, more accurate, physics simulation.

But, how does changing the speed of the physics engine affect the performance of the game?

What happens when you change the Fixed Update Rate?

When you change the Fixed Timestep value, you change how often physics in Unity are calculated.

Increasing the timestep value reduces the frequency of Fixed Update calls, improving performance by, effectively, lowering the physics framerate.

While reducing the amount of time between Fixed Update calls will improve the accuracy and the framerate of the physics simulation, at the expense of an increased CPU load.

In many cases,  unless you have a reason for changing the physics rate, it’s probably best to stick with the default value.

However, if you do change the Fixed Timestep value, what will that actually mean for your project?

Here’s what’s likely to happen in each scenario…

Slowing down physics (increased Fixed Timestep)

Increasing the Fixed Timestep will cause Fixed Update to be called less often, meaning that, more often than not, Fixed Update won’t be called in a frame.

Generally, this should improve the performance of the physics engine, but at the expense of accuracy.

Meaning that physics objects will move at lower frame rates and with less precision.

This is because Fixed Update is being called less often and the physics engine has fewer points of data to calculate where an object should be.

So much so that, at extreme values, such as 0.2 seconds, for example (equivalent to just 5 frames per second) physics objects are likely to miss collisions entirely, causing objects to pass through one another.

Speeding up physics (decreased Fixed Timestep)

Alternatively, it’s possible to increase the precision and frequency of physics in Unity by simply reducing the Fixed Timestep value, making it more likely that Fixed Update will be called in every frame, multiple times.

As a result, the physics system will be more precise and will update more often, reducing the chance that the game’s framerate will be noticeably higher than physics movements.

However…

Increasing the frequency of the physics system to make the game appear to run smoother can have the opposite effect if it places the physics engine under heavy load.

So, what actually happens when you put too much in Fixed Update?

What happens if you put too much in Fixed Update?

If the physics system is under heavy load, and the game can’t process each physics step in the Fixed Timestep window, the frame will take longer to process, impacting performance.

While the physics simulation will still be accurate, the game’s framerate will be lower as a result.

But that’s not all…

In extreme circumstances, consistently overloading the physics engine can cause performance degradation, where each frame takes longer to display than the last.

This is because the number of physics steps that are required in a frame are based on the duration of the last frame.

So, if the last frame took longer, because of a heavy physics load, Unity’s response will be to schedule even more physics steps in the next frame in order to meet the specified frequency of steps over the, now, increased Delta Time.

Meaning that, if the physics engine is still under the same load, each frame will take longer and longer than the last, until the game freezes entirely:

But don’t worry…

While it’s technically possible to drain performance in this way, in the vast majority of cases, this won’t happen.

Firstly, for this test, in order to create a sustained heavy load that Unity couldn’t keep up with, I had to increase the Fixed Timestep frequency to an abnormally high level, in this case, equivalent to 5000 frames per second.

Secondly, to allow Unity to even attempt to process all of the physics steps that were scheduled for each frame, I had to effectively disable the built-in failsafe, the Maximum Allowed Timestep value.

When to use Fixed Update in Unity

While, generally speaking, you should only use Fixed Update for physics-based functions, it’s usually not that simple.

There will, no doubt, be times when you will want to do something physics related in Update, and there will probably be times when you’d like to do something in Fixed Update that would normally belong in Update, such as input checks, for example.

So what is ok and what isn’t?

Is it ok to call physics functions from Update?

In Unity, even if you’re not using any Rigidbody objects, you will probably still find yourself working with the physics engine surprisingly often, such as checking a Raycast or a Collider for example.

But, because they’re physics functions, do those checks need to be carried out in Fixed Update? Or is it ok to run them in Update?

Generally speaking, it’s perfectly safe to carry out most physics-based checks in Update.

This is because all you’re really doing is checking if a Collider is in a certain position or if a Raycast returned a hit at the time the check was made.

Which, in Update, will always be after the most recent Fixed Update.

What’s more, if the check you want to make is linked to a system that also operates in Update, such as input, or other game logic, it’s a good idea to keep the check, and any resulting action, in sync with each other.

Alternatively, if the result of the physics-based check is to perform a physics action, such as using a Raycast to move a Rigidbody when it gets close to another object, then it’s better to use Fixed Update for both tasks.

Should you use Update or Fixed Update for movement?

If you’re moving an object using its Transform component then you should generally use Update to do that.

However, technically, the correct way to move a physics object is by using a Rigidbody component and moving it in Fixed Update.

This keeps the application of force on the Rigidbody in sync with the physics system that’s moving it, keeping the movement consistent and correct relative to other objects.

However, there are exceptions to this rule.

For one-shot physics instructions, or immediate velocity changes, such as the Impulse mode of the Add Force function, you won’t need to use Fixed Update.

Because the function, in that mode, isn’t dependent on the Fixed Timestep duration, it’s safe to call it from Update, since it will only be triggered once anyway and doesn’t rely on Fixed Delta Time to be accurate.

Should you use Update or Fixed Update for input?

When checking for input in Unity, you will usually always need to use Update to do it.

This is because Unity’s input checks, such as Get Key Down and Get Mouse Button Down return true on a per-frame basis.

Which means that, unless Fixed Update is called reliably, and only once for every frame of the game, which it rarely is, some input checks are likely to be missed or duplicated, depending on how many Fixed Update calls are being processed.

As a result, it’s rarely a good idea to try to place input checks in Fixed Update, as it almost always leads to unreliable behaviour and missed input.

However…

If you’re moving an object using physics, chances are that you’re using input to do it.

So how can you use input in Update to control a movement function that needs to take place in Fixed Update?

How to use Update and Fixed Update together

If you’re moving an object using its Rigidbody, then it’s best to do so in Fixed Update.

However, if you want to control that object’s movement, you’ll need to check for input, which can only be reliably detected in Update.

So what can you do?

One simple solution is to keep both functions separate and connect them with a variable.

For example, it’s possible to set up a movement vector using input checks that take place in Update.

Then, in Fixed Update, the movement vector can be passed into a function in Fixed Update to create physics-based movement.

Like this:

public class Movement : MonoBehaviour
{
    public Rigidbody rb;
    Vector3 movement;

    void Update()
    {
        movement = new Vector3(0, Input.GetAxis("Vertical"), 0);
    }

    void FixedUpdate()
    {
        rb.AddForce(movement);
    }
}

This allows you to keep critical input checks where they belong, in Update, while applying physics forces correctly in Fixed Update.