Gameplay Cameras - Intended setup for transitioning between focused actors.

Development Programming & Scripting
, ,
1

Hello,

We’re currently exploring using the Gameplay Cameras system in our upcoming project, so far it seems like a very powerful and intuitive system however I have a couple questions about the intended usage for specific scenarios:

1) According to the documentation:

> The system is designed to be modular, with Camera Assets that can be ingested by one or more Gameplay Camera actors and components. This means you can author your camera behavior once, and use it on many actors in your scene.

Based on that I would expect the gameplay camera component to live on the pawn that is controlled and for it to activate the camera for the player controller that possesses it. However when doing this and changing possession we need to activate a new camera for the player controller and I can’t find a good way to make a smooth in-world transition for the camera from one pawn to the next.

2) Alternatively I tried placing the camera on the Player Controller, if I do this and replace the “attach to player pawn” node with some code in the controller itself (attaching the controller to the controlled pawn so the gameplay camera moves with it) and adding a limiter node in the camera so it smoothly interpolates when the controller moves over to the new pawn.

I’m thinking of replicating this in a new “follow player pawn” node I can write instead of having the controller follow it’s controlled pawn. But before I do that, am I going down the wrong rabbit hole? Is there an intended way that I’m misunderstanding for smoothly transitioning between different camera assets or different controlled pawns?

3) Finally, when switching between different pawns, I’m not sure if we should have all the rigs for the camera attached to the same camera asset, or if it’s mroe sensible to have separate assets for different “categories” of pawns, say for example a character and a vehicle, I’d like to have a smooth transition between the character camera and the vehicle when entering the car, however from the above, I’d require all my rigs to live in the same camera asset, and therefore adding a pinch-point on the camera director which now needs to manage the context for all different types of actors, unless I’m missing something?

Sorry for the block of text, hope this all makes sense and you’re able to offer some guidance.

Thank you,

Gualtiero.

2

Steps to Reproduce
Create an empty 3rd person project.

Create a 3rd person gameplay camera (with attach to player pawn and a boom arm for example)

Add Gameplay Camera component to character

Add 2 more characters in the level

In Level Script add Debug-key nodes and change possession for the 1st local player controller to a new pawn.

3

Hello! Thanks for checking out the Gameplay Cameras plugin. As you might expect, it’s still highly experimental and quite in flux.

> Based on that I would expect the gameplay camera component to live on the pawn that is controlled and for it to activate the camera for the player controller that possesses it. However when doing this and changing possession we need to activate a new camera for the player controller and I can’t find a good way to make a smooth in-world transition for the camera from one pawn to the next.

In UE 5.6 each Gameplay Camera (GPC) component runs its own camera system instance internally, and can be thought simply as a “standalone camera that moves on its own”. While the pawn is possessed, it typically is set as the View Target, and we therefore see through the GPC component that exists on it. If you have a GPC component on another pawn and you possess that pawn, that would change the View Target to that other component. Using SetViewTargetWithBlend would blend between the two, so you can do that on possession (watch out for the player controller trying to auto-manage the View Target, see bAutoManageActiveCameraTarget). So in this sense, GPC components behave exactly like any other camera component.

Being able to use the GPC transitions and blends to switch between pawns and, therefore, between view targets, would require a PlayerCameraManager that is aware of GPC. There is one (see AGameplayCameraPlayerCameraManager) but it’s only a proof of concept for now (I plan to do some more work on it for 5.7). Is that what you were asking about?

Also, note that the camera evaluation implicitly “starts” where the “owner” of running camera rigs is. So in the case of a GPC component, all the camera rigs implicitly run with a starting transform set from the GPC component’s transform. Basically, you get attached to the pawn character “for free”, and don’t need the Attach to Player Pawn node (you may need that node in other cases, such as if you’re running a camera from a GPC component placed elsewhere in the world).

> Finally, when switching between different pawns, I’m not sure if we should have all the rigs for the camera attached to the same camera asset, or if it’s mroe sensible to have separate assets for different “categories” of pawns

I would expect to have different assets indeed. If your game lets the player control different types of pawns, each pawn should probably have its own camera asset with its own camera rigs, assuming they’re different enough. For instance, if you can switch between a big slow robot and small fast drone, I would expect two camera assets with little overlap.

4

Hello Ludovic,

Sorry it took a while to respond, we were in the process of updating to 5.6 and I wanted to play around with the changes you made before getting back to this question.

I think my confusion was due to the auto-managing of view targets, I managed to get the desired effect now in 5.6

> Being able to use the GPC transitions and blends to switch between pawns and, therefore, between view targets, would require a PlayerCameraManager that is aware of GPC. There is one (see AGameplayCameraPlayerCameraManager) but it’s only a proof of concept for now (I plan to do some more work on it for 5.7). Is that what you were asking about?

Yeah, blending between view targets does the job however the “definition” of the blend when changing possession then lives outside of the cameras into some code or blueprint triggered on possession, I think it would be nicer if the transition definition lived inside and behaved similarly to the GPC transitions.

Thank you for your help :slight_smile:

5

> however the “definition” of the blend when changing possession then lives outside of the cameras into some code or blueprint triggered on possession

Correct yes. I’m actually not sure how to fix that… by definition, SetViewTargetWithBlend will set the new view target as “pending” in the default camera manager, and will then blend over the previous view target based on the blend params passed via C++/Blueprint at the call site. The new view target actor could evaluate some GPC transitions and come up with an appropriate blend, but there’s no existing way that I know of for this to be set on the camera manager… if anybody knows something I don’t, or has a good idea to solve this, I’d love to know! :slight_smile:

Cheers!