(This was asked in the WishList Topic, but I feel my reply would be more helpful, and more properly put, here.) Code (csharp): smoothDeltaTime = (current delta time + (sum of 'n' previous delta times)) / ('n' + 1) Using smoothDeltaTime limits the effect of sudden fluctuations in deltaTime. Example: Code (csharp): deltaTime smoothDeltaTime ('n' = 2) -------- ------------------------- ... ... 0.25 0.25 0.25 0.25 0.25 0.25 0.95 (+380%) 0.4833 (+193%) 0.25 (-73%) 0.4833 0.25 0.4833 0.25 0.25 (-51%) 0.25 0.25 ... ... In the table above, you see deltaTime is going along steadly at 0.25, but then suddenly it spikes up 380% to 0.95 then drop down 73% to 0.25. The visual effect of the spike would be everything suddenly moving 380% more units than the previous frame. The smoothDeltaTime, since the values are averaged over several frames, only sees a jump of 193%. And when it does drop back down to normal, the drop is only 51%. Now, while there will still probably be a visually noticible "hitch", it won't be as drastic as the deltaTime hitch. The hitch will have been spread, or "smoothed", out over several frames. I agree, it would be nice if some of the descriptions where expanded on, but hopefully my little description will help in the mean time (and is not too far off the actual mark)
I didn't even know there was such a thing as smoothDeltaTime. Thanks for explaining this. I'm sure I will use this at some point.
Just for information if any docs manager comes by this section : April 2012 (4 years later), and the docs about it are still vague. I had to Google search "smoothDeltaTime" to find out further explanations here.
The doc is quite hurting in some parts. I wonder why they didn't make a wiki version where anyone could contribute to keep things updated.
You can have manual for offline use + an online version and a separate wiki just for online where users can add things. Many applications use this sort of method and it works wonderfully.
Thanks DGuy for the useful information, and thanks n0mad for bumping this Unity docs should really be taken more seriously by the Unity guys. The amount of time that a Unity user has to lose to get information about things that should be well documented is absurd. Online searches, forum help, direct trial and error testing. And all this not to find solutions to issues, but just to understand undocumented (or badly documented) API. If we count these hours as working hours, Unity costs a LOT more than 1,500$.
Should it not be possible to have a community driven wiki then? Someone just have to set one up and I'm sure many will contribute to it.
why can't they just add a comments section to the docs like they have on php.net?! everyone could add clarifications and examples and everyone on the planet would benefit greatly!
This. All day, this. Not that the resources aren't great as they are, but having something a bit more expanded than this kinda (understandably) rushed doc note would be great.
Ahh, thanks for the explanation. The current doc's explanation—"Smooths the delta time"—could mean a hundred different things.
From my experimentation Unity calculates it as a linear combination of current frame time and previous smoothed time like this: newSmoothDeltaTime = f*Time.deltaTime+(1-f)*prevSmoothDeltaTime Where they seem to use f=0.2 (In Unity 5 at least) In the end I had to implement it myself because Time.smoothDeltaTime seems to be updated also when the timeScale is zero causing it to be nearly zero after my game was unpaused.
The documentation almost never has the exact math that goes into any of its built-in methods and members, so this is just one of a million different things that have some magic going on behind the scenes, and no reason (or at least, no more than normal) to update the documentation. Anyways, they've been more focused on those promotional videos that they call tutorials.
Smooth delta time does exactly what it says.If there is a significant jump in the framerate you're running, SmoothDelta time will report values closer to your targetFPS but weighted by the amount of frame loss. deltaTime will give you the actualy time difference.
So shouldn't we always use smoothDeltaTime rather than just deltaTime? Is it ever preferable to just use deltaTime?
Seems like a matter of preference. What should happen if someone's machine lags? Should it skip (deltatime) and be caught-up the next frame, or should it go into slow-mo for a few frames(SmoothDeltaTime)? I've never tried SmoothDeltaTime, though.
Using smoothdelta you will run slower in the spike frames so a slow computer will lose against a faster one in multiplayer
Not what I was looking for exactly, but this kind of implements a simple low pass filter, effectively filtering the time step so it doesn't change so much each frame. Simple DSP (digital signal processing) This: newSmoothDeltaTime = f*Time.deltaTime+(1-f)*prevSmoothDeltaTime Where they seem to use f=0.2 (In Unity 5 at least) Implements a simple "one pole" filter with a "cutoff frequency (knee) coefficient" of 0.2. As you increase the number of 'previous delta times' the 'curve' of fps over frames gets smoother. Of course, to really do it correctly minimizing distortion you have to multiply those previous delta times by their own coefficients...
I am sorry to disappoint you sir; but the documentation of Time.smoothDeltaTime is still vague as ever
... and ten years later it still isn't... https://docs.unity3d.com/ScriptReference/Time-smoothDeltaTime.html
I'm happy to tell you that I'm updating this very part of the documentation (in fact the whole Time API doc) as I'm writing this! I don't know exactly when exactly, but it will be published soon.
@berniegp When you update the docs, can you perhaps poke some devs to update the implementation so that smoothDeltaTime compensates for changes in deltatime when Time.timeScale is changed. Currently, if you were to create a component for a missile seeking a target and you used smoothDeltaTime then paused your game using Time.timeScale = 0; the missile would keep tracking and slowly decelerate for about 2 seconds after the game has been "paused". Given the intent of smoothDeltaTime this feels like an unexpected side effect that should probably be patched.
smoothDeltaTime currently has a very simple logic where it interpolates between the current frame's "real" deltaTime and the previous smoothDeltaTime with a weight of about 20% for the "real" deltaTime. In other words, it tracks deltaTime with a delay to, as the name says, smooth out its variations. While I see your point, the fact is that the current behavior has existed for a long time now and both the current behavior and your suggestion are valid choices for a smoothed deltaTime value in different contexts. Therefore this is not likely to change. However, the upshot is that you can pretty easily make your own smoothed time since it's so simple. Just add a bit of logic to a singleton class (e.g. MyTime) and zero-out your smoothed time when the timeScale is 0.
The new Time documentation is up! https://docs.unity3d.com/ScriptReference/Time.html Time.maximumDeltaTime is missing an important bit which I'm attaching here for now:
The table (and much more) has been integrated in the docs here: https://docs.unity3d.com/Manual/TimeFrameManagement.html
thanks for the documentation, its MUCH MUCH better than before. sadly after the unity 2020 update to improved deltaTime measurement, i still have a lot of jitter when putting a lot of uneven load.