Search Unity

Cinemachine boundary performance

Discussion in 'Cinemachine' started by ShadowLairGames, Jan 10, 2020.

  1. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    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.

    upload_2020-1-10_0-25-59.png

    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.
    upload_2020-1-10_0-45-37.png

    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.
     
    Last edited: Jan 10, 2020
  2. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    20% certainly sounds excessive. Let's see if we can narrow down the cause.

    1. What happens when you set all the vcams' Standby update to Never?

    upload_2020-1-10_8-43-44.png

    2. What happens when you disable the confiners?
     
  3. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    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).
    upload_2020-1-10_21-52-3.png

    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:
    upload_2020-1-10_22-11-58.png
    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? =\
     
  4. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    @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.
     
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    It doesn't make sense that the group and confiner are responsible for that poor performance. They don't do that much.

    It was not clear to me whether you set standby update to Never of all the vcams or on just the active one. Please confirm that it's on all of them. I want there to be only a single vcam being computed each frame.

    Also, you should (for now) disable the noise. It's still being computed, even with the 0 settings.

    If you'd like to PM me the project I can have a look.
     
  6. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    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.
     
  7. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    4,426
    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.
     
  8. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    You should be very cautious before drawing conclusions from profiling data, especially when deep profiling is enabled.

    On the Android, simply enabling these checkboxes, whether actually deep profiling or not, will skew the data due to instrumentation:

    upload_2020-1-15_11-54-14.png

    You need to disable those settings, then run the app on the device, and connect the profiler to the device:

    upload_2020-1-15_11-55-23.png

    That will give a much more accurate assessment of the performance.

    @ShadowLairGames can you check again the performance of CinemachineBrain.LateUpdate, without Deep Profiling enabled? When I recreate your setup without Deep Profiling, I get a reasonable 0.2ms on a slow Android device, even though I was getting up to 9ms with Deep Profiling enabled. Also: make sure to set your Brain's update method to LateUpdate if you can. It's more efficient than SmartUpdate. Finally, for the Noise, if performance is a issue you can use Impulse for camera shake. It might be more efficient.

    @Peter77 How did you measure your performance? With DeepProfling enabled? If so, then you might want to reconsider your conclusions.
     
    Last edited: Jan 15, 2020
  9. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    4,426
    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.
     
  10. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    upload_2020-1-15_20-55-2.png

    @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.
     
  11. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    Can you show me the build settings panel?
     
  12. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    Sending you in pm. The Switch build settings is under NDA.
     
  13. ShadowLairGames

    ShadowLairGames

    Joined:
    Jan 17, 2019
    Posts:
    35
    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.
     
  14. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    @Peter77 Did you also uncheck Script Debugging? That makes a big difference too.
     
  15. Peter77

    Peter77

    QA Jesus

    Joined:
    Jun 12, 2013
    Posts:
    4,426
    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.

    upload_2020-1-16_8-39-3.png

    upload_2020-1-16_8-40-48.png

    upload_2020-1-16_8-43-50.png

    upload_2020-1-16_8-43-58.png

    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.
     
  16. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    3,257
    Hello @Peter77 ,

    Thanks for packaging up that project, we really appreciate your effort and persistence in following it up.

    Running your build from your bug report, we were seeing less-than-stellar CM performance on a low-end Android device:

    upload_2020-1-17_16-14-50.png

    However, this went down to about 0.8ms when we disabled Script Debugging, and then when we built with IL2CPP instead of Mono, it went down again to about 0.4ms.

    In our view, this is not ideal, but is not unreasonable either. Using the new Burst, Jobs, and SIMD math instructions now available in Unity, we could undoubtedly bring these times down quite a bit. This is planned for upcoming versions of CM.

    Best regards,
    Greg
     
unityunity