Cinemachine Update Method error

SlamDaBrakes

SlamDaBrakes

New member
I am getting this error with the Cinemachine integration spamming a lot of noise

CinemachineBrain.ManualUpdate was called from FixedUpdate

UnityEngine.Debug:LogError (object)

Unity.Cinemachine.CinemachineBrain:ManualUpdate () (at ./Library/PackageCache/com.unity.cinemachine@285f38545487/Runtime/Behaviours/CinemachineBrain.cs:575)

Opsive.UltimateCharacterController.Integrations.Cinemachine.CinemachineUpdater:FixedUpdate () (at Assets/Opsive/UltimateCharacterController/Integrations/Cinemachine/Scripts/CinemachineUpdater.cs:29)

Changing the Update Method on the Cinemachine Brain to Fixed, Manual, Smart or Late makes no difference.

Using Unity 6000.0.68f1
Cinemachine 3.1.6
UCC 3.3.2

Don't want to update UCC just yet as using a lot of custom abilities and tweaks.
 
Take a look at this post:

P

Thread 'Error: CinemachineBrain.ManualUpdate was called from FixedUpdate'

After the last update, an error occurred in the Cinemachine integration. This error also occurs in the Cinemachine demo integration.
CinemachineBrain.ManualUpdate was called from FixedUpdate
UnityEngine.Debug:LogError (object)
Unity.Cinemachine.CinemachineBrain:ManualUpdate ()
(at ./Library/PackageCache/com.unity.cinemachine@b66fdb7cd1f2/Runtime/Behaviours/CinemachineBrain.cs:575)
Opsive.UltimateCharacterController.Integrations.Cinemachine.CinemachineViewType:Move (bool)
Temporarily fixed it like this
CinemachineUpdater:
private void LateUpdate()
{
m_Brain.ManualUpdate();
}...

I haven't had a chance to reproduce this but that should fix it.
 
The character is extremely jittery when using Cinemachine (at least 3.1.6+) integrated with a Third Person controller. A user in another post provides a patch to hide the error, but it doesn't fix the underlying problem.

Logging shows CinemachineUpdater.LateUpdate() runs every rendered frame, but CinemachineViewType.Move() does not. The call cadence is irregular rather than fixed-rate, which I suspect is the reason for the character appearing to vibrate all over frame-to-frame. Please see video evidence, particularly the slowed-down portion starting around 10 seconds in:

View attachment Untitled - June 16, 2026 at 11.15.43.mp4

This sort of thing is hard to notice from a distance with the default Cinemachine integration scene and character (bobbing all over as he does) but is extremely evident even at a distance in my project with my character, when the Opsive's Camera Controller built-in (non-CM) view types appear smooth.

260616_11h27m37s_screenshot.png260616_11h28m14s_screenshot.png

I'm on the latest Third Person Controller 3.3.5 (5/28/2026), Unity 6000.4.7f1, CM 3.1.6/3.1.7
 
This is likely related to the update method. I had to use a custom update method in order to not get any jitter, but it sounds like that has other issues. I haven't had a chance to look at the cinemachine integration but I plan on it before the next update.
 
Turns out I need to do an update sooner than later because of the Unity 6.5 release. I looked at the Chinemachine integration and there was a Cinemachine change that made the old integration not work. I've updated the integration which supports Cinemachine 3.1.7. You can get it on the downloads page.
 
The new integration for sure fixes the duplicate ManualUpdate behavior, but the visual jitter looks the same, so I don't think that was the only thing going on.

CinemachineViewType.Move() is still being called from SimulationManager.FixedUpdate() -> MoveCameras() -> SmoothedCamera.Move() so could the issue be related to how the Cinemachine view type interacts with the SimulationManager smoothing/interpolation path rather than the Brain update timing itself?

Thanks for looking into it! I spent a lot of time getting my CM camera rigs behaving and I feel like we're so close!
 
With what setup are you seeing the jitter? The camera is now moved within LateUpdate.
 
I'm testing with a basic Opsive + Cinemachine setup as outlined in the integration documentation; an Orbital Follow + Rotation Composer. The jitter is present in both Editor and standalone builds whenever using the Cinemachine integration, but not with the standard Opsive camera/view types. If you zoom in close while running it's easy to see, or in the video of the (no longer included) integration example scene above. The character in my project runs even faster so it is even more apparent, but even at walking speed it's jerky. Everything in the background jerks around frame-to-frame too (note the clouds and plane in the video below).

