Time.deltaTime Not Constant: VSync CameraFollow and Jitter

you may be looking at old ideas we were spitballing when figuring this thing out. that's not really how my solution works, i only quantize framerates when they are within a narrow band. as soon as framerate becomes variable, delta times are out of range and i revert to good old jittery unity. but that's just my solution, i am sure others can find a better way.

the _real_ fix would be for unity to fix their @#()*$ clock when vsync is on.

 

Frosted is just a troll... best to ignore him. Every post he makes is combative and filled with incorrect information. If you read this Frosted please just unsubscribe from this thread. In this one post you have 2 pieces of incorrect information.
1: The garbage collection had no effect on stutter. I toggled it on/off and it had no effect on the jitter. Test it yourself before drawing conclusions.
2: You say problems are most likely user code. However, the problem can be created by having no user code (i.e. a blank new project with a rigidbody block moving at constant velocity). I'm completely unsure how you jumped to this conclusion... other than your argumentative condescending attitude where you constantly demean and attack people.

Please leave this thread.

 

Done. I'll delete my recent responses.

Good luck.

 

XR: Fixed bject jittering owhen position is being affected by Time.deltaTime. (1157271, 1172058)


https://unity3d.com/unity/whats-new/2019.1.13

 

Anyone try the 2019.1.13 patch? It says xr in the patch notes so im curious if it still happens for your non vr projects?

 

I don't think it's the same issue as the issue tracker says it is not a problem in Umity 2018.x or earlier.

 

hmm i was seeing it everywhere, in vr projects from 2017 . worth a try i suppose?

 

^
i briefly tried 2019.1.13f1, PC only. perhaps I missed a setting somewhere, but Time.unscaledDeltaTime and Time.deltaTime still fluctuated when vsync is on.

However, it felt pretty smooth and according to the graphs of the small sample of data, the range of fluctuation appears to be reduced when compared to the older 2019.2.0f1. this observation could be horseshit, as i did not run the tests for very long or study the data very hard.

 

that "jitter fix" is also in 2019.2.1f1. Same behaviour as 2019.1.13f1 in terms of Time.unscaledDeltaTime and Time.deltaTime still fluctuating when vsync is engaged and not under load. however, it also includes the android frame time optimization switch.

once again it _seems_ like the range of fluctuation is reduced. at the very least, this may help my displayRefreshRate calculations for quantization.

 

Is there a note for this or could this just be a side effect of maybe something else changing and not an actual fix addressing the root problem?

 

all i have to go from is this:

https://unity3d.com/unity/whats-new/2019.2.1

XR: Fix issue with Depth Based LSR on HoloLens V2 that caused significant jitter. (1169760, 1169761)

which is a _different_ jitter fix, and not the deltaTime fix that claims to be in 2019.1.13f1. sorry for the fake news re: 2019.2.1f1.

 

We are using something that sounds similar to herb_nice's fix and it has helped us to reduce jitter to some degree.
We try to run at a consistent multiple of the VSync, usually either 30 or 60 but in some cases 75, 37.5, 59, etc.
We do almost all movement in FixedUpdate
We set Time.fixedDeltaTime to be a fixed fraction of VSync (i.e. 60, 30, etc.) depending on performance. We err on the side of caution. I.e. when things get ugly we stay at 30 until we are sure that we can run at 60 smoothly.
Changing fixedDeltaTime makes physics non-deterministic and potentially unstable, so we design everything to be stable at 20hz simulation rate and design assuming that physics might be slightly different depending on the situation and hardware that the end-user is running on. (in practice it is not different enough to notice, and all solutions that I know of to keep things deterministic for end users with different refresh rates at not agreeable to us.)
If we are doing really badly and we cannot hold 20hz we double or triple step the simulation similar to the default behavior for Unity.
The oddest thing that confuses most first time Unity users is that Unity sets a default FixedDeltaTime to 1/50 seconds.

 

@Zullar Thanks for all your posts. Does anyone know if unity does resolve the jitter.

 

I haven't done any testing in a long time so I'm unsure if any of the latest patches improved the issue. I am also curious if anybody has measured any differences/improvements in the last year or have seen anything in the patch notes/roadmap indicating the issue is being worked.

 

I came across this discussion and try to understand the topic because i have issues following a cross scene referenced rigid body target with an camera who is moved by edy s vehicle physics pro without micro jittering.
Camera jitters around 1mm when you focus steering wheel details on close up but it makes me real mad.

