Can I use 2 camera with Cinemachine Brain?

My current production involves creating arbitrary numbers of 'virtual environments', basically little prefab boxes, that wind up drawing into individual rendertextures on a HUD. At present there could be anywhere from 6 to perhaps 32 of these things active at once! Obviously we wouldn't want to burn through our frame budget by running 32 simultaneous cinemachine brains; generally we employ a culling strategy where we only change & re-render a few contents at once.

Knowing about cinemachine brains' dependence on unity's integer mask layer system, I basically elected to not even try using cinemachine on this project. (Despite having greatly enjoyed using it on other projects!) Instead I just wrote the usual custom camera code that most developers end up writing for unity projects when something like cinemachine isn't available (at this point I've probably built like 7 of those, lol).

I maybe could have solved the layer limitation by pre-allocating a range out of the layermask, e.g. 'VirtualEnv1, VirtualEnv2 ... VirtualEnv8'! Yet like I said, it's hypothetically possible that we'd need 32 little scenes active at once, and unity's layermask only has 32 bits. Other game systems ALSO want their own special layer range sometimes, so there's competition for the use of this mask. What I likely would have needed to do is something like:

- When it's time to update a particular content, change all its virtual cams to be on the special 'ActiveCam' layer
- manually force-update the specific cinemachine brain related to that content (I think I read in the patch notes that there's manual update support now, which is great!)
- jump my actual 'rendering' camera to the brain's targeted location (we use a lot of post-fx stuff so I don't think I would want every brain to be maintaining its own PP layer; at present we have 1 'rendering camera' with the 1 PP layer, and we jump that wherever it needs to go in order to render the next thing in the sequence)
- actually render to the rendertexture
- go and remove every virtual cam from the 'ActiveCam' layer so they don't fight other virtual cams in subsequent updates

At that point I'd be circumventing the layermask system entirely, which in Unity is something people often have to do! I think it is generally the case that for use cases involving 1...n 'brains', the fastest/best solution would almost always involve circumventing the layermask. (Not in 100% of cases, obviously; of course there are cases where the layermask is effective.)

I think 1...n is a pretty common case for this though; I'm now onto my second project where I've avoided cinemachine due to the layermask restriction! If anything I would maybe suggest the layermask to be a sort of... relic? From ancient Unity, when every little feature was some oddly-constrained adhoc-type thing. I'm really never pleased to encounter a plugin using the layermask, even though I've gotten good at preventing the plugins from all fighting over it. Today I think less & less plugins rely on it, which has made my work life simpler

If I were to change cinemachine in some way so that it fit my personal favorite range of Unity use cases, I think what I'd do is let every brain & every virtual cam declare an integer-based index determining which cams affect which brains. From there it's pretty Unity-friendly to erect some 'global manager' type thing with a list of all active brains 'n cams, so it can match them up by index and efficiently expose that info to each brain during their respective update cycles.

 

If i would do anything, i'd separate the which-cams logic from the brain. This is where components shine, im not quite sure why the brain does so much.

So the brain might have a serialized array of cameras, and some API for adding and removing cameras. This way a virtual cam could have a script `add to brain based on layer`, or any other custom logic we desire. At the moment its hardcoded to one particular case, which clearly doesnt meet the demands of the diverse users.

 

A serialized array of virtual cams would impose certain limits around interfaces & polymorphism that I tend to avoid in my own programming practice, tho I agree it'd be one step easier for me to work with something like that!

