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.

 

Just spent the last 2+ hours reading this entire thread. I'm saddened this is still an issue that's occurring in Unity after all of these years.

I'm seeing major stutter in the latest LTS version, currently 2022.3.2f1, although I've been fighting this issue in older versions of Unity as well for years now.

• I see stutter while v-sync is enabled.
• I see stutter while v-sync is disabled.
• I see stutter when playing in the editor.
• I see stutter when playing a built game.

I'm sure the Unity engine has a ton of stuff going on under the hood regarding it's engine loop, but I'm still unsure why this is an issue. I've played around with OpenGL and GLFW in the past and have never encountered any stuttering issues like I've experienced with Unity.

If you create an empty scene with just a sphere that oscillates back and forth using a sin wave, you will see the stuttering.

I have uploaded three videos on Youtube that showcases this:

Am I doing something wrong? I don't understand why I've only ever had this problem in Unity. Any help would be appreciated on this subject as I find this issue makes it extremely hard to make any sort of polished game. It's even become a stigma in the gaming community where you can tell when a game has been made in Unity based on the stuttering. I would be over the moon if this to got fixed, it's literally been plaguing the engine for years.

@Tautvydas-Zilys is this still a known issue that Unity is looking into?

 

Post the actual code how you're moving the object. It doesn't look like a deltaTime issue.
Check the profiler as well, might be something running in the background.

 

Hey thanks for the reply @xVergilx. I've tried different variations, but here is the code that uses deltaTime as the incrementor:

Code (CSharp):

1. public class BasicMovementController : MonoBehaviour
2.     {
3.         private Transform _objectTransform;
4.  
5.         private Vector3 _movementVector;
6.  
7.         [SerializeField]
8.         private float _amplitude;
9.  
10.         [SerializeField]
11.         private float _frequency;
12.  
13.         private float _accumulatedTime;
14.  
15.         private void Awake()
16.         {
17.             _objectTransform = transform;
18.         }
19.  
20.         private void Update()
21.         {
22.             _accumulatedTime += Time.deltaTime;
23.             _movementVector.x = Mathf.Sin(_accumulatedTime * _frequency) * _amplitude;
24.             _objectTransform.position = _movementVector;
25.         }
26.     }

Another variation would be to remove _accumulatedTime and just use Time.time inside Mathf.Sin().

I mostly wanted to highlight Time.deltaTime's inconsistency, but I could also be using Mathf.Sin() wrong in this example. I see stuttering when moving objects in other ways when not using Mathf.Sin(), say at a constant rate across the screen.

I was able to get smooth movement by following @RetroMasters82 's thread and moving things in FixedUpdate() + interpolation: https://forum.unity.com/threads/mot...ion-to-eliminate-fixedupdate-stutter.1325943/ but I was hoping there would be a way to get smooth movement out of the box with Unity by just relying on Update() and Time.deltaTime.

 

It's to the point I think it should be upon Unity to demonstrate how to get stutter free, hitch free and smooth movement, in a demo project, just to prove that it's possible, and what all the settings are that achieve it.

 

Try running simulation only on [0..1] range by using Mathf.Repeat, or by other means (so that _accumulatedTime never runs over 1). Sin is not really precise, but rather an approximation. Accumulating values may make it even worse, not to mention issues with float precision when running simulation for too long.

Alternative to using Sin is to use AnimationCurve. Create a custom one and feed values to it (range restrictions still apply). Should be better, more precise and customizable for the designers.

FixedUpdate runs as fixed intervals discarding frame rate and iterating multiple times over and over if it misses. Its never gonna be smooth without some kind of interpolation. Reason why moving Rigidbody by MovePosition is smooth is because of the interpolation (if enabled);

If you're not writing some netcode or physics [via rigidbodies or custom high precision one] - I'd suggest using Update over FixedUpdate for kinematic movement. Or using Rigidbody + Interpolation when running in FixedUpdate.