However i still at the very beginning of understanding but these are my best test results after following these thread and after combining it with lessons learned before.
Special Thanks to @Zullar and @Edy

Unity 2019.3.0f5

These settings allow around 0.6% variation in a build for my target resolution.

• activated Incremental Garbage Collection in Player settings
• disabled VSync per script
• forced Framerate to 60 per script

and these command line parameters

• -popupwindow
• -screen-fullscreen 1
  
• -single-instance
  
• -window-mode exclusive

all other negated settings and permutations deliver much more worse results.

I also have

• GSync enabled in driver on a GSynced monitor

but this should do nothing for now.
According to this
https://github.com/Unity-Technologies/GenLockProofOfConcept/blob/master/Assets/GenLockedRecorder.cs
i try to implement the external NVidia GSync now.
Don t know if it does anything better but lets test.

here my start.bat

start /D .\TheBigJitter_IGC_VSync_dis_FRR TheBigJitter_Unity_2019_3_0f5.exe -screen-fullscreen 1 -popupwindow -screen-width 3840 -screen-height 1440 -monitor 1 -screen-quality Fantastic -window-mode exclusive -single-instance

Code (CSharp):

1. using UnityEngine;
2. using System.Collections.Generic;
3.  
4. public class TheBigJitter : MonoBehaviour
5. {
6.     private List<float> listDeltaTime = new List<float>();
7.     private const int pixelWidth = 256; //for texture2D
8.     private const int pixelHeight = 128; //for texture2D
9.     private Texture2D texture2D;
10.     private const float deltaTimeMax = 0.05f; //for texture2D
11.     private static readonly Color colorDarkGrey = new Color(0.3f, 0.3f, 0.3f);
12.     private void Awake()
13.     {
14.         DontDestroyOnLoad(gameObject);
15.         for (int i = 0; i < pixelWidth; i++)
16.         {
17.             listDeltaTime.Add(0.01f);
18.         }
19.         texture2D = new Texture2D(pixelWidth, pixelHeight);
20.         texture2D.filterMode = FilterMode.Point;
21.     }
22.     private void Update()
23.     {
24.         listDeltaTime.RemoveAt(0);
25.         listDeltaTime.Add(Time.deltaTime);
26.         RefreshTexture2D();
27.     }
28.  
29.     private bool toggleGC = false;
30.  
31.     private void OnGUI()
32.     {
33.         float deltaTimeAve = Average(listDeltaTime);
34.         float deltaTimeMin = Mathf.Min(listDeltaTime.ToArray());
35.         float deltaTimeMax = Mathf.Max(listDeltaTime.ToArray());
36.         GUI.Label(new Rect(10f, 10f, 200f, 20f), "DeltaTime (Average) = " + (deltaTimeAve * 1000f).ToString("0.000") + "ms");
37.         GUI.Label(new Rect(10f, 30, 200f, 20f), "FrameRate (Average) = " + (1f / deltaTimeAve).ToString("0"));
38.         GUI.Label(new Rect(10f, 50, 200f, 20f), "Time.deltaTime = " + (Time.deltaTime * 1000f).ToString("0.000") + "ms");
39.         GUI.Label(new Rect(10f, 70f, 200f, 20f), "deltaTimeMin = " + (deltaTimeMin * 1000f).ToString("0.000") + "ms");
40.         GUI.Label(new Rect(10f, 90f, 200f, 20f), "deltaTimeMax = " + (deltaTimeMax * 1000f).ToString("0.000") + "ms");
41.         GUI.Label(new Rect(10f, 110f, 200f, 20f), "% Variation = " + ((deltaTimeMax / deltaTimeMin - 1f) * 100f).ToString("0.0") + "%");
42.         GUI.DrawTexture(new Rect(0f, 200, Screen.width, texture2D.height * 2), texture2D);
43.  
44.         toggleGC = GUI.Toggle(new Rect(10, 130, 200, 20), toggleGC, "ToggleGC: " + toggleGC);
45.     }
46.  
47.     Color[] pixels = new Color[pixelWidth * pixelHeight];
48.  
49.     private void RefreshTexture2D()
50.     {
51.         if (toggleGC == true)
52.         {
53.             pixels = texture2D.GetPixels(); //This generates 0.5MB of garbage
54.         }
55.  
56.         for (int i = 0; i < pixels.Length; i++)
57.         {
58.             pixels[i] = Color.black;
59.         }
60.         texture2D.SetPixels(pixels);
61.         float deltaTimeMin = Mathf.Min(listDeltaTime.ToArray());
62.         float deltaTimeMax = Mathf.Max(listDeltaTime.ToArray());
63.         int yMin = GetY(deltaTimeMin);
64.         int yMax = GetY(deltaTimeMax);
65.         for (int i = 0; i < pixelWidth; i++)
66.         {
67.             texture2D.SetPixel(i, yMin, colorDarkGrey);
68.             texture2D.SetPixel(i, yMax, colorDarkGrey);
69.         }
70.         for (int i = 0; i < pixelWidth; i++)
71.         {
72.             int y = GetY(listDeltaTime[i]);
73.             texture2D.SetPixel(i, y, Color.white);
74.         }
75.         texture2D.Apply(false);
76.     }
77.     private static int GetY(float deltaTimeIn)
78.     {
79.         return Mathf.Clamp(Mathf.RoundToInt(deltaTimeIn / deltaTimeMax * pixelHeight), 0, pixelHeight - 1);
80.     }
81.     private static float Average(List<float> listFloatIn)
82.     {
83.         float average = 0f;
84.         for (int i = 0; i < listFloatIn.Count; i++)
85.         {
86.             average += listFloatIn[i];
87.         }
88.         average = average / listFloatIn.Count;
89.         return average;
90.     }
91. }

