Time.smoothDeltaTime ???

(This was asked in the WishList Topic, but I feel my reply would be more helpful, and more properly put, here.)

Code (csharp):

1.  
2.   smoothDeltaTime = (current delta time + (sum of 'n' previous delta times)) / ('n' + 1)
3.  

Using smoothDeltaTime limits the effect of sudden fluctuations in deltaTime.

Example:

Code (csharp):

1.  
2.     deltaTime          smoothDeltaTime ('n' = 2)
3.     --------           -------------------------
4.     ...               ...
5.     0.25               0.25
6.     0.25               0.25
7.     0.25               0.25
8.     0.95 (+380%)       0.4833 (+193%)
9.     0.25 (-73%)        0.4833
10.     0.25               0.4833
11.     0.25               0.25   (-51%)
12.     0.25               0.25
13.     ...                ...
14.  

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)

 

Thank you for sharing.
The documentation hasn't been updated yet :-/

 

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.

 

Cause the docs also have to be accessible offline and it doesn't work with Wikis?

 

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.

 

Wow. 7 years(!) later the docs page for this hasn't changed.

 

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.

 

Or might the reason about silly of their document for a big community then you all are here

 

2018 and still had to google it since the Docs weren't very helpful

 

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

 

@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.

 

Great!

 

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.