I have a vCam which follows an object that moves via Rigidbody physics motion (AddForce) with interpolation enabled (although the bug doesn’t seem to care either way).
When I have damping > 0 on my transposer I get extreme jittering. When I disable the damping, the movement is smooth again. What’s going on here?
This happens on both my Macbook Pro and my Windows PC. The jittering seems to get worse when:
The framerate is lower.
The damping value is increased.
Changing the update method on the CMBrain doesn’t seem to do anything to mitigate the issue. Disabling interpolation on the object reduces the jitter when the object is travelling at high speed but then the object itself is a jittery nightmare at low speed under acceleration.
Looking at your video, I would say that your problem is unsteady movement of the target. To get smoothly damped cameras, your target needs to move in a smooth manner, otherwise there is no cure. The best you can do in that situation is to lock the camera to the target (0 damping) but in that case your background will jitter, as it does in your video.
Unsteady movement in a RigidBody is often caused by code that displaces it outside of the FixedUpdate loop. Are you sure that you aren’t doing something like that?
I’m reasonably certain my target moves steadily. I don’t have any code which directly translates or displaces it. I only use Rigidbody forces and torques to move it, and only inside FixedUpdate.
I’m starting to think this is some kind of bad interaction between my framerate and my physics update rate. I’ve been experimenting and even with zero damping on the vCam, if I set my Application.targetFrameRate to 30FPS, there is really bad jittering. 15FPS is obviously a bit of a slideshow but objects are not “jittery”. 60FPS looks smooth as butter. But then if I change my Fixed Timestep to 0.005, I start to get jittering even on 60FPS…
I did some experimentation with various framerates, CM damping settings, and Fixed Timesteps. This was not exhaustive by any means, but it is really frustrating:
There seems to be some kind of impedance mismatch going on! In some framerate/fixed update combinations there is a clear pattern of smoothness, followed by jittering for a second, followed by smoothness again on a regular interval! Is there some kind of rule I can follow to completely avoid the jittering? E.g. “If my application framerate is X, then Physics Timestep of 1 / X will cause jittering”? I can do more experiments and try to derive something but I wonder if others have explored this relationship before.
Interesting… I was hoping to build this particular game on the 2019.4 LTS version of Unity. Looks like a backport is not in the cards though https://discussions.unity.com/t/639394 page-7#post-5725024
I’ll give the alpha version a shot when I get a chance tonight.
The bad news is that it has done nothing for my problem.
The good news is that I went back and triple-checked everything, and somehow switching the CM Brain UpdateMethod to FixedUpdate seems to have resolved my issue. I could have sworn I had tried that a million times already to no avail! Embarrassing for me, but it’s looking good for now.
Edit:
Ok so turned out that using FixedUpdate only fixed my issue when I wasn’t using damping on the Transposer. When I re-enabled damping, I started getting jitter again in 2019.5.4. Then then I tried updating the project again to 2020.2.0a19 and… it seems like there’s still jitter but a little less? I feel like I’ve been staring at this for so long now that I can’t even tell anymore.
Ok so last night and this morning I made and refined a test project showcasing the issue. For some reason with this combination of settings (which are set up in the project already) there is extreme jitter.
I think there might be some kind of bug in the Smart Update logic for the CM Brain. In normal circumstances I think it sees a Rigidbody with interpolation on and chooses Late Update. But for some reason with this combination of settings (Time settings, Application.targetFramerate, Smart Update) it seems like it’s choosing Fixed Update.
That’s the main issue here.
However, if I set Application.targetFramework to -1, and use LateUpdate, I still start to see a small amount of jitter when the sphere is moving at higher speeds in this project (and my other).
I pushed up another branch of the project showcasing another set of conditions that cause the jitter. It seems like when Unity runs up against the “Maximum Allowed Timestep” setting, it can also cause jittering. This type of jittering seems to be resolved when you set transposer damping to 0. See GitHub - jschiff/CinemachineJitterBug at maxallowed
Thanks for the upload. I’m able to reproduce the jitter, and will look more deeply into it next week. Superficially, it does seem that SmartUpdate is not correctly detecting that the RB has interpolation on. I’ll have to dig into why.
So let’s work with the Brain’s update method set to LateUpdate, which takes care of the clock mismatch, which is where the lion’s share of the jitter is coming from.
The jitter at high speeds might be coming from the uneven deltaTime. Can you try it with the newer Unity? Also: don’t test for jitter in the editor. Make a build. The editor still has lots of extra stuff that can affect deltaTime and cause this sort of jitter at high speeds.
Thanks for the response! I will try with a build and also with the newer version of Unity. However, last time i tried to build on the 2020.2 alpha I kept getting build errors and haven’t had time to dig into that (some kind of shader compile errors). Hopefully with the trimmed down test project it’s not a problem. I’ll report back here with findings.
I did a build of the project in both 2019.4.5 and 2020.2.0a. My findings were that in both builds, there is a very slight jitter at high speeds. The 2020.2.0a version seems like it might be a bit more stable, but it could just be the placebo effect.
One thing I have found that absolutely causes extreme jitter is the combination of time settings like the following, mixed with Application.targetFramerate of 60:
I’m beginning to wonder if Unity’s rigidbody interpolation doesn’t properly handle what happens when the Maximum Allowed Timestep is reached and the physics updates are slowed down.
These settings seem to be rather pathological. When you set your physics timestep to be so much smaller than your rendering timestep, you are paying not only a heavy performance price, but also interfering with the benefits of physics interpolation, which is designed to support the case of the (expensive) physics timestep being on the whole less frequent than the render timestep.
Is there a reason why you need these extreme settings?
Oh I don’t actually need these settings. It’s a degenerate case I was using to see what happens when Maximum Allowed Timestep kicks in under normal circumstances. I was wondering if that would have any effect on interpolation and CM damping.
But you’re right, those settings themselves are degenerate so maybe they aren’t actually saying anything about what happens when Max Allowed Timestep kicks in under more normal conditions.
