So I found a very easy to reproduce, yet very annoying bug inside unity. Basically if vsync is OFF, auto sim is OFF, and you manually step the physics engine multiple times every fixedupdate (or a bunch of times in a single frame to say), there is a VERY noticeable jitter on everything in the scene even if there’s NO rigidbodies in the scene. However, if you turn vsync on, the jitter goes away.
I tried this just now with two fresh scenes, with only the character controller, and another 3d model to look at as a reference to know when the jittering is happening. This is the ONLY script in the scene.
You can enable/disable the simulation loop in-game by clicking left click.
You’ll probably need to load another 3d model in and strafe around it to see the jitter.
Again, if you’re going to reproduce this, MAKE SURE Vsync is off and auto sim is off. (And then once you’ve seen the jitter, turn vsync on and magically watch the jitter disappear)
Obviously you’ll need to adjust the speed of the character controller to about 15, but yeah very easy to reproduce and a very noticeable jitter. And yes, I did look in both the profiler and my nvidia overlay. Both say I’m getting a steady 100fps (that’s what it’s capped at when vsync is off).
There’s something inharmonic or otherwise discordant going on with timings at the very heart of Unity that creates some noticeable polyrhythmic jitter under certain conditions and on certain machines.
Very noticeable on Macs, especially if you crank up the brightness of your screen and the contrast in your scene.`
Not been able to pin it down. But what you’re seeing sounds like an issue created by this issue.
2020.2 onwards has better reporting of deltaTime (more accurate) but did not solve the underlying (I believe) slightly askew or polyrhythmic actuation of various engine calls, which I think cause this jitter/stutter look.
There’s a good chance that what I’m seeing may just be very intense screen tearing, since it looks like 30fps at 100fps, and vsync fixes it entirely. But yes, running a bunch of Physics.Simulate() in a single frame every fixedupdate does seem to bring out the beast despite having an extremely high FPS alongside it.
Just two tips, not an answer, but maybe they improve your situation: cameras should be updated in LateUpdate if they attach to some physics object. And, the gameview in newer versions has a vsync option which is found under the aspect ratio dropdown. Turning this on typically worsens everything (desyncs gameview and game), make sure it’s turned off.
This info about the vsync game view is VERY interesting.
I’ve had it turned on since it was a thing, as it somewhat seems to solve issues with thrashing and the GFX.waitforsync issues of particle systems and other graphics stuff… IF trying to cap framerate in Editor with one of the code ways to do this.
Since nothing has been good, for me, in terms of getting smooth, great performance in PlayMode in the Editor, I’ve streamlined my project to do fast builds, so I can play test in them. It’s not super fast, though… building is still 4x slower (or sometimes much more) than Play Mode testing.
Do you happen to know what’s the best way to get smooth movement in Builds and Editor?
I’ve tried DOZENS of different variations of the frame settings and sync settings and never really been happy with anything I’ve found. There’s always some skipping/stuttering.
I don’t have issues with stuttery movement. I’ve had some at times where using LateUpdate for camera movement was the fix, that’s why i suggested it (meaning the camera only updates when however many physics steps are completed).
But in your case i’d try not stepping the physics manually first, if that’s possible for your case, updating the camera in LateUpdate and if using rigidbodies trying one of its interpolation modes.
Also check that in the quality settings vsync is not set to update every second frame.
In your example you toggle manual stepping but don’t disable it in the settings, which i’m guessing may also interfere.
I’ve tried all these things, and a dozen x dozen more combos and variants.
Never got a flawlessly smooth Unity for physics and cameras. Can get close, but never flawless, even when the framerate is absolutely consistent. For the longest time I thought it was me, doing something weird, then I starting making the simplest possible test rigs, and discovered it’s definitely not me.
If it’s for a character controller i can recommend the asset ‘Kinematic Character Controller’ by PhilSA, that’s what i’m using; it’s pretty extensible and there’s an example you can try to see if it solves your issue.
Apart from that you may try to do update-motion smoothing yourself.
Yes! I use application.targetFrameRate in the problematic projects (currently limited to 100fps in all of my test projects) yet if I give it a bigger value (say setting it to 250fps) the jitter gets less and less.
Definitely makes sense since turning Vsync on supposedly makes the project ignore targetFrameRate.
As for disabling Vsync, It’s just always been disabled for the duration of my project (6 months or so in progress) and I never thought it could be the culprit until actually realizing that it was.
My monitor is 144hz btw and all of my settings are for 144hz inside windows. So I’m not sure how running below the refresh rate could cause this since it happens even when I lock unity to 144fps with vsync off, but I’m glad that unity staff are finally acknowledging this issue.
In case you missed it since I’ve made multiple threads about this problem, the issue only arises when Physics.Simulate() is called multiple times in a single frame (might just be increased CPU time per frame in general who knows), yet I’m still getting a solid 100fps as you’re probably aware. The “jitter” I’m seeing worsens with the amount of Physics.Simulate() calls per frame despite FPS staying constant. Is this still what you’re referring to regarding the Sleeps() on the CPU? Could it be an issue with how physx is multithreaded?
The so-called “jitter” I’m seeing, literally looks like you’re running the game at 30fps despite everything saying otherwise.
Application.targetFrameRate doesn’t “lock” frame rate. It tries to achieve it using best effort, but it’s in no way guaranteed and if you were to analyze when the frames get to the display using software like GPUView, you’d see that it’s not stable 144 FPS and the frame times will vary slightly. The only way to “lock” frame rate is to use VSync.
Indeed I didn’t see your previous threads. You keep saying “Solid 100 FPS”, but how do you measure that? If your monitor is 144 Hz, it cannot display 100 fps:
Frame 1: 0 ms
Monitor Refresh 1: 0 ms - displays frame 1
Monitor Refresh 2: 6.94 ms - displays frame 1 still
Frame 2: 10 ms
Monitor Refresh 3: 13.88 ms - displays frame 2
Frame 3: 20 ms
Monitor Refresh 4: 20.83 ms - displays frame 3
Monitor Refresh 5: 27.77 ms - still displays frame 3
Frame 4: 30 ms
Monitor Refresh 6: 34.72 ms - displays frame 4
Frame 5: 40 ms
Monitor Refresh 7: 41.66 ms - displays frame 5
Monitor Refresh 8: 48.61 ms - still displays frame 5
So in this example, you have Frame 1 displayed for 13.88 ms, frame 2 for 6.94 ms, frame 3 for 13.88 ms, frame 4 for 6.94 ms, frame 5 for 13.88 ms. This is a simplification and doesn’t account for tearing, but on most frames, that’s what the upper part of the screen will show.
This has nothing to do with Physics.Simulate. I suspect it just loads the CPU the right amount to exacerbate the issue.