As for the kinematic one - Vector3/[Mathf].MoveTowards is best when moving something by speed * dT. Vector3/[Mathf].Lerp is best when moving something by duration / percentage (just make sure you're actually running interpolation correctly, https://chicounity3d.wordpress.com/2014/05/23/how-to-lerp-like-a-pro/).
For custom curves - t can be fed from AnimationCurve.

Main reason why most indie projects interpolation sucks is because actual code sucks.
If you see large stutter - there's a user reason for it. Its either interpolation code, camera, or something else (like forgotten Rigidbody attached to the object, editor running in the background, etc).
Execution order also matters more than most of users even know it exists.

deltaTime inconsistencies are really small and near invisible unless you chart it over some graph and running at high fps. Plus, they were fixed (at least, most cases of it were).

 

And yet it's clearly visible the videos shown, and repeatable on any machine. Mac Intel, Mac m2, iPad, iPhone etc.

And as @Andy608 has said, has become known about by players.

Since Andy is using the recommended way to use Update with time based movement, the only explanation is a problem with time reporting and/or timing of the presentation. I don't think this problem is nearly as fixed as Unity claims. It's still highly visible in particle systems, too.

And even when Unity goes out of the way to show how great their engine is, it shows up. See the video on making Pong with DOTS and the videos promoting their particles in the Asset store, both of which feature these stutters.

 

Submit a minimal repro of it with deltaTime graph charting, device hardware specifications, and specific editor version you think is affected.

Thing is - videos aren't representative. They give 0 information about the reason.
Plus video recording isn't flawless at representing framerate (nor playback is).

Framerate settings and vSync settings differ per project and per platform.
Project settings differ (see as optimized frame pacing).
There are a lot of nuances to the implementation.
Hardware differs.

Personally I haven't seen it being an issue since v2020 LTS for the PC, Android, and IOS.

 

Good for you.

Those of us that do see it have long been doing everything we can to draw attention to its many causes.

We get blown off, at best, even with repros, because the problem is at the route of the game engine's looping and time reporting. Even source access users have submitted quite exacting demonstrations of where the polyrhythms occur.

It took more than a dozen years to solve the time reporting problem that's solved your problems in 2020. It'll probably take as long again to solve these other issues.

 

Hi @Tautvydas-Zilys

Have you know some thing about this input jitter regression from Unity 2021.3.20
https://issuetracker.unity3d.com/is...g-and-restoring-the-app-when-built-on-android

May be some plans to fix it at least for current LTS?

 

Hi @Tautvydas-Zilys,

Thanks for your reply and for providing a demo project! I have loaded that up locally and I do not see any stutter. Unfortunately, I foolishly deleted the project I was using when I first commented on this post. I have just created a blank project and tried recreating the stutter with the same code, and I do not see it anymore. I'm kind of at a loss and not sure why it's gone now. If I continue to see any stutter in the future, I will report back with an appropriate demo project.

Thanks,
Andy

 

We are working with the Meta Quest 2 and Unity 2021.2.17f1.
We get a lot of cases where the deltaTime is twice what it should be, but then in the next frame it's 0. So the average is fine, but there are big hick-ups. Sometimes there is an occasional hick-up once in a while, sometimes you enter a phase were hick-ups happen repeatedly in short intervals.

There are definitely no real frame drops. I can fix the problem by overriding the deltaTime using Time.captureFramerate. I set it to 12.5 ms (1/80) and the simulation becomes smooth. Of course this "fix" causes problems once you get real frame drops. Then the simulation goes slow motion.

Can this behavior be explained by the VR deltaTime problems described in this thread, or is this a different kind of problem?

 

Phase sync is already disabled. I verified that it's disabled with this command:

adb logcat -s VrApi

It shows that the LAT value is 1, which means extra latency mode is enabled and phase sync is off.

 

this is the exact same behavior I see in VR , with Time.captureFramerate being the only fix

 

Short update: the frames with deltaTime=0 I mentioned above disappeared since we switched to a newer Unity version (2022.3.8f1). It's still not ideal. The deltaTime is constantly fluctuating. We are running the Quest headset at 80Hz. The deltaTime should be a constant 12.5ms (except for when frame drops happen). There is constant jitter in the motions of objects because of the jittering frame time. Overriding with Time.captureFramerate is the only way to make it smooth. Why can't the deltaTime just be 12.5ms constantly?

 

Hello all,

We encountered the same problem on Switch after updating our game, ATOM RPG, from Unity 2019 to 2021.3.32f1. The profiler shows unstable FPS (40-50) during camera movement, causing jittering for the eyes. For now, I want to try using smooth delta for our camera. Does anyone have a solution for the Switch?

Thanks!