Why is FixedUpdate called before Update?

Unity Engine
1

Out of curiosity: is there any simple way to make Unity run FixedUpdate after Update? Or is there a reason why it’s called before?

As I understand it, you’re supposed to poll for input in Update, just to make sure user input is recorded before every single frame, regardless of frame rate and timestep.

But if physics is executed in FixedUpdate, then that means the result of each input isn’t visible until 1 frame later. If physics were called immediately after Update (but before the frame is rendered), then the player’s action would execute on the same frame that the button is pressed.

One frame of lag won’t kill me, but I’m wondering why the engine works this way. It feels as if the lag is deliberately built in.

2

See here for a great diagram showing the execution order in Unity: Unity - Manual: Order of execution for event functions

I don’t think there is any way to change that behaviour. Note, FixedUpdate can be called many times per frame. I don’t think it’s right to attempt to maintain an “order” between when these are called.

3

Update and FixedUpdate can be seen as two separate execution flows, not necessarily “after” or “before” each other.

  • Update executes at the screen’s refresh rate. Frames may be skipped sometimes if the cpu/gpu load can’t keep the rate.
  • FixedUpdate executes at a fixed rate (50 Hz default). Frames won’t be skipped here: instead, the game time may be “slowed down” and/or Update calls will be skipped in order to perform every FixedUpdate call.

There are situations where multiple FixedUpdate calls are performed between each Update call. Commonly, Update is called several times between each FixedUpdate call.

If you record an atomic event input in Update (i.e. GetKeyDown) then the effect will happen the next FixedUpdate call. But note that you can monitor the continuous inputs within FixedUpdate (GetKey, GetAxis), so you may have them processed in the same physics step.

1 Like
4

I guess that’s what it comes down to. In my case, I wanted to set FixedUpdate to roughly 60hz (0.016667), just to keep things simple. But even when FixedUpdate is called roughly once per frame, it still executes before Update, so it can’t act on GetKeyDown until the next frame. This also can’t be fixed by making the fixed timestep faster (e.g. 120hz), because that just causes FixedUpdate to run twice before each Update.

In the end it’s probably not a big deal. If anything, it makes me want to frame step through Mega Man or something in an emulator to see if and when there’s any input lag.

5

Can’t you just GetKeyDown in FixedUpdate?

6

A quick test Unity 5.5.2

Listning for Input with GetKeyDown in FixedUpdate, Update and LateUpdate

Execution order result

  • “Key Pressed”

  • FixedUpdate

  • Update

  • LateUpdate

So it appears that Input is set before FixedUpdate. Maybe a change has happened in a patch and the execution order flow chart has not been corrected?

edit:

void OnMouseDown() is however called after FixedUpdate so perhaps this is what the flow chart is referring to?

7

No, because FixedUpdate does not run every frame, so it will miss events.

–Eric

2 Likes
8

Gotcha. I’m wondering though, if the input is only being assessed in the physics step, is that such a bad thing?

(I rarely use the physics system and have never done so directly with input so please forgive my ignorance)

9

You should still detect the one-time events at Update. If you’re monitoring the space bar for jumps, then GetKeyDown(KeyCode.Space) in FixedUpdate will likely cause the character not to jump every time the player hits the space bar.

1 Like