Search Unity

  1. We are migrating the Unity Forums to Unity Discussions by the end of July. Read our announcement for more information and let us know if you have any questions.
    Dismiss Notice
  2. Dismiss Notice

Can I use 2 camera with Cinemachine Brain?

Discussion in 'Cinemachine' started by fmacro, Jul 14, 2017.

  1. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    If that's the case then you will have to embed CM into your project and change it directly. Using the layers would be much simpler, don't you think?
     
  2. bvance

    bvance

    Joined:
    Oct 25, 2012
    Posts:
    13
    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.
     
    TJHeuvel-net likes this.
  3. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    838
    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.
     
  4. bvance

    bvance

    Joined:
    Oct 25, 2012
    Posts:
    13
    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!)
     
  5. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    What if we just decoupled the vcams from the layer bitmask? Instead of using the layer and filtering with the camera's culling mask, we just make our own vcam channel resource, like we do with Impulse channels? That would be a fairly easy mod. The limitation would be the number of bits in the mask, like with layers. Would that suit your needs?
     
    ModLunar and TJHeuvel-net like this.
  6. TJHeuvel-net

    TJHeuvel-net

    Joined:
    Jul 31, 2012
    Posts:
    838
    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.
     
    ModLunar likes this.
  7. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    There are many use-cases where vcams are in prefabs, and having explicit references between them and brains becomes problematic. I would prefer an automatic discovery mechanism, such as is achieved by the layer strategy. If you want to manage explicit lists, you can make your own logic that does that and handles the layers under the hood.
     
  8. stonstad

    stonstad

    Joined:
    Jan 19, 2018
    Posts:
    676
    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.
     
    ModLunar and Gregoryl like this.
  9. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    Thanks all for the valuable feedback. What we will likely do is keep the auto-selection mechanism, but decouple it from the layer system. That means that you can assign vcams to a Brain by assigning them to a CM channel, which you define via an asset.
     
    ModLunar, TJHeuvel-net and stonstad like this.
  10. Skotrap7

    Skotrap7

    Joined:
    May 24, 2018
    Posts:
    125
    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?
     
  11. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    Skotrap7 likes this.
  12. Skotrap7

    Skotrap7

    Joined:
    May 24, 2018
    Posts:
    125
    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!
     
    Gregoryl likes this.
  13. vs743

    vs743

    Joined:
    Feb 10, 2020
    Posts:
    2
    This is an amazing answer. Thank you!!
     
    Gregoryl likes this.
  14. betomaluje

    betomaluje

    Joined:
    Mar 23, 2019
    Posts:
    18
    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;
     
  15. ModLunar

    ModLunar

    Joined:
    Oct 16, 2016
    Posts:
    374
    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?
     
    Marc-Saubion and TJHeuvel-net like this.
  16. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,355
    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
     
    ModLunar likes this.
  17. LeviTM

    LeviTM

    Joined:
    May 28, 2021
    Posts:
    2
    I know this is a little late, but this video helped so much! Thank you for posting this here; it was perfect.
     
    ModLunar likes this.
  18. sunwooz

    sunwooz

    Joined:
    Nov 9, 2012
    Posts:
    10
    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?
     
  19. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    Sometimes people want to have the vcams in a separate unity scene, and you can't have cross-scene links. That's why the CM Brain dynamically finds the vcams.
     
    far20shid likes this.
  20. gg_michael

    gg_michael

    Joined:
    Sep 24, 2012
    Posts:
    73
    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?
     
  21. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    @gg_michael It is indeed something that has been requested, and we haven't ignored it. The upcoming CM 3.0 has decoupled Cinemachine from the layer system by introducing the concept of "Cinemachine Channel". You assign your vcams to a channel, and configure the brains to monitor one or more channels. You still can't directly set the "current active vcam" field in the brain, but you can indirectly control it with the priority system or by calling vcam.Prioritize().
     
    ModLunar, gg_michael and Yuchen_Chang like this.
  22. Baste

    Baste

    Joined:
    Jan 24, 2013
    Posts:
    6,355
    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.
     
    Yuchen_Chang likes this.
  23. gg_michael

    gg_michael

    Joined:
    Sep 24, 2012
    Posts:
    73
    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?
     
  24. ModLunar

    ModLunar

    Joined:
    Oct 16, 2016
    Posts:
    374
    @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!
     
    Gregoryl likes this.
  25. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    Yes, there have been a lot of changes, notably in the API. We've taken the opportunity to address many long-standing issues that were difficult to address without significant API changes.

    We have made a tool to help upgrading existing projects, but you should note that any custom scripts you may have that use the CM API will probably have to be manually upgraded. More details are available here, in the upgrade guide: https://docs.unity3d.com/Packages/com.unity.cinemachine@3.0/manual/CinemachineUpgradeFrom2.html

    CM 3.0 is still in development, and we will continue to release preview versions as we iron out the bugs and other issues. Note that CM 3.0 requires minimum Unity 2022.2, and is expected to be the default CM version starting in 2023. We will continue to support CM 2.X for a considerable time, so please don't feel pressured to upgrade projects that already have significant investment in the CM 2.X API.
     
    Last edited: Nov 12, 2022
    ModLunar likes this.
  26. xucian

    xucian

    Joined:
    Mar 7, 2016
    Posts:
    854
    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).
     
  27. petersvp

    petersvp

    Joined:
    Dec 20, 2013
    Posts:
    63
    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 :)
     
    Last edited: Oct 22, 2023
    xucian likes this.
  28. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    @petersvp Thanks for the rant, but not sure that I see any specific action items for us in there. Care to summarize?
     
  29. petersvp

    petersvp

    Joined:
    Dec 20, 2013
    Posts:
    63
    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).
     
    Last edited: Oct 23, 2023
  30. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    @petersvp Thanks for the kind words. Cinemachine is open-source for a reason, which is to allow clients to customize it through modifications. That said, I'd rather work on improving the interfaces than start endorsing and encouraging forks and code mods. There more you have local mods, the harder it is to incorporate future CM upgrades and bugfixes. It really should be a last resort.

    In CM3, the API-friendly way to make a new object that selects CM Cameras in a customized way is to write a new class that inherits CinemachineCameraManagerBase. That's what it's for.
     
    Last edited: Oct 23, 2023
  31. petersvp

    petersvp

    Joined:
    Dec 20, 2013
    Posts:
    63
    @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 :D 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. }
     
  32. Gregoryl

    Gregoryl

    Unity Technologies

    Joined:
    Dec 22, 2016
    Posts:
    7,842
    @petersvp Actually that's a pretty good idea. I can't do it in CM2 because it's an API change, but I can do it in CM3.

    That said, your use-case is a good candidate for the Override API, which gives you what you need without any CM code changes, it seems to me.
     
    Last edited: Oct 25, 2023
  33. petersvp

    petersvp

    Joined:
    Dec 20, 2013
    Posts:
    63
    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 :)
     
    Last edited: Oct 25, 2023
    xucian likes this.