Search Unity

  1. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Time.deltaTime Not Constant: VSync CameraFollow and Jitter

Discussion in 'General Graphics' started by Zullar, Sep 9, 2016.

  1. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    @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.
     
    Last edited: Jul 26, 2022
    sirleto likes this.
  2. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    The fix was to take delta time values as reported by the graphics driver, instead of measuring the time ourselves. That significantly improved its stability. However, the behaviour in the editor was not changed, as it has multiple windows that get rendered to separately. The fix did go in for Nintendo Switch.

    If you are seeing an issue that happens both in the editor and on Switch, it's unlikely it was caused by this change (because the editor did not receive a fix).

    Now, I don't know why you're getting the jitters. I'd try a few things:

    • Check if the actual frame rate is stable. You can do that by looking at the profiler as it doesn't use Time.deltaTime to display data;
    • If frame rate is stable but you're still getting jitters, try outputting Time.deltaTime values. They should be stable too (as long as the frame rate is solid).
    • If the jittery objects, the camera or anything in their hierarchy have rigid bodies, make sure that interpolation is enabled on them.
     
  3. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    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.
     
  4. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    164
    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.
     
  5. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    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?
     
  6. Vincent454

    Vincent454

    Joined:
    Oct 26, 2014
    Posts:
    164
    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
     
    xVergilx likes this.
  7. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    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.
     
    Last edited: Jul 26, 2022
    MartinTilo likes this.
  8. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    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.
     
  9. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    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.
     
  10. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    Time.deltaTime wasn't the only thing that changed in 2020.2: https://unity3d.com/unity/whats-new/2020.2.0

    Anyway, I don't know if the stuttering you're seeing has anything do to with Time.deltaTime changes. Furthermore, it's not clear if the issue you're seeing in the editor is even the same issue you're seeing on Switch. I'd suggest posting on Nintendo development forum about this because console development details cannot be discussed here.
     
  11. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    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.
     
  12. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    If that's the case, then taking this to Switch forum is still recommended. Time.deltaTime implementation is highly platform specific. The code that calculates it on Windows is completely separate from the code that does it on Switch.
     
    tatoforever likes this.
  13. tatoforever

    tatoforever

    Joined:
    Apr 16, 2009
    Posts:
    4,361
    Thanks,
    I did that, let's see what they respond.
     
  14. RetroMasters82

    RetroMasters82

    Joined:
    Nov 3, 2021
    Posts:
    27
    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.
     
    Last edited: Aug 25, 2022
    tatoforever likes this.
  15. RetroMasters82

    RetroMasters82

    Joined:
    Nov 3, 2021
    Posts:
    27
    @ 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.
     
    Last edited: Aug 28, 2022
    Andy608, glenneroo, jvo3dc and 2 others like this.
  16. sirleto

    sirleto

    Joined:
    Sep 9, 2019
    Posts:
    135
    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 :-(
     
    Unifikation likes this.
  17. hellstorm

    hellstorm

    Joined:
    Jun 29, 2015
    Posts:
    41
    ScottJustScott likes this.
  18. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    I'll ask our VR team.
     
    DevDunk and ScottJustScott like this.
  19. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    399
    When we first investigated fixing this for VR, the native VR SDKs didn't give us the proper timing information we needed. OpenXR solves this and by now most vendors have moved to using it. We have a prototype that enables driving the simulation with the timing information coming from OpenXR, but some runtimes were behaving badly in this mode which halted our release. We reported these issues some time ago - we'll follow up and re-evaluate to see if things are better across runtimes (now that things have matured a bit more in the OpenXR space) so we can move this forward.
     
    hellstorm, GameFinder, Edy and 2 others like this.
  20. hellstorm

    hellstorm

    Joined:
    Jun 29, 2015
    Posts:
    41
    thanks! is there any info about this yet?
     
  21. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,093
    Unifikation likes this.
  22. sirleto

    sirleto

    Joined:
    Sep 9, 2019
    Posts:
    135
    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?
     
  23. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    It's hard to tell without seeing the code. Is the camera moved in Update()? FixedUpdate()? Does it have a rigidbody on it? Is interpolation enabled on the rigidbody?

    You'd graph Time.deltaTime values as seen in Update() and see if they are multiples of your refresh rate or all over the place.
     
    sirleto likes this.
  24. sirleto

    sirleto

    Joined:
    Sep 9, 2019
    Posts:
    135
    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).
     
  25. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    If your framerate is uneven, even with perfect delta time implementation your eyes will notice some frames taking longer than others, and the hitching that introduces. 8 ms vs 20 ms is a huge difference, it's not going to be easy to hide.

    General scene changes should not cause this, though: when you add stuff to the scene, the frame rate will drop but it's not going to cause the frame times to be 8 ms followed by 20 ms followed by 8 ms. That is either caused by some random expensive work being done and not spread out over multiple frames, or the inability to reach monitor's refresh rate in general, which manifests as missed vsyncs and some frames taking double amount of time. In general, if you're running at a lower frame rate than the refresh rate and don't have a variable refresh rate display, it's common to disable vsync to not be limited to presenting at that boundary.
     
    sirleto likes this.
  26. sirleto

    sirleto

    Joined:
    Sep 9, 2019
    Posts:
    135
    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 :)
     
  27. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    So this issue is only reproducible with VSync off?
     
  28. sirleto

    sirleto

    Joined:
    Sep 9, 2019
    Posts:
    135
  29. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,073
    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.
     
    sirleto likes this.
  30. Andy608

    Andy608

    Joined:
    Jun 17, 2017
    Posts:
    15
    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?
     
    sirleto and Unifikation like this.
  31. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    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.
     
  32. Andy608

    Andy608

    Joined:
    Jun 17, 2017
    Posts:
    15
    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.
     
    Unifikation likes this.
  33. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,073
    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.
     
    kirkgamesllc and sirleto like this.
  34. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    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).
     
    Last edited: Jun 18, 2023
    SonicBloomEric and sirleto like this.
  35. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,073
    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.
     
  36. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    3,296
    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.
     
    Last edited: Jun 19, 2023
    Edy likes this.
  37. Unifikation

    Unifikation

    Joined:
    Jan 4, 2023
    Posts:
    1,073
    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.
     
  38. Tautvydas-Zilys

    Tautvydas-Zilys

    Unity Technologies

    Joined:
    Jul 25, 2013
    Posts:
    10,628
    Can you share that project from the video? By the way, the delta time fix does not apply to the editor. So you have to test a built game. You mentioned that it happens in a built game so there may still be issues, but your videos are from the editor.

    I tried reproducing it in a built project on Windows using your script but I was unable to on 2021.3 and 2022.3. There was one stutter at startup just as Nvidia GeForce Experience banner pops up, but that is caused by frame taking longer to render rather than Time.deltaTime inaccuracy. I've attached the project I made to this post so you could test it on your end.

    All interpolation does is makes the object appear as if it was updated from Update() via Time.deltaTime. It uses the exact same delta time values.

    Not for general case, no. XR is still something we're trying to get to work across vendors.

    If you give me a bug report number where this happened, I can follow up on it.
     

    Attached Files:

    Last edited: Jun 21, 2023
    MartinTilo and Edy like this.
  39. JesOb

    JesOb

    Joined:
    Sep 3, 2012
    Posts:
    1,093
  40. Andy608

    Andy608

    Joined:
    Jun 17, 2017
    Posts:
    15
    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
     
    sirleto likes this.
  41. Markus_Hoetzinger

    Markus_Hoetzinger

    Joined:
    Jan 12, 2023
    Posts:
    3
    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?
     
  42. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    399
    I think this may be an artifact of meta's phase sync - you can try disabling that (although I saw reports that disabling it is broken at the moment - we'll report this to meta as their plugin handles this).

    Looks like the production work for using OpenXR predicted times to drive delta time I mentioned here is scheduled to start next sprint .. will still be some time before it's released.
     
    hellstorm and Edy like this.
  43. Markus_Hoetzinger

    Markus_Hoetzinger

    Joined:
    Jan 12, 2023
    Posts:
    3
    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.
     
  44. hellstorm

    hellstorm

    Joined:
    Jun 29, 2015
    Posts:
    41
    this is the exact same behavior I see in VR , with Time.captureFramerate being the only fix
     
  45. Markus_Hoetzinger

    Markus_Hoetzinger

    Joined:
    Jan 12, 2023
    Posts:
    3
    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?
     
  46. MartinTilo

    MartinTilo

    Unity Technologies

    Joined:
    Aug 16, 2017
    Posts:
    2,406
    I'm not sure if there might be any correlation from this issue to jittering, but the surrounding thread started on the topic of a freeze that seemed related to Optimize Frame Pacing. While the bug that was fixed on 2022.3.14f1 was unrelated to OFP, it might have in general stabilized jobified rendering (also in combination with the changeset which triggered the issue on backporting to 2022.3.3f1).
    Bit of a stab in the dark and I don't have any particular insights beyond that but, maybe there's something there to look out for for you?
     
    sirleto likes this.
  47. reev4eg

    reev4eg

    Joined:
    May 10, 2015
    Posts:
    37
    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!