CM3 missing method: CinemachineBrain.GetAllVirtualCameras() or equivalent?

Unity Engine
,
1

I’m assuming CM has this information (how else can it decide which vcam to use?) but it’s missing from the API. Why is this missing?

(I find very often having to do this, because CM3 requires me to manually update every vcam’s target in the scene every time the target changes or a vcam is added. Which is often)

I can obviously estimate it by manually searching the scene, but this feels a bit stupid when CM has the ‘official’ list of what vcams exist.

2

You can find a list of active vcams in CinemachineCore.VirtualCameraCount and CinemachineCore.GetVirtualCamera(index). There is no repository of inactive virtual cameras.

This is surprising and unexpected. Why do you need to access all the vcams when a new vcam is added?

One convenient way to implement a dynamic target is to use a CinemachineTargetGroup with a single member. Let all your vcams target that, and then just swap out the member whenever you like.

1 Like
3

Vcams are constantly being created and destroyed. Prefabs, right? And Scene changes (especially: additive ones). Two unity features we use … quite a lot :).

As far as I can tell, the TargetGroup is not for this, TG only takes a couple of lines of code for anyone to re-implement themself without it, but leaves all the annoying boilerplate lines of code left to write and still have to be re-written on every project.

Unless I’m using it wrong, and reading the docs wrong, with a TG, I have to:

  1. Any time a vcam is instantiated, anywhere, write custom scripts to detect that and manually assign them to use the TG ← this is half the work, and for some reason I don’t undertsand: CM refuses to facilitate this
  2. Any time the target changes, write a custom script to update the TG ← that’s fine, that’s only 1-3 lines of code

Without TG, I have to do … exactly the same, the only difference is that I have to store a global var somewhere of “what is the current tracking target”. But I have to store a reference to the TG in order to use it, so, actually, TG saves me precisely: nothing. It’s the same amount of code as if it didn’t exist.

4

So, for instance, what I would expect an API like CM3 to do, in order to be ‘unity compatible’ is:

  1. ‘TrackingTarget’ has a checkbox toggle for “use Brain’s default”
  2. Brain has a ‘default tracking target’
  3. … nothing else has to be done: vcams that are configured to use the default from the Brain … use the default from the Brain. If you need to chage the global target: you call the API methods to grab the global brain / grab your main camera and its brain, and directly update it.

CM3 has been a good step forwards to making CM into a ‘Unity’ package. But in this area (tracking) it feels like the new setup is still like traditional CM: not written for Unity, architected by someone who wasn’t a Unity user / didn’t really understand how Unity works and the different pieces fit together.

unless I’m still missing something here - I haven’t fully upgraded all my projects to CM3 yet, some are still on CM2, so I’m still gradually discovering changes and ways of porting the old code (some of my code is quite complex customizations of CM2, so it’s a rolling upgrade, where I try to use more features in CM3 each time I upgrade a project)

5

Additionally: TargetGroup appears incomplete in my current version? (3.0.1 - UPM is claiming this is current) - it can be assigned in the Inspector, but the API doesn’t support it, in script you can only assign “Transform” to a vcam.Target.TrackingTarget (the source code copy/pasted below), and there appears no alternative field to assign to:

/// <summary>Object for the camera to follow</summary>
        [Tooltip("Object for the camera to follow")]
        public Transform TrackingTarget;
6

…yep it breaks horribly. TrackingGroup is unusuable here: adds nothing and causes tracking to go haywire. Back to the code I had that works: do it manually (but lots of annoying boiler plate that IMHO CM should be doing)

7

Still not sure what you’re trying to accomplish with targetgroup in particular, but you can put a single script on your vcam prefab that takes care of “boilerplate” setup. No need for some central authority to monitor all vcams for this.

1 Like
8

Your suggestions are interesting, but they are “one-target-centric” and CM is designed to not make any such assumptions. Not being complete for any one use is a side-effect of trying to help everyone.

Using the target group would eliminate the need to iterate the vcams and update their targets, which was the issue you mentioned. If you have a new target, clearly you have some code somewhere that instantiates it and does the bookkeeping. Just add a line there to put it in the TG.

I don’t understand what you mean when you say it breaks horribly. For me it works just fine. What behaviours do you have on the vcam? Maybe you have some other code that isn’t suited to this paradigm?

To assign a target group as a vcam target, just put the TG’s transform in the tracking target field.

And yes, what @halley1 said.

9

A good way to do that would be to hook into the CameraActivated event and take that opportunity to update the target.