120

What is the difference between the Update and FixedUpdate methods, and when should these methods be used?

Tiskolin
  • 167
  • 17
Kapil11
  • 1,355
  • 2
  • 9
  • 6

7 Answers7

125

From the forum:

Update runs once per frame. FixedUpdate can run once, zero, or several times per frame, depending on how many physics frames per second are set in the time settings, and how fast/slow the framerate is.

Also refer to the answer given by duck in the same forum for a detailed explanation of the difference between the two.

It's for this reason that FixedUpdate should be used when applying forces, torques, or other physics-related functions - because you know it will be executed exactly in sync with the physics engine itself.

Whereas Update() can vary out of step with the physics engine, either faster or slower, depending on how much of a load the graphics are putting on the rendering engine at any given time, which - if used for physics - would give correspondingly variant physical effects!

Rahul Tripathi
  • 168,305
  • 31
  • 280
  • 331
  • 6
    The answer in the link you provide is by far the best answer I've read about the topic. – vcRobe Jul 23 '19 at 13:09
  • 3
    So, which one should I use if I want to move an object? – some1 here Dec 20 '20 at 09:05
  • @some1here Sorry for being late, but you should move an object via transform/CharacterController with Update and Rigidbody with FixedUpdate. – gbe May 24 '21 at 21:06
  • One thing to keep in mind: "Input" works on a frame basis too. Since keystrokes often are meant to trigger forces on the physics system, it is a common pitfall to use GetKeyDown/Up in FixedUpdate(). That will result in missing clicks because those functions return True only in one single Frame thus possibly skip the whole FixedUpdate() event. – AlexGeorg Sep 07 '21 at 14:05
82

FixedUpdate is used for being in-step with the physics engine, so anything that needs to be applied to a rigidbody should happen in FixedUpdate. Update, on the other hand, works independantly of the physics engine. This can be benificial if a user's framerate were to drop but you need a certain calculation to keep executing, like if you were updating a chat or voip client, you would want regular old update.

Unity has a nice video about Update vs. FixedUpdate here: Unity - Update vs. FixedUpdate

The site is a great resource for beginner game programmers.

Rickest Rick
  • 1,519
  • 1
  • 15
  • 28
6

Adding to the other answers, Update is in time with the frame rate, not the physics calculation rate. This means that usually when something changes visuals, you want to have it done in Update, not FixedUpdate. This ensures it's always in time for the very moment at which the frame is rendered. I've encountered a number of cases where I had movement that didn't look smooth because I had it calculated in FixedUpdate.

The only potential cost to having something done in Update that should be done in FixedUpdate is that your physics fidelity could drop, especially if you're hitting low frame rates (but in general that's a separate problem that should be fixed, so it's usually not a good reason to put something in FixedUpdate instead of Update).

If you're looking to control the order in which different scripts do their Updates, FixedUpdate is the wrong tree to bark up; you should be looking at something like EarlyUpdate instead.

Semimono
  • 664
  • 1
  • 6
  • 14
  • So, are you proposing to move things in games around while being out of sync with the physics engine? – some1 here Dec 20 '20 at 09:04
  • @some1here Yes. Usually physics fidelity will not drop noticeably, if it will drop at all. Another trick I've found is to change the physics tick-rate to match the framerate (e.g. 60 per second both). This won't help if the system is overloaded and falling behind the target tick/frame rate, but that's a different problem. This I found was especially valuable for things like camera movement. – Semimono Dec 22 '20 at 16:31
  • That is completely wrong. The whole purpose of the physics engine is for it to be used. You should not use Unity if you are going to fight against the default physics engine. All the movement which uses physics engine features should happen in FixedUpdate. – some1 here Jan 02 '21 at 18:08
  • 1
    @some1here Camera movement usually isn't integrated with the game's physics system. In addition, most game physics engines (including Unity's) are extremely low fidelity to begin with. I haven't ever been able to see a noticeable degradation in physics fidelity by moving something out of fixed update unless the framerate is already getting very low (something like 20 fps). In principle, I don't like it either, but in practice I haven't been able to find a problem with it. If you can build a test project to demonstrate an issue, that would be very useful. – Semimono Jan 03 '21 at 23:56
6

I noticed most of the answers here explained clearly what FixedUpdate was good for and and when to use it. However, I didn't see any clear examples for when regular Update should be used; Following is from the official Unity tutorial:

Update()

  • Called every frame
  • Used for regular updates such as :
    • Moving non-physics objects
    • Simple timers
    • Receiving input (aka keypress etc)
  • Update interval call times will vary, ie non-uniformly spaced

FixedUpdate()

  • Called every physics step
  • FixedUpdate() intervals are consistent, ie uniformly spaced
  • Used for regular updates such as adjusting physic (eg. RigidBody) objects
jfunk
  • 7,176
  • 4
  • 37
  • 38
  • 3
    fixed update is hard locked to a target rate based on the cpu clock(i guess) because of the variable time between two frames which easily can accumulate and destroy any simulation. update should be used for everything that does not depend on a simulation of physics, animation etc. because of performance. the fixed update also can only handle so much. it will start to slow down the game dramatically if the load is too high. – user11220832 Jun 12 '19 at 09:43
6

Update(): contains that code which has to be executed with visual rendering

FixedUpdate(): contains that code which has to be in sync with physics interaction

source : https://youtu.be/noXtT_zN-84?t=3057

Raman Kumar
  • 371
  • 3
  • 11
1

I found this answer by OncaLupe to be the best explanation:

For others that may not know the difference: Update runs at the same frequency as the game's framerate. If you're getting 100 FPS, then Update() runs 100 times per second. FixedUpdate() runs at a constant 50 FPS to match the physics engine.

There's nothing inherently wrong with only using FixedUpdate, and it is where physics calculations and changes should go since it matches the physics engine. However if you're doing things like manually moving non physics objects around and your game runs at a higher framerate, you may notice the movement stutters since there's frames where nothing moves. Using Update makes sure the movement happens every visual frame.

Also, if you need to use inputs that only trigger when a button is pressed down and not when being held (jumps, single fire weapons, etc), you will likely miss them in FixedUpdate. Things like GetButtonDown/GetButtonUp are only set for one frame of the game when the user presses the button, and go back to false the next frame.

In the end though, it all depends on your game and how you set it up or program it. If only using FixedUpdate works for you, then you're free to stick with it. Just realize that there are some limitations like missing one frame triggers and possible movement stuttering with non-physics movements.

Dominic
  • 62,658
  • 20
  • 139
  • 163
0

Update is called once per frame for every script that it uses it. Almost anything that needs to be changed or adjusted regularly happens in update. The movement of non-physics objects, simple timers and detection of input are set here. Update is not called on regular timeline. If one frame takes longer to process than next, then the time between the update calls will be different.

FixedUpdate has a few differences:

  • It is called on a regular timeline and will have the same time between calls

  • FixedUpdate() has the advantage of running in fixed time steps and is helpful for time-dependent but frame rate-independent tasks.

  • Right after FixedUpdaet is called, any necessary physics calculations are made. such as, anything that affects the rigidbody, meaning that a physics object, should be executed in FixedUpdate.

  • When scripting physics in the FixedUpdate loop, it is good practice to use forces for movement. Any physics or Rigidbody-related code always goes inside the FixedUpdate method, rather than Update or the other MonoBehavior methods

  • Checking for inputs in FixedUpdate can sometimes lead to input loss or even double inputs because it doesn't run once per frame. That is why we should be checking for inputs in Update and then applying force or setting the velocity in FixedUpdate.

Yilmaz
  • 35,338
  • 10
  • 157
  • 202