I may be misunderstanding what you mean by "the camera is now moved within LateUpdate", but logging makes it look like CinemachineBrain.ManualUpdate() is now occurring during render frames, while CinemachineViewType.Move() is still being called from the SimulationManager fixed-step path.

For example, my logs look like:

Move frame 248 fixed=True
CM Update frame 248
CM Update frame 249
Move frame 250 fixed=True
CM Update frame 250

and the stack trace for CinemachineViewType.Move() still goes through:

SimulationManager.FixedUpdate() -> FixedMove() -> MoveCameras(-1) -> SmoothedCamera.Move() -> CameraController.Move() -> CinemachineViewType.Move()

The duplicate ManualUpdate issue appears fixed in the new integration, but the visible jitter is unchanged compared to the previous version.

Is CinemachineViewType.Move() expected to be called from the fixed simulation path, or should it now be occurring from the smoothed/render update path?
 
Last edited:
For comparison, here is the same setup except with the Opsive camera/viewtype, in which the character and background appear smooth:
 
Last edited:
CinemachineViewType isn't doing the actual camera movement, it just signals Cinemachine should move within the updater component. Can you attach your scene?
 
Sharing my scene is not easy to do... I have a lot of other dependencies and tweaks so it'd probably be a nightmare for you to get working.

But it got me thinking: I can see the issue in the demo scene with the Atlas character, but it's nowhere near as pronounced (in fact I probably wouldn't even have noticed and be having this conversation if I was using Atlas) so why is it SO much more pronounced on my character, even at a distance? The only thing I could think of was animations, but then why are those smooth with the Opsive camera?

As a test I set the Animator and Animator Monitor update mode from Normal to Fixed and the issue completely vanishes! However, unless you're on a completely flat surface with no elevation changes FinalIK Grounder and FBBIK flip out with the animator in Fixed, making the character vibrate up and down on any slope/terrain or near a ledge of any kind, even when stationary/idle.

The standard Opsive camera remains smooth in either update mode.

What stood out to me is that changing the Animator timing completely resolves the Cinemachine jitter, while the standard Opsive camera doesn't appear sensitive to the Animator update mode at all.

Does that point to anything in the way the Cinemachine integration is consuming character/animation data compared to the standard Opsive camera?
 
The Animator Update Mode determines when IK runs. If you completely remove CharacterIK/FinalIK is it smooth?
 
Ok, so it's something related to the interaction with the controller, FinalIK, and Cinemachine. I haven't tested this combination before but will take a look at it (though I don't have a timeframe right now).
 
Well to clarify the FinalIK stuff was just a byproduct of the Animator update mode change. Just to be extra sure I just tested with Animator back to Normal update mode and no FinalIK and it's still there, so that definitely wasn't causing the jitter issue. This seems to be purely a CM camera <-> animation update order issue.

The run animation I use is Humanoid Run from Standard Assets if that helps you test Atlas in the future. I love the guy but his bob & weave run makes it harder to see the jerkiness :D

Cool man, I'll keep testing but Animator: Fixed (+ FinalIKBridge: FixedUpdate, if you use FinalIK) seems like a solid resolution path for me. It would be awesome if there's a way to get CM to work as well as the standard Opsive camera in any Animator mode, but I imagine you have many things on your plate.

Thanks for the ManualUpdate fix and thinking out loud through the rest with me.
 
I'm glad you have a viable solution for now. Overall having an update mode of Normal makes the most sense for the controller because then you are not reliant on FixedUpdate for the animations. It sounds like there's definitely an order of operations conflict with the three though and that is making it jitter. Let me know if you find out anything more, and I'll also let you know when I have a chance to look at all three with a normal update mode.
 
Ah, slight update.

Changing the FinalIKBridge to update the solvers in FixedUpdate wasn't actually a fix... turns out that breaks FBBIK Grounder. Grounder was actually what was causing the vertical jumping in Fixed update for the animator, not FBBIK. But Grounder knows when to update thanks to its firstSolve flag, so the fix for FinalIK whilst using Animator: Fixed update was to remove the FinalIKBridge script entirely and let FinalIK just do its thing.

Not sure if this breaks some cross-functionality the bridge was doing (look-at, or an ability that uses IK perhaps?) but I don't use those for now so that's a problem for a different day, lol. However FBBIK, Grounder, and AimIK all work just fine like this.

Edit: Oh right, one thing the bridge did (that you do have to do yourself without it) is disable FBBIK on death for ragdoll. This is simple to enable/disable on death/respawn events.
 
Last edited:
You must log in or register to reply here.
Back
Top