Search Unity

  1. Unity 2019.2 is now released.
    Dismiss Notice

Time.deltaTime Not Constant: VSync CameraFollow and Jitter

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

  1. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    542
    So, jitter occurs because of different timings between CPU and GPU, and the current implementation doesn't take that into account, therefore the appropriate API is not used there. So my question is, why Unity 4 doesn't suffer this problem?
     
    sledgeman likes this.
  2. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    No, that's not the cause.
     
  3. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    Edy is correct.

    A clock cannot predict how long it will take to simulate and render and wait for vsync for the NEXT frame- which is the duration you need to simulate if you want to avoid jitter. Even the most accurate clock in the world can only tell you how long it took to produce a PREVIOUS frame.

    Refresh rate is fairly constant on most displays. If you are synchronized to vertical refresh (
    QualitySettings.vSyncCount > 0), then Time.unscaledDeltaTime should be quantized to a multiple of your display's refresh rate. Otherwise jitter will happen. With vsync, if you use the ANY clock instead of quantizing, you will get jitter.
     
    nxrighthere, Edy and Zullar like this.
  4. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    I believe this is incorrect.

    Test it yourself. Ever other update do something during Update() that chews up lets say 5ms of CPU time. You will see that this will not affect Time.deltaTime or jitter in any way!

    Excluding high loading where you drop frames the variability of time spent in the Update loop does not seem to matter!!! The source of Time.deltaTime variation & jitter appears to be something else.

    Here's some code if you want to prove it to yourself. This code will generate additional loading every other frame
    Frame1: 5ms additional Update loading
    Frame2: 0ms additional Update loading
    Frame3: 5ms additional Update loading
    Frame4: 0ms additional Update loading
    Frame5: 5ms additional Update loading
    Frame6: 0ms additional Update loading
    ...and so on.

    And it has no effect on Time.deltaTime or framerate jitter (Unless you really crank up the loading and cause dropped frames).

    Code (csharp):
    1.  
    2. public class EveryOtherFrameLoad : MonoBehaviour
    3. {
    4.     private const int counter = 2000000; //Adjust this number to cause a ~5ms loading every other frame
    5.     private bool frameToggle;
    6.     float timeElapsed;
    7.  
    8.     void Update()
    9.     {
    10.         frameToggle = !frameToggle;
    11.         if(frameToggle == true)
    12.         {
    13.             float timeStart = Time.realtimeSinceStartup;
    14.             for(int i = 0; i < counter; i++)
    15.             {
    16.  
    17.             }
    18.             float timeStop = Time.realtimeSinceStartup;
    19.             timeElapsed = (timeStop - timeStart)*1000f;
    20.         }
    21.     }
    22.  
    23.     private void OnGUI()
    24.     {
    25.         GUI.Label(new Rect(400, 10, 200, 30), "ToggleTime: " + timeElapsed.ToString("0.00") + "ms");
    26.     }
    27. }
    28.  
    29.  
     
    Last edited: Feb 1, 2019
  5. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    I suppose rewinding and explaining the cause of jitter may help some.

    At 60hz refresh rate, you are essentially strobing an image to the display every 16ms. This rate is constant. Nothing you do will change that rate.

    If you are simulating a fluctuating duration other than 16ms- there will be visible jitter as things will move a little too far or not far enough every frame.

    If it takes you longer than 16ms to produce an image, you will drop a frame if vsync is engaged, or worse, tear if is not.

    Your best bet to keep things smooth and buttery are to synchronize to the display's refresh rate and simulate accordingly.
     
    nxrighthere, Edy and Zullar like this.
  6. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    (Quoting myself)
    "there's an actual variability in the time spent in each Update cycle, which directly translates to variability in the Time.deltaTime values, causing the stutter."

    I know it's difficult to understand the problem ("heartbeat stutter" is the name), so I'll do my best to explain how all these observations fit in it.

    With "the time spent in each Update cycle" I mean everything Unity does from an Update to another. You're measuring that time in the Update method of the script.

    With vSync disabled you'll see those 5ms fluctuating every other frame, together with all other fluctuating Unity stuff.

    With vSync enabled "the time spent in each Update" includes the time Unity waits for the GPU to be ready to accept new frames. Those extra 5ms don't make a difference because Unity still has to wait for the GPU within that Update cycle.

    In some systems/drivers/settings the GPU accepts frames in sync (or acceptable sync) with the monitor's frame rate. These systems don't have the stutter problem as the time between each Update remains mostly coupled with the frame rate.

    But in other systems/drivers/settings there's a huge variability in the time Unity waits to for the GPU to be ready. The GPU is also queried in a different time every frame depending on Unity's internal stuff. The GPU may also be in different states when it's queried. All that results in the GPU accepting new frames at varying times in these cases. So the time spent in each Update cycle fluctuates hugely, as we've observed.

    And even then, you may only measure how time it took to produce the frame. But there’s no way to know for sure when that frame is actually displayed on the screen.

    Well, not necessarily. There may be a triple buffer, there may be one or two frames already queued... so the GPU may actually display a correct frame in that refresh cycle, then quickly request a new frame when you're finished with the previous one. THIS is what causes the heartbeat stutter.

    In the picture below there's an Update cycle that took 30ms, immediately followed by another one that took 6ms. However, there's not a single frame dropped in this sequence. But as Time.deltaTime is the time between Update cycles, then everything stutters.

    upload_2019-2-2_13-12-49.png

    Correct.

    An easy way to remove the stutter in Unity is forcing vSync in the display settings (not only in Unity), then setting Time.captureFrameRate = Screen.currentResolution.refreshRate in some script. This forces Time.deltaTime to be 1/refreshRate every frame. Also collapse the Transform component in the Inspector (continuously updating inspectors do drop frames for some reason)

    Forcing vSync in the display settings is necessary as Time.captureFrameRate disables vSync in some systems. Opening the Unity Editor in OpenGL mode also works (vSync seems already forced in OpenGL).

    Setting Time.captureFrameRate is not a generic solution and causes other issues, but it's a step in demonstrating the nature of the problem and the challenges for resolving it.
     
    Last edited: Feb 6, 2019
    gresolio, nxrighthere and herb_nice like this.
  7. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    this may be true. personally i try to avoid triple buffering as I am oldschool and prefer to minimize the latency between inputs and response on screen...
     
    Edy and Zullar like this.
  8. nxrighthere

    nxrighthere

    Joined:
    Mar 2, 2014
    Posts:
    542
    @Edy Thanks, now I see... Funny, I've never noticed this artifact in other engines and games that I'm playing, usually they running at constant 60-70 FPS (I'm adapting settings to this framerate), but I clearly see this jitter in Unity where scenes are running at 120+ especially when transform positions are interpolated with lerp using time deltas.
     
    Edy likes this.
  9. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    Surely they're locking the frame's time to the actual frame rate and use some quantizing algorithm to detect dropped frames. But the highly fluctuating values of Time.deltaTime in Unity makes everything stutter in some cases. This is why I propose a way to override Time.deltaTime as a helpful tool for the community to find solutions for each specific case.
     
    Last edited: Feb 2, 2019
    zyzyx, herb_nice and nxrighthere like this.
  10. Obsurveyor

    Obsurveyor

    Joined:
    Nov 22, 2012
    Posts:
    276
    Is this only in editor or builds too?
     
  11. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    I've tested that to happen in Windows Editor with DX11. I haven't tested on builds. Note that you may also launch builds in OpenGL Mode (-force-glcore), so this should force vSync on builds too.

    EDIT: Builds exhibit the same issue.
     
    Last edited: Feb 7, 2019
  12. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    Zullar likes this.
  13. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    those poor guys have to battle a lot of jittery stutter deniers
     
    Xarbrough, Prodigga, tommox86 and 3 others like this.
  14. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    some notes that may help others on this quest

    QualitySettings.maxQueuedFrames = 1; // disable triple buffering for less laggy input and less laggy frame duration correction

    also we have been experimenting with a hard quantization method where delta time is quantized to multiples of refresh rate only- when a frame takes too long we emulate dropping a frame like days of yore instead of breaking quantization. gamespeed does drift slightly when this happens, but the constant shutter interval makes things have a very nice retro feel.
     
    Zullar, nxrighthere and Edy like this.
  15. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,186
    I noticed that Unity closed the ticket for this. I hope they'll address this eventually but it's not looking good.
     
  16. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    Which ticket was closed?
     
  17. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,186
    977641, I believe it was yours?
     
  18. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    they closed the bug without fixing anything. not surprised.
     
    Last edited: Feb 20, 2019
  19. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    Ah they said they closed the 977641 bug ticket because they consider it a feature request, not a bug.

    So all is well. They are still working on it.
     
  20. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    i didn't see anything about this in the roadmap.... don't give up on your hacky workarounds yet.
     
  21. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,797
    Sadly still a problem invoking heated debate on unity's official discord. @rizu was unable to see any stuttering from UE4 and they use the same vsync code unity does.

    Thoughts?

    Says who :p
     
  22. rizu

    rizu

    Joined:
    Oct 8, 2013
    Posts:
    1,186
    Small correction here, I meant they use similar method of calculating deltatime itself, their vsync implementation could be very different for all I know (and I actually suspect the reason why Unity suffers from this jitter and UE4 does not comes from the rendering/vsync implementation differences).
     
  23. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    The vsync code doesn't really matter. It's the value you feed Time.deltaTime with what makes the difference.

    Even with vsync enabled the GPU accepts frames at different rates in different systems. In some systems there's a huge variability in the time the GPU accepts each frame. Unity feeds Time.deltaTime with this value, so this variability makes everything stutter. If you could fin a way in which the rendering rate matches the vsync rate in every system, that would also resolve the issue. Maybe UE figured that out somehow. Otherwise, you should review the way you compute Time.deltaTime.

    Forcing Time.deltaTime to be 1 / refreshRate removes all the stuttering in Unity, as I've demonstrated above (bottom of the post). However, it's not a generic solution because causes other issues (i.e. no adaptation to dropped frames) that must be addressed at Unity's side.

    While, as suggested by Unity team, using Time.smoothDeltaTime may also work, the problem is that all internal Unity systems use Time.deltaTime (animation, particles, rigidbody interpolation...). So everything stutters when Time.deltaTime varies so much in each frame.

    Some solutions I can think of:
    • An option or API call that makes Time.deltaTime to use the value from Time.smoothDeltaTime, so all internal Unity systems use it.
    • The possibility of setting Time.deltaTime ourselves by scripting (maybe a callback or API hook?). This way we could find and test different solutions, such as setting Time.deltaTime to smoothDeltaTime, 1/refreshRate, or the experimental value of our choice.
    • Ideal solution: Unity computes Time.deltaTime based on refresh rate, then figure out some way to detect dropped frames because the application slowed down, and adjust Time.deltaTime in those situations.
     
  24. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,797
    Your last option would make it Unity's problem to fix - a bug after all, I suppose.

    That butter-smooth DOTS next gen feel would totally be ruined. Performance by default would just not include "butter smooth by default".
     
  25. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    Time.smoothDelta time breaks down when performance gets bad. You want a quantized delta time, not a smoothed delta time.

    Our quantization algorithm is evolving. We're back to a running total, which it does inject a drop frame (2xdelta time) when the difference builds up. If it has to inject 2 drop frames within a window (say 16 frames), quantization is disabled for a small window while performance hopefully recovers. Smoothing over performance burps like these would affect your average delta time, no?
     
    Last edited: Feb 25, 2019
    hippocoder likes this.
  26. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    Ideally, If Unity cannot figure out how to do vsync with deltaTime quantization properly, I would like them to let me replace Time.deltaTime with my own value. But for now I just avoid all systems that use Time.deltaTime internally (particles, animations, timeline, interpolation, extrapolation, etc).
     
  27. BakeMyCake

    BakeMyCake

    Joined:
    May 8, 2017
    Posts:
    126
    Some systems left you've got there :p Might as well make it your own engine so you don't have to pay for the 10% of Unity that you're using.
     
  28. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    I wish there was some way to track the issue. It's a bit scary the 977641 bug ticket was close/cancelled because this is not a "bug" but rather a "feature". However as herb pointed out this "feature" is not on the roadmap. I wish we had visibility to a solution to ensure this issue isn't forgotten about.

    You can vote here to help raise visibility on this Time.deltaTime variability issue.
    https://feedback.unity3d.com/sugges...h-vsync-is-not-constant-causing-visual-jitter

    Not sure what else to do.
     
    herb_nice likes this.
  29. qkjosh

    qkjosh

    Joined:
    Nov 29, 2015
    Posts:
    28
    Not that I have much to add to the great work you've all done investigating this issue, but I thought I'd chime in and say that I'm really hoping Unity takes this seriously and is actively working on a fix. The jitter has bugged me since day one. I've voted on the issue tracker.
     
    herb_nice and Edy like this.
  30. BakeMyCake

    BakeMyCake

    Joined:
    May 8, 2017
    Posts:
    126
    I know this article isn't really addressing the issue described here, but this approach can get you some results:
    http://www.kinematicsoup.com/news/2016/8/9/rrypp5tkubynjwxhxjzd42s3o034o8

    The TLDR is that if it's acceptable for objects to be positioned slightly off, one could introduce a layer of interpolation between the real positions of objects and the visuals displayed and get control over how smooth things are that way. Not a universal solution but if you're completely out of options this could maybe make it less of an issue.
     
  31. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    Yep, there are several workarounds available when implementing the movement in our scripts, but all them are useless when using Unity's systems (animations, rigidbody interpolation, particles, timeline...)
     
  32. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    :[

    Depends how you are moving it. If it's physics based with rigidbody.interpolation then I do not know if there is a way to fix it. However if you are rotating it by using Rotation += RotatationSpeed * Time.deltaTime then you *can* fix it with some work. Instead of using Time.deltaTime you will have to use a smoother delta time value.
     
  33. BakeMyCake

    BakeMyCake

    Joined:
    May 8, 2017
    Posts:
    126
    Are physics involved? If not then you can calculate rotation manually using your own frame delta time. How you would obtain a more consistent frame delta without making things even more inconsistent is the big question.
     
  34. xVergilx

    xVergilx

    Joined:
    Dec 22, 2014
    Posts:
    2,012
    It's been a while since this post:
    But you can actually do that. Actually, Chronos (time control asset) does something similar under the hood.
    - Physics (all physics) timestep can be overriden, and simulated at desired time / rate. (Disabling Auto-Simulate, and calling .Simulate does that);
    - Particle system simulation can be performed manually as well.
    - Animator has rewind / simulation feature.

    In any case, this is really an interesting topic, and I've been monitoring it for a while.
    Just wanted to say that to most people that jitter won't be really visible, yet I agree that it must be fixed at some point.
     
    Zullar likes this.
  35. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    first thing i would suggest: set QualitySettings.vSyncCount = 1; and Time.captureFrameRate = 60; and see if that makes it look better. It will slow down under load.... but it should be smoother.

    Otherwise you can go down the road I did to do jitter-reduced physics, which is to disable all interpolation and extrapolation on all of your rigidbodies, as well as Physics2D.autoSimulate = false; (or physics), and call Physics2D.Simulate(quantizedDeltaTime) from your update manager.
     
    jrumps likes this.
  36. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    ^ I should add that if you do that manual simulation, you can get rid of all that fixed update nonsense and related synchronization headaches, as everything will be driven by a single update loop. no fixed updates for real.
     
  37. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    oh dear, how is battery life at 120hz with physics ticking twice a frame? i will fire you a pm
     
  38. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    So I've been having some additional jitter due to intermittent loading spikes (caused by my code doing a lot within 1 update frame). If I am running at 60Hz (16.7ms loop time) and I do something that is CPU intense (and consumes 4ms of CPU time measured by looking at delta in Time.realtimeSinceStartup) it will cause me to drop a frame.

    The part I don't understand is I am dropping this frame when lightly loaded (i.e. I don't think there is 12.7ms of other stuff in the loop pushing me over the 16.7ms but I am not 100% sure on how to check this).

    Ugh.
     
  39. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    The below pictures assume everything is synced/phased properly. Which may or may not be the case... unsure how to tell. I'll make another picture showing syncing/phasing.
     
    Last edited: Mar 12, 2019
  40. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
  41. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    Not necessarily. Indeed, how are you sure that a frame is dropped? Currently, the only reliable way I can figure out is recording a video at 60fps and then watching it frame by frame searching for a duplicated frame. Otherwise, inside the application there's no way to know for sure that a frame has been dropped.

    Comments on the figures:

    Ideal operation: That's how it used to work in 90's and 00's, but that's not the paradigm with modern GPUs anymore.

    Dropped frame: In the 90's and 00's you could tell that's a dropped frame for sure. But today that's just a frame that took some extra time to render. Most probably the GPU had enough frames rendered and queried in advance to present them at perfect 60fps, and that one made into its slot properly as well. Indeed that "idle time" right after the long frame would have been removed or minimized to start a new Update loop immediately afterwards.

    Varying Time.deltaTime: THAT is the problem in Unity. You may simply remove the "monitor" parts from the figure as they're not relevant nor representative anymore. That "External loading" may well be the GPU requesting frames at varying rates (the infamous Gfx.WaitForPresent). Waiting for the GPU to accept frames occurs at correct rates in most systems. But in many other systems (ours) this rate varies hugely, causing variations in Time.deltaTime and the visual jitter.
     
    Last edited: Mar 12, 2019
  42. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    "Otherwise, inside the application there's no way to know for sure that a frame has been dropped."

    You don't need to record a video and watch it. My method:
    Take a 10sec running count of the number of Updates. At 60Hz with VSync enabled and it is always 600 (+/-1 due to rounding) at low loading (i.e. a blank new project).

    If I introduce 2ms CPU spikes periodically my 10sec running total stays at 600. If I add on a lot graphics loading with monsters my frames still stays at 600 +/-1.

    If I introduce single 4ms CPU spikes periodically my 10sec running total will drop to say 580. If your 10sec total is 580 then you've dropped 20 frames over 10 seconds.




    Regarding frame buffering... is this an adjustable setting? I don't want any frames buffered in the GPU because I don't want lag. A 2 frame buffer will add 16.67ms x 2 or 33.33ms of lag... this is highly undesirable for any action game. The benefits of being able to absorb a single long frame without dropping a frame just isn't worth the added lag. What makes you think Unity and my GPU is buffering frames by default? Can you link? If frames were buffed then it would make no sense why a single 4ms CPU load would cause me to drop a frame. Hell even without a buffer a 4ms CPU load shouldn't cause a frame drop (barring a lot of excessive other loading).
     
    Last edited: Mar 12, 2019
    sharkapps likes this.
  43. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    Nice, that way of counting frames makes sense. No idea on why frames are dropped in that situation, but that would be a different topic to investigate.

    It's not a setting, nor it's part of Unity. It's the asynchronous nature of modern GPUs. Some settings are adjustable (i.e. triple buffer), but GPUs work by notifying when they're ready to accept new frames, then managing them internally. That's how it works at the driver and APIs level. After you render a frame and send it to the GPU, there's no way to know for sure when that specific frame will be actually displayed on the screen.

    Possibly (my own guess) frames take a more direct path in exclusive full-screen mode. The rate of the Update calls, which causes the heartbeat stutter in Unity, still depends on when the GPU notifies the application it's ready to accept new frames. I haven't tested if the exclusive full-screen mode provides a more reliable update rate.

    Sure:
    https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92

    Summarized and explained:
    https://forum.unity.com/threads/tim...afollow-and-jitter.430339/page-4#post-4173886
     
    Zullar likes this.
  44. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,570
    The stutter with physics is caused by the rigidbody interpolation, which relies on Time.deltaTime, no matter the physics simulation rate.

    Simulating physics at the screen's refresh rate might work for specific projects, but it wouldn't be a generic solution.
     
  45. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    by nature, fixed update is flawed and will lead to aliasing. interpolation/extrapolation to correct this is also flawed, as it introduces error. and since interpolation/extrapolation uses a flawed deltaTime, it also adds noise. all of these are visible as jitter.

    The only way to avoid these 3 problems that cause jitter currently is to NOT use fixed update or interpolation/extrapolation. Physics(2d).autoSimulate = off;
     
    Zullar likes this.
  46. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    I believe the reason fixedUpdate/physics is on a different time scale is so that if your framerate drops you don't get crazy physics behaviors like falling through the floor during a big time.deltaTime spike (like level loading) or numeric instability (I'm speculating here correct me if I'm wrong).

    But I agree with you. I really dislike the physics/update system being on 2 different loops because of all the various issues it introduces. I would prefer the physics FixedUpdate to also update at the same rate as the regular vsync'd Update loop. Can this be accomplished by manually taking over the physics simulation loop time? If so I may do this (to get away from having to interpolate/extrapolate and other issues)

    For example lets say you have low loading w/ vsync monitor & update loop is 20ms. Then you would set your physics to also update every 20ms. And it would look something like this.

    T=0
    Physics
    Update

    T=20ms
    Physics
    Update

    T=40ms
    Physics
    Update


    ...but if you were heavily loaded and could only render every 40ms (due to large render/Update loading) then it would look something like this?

    T=0
    Physics
    Update

    T=20
    Physics

    T=40
    Physics
    Update

    T=60
    Physics

    T=80
    Physics
    Update
     
  47. herb_nice

    herb_nice

    Joined:
    May 4, 2017
    Posts:
    159
    * if you can keep your framerate stable, and are running at vsync with a quantized delta time- every frame will have the same physics interval.

    i experimented, and even have code that does what you suggest on #defines from when i was testing this stuff. ie, updating physics multiple times per frame when the frame rate drops. but in A/B tests it did not provide any more convincing output than just calling physics once per rendered frame. calling physics just once per frame is incredibly more performant so that is what we do.

    i do slow down stuff, micropauses, and allow delta time to change when framerate fluctuates and do not experience any bizarre physics action due to manual simulation with a fluctuating deltatime. HOWEVER, i keep my crap simple. YMMV. 2d physics (box2d) on a top-down game, removed most complex physics stuff (eg, spring joints, as they did do weird things and also cause occasional performance spikes). just torques and forces applied to a few dynamic capsule and circle colliders. some hiearchies of stuff that is being procedurally moved... a few kinematic colliders in the mix too.
     
    Last edited: Mar 29, 2019
    sharkapps and Zullar like this.
  48. DragonSix

    DragonSix

    Joined:
    Jul 2, 2013
    Posts:
    31
    I can't fathom how Unity had that problem for 5 straight years and still hasn't addressed it. Microstutters are on every games and it's an horrible look for the engine.
     
    herb_nice likes this.
  49. Zullar

    Zullar

    Joined:
    May 21, 2013
    Posts:
    615
    Agreed. Literally every unity application will be glitchy and jittery (unless the dev completely overhauls the update loop themselves). Seems like it should be a high priority issue since it affects every app in a noticeable way.

    I just wish they had an issue tracker for it so we could see the bug's status.
     
    DragonSix and herb_nice like this.
  50. GameDevCouple_I

    GameDevCouple_I

    Joined:
    Oct 5, 2013
    Posts:
    2,113
    Reading this entire thread makes it pretty clear unity should just hire @Edy as part of their physics team and be done with it.