Firstly I would like to know a clear difference between LateUpdate() and Update() in unity. I know the order of executuion, i know their uses, but i just don’t understand why these two different methods.
Secondly, i found a very interesting issue with the behavior of Time.deltaTime() in each of these functions.
To explain more briefly, I first created a method Update().inside update() I did a lot of maths and then printed Time.deltaTime(). i got almost same results each frame. Then i changed the method name to LateUpdate() and did the same thing. This time i got different results for each frame.
It’s hook that runs after all other Update calls, including animation and coroutine updates.
Think of it like Awake and Start.
Awake and Start each are called in any weird order that unity happens to call them depending on the order of the scripts loaded and the ‘script execution order’ defined in the project settings.
BUT
All Starts are called after all Awakes. You can be certain that when you run code in Start, any script you’re accessing has already had its Awake code ran. This way you can coordinate accordingly. Lets say one script needs to set several variables on itself which will then be accessed by another script… it’ll do this in Awake, so that when the other script has Start called, it knows for certain those variables are ready (there is the exception of the fact that some objects are created AFTER Start).
The same goes for Update and LateUpdate.
When LateUpdate is called, you know for certain that all Update/coroutines/animation updates have occurred for that frame. So the state of any object you access aught to be in the state it will be when rendering for that frame actually begins (just after LateUpdate).
This is useful for say a camera follow script. It wants to be at a specific position at render time… but that position aught to be where the gameobject is at render time. If you put the follow code in ‘Update’, there’s a chance the camera follow update code will occur BEFORE the player movement code. This would cause the camera to be positioned where it was supposed to be the prior frame. This would be bad… it gives the impression that the camera is lagging behind the player rather than staying right on top of it. So instead, put it in LateUpdate, and you are right on top of it.
It’s sort of a way to get an ‘execution order’ with out having to go and set the ‘script execution order’ in the project settings. Also noting the ‘script execution order’ effects ALL update callbacks (Awake/Start/FixedUpdate/Update/LateUpdate)… where as the LateUpdate only deals with the one ‘Update/LateUpdate’ relationship.
It also has the added benefit of the fact that ‘script execution order’ is still arbitrary between scripts of the same type.
It is suggested to use Awake/Start and Update/LateUpdate to schedule things appropriately, and only use ‘script execution order’ if there’s no other way to do it.
First regarding Update and LateUpdate. You never know in which order the Updates are executed among the different components. So if you have a bunch of scripts, all containing Update and you add them to a bunch of objects, you will never know the order in which those Updates are going to be executed. We always have to assume a random order, unless we explicitly define the script execution order. But even in that case, if the same script with Update is added to multiple game objects, the execution order of those is still random. The same is true for LateUpdate.
There are cases in which I first want to perform a certain operation on all the game objects and afterwards perform another operation. E.g. I could modify the position of all the characters and props in Update and in LateUpdate I could then use the result and compute the IK (inverse kinematics, e.g. to make sure the hand of a character is at the correct location when pushing an object). In the IK computation it could be needed that all the positions are already updated, because the characters may push some props around and in order to get correct visual results, it is required that the positions are updated before the IK is computed.
This could also be achieved in other ways only with Update. However, this is one of the possible uses of Update in combination with LateUpdate.
There should be no difference whether you execute it in Update or LateUpdate. You can easily try it out by using Debug.Log to print Time.deltaTime in both.
Thanks for the info. It made me help understand it more clearly. But my second question regarding Time.deltaTime() remains unanswered. From what i understand Time.deltaTime() gives the time taken for the last frame to render(last frame to render meaning , everything update(),lateupdate(),fixedupdate() etc. has been done). So it doesnt matter if i print the time in update() or lateupdate(). So why do i get contrasting results?
the deltaTime from frame to frame will be different, sometimes the same, but most often different.
The deltaTime should be the same in an Update and LateUpdate call during the SAME frame.
But the next frame, it will be different.
Because each frame might take a different amount of time to calculate.
This is why the framerate of a game varies. If you set a target framerate, unity will attempt to keep it at that framerate, but there’s no guarantees. This is why deltaTime exists… so that you can write animation/movement code that is independent of the framerate. If you moved a constant 1/60th of the speed every frame, you’d find that as the game slowed down, so would your movement… and as the framerate went up, so too would your movement.
This is why old school games on like DOS and earlier, which did use constant framerates, run so freaking fast if you don’t throttle it with an emulator like DOSBOX.
I would recommend reading the docs for every single question you ask about the Unity API in addition to asking questions, because there’s often links in the docs to things that really, really help you do even better.
