Cinemachine stutters when following a Rigidbody

Standby Update is not relevant here.

If you set the Brain's Update Method to Smart Update, then play the scene and look at the virtual camera's inspector while the game is playing, what text do you see here?

 

It says FixedUpdate? And it's stuttering? That should not be, unless your target is moving unevenly. But you say it's smooth.

Can you make a small project the reproduces this problem, and send it to me?

 

Sure. Delete the library folder before zipping, it will be much smaller

 

Had a look at the project, thanks for uploading.

I'm definitely seeing some stutter when playing in the editor. I believe that this is due to the discrepancy between the physics framerate and the render framerate. You will get aliasing, which is magnified by 2 things:

1. Running in the Editor, which has a lot of extra overhead, making the render framerate more uneven. To get a more accurate idea of the situation, you should test a build of the project. When I do that, the stuttering is very considerably less.

2. Using Damping on the camera. Unfortunately, damping is very sensitive to uneven frame rates, and the stuttering will be amplified by this. One way to mitigate this is to reduce the aliasing by increasing the physics framerate. When I changed the Fixed Timestep (in ProjectSettings/Time) to 0.01 it was quite smooth in the build.

On a side note, changing the vcam's Aim to Composer (with default values) made the camera very sweet.

 

A shorter fixed timestep definitely helps in the editor too. Don't make it too short, or you'll kill performance.

The editor is a big complex program and it does lots of stuff, even if there's not much in your scene. The build, on the other hand, is 100% focused on the game.

Smooth camera movement with an uneven framerate is a hard problem: because it's the camera, any little glitch in its smoothness results in a hugely visible artifact, which our human brains are very much tuned into detecting. Putting some effort into guaranteeing a smooth framerate would be a rewarding investment.

 

Update: I thought of something this morning and had another look at your project.

Your player is being driven on the physics clock, but your script is tinkering with the velocity on the render clock. That's a problem. So I changed PlayerInput.Update() to PlayerInput.FixedUpdate(). Then, everything was perfectly smooth in the editor, even with the physics timestep at its original value of 0.02. Setting the timestep smaller was just covering up the real problem.

You can even increase the timestep further and, if you want, you can enable rigidbody interpolation on the player to smooth it out. It all works quite well.

The take-home message is that you have to be very careful with physics-driven objects to consistently alter the movement only in FixedUpdate, never elsewhere. Otherwise you're liable to get judder.

 

@Mashimaro7 What is the Update Mode setting of the CM Brain?