- Home /
Why does fixed Timestep affect deltatime in Update?
I am using
Debug.Log("Update time :" + Time.deltaTime);
in Update() to get the time between each frame. (Not fixedUpdate)
When the timemanager is in default settings ( Fixed Timestep = 0.022 / Maximum allowed Timestep = 0.022) then I get values that I am expecting ( Varying deltaTime at each frame around 0.0164 s )
However when I change Fixed timestep to 0.0083 AND Max. allowed Timestep to anything smaller 0.016 (i.e. the frame rate that I normally get) then Time.deltaTime returns the value set for the Max. allowed Timestep.
Looking at a wealth of other questions and the manual I expected the timestep to have no effect on what Update does. But I was wrong.
So why is that? Is the deltaTime set somewhere that is specific to how long the physics are allowed to run for? Have I misunderstood something? Or have I made a goof somewhere?
EDIT: TL;DR ANSWER (by @Bunny83):
Maximum Allowed Timestep is the upper limit that time.deltatime will report.
Answer by Bunny83 · Jul 29, 2015 at 01:43 AM
I'm not sure when you modified your default settings but in my Unity the default settings are:
0.02 Fixed time step
0.333333 max allowed time step
First of all the fixed time step defines how many physics frames you get per second. The default setting is 50 frames (1 / 0.02 == 50). the max allowed time step is not related to one physics frame but to your whole game performance.
Time.deltaTime when read outside FixedUpdate simply returns the time one game frame took in total. So if you get a value of 0.0164 that means you have a frame rate of about 60 frames per second (60.9756...).
When you decrease the fixed time step to "0.0083" that means you increased the physics frame rate up to 120 fps (120.4819...). The physics frames are part of your whole frame time. The more physics frame you have per second the more time it will require from your game frame time. with 120 fps fixedupdate and 60 normal fps you get about 2 fixedupdate calls in one frame. If you do heavy things in FixedUpdate your game frame rate will suffer.
The max allowed time step is just a security cap to prevent a down spiral. Each frame Unity's physics system tries to "catch up" with the normal game time. It does that by running several physics steps in a row until the physics time is equal or greater than the normal game time. That way Unity ensures that the same amount of physics frames are executed in one second. Howeever if one physics step takes too long the over all frame time will get longer. Therefore you get a lower fps. However that means since you have less Update calls, Unity has to execute more FixedUpdate each Update to get to it's 120 frames per second. So if the framerate drops to 30fps Unity will execute 4 fixedUpdate each frame which might cause the frame rate to drop even further. This could go forever until a single frame takes 10 seconds and unity will have to call 1200 fixedupdates per frame and it would get worse and worse. The max allowed timestep simply caps the over-all frame time to usually 1/3 second so it won't get worse than 3 frames per second.
If you set the max allowed time step to 0.016 that would mean as soon as your frame time takes longer than this your frame time is capped to that value and it will stop calling fixedupdate until the frame rate "gets better". However 0.016 equals 62 frames per second. You probably have v-sync on so your framerate is limited by your monitor's update rate of 60Hz.
You really shouldn't mess with the max allowed timestep. If it's too low your physics calculations will go wrong as Unity will simply skip physics frames.
Thank you for the detailed answer. A few comments based on your response:
I'm not sure when you modified your default settings but in my Unity the default settings are
You are right, just a typo :)
Really good explanation, I had read this part from previous readings but you put it nicely and it was good to reassure that I understood this part correctly.When you decrease [...] worse and worse.
The max allowed timestep simply caps the over-all frame time
That's the important bit. Is it the over-all frame time that it is limiting (effectively stopping all processes and going to next frame) or just the physics calculations when the limit has been reached (stopping physics and allowing rest of code to continue)? If it is the over-all frame time then does it just stop the Update() code half way through executing? Or is time.deltatime tied to the physics calculations and the timer stops when the physics are throtled by the $$anonymous$$ax. Allowed Timestep?
Quoting the manual:
The $$anonymous$$aximum Allowed Timestep setting (in the Time $$anonymous$$anager) puts a limit on the amount of time Unity will spend processing physics and FixedUpdate calls during a given frame update. If a frame update takes longer than $$anonymous$$aximum Allowed Timestep to process, the physics engine will “stop time” and let the frame processing catch up.
I would assume then that changing the $$anonymous$$ax. Allowed Timestep should have no effect on the Update() or what deltatime reports inside the Update. Unless, deltatime is a physics calculation.
In reality (as per my answer to meat500) there is no discernible effect on fps or play behaviour other than what deltatime is telling me that the time since last Update frame was.
You probably have v-sync on so your framerate is limited by your monitor's update rate of 60Hz.
Good guess, vsync is off but I have vr support enabled, which has a similar effect to vsync as far as I understand it (amongst other things). I didn't mention it because I don't think it should have any effect on neither deltatime nor max allowed time.
To sum up:
a) Is the maximum allowed timestep regulating and limiting physics/fixedUpdate() only or does it also regulate and limit the Update() frame time as well.
If the later then that's not apparent in the manual.
If the former then why does it affect deltatime from within Update()?
b) In either case neither the fps (according to profiler) is changing nor is the behaviour on play. Only what deltatime reports changes.
$$anonymous$$ax allowed time step will essentially do two things:
make the physics catch-up process drop physics frames when it takes too long.
limit the reported deltaTime to that value.
The first thing i explained already in my answer. It's to stop this sprial of death. The second thing is to ensure a $$anonymous$$imum accuracy for any kind of calculations.
Next important thing is to remember that Unity uses a single thread for everything that is related to scripting. So everything that happens within a single frame is executed one after another. This includes the physics catch-up. Look at this page and the flow chart. This chart isn't 100% correct but it shows the overall structure of the mainloop of Unity. The section named "Physics" is the physics catch-up loop.
Now if you have some really heavy calculations in Update which takes 3 seconds to complete your frame rate will drop to 0.3fps as you only get a frame about every 3 seconds. Unity however will limit the reported deltaTime value to the max allowed timestep to ensure a certain accuracy. Since you usually linearly scale all time dependend processes with Time.deltaTime it's usually ensured to accumulate over time so you get a certein value after 1 second. So when you move an object with 15 units per second you multiply 15 with Time.deltaTime and each frame you move your object by this fraction. That ensures that after 1 second you get an accumulated value of 15.
However if the framerate is too low calculations would become more and more inaccurate. In the example above where we actually have a deltaTime value of 3 seconds. Things get fast out of control. Our 15 units per second object would jump 45 units each frame. That's of course technically correct, but usually leads to undesired results as an elephant could pass through a whole house without ever intersecting it.
When your frame rate is lower than the "$$anonymous$$imum required framerate" (which is the same as the maximum allowed timestep) your game simply will run slower than it actually should be. If the max allowed timestep is exceeded it's an exceptional situation which usually should never happen.
If you think about a real world example: Imagine every driver is required to have a reaction time that is faster than 0.3 seconds. In reality if someone can't provide such a reaction time he's not allowed to drive at all. Unity however does something different. Since we have code that is too slow but the system requires a reaction time of 0.3 seconds Unity simply slows down time so the code actually has the required reaction time.
Damn 222 characters over the limit ^^...
...
If you setup a very low max allowed timestep like you did you essentially slowing down your game whenever your system is too slow to keep up with the requirements.
Unity doesn't "stop all processes". A heavy calculations in Update scales linearly If it took 3 seconds one frame it will take about the same the next frame and it doesn't get worse over time like it does with the physics update. So when you exceed the max allowed timestep all Unity does is skipping physics frames and limits deltaTime to slow down game time so physics have a chance to catch up with the game time.
Thank you again for the prompt reply
limit the reported deltaTime to that value.
That is the bit I was asking about. I didn't find any reference of that in the manual and that's what confused me. Is it mentioned somewhere in the manual that $$anonymous$$ax allowed time step limits the reported deltaTime?
If that is the case then that's the answer.
Ps. $$anonymous$$y poor google-fu only returns me another answer by you. Can't find anything else on $$anonymous$$ax. Allowed timestep limiting deltaTime.
The link @$$anonymous$$eet5000 provided in his answer does talk about slowing down the frame rate.
If a frame update takes longer than $$anonymous$$aximum Allowed Timestep to process, the physics engine will “stop time” and let the frame processing catch up.
While it doesn't explicitly state that deltaTime
will be reported as the maximum value, it can be inferred from it.
Answer by meat5000 · Jul 29, 2015 at 01:29 AM
If a frame update takes longer than Maximum Allowed Timestep to process, the physics engine will “stop time” and let the frame processing catch up
This page explains it all.
Max allowed TimeStep pretty much specifies the minimum allowed FPS under the condition of a heavy FixedUpdate, like if you have heavy physics. Setting such a low FixedTimeStep makes FixedUpdate run a lot.
I believe you are telling it :
Attempt to run FixedUpdate 120 times a second but only allow FPS to drop to 62.5 as a result.
62.5
is a decent target, but the fact that your FPS is being throttled down to your MaxAllowed defined FPS could indictate that your FixedUpdate is doing too much work.
Thank you very much for the answer. I have a few comments
FPS is being throttled down
If I were to believe the time given by deltatime then I would have to assume that my fps is increasing (deltatime is smaller in the case of small $$anonymous$$axAllowed).
In reality I don't see any performance difference between the two cases, the only difference being what deltatime is reporting as being the case.
FixedUpdate is doing too much work
There is no code in fixed update in any of my scripts and there is barely any physics in the project. That is evident in the profiler (Fixed update doesn't even come up)
So, to sum up when I change the maximum allowed timestep:
a) There is no change in fps performance (through the profiler / behaviour in play)
b) Delta time reports a smaller time since last frame in Update (like a free lunch)
c) There is no work that is visibly being done by physics.
I hope that is a bit more clear now. I can provide screenshot / logs if that would make more sense.
Its just that when $$anonymous$$axTimeStep was set to allow a $$anonymous$$imum of 3 FPS (the editor default) the Physics routine was being allowed to run more. It is still intensive enough to drive your FPS down to that amount. Lowering $$anonymous$$axTimeStep allows $$anonymous$$in FPS to be greater at the cost of skipped Physics loops.
Any rigidbody interaction and collisions will also go in the Physics loop. I'm guessing Raycasts will too.
Setting the values in Time $$anonymous$$anager should only affect performance if there is some load but even with empty FixedUpdate the Physics loop will still run.
As an example, cranking up the Fixedfps (FTS 0.0001 $$anonymous$$axATS 0.3333) on my own $$anonymous$$imal game I get 1840 calls to Physics Cloth Preprocessing even though theres no cloth in my game. CollisionTask and SingleAABBTask appear to be the most intense. Physics takes 331ms (161ms self) in my simulation even though the game is sat waiting for me to click the server Host button before any gameobjects are even created.
Set your FixedTimeStep to 0.0001 and $$anonymous$$axATP to 0.333333 and see if that drives you down to 3FPS. Its easier to see the effects with VSync on at least thats what I found when playing around with it in my editor.
Setting $$anonymous$$axATP is meant as a failsafe parameter and shouldnt be used to set tickrates, but if it works for you without any of the cons then its a win!
Thanks again for the reply. I think the answer was that the $$anonymous$$aximum Allowed Timestep is the upper limit that time.deltatime will report.
So update will continue running as normal but the reported time.deltatime will be wrong (capped).
I don't think it offers any advantage to leave the $$anonymous$$axATP so low, I was only experimenting with reporting time for each frame (and how reliable deltatime was) when I stumbled into this issue. Still not sure how I should know that time.deltatime gets capped by $$anonymous$$axATP but it seems to be a known effect so I will go with it.
Your answer
Follow this Question
Related Questions
Should we use Time.deltaTime in FixedUpdate 5 Answers
Add 1 Per Second to an Int 1 Answer
Slow update best practice 0 Answers
Time.deltaTime not consistent over time 1 Answer
how do i make this to a negative (ShopRespawn < 180)? 1 Answer