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.