Cinemachine boundary performance

Hello,

I'm in the process of optimizing my project to get to 60fps, and have come across a BIG bottleneck related to Cinemachine that I was hoping to find an explanation or workaround for.

Below is my profiler snapshot where you can see CinemachineBrain.LateUpdate eating up 3.5ms.



Deep profiling down the callstack makes me think that this is about the process of calculating bounds for the camera confines.
Still, I can't possibly afford 20% of my frame time going to just this.
Any ideas?

My setup is as follows:
The camera set in a static angle, and move in space to make sure all characters on screen are inside its view, up to a limit defined by a CinemachineConfiner.


Using Unity 2019.3.0f3 and latest stable Cinemachine package from the Package Manager.

- CinemachineBrain
-- Update Method: LateUpdate

- 2x Virtual Camera
-- Priority of 0 (Which doesn't change throughout the entire gameplay sequence).
-- Different game modes use different camera styles, so the active camera is set once at the beginning of the game and doesn't change for the remainder of it.

- 1x Active Virtual Camera
-- Priority 10
-- LookAt: TargetGroup
-- Body: Framing Transposer
-- Aim: Nothing
-- Noise: Basic Multi Channel Perlin (Set to 0 frequency and amplitude at rest, and sets them higher for screen shake effects on impact).
-- Cinemachine Confiner: 3D

- CinemachineTargetGroup
-- Position: Group Center
-- Rotation: Manual
-- UpdateMethod: LateUpdate
-- Targets: A collection of dynamic objects that move around the screen with dynamically changing weights.

- CameraConfines:
-- Box collider. Doesn't move or change throughout the run.

 

1. Disabling Standby Update seemed to have no effect.

2. Disabling the confiner component seems to reduce the load by nearly a millisecond (With Standby Update still set to never).


3. The above profiler snapshop seems to suggest that the bounds calculation I originally saw was related to the bounds needed to contain all players within the shot, so I went ahead and disabled the CinemachineTargetGroup on the camera, and this is the profiler result:

That's another millisecond and some scrapped off, but now I'm asking what am I even paying the remaining 1.5ms for if I'm literally using a static camera with no Cinemachine-related features enabled?


Additionally, it's all nice and good that the confines and target groups were responsible for the poor performance, but what exactly is the alternative? These are kind of the core features that Cinemachine is even needed in my game (And possibly many others) for.
What am I supposed to do with this information? =\

 

@Gregoryl Apologies for bumping this so quickly, but this is a blocker for us and I need to make a decision on whether I should scrap Cinemachine from the project entirely.

 

Yes, all vcams were changed to Never.

Thanks for the note about the noise, though I remember when originally implementing it that it was necessary to keep it active since the module is actually a cinemachine component added to the object and hidden in the inspector, and turning it off meant removing a component.

I'll try and send you the project, thanks.

 

I made the same experience. I've used Cinemachine in two different projects (Switch & Android) with big regret from a performance point of view.

I needed a simple 3rd Person Camera with no fancy things. Unity was advertising Cinemachine at this time, so I thought it's a good idea to integrate it. I used the "Free Look" Component with no add-ons, no nothing, just one virtual Camera. Even such simple setup came with a huge performance penalty, like you observe yourself.

I reported a bug for that a while ago too:
https://issuetracker.unity3d.com/is...-using-simple-camera-setup-on-android-devices

The "Cinemachine is slow" topic shouldn't be new to the Cinemachine team.

 

Nope, DeepProfiling was not used. If you're interested to take a look at it, you find everything you need in bug-report Case 1176699.

 

@Gregoryl Deep profiling disabled, Brain is set to LateUpdate, still seeing over 2 ms on CPU.
This is running on the Switch, same as the previous profiler snapshots I attached.
This issue can still be replicated in the editor but with understandably lower times of around 0.8ms.

 

Sending you in pm. The Switch build settings is under NDA.

 

Interestingly enough, by Gregoryl's advice I turned off not only the deep profiler but also script debugging, and the profiler now samples the same LateUpdate at 0.6ms-0.8ms.
So it seems this was just a profiler overhead after all.

 

Hey, thanks for the answer.

Good question! I couldn't remember it, so I used the project attached to Case 1176699 to profile again. Unfortunately, I couldn't get the phone I used a few months ago, so the results are different to the ones in the original bug-report. However, I profiled with and without Script debugging.

Spoiler: No Script Debugging and no Deep Profiling enabled

Spoiler: With Script Debugging enabled, and no Deep Profiling enabled

According to these tests, Script Debugging adds a significant overhead to CinemachineBrain.LateUpdate as you pointed out.

However, the issue that Cinemachnine costs about 2ms in this simple test, even without Script Debugging enabled, still stands. If you're interested to demystify this, you find everything you need in bug-report Case 1176699.