System for changing camera angles

[vjs22334]

Card : https://open.codecks.io/unity-open-project-1/decks/15-code/card/1ak-special-camera-angles
Forum : https://forum.unity.com/threads/camera-cinematics.1051310/
I have implemented the approach I posted in the thread above. I have created a scene : Scenes/Examples/CameraSwapTest where you can test the new system. I have basically created a prefab with a trigger collider which when the player walks into will raise an event for the camera manager to swap the live virtual camera with the one set in the trigger.

[ciro-unity]

Added a few considerations

[vjs22334]

I have added generic colliders and an option to the prefab to use the entire volume of the collider along with the previous functionality. You can test it out in the test scene, where I have set it up with a capsule collider. I believe these 2 options will cover most of the scenarios which may arise. Is there a specific scenario which you see requiring compound colliders? because it can lead unexpected situations as the callbacks of each child collider will be independent

[vjs22334]

Updated the system to work with compound triggers (colliders). The camera will now be swapped when the player enters/exits the volume of the collider. All colliders should be added as children of the parent gameobject of the prefab and should have the CameraSwapTriggerChild script on them. the child scripts will listen for OnTriggerEntry and OnTriggerExit call the parent which will keep track on whether the player is inside the compound trigger.

[vjs22334]

All requested changes have been made

[ciro-unity]

Sorry, needed some time to evaluate this. Some thoughts:

We might need to implement two types of colliders: one that is like, "turn this VCam on when entering, turn it off when exiting". This is good for colliders that you can access from all sides.

The other type (useful for situations like the trunk or tunnels) would be: "turn this VCam on when entering, do nothing when exiting". This could be used so that there's two different VCams running on the same track, like in the trunk example, and each one can follow the player from behind (so they'd need different settings). This way we can have two entrances (on both sides of the trunk) and depending on which side the player enters from, we activate the correct VCam. I believe it's the only way to avoid the Vcam doing weird gymnastics and going through walls, which happens now when you enter the trunk with the Vcam in front of you from the wrong side (imagine it's already above the trunk), which forces it to go through the trunk's roof to reach the position "in front of you but inside the trunk". If we had two cameras, as you walk inside the trunk and the camera is above it, it would do a spherical motion and transition to "behind you", so that it can follow you walking into the trunk.

The other thing is that we don't need the CameraSwapTriggerParent.cs and CameraSwapTriggerChild.cs combination to make compound collider work. We can use a script on the root that has an int variable inside keeping track of how many colliders are active at the moment. If for instance the player is going out of the last collider, this number would be 0, so the event can be fired.

Something like this:

private void OnTriggerEnter(Collider other)
{
	if (other.tag != "Player")
		return;

	colls++;

	if (colls == 1)
		VcamEventChannel.OnEventRaised(cameraToSwap);
}

private void OnTriggerExit(Collider other)
{
	if (other.tag != "Player")
		return;

	colls--;

	if(colls == 0)
		VcamEventChannel.OnEventRaised(null);
}

Here's a video of the current system, as you can see it works only if you approach the trunk from one side:

WorkDontWork.mp4

What do you think?

[vjs22334]

If we add the second type of collider, we would need another collider to switch the camera back to default (free look) when we leave the trunk. so we would have one collider just outside the mouth of trunk for free look on just inside for the rails cam on each side for a total of 4 triggers. I don't really see a better option than this. I could go back to my previous version of checking along the z axis of the collider but that feels hard coded and confusing to a level designer.

Regarding your 2nd point about using an int on the parent to keep track of collisions, that is what I did initially but when I put a rigidbody on the parent, the pig chef was always triggering ontrigger events twice. the capsule collider and character controller each seem to trigger it. while this won't be a problem as it will increment and decrement twice. I thought using child collider scripts and booleans is more robust in terms of avoiding this kind of issues. let me know what you think about this @ciro-unity

[vjs22334]

I think I found a better way to resolve the Issue we had of needing "two cameras running on the same track". Since we had a child trigger system already. I thought maybe we could choose the camera based on which child trigger was entered. So I added a camera field to the child trigger which is the camera which will be used if that child is entered. if that field is empty the parent's
camera will be used instead. I feel this system gives a lot of customization options. we can even add a field for which camera to swap to on exiting a trigger in future if required. Let me know what you think.

Here's a video:

child_triggers_with_different.cameras.mp4

[ciro-unity]

Haven't forgotten about this, I'm just waiting until we have some more finalised scenery so we can put it to test in a real scenario!