If you have been working with unity for any length of time you no doubt have run into the question of weather or not to use
LateUpdate() to run your game code.
At the surface each appear to do the same thing with some subtle but significant differences. Understanding these differences is key to getting your game to run smoothly and properly.
This article aims to define the behavior and provide guidance for implementing each of these three event handlers in Unity.
Update() runs every frame (aka frame-dependent). Put simply, the number of executions per second is based solely on the frame rate of the client (aka device). This means if you are playing a game on a device that has a max frame rate of 120 FPS, you will see
Update() fire approximately 120 times every second (keeping in mind that frame rate is never constant).
Update is great for things like character movement or user input. Things that can and should update as frequently as the CPU and GPU can handle. Think of it this way, if a device can process your code at a more precise level and faster rate without any negative side-effects, then you can and should use
You may think that because you cannot predict the timing of
Update() with any certainty that you cannot use this for time sensitive operations, however that's not entirely true.
Time.DeltaTime offers you a way to know how much time has passed since the last frame. To learn more see https://docs.unity3d.com/ScriptReference/Time-deltaTime.html
FixedUpdate() is frame-rate independent and runs every .02 seconds. As you can imagine there are times when you need to ensure a consistent tick in your code. Physics is a great instance of this. Physics requires precise timing to simulate interaction between objects and
FixedUpdate() provides this predictable and precise timing.
Generally speaking you want to put anything relating to collisions or triggers in this event handler.
A common mis-use of
FixedUpdate() is detecting button clicks. When a button is clicked it triggers for only a single frame. Remember though,
FixedUpdate() does not fire on each frame, because of this it's possible to miss the trigger altogether.
You may also find that character movement stutters or skips frames when executing movement controls on
FixedUpdate(). While it technically will work, you will find you have a smoother game play experience using
While it is true that
Time.DeltaTime can help you figure out how much time has passed since your last Update cycle, if you are interacting with colliders
FixedUpdate() ensures your code is in coordination with updates to the physics simulation. If you place physics logic inside
Update() there is a small chance you will get incorrect results due to missed ray-casts or collisions.
You can actually change the frequency of
FixedUpdate() navigating to
Fixed Timestep and chaning it there.
LateUpdate() is frame dependent, however it's guaranteed to run after all
Update() functions have executed. If you need to ensure all objects have finished their
Update() cycle before executing code,
LateUpdate() is your preferred event handler
LateUpdate() is used for camera updates. The reason for this being that the camera must track an object where it is located and not where it was. By putting camera logic in
LateUpdate() you are guaranteed to have its final position each frame.
Thank you for taking the time to read this. If you found it helpful or simply want to add to the discussion please leave a comment below.