Code (CSharp):

1. using System.Collections;
2. using System.Threading;
3. using UnityEngine;
4.  
5. public class ForceRenderRate : MonoBehaviour
6. {
7.     public float Rate = 60.0f;
8.     float currentFrameTime;
9.  
10.     void Start()
11.     {
12.         QualitySettings.vSyncCount = 0;
13.         Application.targetFrameRate = 9999;
14.         currentFrameTime = Time.realtimeSinceStartup;
15.         StartCoroutine("WaitForNextFrame");
16.     }
17.  
18.     IEnumerator WaitForNextFrame()
19.     {
20.         while (true)
21.         {
22.             yield return new WaitForEndOfFrame();
23.             currentFrameTime += 1.0f / Rate;
24.             var t = Time.realtimeSinceStartup;
25.             var sleepTime = currentFrameTime - t - 0.01f;
26.             if (sleepTime > 0)
27.                 Thread.Sleep((int)(sleepTime * 1000));
28.             while (t < currentFrameTime)
29.                 t = Time.realtimeSinceStartup;
30.         }
31.     }
32. }

The only thing i cannot understand is why noone from the Unity devs participated on this discussion after the inital help from @Dave-Hampson
@oliverschnabel . Is there any help or further insights for noJitterperDefault possible?

 

Did some further testing with multiple applications on two and more monitors whats my default setup.

So with these settings it is the first time that i can run the CID, UI and FPK.exe on monitor 2 with application focus by
having a solid behaviour in TheBigJitter_Unity_2019_3_0f5.exe on monitor 1.

Thats everything i needed for the first step.

 

Is this the same issue ? A heartbeat stutter ? I cant find any solution and days are passing....

Is there any solution ? I tried already most of the stuff posted here.

Code (CSharp):

1.  
2.         Application.targetFrameRate = 60;
3.  
4.         QualitySettings.maxQueuedFrames = 1;
5.         QualitySettings.vSyncCount = 0;
6.  
7.         Time.captureFramerate = Screen.currentResolution.refreshRate;

 

the only solution that worked for me is described earlier in this thread- it involved using as few unity systems as possible that use deltaTime internally, getting rid of fixed update entirely, and then using vsync and calculating my own quantized deltaTime based on the display interval of the device.

this solution will not work for everyone. the real solution would be for unity to fix their clock to be constant when vsync is working, but as noted they do not even acknowledge that this is an issue.

 

@Dave-Hampson any updates?

 

I managed to get rid of this using an interpolated rigidbody and setting the framerate to -1, also i have vsync enabled now and it runs butterly smooth.

 

Hi everyone. I just started a new project using 2019.3.0f5. I added in some terrain, and a model ship.

I added some code to get the plane moving:

Code (CSharp):

