It’s a bit of a headscratcher for me lately. Takes about 2-10ms of performance.
Goes up and down pretty wildly in the profiler.
Have about 14 virtual and some freelook cams which i switch via changing priority in the scene.
Is there a better way of switching the cams which is more performant? Turning the gameobjects on/off doesn’t seem to make it better.
Working with 2017.03 latest patch
Using FixedUpdate Mode
I actually had a similar problem, but it disappeared after I restarted the unity editor. Since then I’ve not been able to reproduce it. I’ll let you know if I’ll bump into this again.
We found a fix pretty quickly with gregory via pm. Mine was reproducable, and was likely to be a combination of too many vcams in a cpu/physics heavy scene. The best workaround so far is basically always having all vcam gameobjects off except the one we’re using.
FixedUpdate mode means that virtual cameras are updated every physics frame. If you’re doing something (e.g. recording) that bumps up your frame time, you end up causing many more physics frames to be computed every frame, which if you have lots of vcams ends up taking longer, which causes more physics frames to be computed per frame… you get the picture.
Those numbers look way off.
Can you give more details about your scene, like physics timestep, now many vcams, etc.
Also: can you show image of your vcam inspector?
We’re not using physics except for particles or other actions, but there are none at that time. Maybe you can give me some hints on how it behaves.
The scene is not optimised as it is not the focus at the moment, quite texture heavy, lots of draw calls (several thousands) and tris (several millions)
The Cinemachine Setup is as Follow
Blend List
→ 6 Cameras
→ Last Is Active and is a StateDrivenCamera
→ 2 children
→ 1 Active a StateDrivenCamera Again
→ 2 Children
→ 1 is active a vcam. This vcam transform is following another object, the vcam itself has no active component (save during play is enabled)
That doesn’t make sense. Can you please show me the profiler (like you did above) when the Brain is on LateUpdate? I don’t care about FixedUpdate for now.
My bad, I didn’t look to the call list thoroughly or restarting the game maybe helped, in “LateUpdate” indeed the CPU spike remains but it seems, as I read it, that it now comes from our side, I’ll do a deep profile :