Time.deltaTime Not Constant: VSync CameraFollow and Jitter

@Tautvydas-Zilys
I really wanna know exactly what did you folk fixed in 2020.2? Cause my characters and my camera movement/rotation now jitters like crazy. It was working fine until 2020.2 (doesn't happen in 2019.4 or 2018). This happens on Nintendo Switch builds but the jittery can also be seen in Editor but hard to notice (looks like a regular editor spike).
Is there a way to use the old deltaTime value? Or at least simulate it? I'm forced to use 2020 now otherwise I won't be able to do lootcheck submisions for the eStore with 2019. Not only 2020.2 introduced jittery, but also my game run slower too (~5 fps slower) on the Switch hardware. Game is unplayable now due to this jittery.

 

Frame rate fluctuates in the ~45-55 ish fps range, because is a nintendo switch game.
I don't have any rigidbody attached to my characters, they move through NavMesh using the Animator.velocity.
This issue does not happens in 2019 btw, not only the game is slightly faster in 2019 but theres zero jigger/stutter.
Something to notice, if I use deltaTime to scale camera rotation/positon speed, the camera jitters, but characters do not jitters. If I use smoothDeltaTime to scale camera rotation/positon speed then the camera is smooth but characters jitters.
Other info that might shed some light:
- Targetframerate is exposed to users (30,45 and 60fps, default to 30)
- vSync is disabled
Anything else that might affect this is either disabled or using Unity default values for the Nintendo Switch platform.

 

Not sure, but are you using lerp to scale the rotation/position speed maybe? That can cause jittering very often if not used in the "correct" way.

 

No, I got a custom Lerping (a safeguard) to avoid overshooting the interpolated value. But if what you say is true it means that Lerp also change behavior in 2020?

 

Well, a lot of people use lerp with just the current and the target value and put in time.deltatime * some other value. But this is not the way you should be doing it, as lerp is linear interpolation. https://gamedevbeginner.com/the-right-way-to-lerp-in-unity-with-examples/ So I would rather use movetowards if this is what youre doing currently. Lerp hasnt changed at all, but maybe you just didn't notice the stuttering before? Sometimes that happens. Also as editor performance has been getting much worse in the last few years, microstutters that may be caused by lerping incorrectly might have gotten more noticeable. But maybe I am wrong and its something else, but maybe not lol

 

As mentioned, Lerp never reaches destination value if percentage parameter (t) is used as dt * value (mathematically);

Also, worth checking execution order. In short, you'd want to move camera after followed object is being moved.
Otherwise object may get moved, and there will be a frame skip.

But to be honest, nowadays we don't use custom camera controllers.
Just Cinemachine camera with Update Mode set to LateUpdate.

Smooth like butter. Plus, lots of cool features that you don't need to maintain on your own.

 

Right but this was working fine until after the change in deltaTime in 2020.2. Like i said earlier, I have a safe guard to avoid overshooting interpolated values when lerping. I don't think it has anything to do with it.
PS: Camera is the last thing that moves (LateUpdate), characters animates in Update call.

 

The stutter happens only after 2020.2, is very hard to notice in Editor as it look like one of those editor spikes that happens now and then due to the heavy load in the mainthread but on console is a lot more visible and constant.

 

Im sure is due to deltaTime because replacing deltaTime by a constant value makes the stutter go away. However this is not the solution because my fps varies a lot and movements/rotations speed and slow down because fps varies a lot.

 

Thanks,
I did that, let's see what they respond.

 

The linked thread doesn't address the issue with inconsistent deltaTime. But assuming this issue is solved and you want to update logic in FixedUpdate(), and still have stutter-free visuals, then you will get a useful solution.
https://forum.unity.com/threads/mot...ion-to-eliminate-fixedupdate-stutter.1325943/

Btw. @ engine team. It is more FixedUpdate()-related. I see it as a flaw to rely on raw deltaTime/time to time fixed updates or normalizing movement speed (at least there is smoothDeltaTime for that), for the purpose of game engines. Games are not a hard real-time demand, so trying to update something in accord with the wall clock at any given moment tends to add more instabilty than benefit. The timing mechanism for fixed updates should involve an averaged deltaTime instead. An accumulation of averaged deltaTime won't exhibit spikes on any hardware, except for something like long loading times of course. Scheduling of FixedUpdate() calls will still expose algorithmic instability, given how it is implemented, but at least it is something for the better.

 

@ engine team and everyone wanting to implement a stable fixed update loop (with motion interpolation):

For a serious deep dive to a fundamental level, I dedicated an entire Bachelor-Thesis to the stability of fixed update loops (it also includes interpolation, but it is orthogonal to actual stability):
https://drive.google.com/file/d/1VajBHqmsajsU3Gp1ZYFhAPhavFQJC7wL/view?usp=sharing

It essentially reveals why "everyone" is implementing fixed time step loops wrong and offers better (and also simple) solutions. Now I know the paper is hard to read and is in need for a tldr-version. But to get the gist, just understand the graphical instability examples. Then you will understand the "Hysteresis Loop". It's almost as easy to implement as the "Standard Loop" (the one Unity is using). But it is significantly more stable and has no caveats.

Like already suggested, we should not use/rely on raw deltaTime values but on a moving average (take around 30-60 samples and everyone is happy). A moving average doesn't introduce a drift to the wall clock (as shown in the paper), and reduces noise significantly. (Also, the data type float is fine for deltaTime, but time/fixedTime should better be double since it accumulates over time. With float, you will get more noise and loss of information in longer play sesssions.)

In particular, I would suggest the following solution:
You can improve fixed update and automatically remain backwards compatible to the way Unity works now by doing the following: My suggestion would be to include a moving average filter over deltaTime and having the timing of FixedUpdate() be controlled by the Hysteresis Loop. In the editor, you expose the following variables for users who want to tweak them.

1. sampleCount (for the moving average filter (30 is a good default))
2. noiseWidth (for the Hysteresis Loop)

Now there are good defaults for the vast majority of users. But when you want to tweak them or go back and make it work the old way, you just set sampleCount = 1 (you get now raw deltaTime) and noiseWidth = 0; Now the loop turns into equivalent FixedUpdate() scheduling of Unity, which basically means it does nothing to eliminate the influence of noise. Instead it gets controlled by it.

 

i second tatoforever, i have a steady speed camera flying through terrain + lots of performance cost in render, in editor AS WELL as in build, using deltaTime results in choppy visuals.

in my test the frame takes between 8 and 20ms, dependign on what settings i do, and without vsync it chops ugly at high frame rates (8ms) as well as low (20ms) as well as it changes (e.g. local foliage rendering slows temporarily down)

averaging it A LOT helps with the result, but doesnt provide a good experience.

its strange to me, as it seems that in the 2021.3.14f1 the deltaTime fix seems totally unapplied :-(

 

@Tautvydas-Zilys

Is this fix out for desktop VR yet?

 

thanks! is there any info about this yet?

 

may be this bug is related

Looks like it introduced in Unity 2021.3.20f1 while attempt to fix jitter delta time jitter
https://issuetracker.unity3d.com/is...g-and-restoring-the-app-when-built-on-android

 

my issues are on windows desktop + nvidia + built in pipeline, so the biggest user base of developers + projects (and its a RTX 2070, so according to steam also the middle ground of performance).

i would be happy if someone from unity can describe what is expected to happen when you do what i described https://forum.unity.com/threads/tim...follow-and-jitter.430339/page-11#post-8703051

i mean, how do i regression test that the deltaTime fix does work?

did you find any conclussions tatoforever?

 

Thanks!

Update(), no rigid body, simple movement manually coded by: pos += vel * deltaTime

The deltaTime is varying between 8 and 20ms. Not "all over the place". AFAIU this makes sense as I describe a vsync off situation, where the scene changes cause frames to take longer or less long, including GPU and CPU heavy rendering (incl. Heavy shader work).

 

Thanks, i am aware that strong changes are causing the eye to see it, but thats not really what is happening here.

i have a canyon, i fly with a "spaceship" through it, the speed is somewhat 140m/s, the objects and canyon have some realistic sizes, we are flying halfway high, far away from trees and objects. it will stay betwen 11 and 13ms for atleast few seconds, spiking more or less 1ms up and down around 12ms. i can turn off features that are calculated every Nth frame to get a more even load, and then we can see something like 9ms to 10ms, and the spiking only half a milli second.

what we can clearly observe visually, is that even with post processing motion blur turned on, the spaceship is constantly, evenly, jumping. not flying smoothly. with vsync on, we can see it fixed to 16ms, the load of the game is less (9 or 12ms tests) and the spaceship flys perfectly smooth.

i do not understand how that half millisecond difference (so between 100 and 110fps) causes strong visual jumps, rhytmically even, that seem like a difference of 150% every 10ish frames.

any proposal what i could screenshot (profiler view or something) to see these jumps in a debug tool?
should i just plot to console every frame the deltaTime?

it is not that i dont believe you that visual differences will cause uneven behaviour. but this micro stuttering, stable, feels like an issue of something and not that minute barely unnoticeable difference between 100 and 110fps. so i would like to show you something where you can point with your finger and tell me: see, thats your problem, not the deltaTime

 

Yes

 

It is very difficult to get Unity to run smoothly. If you have an eye able to see stutters and hitches, you're going to see them.

Each fortnightly build of Unity will have different variations, often, of things that trigger this, in different ways.

For some reason it's not good with time. There's so many settings and foibles that can cause this that it's almost impossible to diagnose over the internet.

It's to the point where I would just tend to say "keep working, but don't do graphics or effects" do all that last, as you'll need to spend an inordinate amount of time compromising between your vision and what any given version of Unity is willing to run smoothly.

ESPECIALLY if you're using any kinds of motion blur and other post processing, cinemaccine, physics and flight controllers. If you've got some custom shaders, too... you're in for a lot of fun.