The thing with the list approach is that: The virtual cams for my projects (I'd think in most projects!) live in separate assets from the brain (the brain usually lives in some runtime-only camera prefab, while virtual cams tend to scatter throughout the project's level' data). I could definitely append to a list on the brain & manage all that conveniently just by writing a small global manager, so that'd be no problem for me really. (Yet since the manager I'd write would likely do nothing except allow virtualcams to specify a desired brain index, that's why I mention doing it the integer index way!)

 

A component based approach, and a simple API would, in my opinion, cover many scenarios.

So a brain has the possibility to add and remove cameras, and the unity auto-upgrader automatically adds the 'add-camera-to-brain-based-on-layer' component to vcams.

That way if im too stubborn to use it i can simply remove that functionality and provide my own.

 

Agreed. Just let us assign a property. Having to create additional layers is unintuitive and not helpful for highly complex scenes with existing layers and requirements.

 

Reading over this thread, I'm a bit curious and a bit confused.

I see how the cinemachine and virtual cams work, but I'm curious if I can use this to solve a camera blend I want to implement in my game. Currently, I have a unity camera following my player, and I have a second unity camera that is orthographic. In this scene, when a player interacts with a specific object, I want to move and fade into the orthographic cameras view.

Basically, I'm trying to create a very smooth transition that will move the camera from a 3rd person view of the player forward, past them and into the same position as the orthographic camera, while transitioning between the view change smoothly as the 3rd person camera gets close to the ortho camera.

My setup currently is:

• A Unity main camera with a culling mask excluding my "orthocam" layer
• A virtual follow camera to follow the player
• A Unity ortho cam positioned where I want it on my "orthocam" layer deactivated
• A virtual camera on my "orthocam" layer
• A script that enables the Unity ortho cam

When my script runs and the ortho cam is activated, it just switches to that camera as it does without cinemachine.

I had a nice transition working between the 2 virtual cameras, but there doesnt seem to be a way to set the virtual cam as ortho, so I tried this additional camera and layer thing.

Any ideas?

 

Hi, thanks. I'll check these out and see if I can get something nice, it looks like I may be able to get something reasonably acceptable with it. It is a bit different than what I was attempting to do, but that may be the better way to do it anyway.

The scenario in the game is that the 3rd person player will go into an ortho view to solve a "puzzle." It's really only ortho because it makes the interactions with the puzzle look clean, so narrowing the field-of-view may be plenty sufficient for that.

Anyway, I'll post back if I have any other issues/thoughts after trying these.

Thanks a lot for the response!

 

This is an amazing answer. Thank you!!

 

This is not my website but I also found this great tutorial to make an automatic layer mask assignment: https://www.monkeykidgc.com/2020/12...iplayer-using-cinemachine-follow-cameras.html

basically it does:

Code (CSharp):

1.  
2.         YOURPLAYERSCRIPT[] characterMovements = FindObjectsOfType<YOURPLAYERSCRIPT>();        
3.         int layer = characterMovements.Length + 9; // where 9 is just your first player layermask you assigned - 1
4.  
5.         virtualPlayerCam.layer = layer;
6.  
7.         var bitMask = (1 << layer)
8.             | (1 << 0)
9.             | (1 << 1)
10.             | (1 << 2)
11.             | (1 << 4)
12.             | (1 << 5)
13.             | (1 << 8);
14.  
15.         cam.cullingMask = bitMask;
16.         cam.gameObject.layer = layer;

 

Hey all!
Just stumbling upon the issue of 2 cameras with Cinemachine today,

I was quite confused when I had to change my Camera's culling mask to change which Virtual Camera was to be used with the CinemachineBrain -- I definitely agree with @TJHeuvel-net that a component-based (or serialized/inspector array) approach would be super beneficial!

But anything that could let us customize this without using layers/culling masks would be happily welcomed!
I'm wondering if anything new is possible now, as of Cinemachine v.2.7.8?

 

I'm also wondering!

The brain just grabbing the vcam with the highest priority rather than having to assign vcams to the brain is one of the things that makes Cinemachine powerful and easy to work with. I love it.


@Gregoryl, any progress on the CM channels system? Layers are already overworked (we've been nagging Unity to decouple physics and rendering layers for years already), so having CM handle this internally rather than through the layers would be a big boon. It'd also make it a lot more intuitive - this is one of the few things over the last years working with Cinemachine I've had to google in order to find out how to do. Everything else I can figure out by just fiddling with the CM UI

 

I know this is a little late, but this video helped so much! Thank you for posting this here; it was perfect.

 

I thought putting them on different layers didn't apply to me, but this was the exact solution I needed!

Is there a reason why we can't directly set the default virtual camera for each unity camera?

 

A potential edge case problem is not a reasonable response to never include what is clearly a popular requested feature. We should be able to (optionally) manually set the active vcam for a cinemachine brain. The property is right there in the inspector, it's just read-only for some reason. You don't even have to include it in the public docs if you're so concerned with inexperienced users making things unintentionally difficult. Why is this so hard to do? Let us disable the auto-switching.

A separate cinemachine-only layer group is a decent half-measure but it seems like that's not happening anymore? It's been like two years since your initial post. I literally do not have enough layers left to support 4 local players. Any updates?

 

CM is a package, so it's completely possible to fork it. Modifying it so you're responsible for setting the camera, or have the ability to override the camera, should be fairly straightforwards.

 

Yes, of course it is possible to literally fork and edit the package itself. I think I speak for most users when I say that is not the ideal solution for a variety of reasons, most obviously regarding upgradability and compatibility with future releases. But it sounds like the team is still working on an update.

@Gregoryl Sounds good, thank you for the update. What's the ETA on 3.0?

 

@Gregoryl Awesome, thanks to you and your team for implementing that, sounds very useful!

@gg_michael Not sure if this helps you since it's in an Alpha version of the engine with a preview package version, but I was able to start testing with v3.0.0-pre.3 on Unity 2023.1.0a17. Looks like quite a bit has changed in Cinemachine, so it may be helpful to start getting acquainted with the changes in a test project at least!

 

Any progress in using multiple cameras without the multiple layers solution? It's really curious why the choice to use layers as you could've simply added a way to strongly link a vcam with a brain, or at the very least using tags (which you can have an infinite number of).

 

Very old project with CM 2.1 here and just started working on the split screen which turned out to be serious issue. The project is structured with "camera triggers" that activate CM Vcams when the only one singleton antipattern brain then manages... During the HUGE split screen refactor process I've made it each Camera Trigger to resolve which brain must respect this specific VCAM or a dolly track... And then... The most important part of it was coding my CameraTrigger to manage the Brain of whoever player triggered the trigger. It turned out that the SetCameraOverride public but anti advised API gives almost full control but you must maintain you own blend states - which in my case I mixed with DoTween's Easing myself - a lot of flexibility indeed... But you have to then ReleaseCameraOverride when you are done with manual mixing blends.

Another thing I did was to allow ActiveVirtualCamera to be SET and hacked a lot of things into the TopCameraFromPriorityQueue() - it's not that hard to add extra bool field to never use this queue and this default behavior in the first place but to instead use a VCAM override setter. You can even subclass CinemachineBrain and just overload whatever you want - works!

With the TopCameraFromPriorityQueue, maintaining the automatic blends then almost went for free to me but weasnt as flexible as manually using the Override API.

Is sad that unity employees (devs too) want to give us something modular but it's true quirks and best features are either not well documented and they want to force us to use that thing in a way it's not optimal. LAYERS for example... When you have 50 scenes and over 200 VCAMS and dolly tracks everywhere and had only one cinemachine brain but now want ordinary number of brains to just work out with your level design, the easiest thing to do in my case is to make these brains not that brainy but instead to control them by the game logic itself
Player X on that 4x 2x2 table split screen entered room Y? It's the room that controls all player s' Cinemachine Brain and in this case the room merely needs to ask this specific brain to use this specific VCAM.
It was obvious that Cinemachine was indeed designed with Split Screen in mind but like anything in unity, there is one tip of the iceberg that tries to break the entire thing.

At least it is an easy fix, however this API should be there! Should be documented and the Brain should have ways to manually control into which VCAM you blend... Oh and, there's already such a way. Why it's documented in such a way like you pulled down someone's pants? Why in the entire thread @Gregoryl is advising against modding the package, but to use layers? In this forum there are fellow programmers too, and supporting them is also a thing - after all, encapsulation You don't need to encapsulate use cases! Unity has 32 layers that was originally created for rendering but then also abused for physics. Ouch. It will take ton of time and effort to set ton of layers. Well at least in CM3 channels give us the way to overcome the layer nonsense but what if you destroy the active VCAM? The camera cuts instead of to blend with its previous camera... I ended up modifying CM3.3 and CM 2.1 to always blend no matter what even though for the more complex stuff I just use the Camera Override with manual blend factors API - It's the best.

Encapsulation (private APIs) is usually good thing but in case with Unity, it gets abused a lot. Your "library cores" that do math aren't truly "private" - they can be used for similar purposes too. I've made lots of things public instead of internal in CM2.2. The default BRAIN must only be an example that serves most designer-centric use cases. The Brain is that algorithm that picks which camera to be used next or based on circumstances - giving it flexibility is nice and definitely important - documenting it too.

But about modding it - Modding any Package in fact - this is another serious Unity design flaw where people didn't think about programmers and tinkerers! In the professional world where we use git we have the git submodules - and we can keep local modifications, aven commit them to our branch, and merge with the upstream - Package Manager have to mature enough to allow package modding and resolve diffs and local changes.

Unity itself matured really fast on this, Safe Mode wasn's a thing in 2017 and Safe Mode is a lifesaver, really lifesaver. It's sad that I still need to keep 2 unity projects so i can do folder level DIFFing when a package updates and I have embedded it into my project.

Also, subclassing CinemachineBrain may have some editor side effects but in my case it worked.

Sorry for the long post that turned into political.
I really want to see UT themselves make and publish an AAA game!
This will make you guys understand us well. and most use cases that can get hacked too

 

Mostly for CM 2.X users,

Method 1:

1. Embed CM as asset or setup git submodule or somehow make it sure you can alter CM
2. Edit Cinemachine Brain. To allow overriding the VCAM it picks, you can alter the TopCameraFromPriorityQueue.
Alternatively you can subclass the brain and override this method

Method 2
Your can use this without embedding cm and it works with 3.x, gives ton of flexibility but it's also harder:

1. Make sure you track your blend factors yourself. In this case use the SetCameraOverride and don't be worried by the comment there. You have to track this and call ReleaseCameraOverride when done.

Method 3 that have some issues is adding a setter for the Current Camera.

The use case for this is a split screen setup with multiple cinemachine brains that must use triggers and dolly tracks that are part of the world itself but just be associated dynamically based on which player enters a trigger that sets camera effect.

I myself ended up by mixing method 1 and method 2.

The rant was merely because of me reading the entire thread and usually getting the "use layers" instead of "mod this and that". Though the SetCameraOverride was mentioned! I really suggest to change this comment to mention "advanced use". It's there because of the timeline but it's usable anyways. Virtual cameras are interfaces and we programmers love interfaces

BTW sorry for being that ranty, things like the package manager are really hindering sometimes and modifying packages is hard but should in my opinion not be advised against.

Cinemachine itself is really really well written thing and it's orders of magnitude more usable and abusable than some other things in unity.
The abusable part as well can be documented and endorsed too.

In addition the project I had was so huge so that was the best thing I could do - male it work programmatically instead of altering 50 scenes to add support for 4 players based on the spilt screen demo.

Suggestion to Cinemachine devs: add more featured split screen demo that have big world with dolly tracks with an example of how to subclass the brain to dynamically track players and starts the dolly closest to the player it photographs. Snapping to the closest dolly and blending with it is really fun thing and very possible with minimal code. And don't forget that you also have programmers in your userbase. It's sad that many people go for visual scripting and "configurable logic", but Cinemachine is a gem itself and with some coding it can really shine more that intended by design

Hope this post helps devs that add split screen late in their development, and those who end up here (this was first result in my Google search).

 

@Gregoryl Can you guys at least mark the TopCameraFromPriorityQueue as virtual protected instead of private in CM 2.x? This makes possible way too many things by a subclass, like the example below.

Following code is literally whatever I ended using at the end:

1. Setup: 2 or 4 cams in a split screen setting with this SplitScreenCMBrain component. Additionally 4 separate VCAMs with transposers each set to follow the player it belongs to. All these Split Screen CM Brains have their DefaultPlayerVCAM to the VCAM that follows their player.

During runtime, if a player enters a dolly trigger, the dolly trigger class resolves that player's brain and calls on it "AddVirtualCamera" with given priority. The camera trigger itself instantiates a copy of the templated dolly that gets removed once the player leaves the trigger, in which case the trigger calls RemoveVurtualCamera on the Split Screen CM Brain it controls.

I also have static cameras that merely call AddVirtualCamera / RemoveVurtualCamera on whoever enters/exits that trigger.

Here is the code of the SplitScreenCMBrain - but you have to modify the base class as of now to make the method in question TopCameraFromPriorityQueue a virtual protected.

Code (CSharp):

1.  
2. public class SplitScreenCMBrain : CinemachineBrain
3. {
4.     public CinemachineVirtualCameraBase DefaultPlayerVCAM;
5.     public Dictionary<CinemachineVirtualCameraBase, float> ExtraCams;
6.  
7.     public void AddVirtualCamera(CinemachineVirtualCameraBase cam, float weight)
8.     {
9.         ExtraCams.Add(cam, weight);
10.     }
11.  
12.     public void RemoveVirtualCamera(CinemachineVirtualCameraBase cam)
13.     {
14.         ExtraCams.Remove(cam);
15.     }
16.  
17.     public void ForgetAllExtraCameras()
18.     {
19.         ExtraCams.Clear();
20.     }
21.  
22.     public override ICinemachineCamera TopCameraFromPriorityQueue()
23.     {
24.         // extraCams set on this brain take precedence over anything
25.         if (ExtraCams.Count > 0) return ExtraCams.OrderByDescending(x=>x.Value).First().Key;
26.  
27.         // if no extra cam, prefer the default player vcam
28.         else if(DefaultPlayerVCAM != null) return DefaultPlayerVCAM;
29.  
30.         // and in case that isn't set fall to the default rules
31.         else return base.TopCameraFromPriorityQueue();
32.     }
33. }

 

Private thing that goes to protected is not truly an `API change` - exposing a member for subclassing won't break anything.
The code above works with CM 2.1 but only requires changing one single line in CM: the "private" to "protected virtual" in CinemacniheBrain.cs - and it looks dope in the inspector too - truly what a subclass is best suited for