UE5 Gameplay Cameras: Parameterization

This is the third article in my developer diary about the Gameplay Cameras (GPC) plugin for Unreal Engine 5. It comes a day late because my workspace is in the middle of a big refactor — nothing compiles and I can’t take screenshots! 😅 In the end, I used some old screenshots and videos I had captured a couple weeks ago… oh well.

One of the big improvements in GPC that you’ll see in UE 5.6 is what I call the “parameterization” of Camera Rigs. This is a fancy made-up term that refers to the various ways you can pass values and data into a running Camera Rig, and somehow use that to affect its behaviour. Let’s look into it!

In UE 5.5, camera parameterization was pretty basic and experimental. You could “expose” some Camera Node’s property and set it, either on a Camera Rig Prefab node or via a rather clunky and limited Blueprint workflow. For UE 5.6, the workflow is much better and supports more types. It’s still a work in progress as I write this, though.

The first thing you’ll notice in the Camera Rig asset editor is a new “Parameters” panel. There are two types of parameters in there: “blendable” parameters and “data” parameters.

• The first type of parameter is what was supported before. It’s a fixed set of blendable types like integers, floats, vectors, and so on.
• The second type of parameter is new, and is for non-blendable types like strings, enums, actor references, arbitrary structures, etc.

Just as before, you connect the parameter node to a compatible property pin on a Camera Node, but now you have more control over your Camera Rig’s parameters since you explicitly create and manage them in the Parameters panel.

The main reason that “blendable” parameters are separate from “data” parameters is because they’re handled differently. Blending stuff is the heart of a camera system, and you should know what happens to your values. In particular, blendable parameters have an option for “pre-blending”, which you can see in the screenshot. I’ll talk about pre-blending in depth in a later article.

You can connect more things to Camera Rig parameters, too. For instance, the Blueprint Camera Node now exposes compatible public variables from the referenced Blueprint as parameter pins. In the following two screenshots, my Camera Node Evaluator Blueprint has two public properties that now show up as pins on the node.

Parameters exposed on all Camera Rigs referenced by a Camera Asset (generally via its Camera Director) are available on that Camera Asset. In the screenshot below, a Gameplay Camera Actor references “CA_FixedAim“, whose Camera Rigs expose three parameters (a float, a structure containing an actor reference, and a string). You can override the default values directly on the Gameplay Camera Actor if you simply need to set fixed values.

For dynamic overrides, there are now Blueprint setter functions that you can call on the Gameplay Camera Component. In the screenshot below, you can see calls to either single-setters (i.e. functions setting a single parameter value) or multi-setters (i.e. functions setting all parameters in one go).

But now, you might wonder where those values really go when you set them, and what that “Camera Data” pin means.

The problem I faced was that a Gameplay Camera Actor that runs, say, Camera Rig “CR_FixedAim“, doesn’t have a single instance of it that it can give you so that you can set parameter values on it. That’s because these Camera Rig instances come and go all the time. You could blend out from “CR_FixedAim” but immediately blend back into another instance of it, with something else “sandwiched” between the two in the blend stack. Or you could simply push new instances of it on the blend stack and have three or four of them running and blending together. So what does it mean to set parameter values on “CR_FixedAim“? Which instance(s) get the parameter value?

Well, I’ll probably do an in-depth article on that topic in the future, but to keep it short for now, the new Blueprint functions set parameter values under a given Gameplay Camera Component, for either “all running Camera Rigs” or “only the active Camera Rig”. By “active”, I mean “on top of the blend stack”.

For instance, if you have two Gameplay Camera Actors that are both running “CR_FixedAim“, setting parameter values for the actor on the left would not affect instances of “CR_FixedAim” run by the actor on the right.

As for which instances of “CR_FixedAim” receive the new parameter values, that is determined by this “Camera Data” that the setter functions take as input. From the Gameplay Camera Component, you can either get the “Shared Camera Data” (used by all running Camera Rigs from that component), or the “Conditional Camera Data” with an “Active Camera Rig” condition (used only by the active Camera Rig from that component, if any).

Setting parameter values only on an active Camera Rig allows doing things like pushing a new instance of “CR_FixedAim” with a different target actor to look at. Any previous, still running instances of “CR_FixedAim” aren’t affected, and so the new instance can blend on top of the old one, using whatever transition rules match this situation:

Disclaimer: of course, this is all programmer art for the purpose of demonstrating a feature. You wouldn’t necessarily do target switching this way. You could just as well switch the target on the same Camera Rig instance but use some rotation damping or transform interpolation to make the switch smooth. Or you could also dynamically manipulate the player camera’s rotation if it all needs to happen as if the player themselves had looked at the target using their gamepad or mouse. I can think of at least a handful of ways to look at something, all with different pros and cons. The point of the GPC plugin is to support most of them so that you can pick the best one for your use-case.

Anyway, here’s the same target switching, but with debugging information enabled, so you can see that two instances of “CR_FixedAim” are indeed blending on top of each other. Notice that the “Context Data Table” lists two different values for the “Target Info” parameter (they have two different static mesh actors).

There’s a lot to be discussed about dynamically changing Camera Rig parameters but that’s it for now!

In the meantime, you can check out this Inside Unreal live-stream about the Game Animation Sample Project. I tagged along some fine animation folks, showing off the Gameplay Cameras plugin in UE 5.5. That part starts around 49 minutes into the video. And yes, after the live stream I figured out what made Rewind Debugger crash on me, and you probably won’t be surprised to know the bug was indeed in my code 😆