what is the difference between Update & FixedUpdate in Unity?

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

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!

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.

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.

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

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

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.