1.  
2.         Vector3 newPosition = transform.position + transform.forward * Time.deltaTime * 100.0f;
3.         transform.position = Vector3.Lerp(transform.position, newPosition, 1);

But now I am getting the following jittery result:

Does anyone know what's going on here based on my code?


EDIT:

Code (CSharp):

1. Application.targetFrameRate = 60;
2.         QualitySettings.maxQueuedFrames = 1;
3.         QualitySettings.vSyncCount = 0;
4.         Time.captureFramerate = Screen.currentResolution.refreshRate;

Adding this to an empty game object fixed it. Thank you!

 

^ this will work, but there are some comprimises-

you have vsync disabled, which can cause tearing on some systems.

you are using Time.captureFrameRate, which will force Unity to render and simulate every frame, which will cause slowdown instead of dropping frames if you can not simulate/render faster than display refresh. but! it does force unity to use a constant unscaledDeltaTime internally which is a big win in the fight vs jitter. some games (like, say downwell) lean towards slowdown method rather than dropping frames, so this is really a question of preference...

 

As far as I understand, this problem is still not resolved properly for the last three years?

 

Thanks.

 

I tried to bring more attention to this thread and issue internally about a month ago. I'm happy to say that this has been taken up and serious work has been done in addressing this to get a much more stable deltaTime (when vsync is on and not missed).

The issue has to be fixed separately per platform, and this has been done for several platforms already - and more are planned as far as I understand. I'll let the developers working on it fill in the details; it's really to their credit that something is finally happening with this now.

 

This is great news, but this is not only a problem with vsync enabled, it happens with it disabled too.

The whole of unity seems to jolt/stutter, with varying delta times, and they give intresting results. as example we build a client in release mode with a "turn table" which literally is nothing more than updating a gameobject's rotation every frame with a rotation * deltatime.
It randomly stutters.. whilst FPS was solid 60 FPS or higher.
Look at the stuttering here:

You will notice on the moments it stuttering other things are not lagging (like the dynamic shadows)
This is purely because of weird deltatime results.

We overcome it (a little bit) by making a "smoothed" delta time, ie, we take the last 3 deltatime values and take the average of that to influence the rotation of our turntable.
Results are better, but some jolts are still visible, note here that the fire/grass moves fine whilst the pack sometimes jolts.

These problems are less visible in normal game setting, where we influence the objects rotations/positions with delta times. because in a game a lot is happening, but it still happens and it's distracting.

I don't have high hopes on a fix personally, things at unity are moving in dots heaven and current projects that use the build-in render pipeline and monobehaviour are left behind.

But it's nice to see you guys are doing something at least.

 

Does this affect SRP also ?

If you use this code in start, does anything change?

Code (CSharp):

1. void Start()
2.     {
3.         // Sync framerate to monitors refresh rate
4.         QualitySettings.vSyncCount = 1;
5.     }

 

Time.deltaTime is determined based on VSync settings so hopefully these changes should fix your jitter caused by Time.deltaTime variation. *crosses fingers*

 

I meant, it is also jittery and variable mess with vsync disabled. causing stutter, jitter, lag.

See my samples in video above.

 

My understanding is that with VSync disabled the loop will Update as quickly as possible. With VSync disabled Time.deltaTime will usually be small and vary significantly depending on loading (how long it takes to complete the loop + external loading). I believe the large Time.deltaTime variation with VSync disabled is expected.

Most of this thread discusses the case with VSync enabled where Time.deltaTime *should* be constant and match monitor refresh rate (assuming no dropped frames).

 

Yes. Naturally the value should vary without vsync. But something is incorrect. The values are not the actual frame time. This is causing the problem proposed above.
Things hang then jump.

 

Please have it backported once it is stable to 2018.4 LTS and the opcomming 2019.4 LTS. This stuff is vital for many production games. Including mine.

 

Could you confirm if the issue you are tracking and fixing internally is specifically related to VSYNC? As some users have mentioned they seem to be experiencing this issue with VSYNC disabled.

Could you also confirm which platforms this is an issue for? As you mentioned Windows D3D11 and Mac Metal fixes are being tested/underway. What about Android OpenGL2/3/3.1/3.2/Vulkan, and iOS Opengl2/3/Metal?

I just want to make sure us (The community) is on the same page as you (Unity) when it comes to tracking this issue.

 

Just get it working on Windows DX11 for 2019.4 LTS.
That is where all the desktop games are sold anyway.

No real company is going to pick up a non LTS version, it is simply shooting yourself in the foot.
It's troublesome enough how unstable 2018.4LTS is. today.. a year after release.

I would love to test your changes that you added in 2020.2 Alpha. but I can sadly not import my 200 GB project in the latest alpha. too many incompatible things, amongst them some assets, but mostly own code. so for now I'm going to trust others to comment on this.

 

You have to understand the distribution model and promises unity makes to us devs. There will not be new features to old versions, especially not to LTS. 2018 and 2019 feature sets are already locked, there's nothing new coming to either anymore, only bugfixes and SDK updates.

The thing fixed here is a thing that could potentially introduce more bugs and issues and rolling such thing to LTS.. I mean really, you need to understand that this is the type of action which LTS releases were introduced to prevent. While everyone would want their favorite new thing to be included on LTS, imagine how that would go if everyone got their way on that? (and yes, everyone feels that THEIR favorite feature is the only thing needs to get included as it's super important).

LTS is there to give Unity stability for longer duration of time, not to potentially break the backwards compatibility.

I'm just personally super happy they are finally addressing this on 2020 cycle Also considering they have only rolled this out for DX11, it's very likely that more featured platform support is available only when 2020 cycle is done anyway, if even then.

PS. I know someone is going to argue that this is a bug fix and not feature addition but I trust the dev on this when it's mentioned it's such big scale change that it could break a lot of things - which LTS releases absolutely can't do.

 

This is a bug. present for ages. and never fixed. This is a serious bug. NOT A FEATURE. Bugs should be fixed in an LTS!
People make professional games that are dependant on stable frame-rate, and stable connection between screen HZ and game frames.

I know it's a lot to ask, because we are on 2018.4 LTS with our project, and Bugs that get reported and fixed, get fixed in 2020.2 Alpha, and never backported to 2018.4 LTS.. It's just.. I cannot even.

Stability for longer time? fun topic... Try to make a real game in Unity, It is PAIN.

With my team recently we discussed that probably 40% of the time we are building workarounds because Unity is not up for the job. This sentiment is shared amongst other game developers I am in contact with in the industry.

 

While I share some of your pain, I agree this bug is not the one to backport to the previous LTS.

If some basic fixes sometimes cause major issues somewhere along, just imagine how bad fckup on this one can be.
If the main clock breaks on some untested device and / or platform that would be a disaster that cannot be fixed by your team.

Wait for the 2020 LTS, bite the bullet and use 2020 as it is, or don't port it over to the next version at all.
Or, just use stable 2020.x once its officially released.

LTS doesn't mean there will be no bugs.
LTS just means there wll be less changes that cause those.

 

Yet you want Unity bring largely untested feat (meaning, only tested by Unity QA) that's now only landed on one alpha for only one platform into existing LTS, making it potentially more unstable?

Once the potential kinks of this change have been ironed out the chances are that we are already at 2020 LTS and 2018 LTS support is dropped by then anyway so you'd be out of luck regardless.

I can totally understand the frustration. If you've read this thread through you can see my comments and test results (I tested this issue having been around even on Unity 3.x), I can totally understand that people are eager to see the fix.

So far nobody complaining here about this has actually tested the change and seen it improve things on their use cases (or at least tested and reported it here). Chances are it will not even affect your game in ways you are hoping it to do. I'm currently building a test rig for one case where I know more stable delta times would help me and will report my finding here once I'm done, not expecting miracles here but I'll welcome any improvements on this

 

Is this fix in for VR as well? im so shocked to wake up this morning and see this . great news. im seeing in index, (steamvr) and latest oculus sdk on rift, quest, ect.

 

I suspect it will be that it will not be backported because it touches too much surface area - much like a new feature would.

It doesn't matter that Unity's said that "features will not be backported", it matters that backporting would likely take far longer than you expect. Because one cannot backport something that is not yet proven to be stable. 2020.2 will have to be released before a backport could even be considered because it's not a bug fix where the existing codebase is the same, instead it is an invasive change.

This is why it is actually the wrong decision to backport.

(and I hope this will benefit VR too!)

 

hurray! its really noticeable, thanks for taking this seriously!

 

Is there a bug report page where we can track the status of this issue for all the various platforms that are effected?

 

what is the current dx11 fix listed as? i cannot find it in the release notes.