UE5 Gameplay Cameras: Pre-Blending

This is the fourth post in my developer diary about the Gameplay Cameras (GPC) plugin for Unreal Engine. I skipped last week because I was too busy! This week let’s pick up on something I alluded to last time, which is “parameter pre-blending”. As always, everything I’m showing here is work-in-progress, scheduled to ship in UE 5.6. You can grab the code from Github and play with it early if you want.

What’s Pre-Blending

The term “pre-blending” is something I totally made up, but the concept behind it has been used for years in camera systems. I’m just not aware of any de facto standard term so I made up my own… I’d be curious to know how y’all call this thing!

Anyway, pre-blending is the idea that you don’t just want to blend the outputs of two cameras, but also their inputs.

When blending outputs, you run, say, two cameras, obtaining their transform, field of view, etc. Then you blend those to get the final transform, field of view, and so on. But let’s say these cameras run some logic that takes a certain number of input values like a boom arm’s length or a damping factor. If both cameras are running similar logic (maybe even the same logic), they would have some of these inputs in common. We can then pre-blend these input values. That is, we first blend the boom arm’s length and damping factor between the first and second camera’s values, then we run both cameras’ logic using the blended boom arm’s length and damping factor. Finally, we blend the resulting transform, field of view, and so on.

Time For Programmer Art!

In the GPC plugin, blendable parameters on your camera rigs are pre-blended by default, although I might change my mind by the time UE 5.6 is ready to ship. You can disable that if needed in the “Parameters” panel:

An obvious way to tell the difference between pre-blending enabled or disabled is with cinematic cameras. Well, maybe, I don’t know. It’s just that I’m currently working on integration with Sequencer, so I have some test content ready to record! 😅

Disclaimer: as always, this is just programmer art. I’m demonstrating features of the camera system, not showing best practices for building good cinematography!

What we have here are two cameras running the same rig, which frames the mannequin’s head bone in into a “dead zone”, shown in green below. The first camera has a moderately sized dead zone, and frames its target on the left third of the screen. The second camera has a tighter (smaller) dead zone, and frames the target in the centre of the screen.

Now let’s see a short sequence where one camera blends into the other without any pre-blending:

One camera frames the subject one way, and the other camera frames it another way. They run independently, and only their final transforms are blended. You can tell they’re each doing their own thing because, during the blend, you can see both dead zones and ideal framing points separately.

Now let’s enable pre-blending on the dead zone and ideal framing points:

Here’s what it looks like (and again, the point isn’t which one looks better, frankly I didn’t try to make anything pretty, I’m just demonstrating the principle).

As we blend from the first camera into the second camera, we see that first camera starts moving its framing to the centre, tightening its dead zone. The second camera starts with the same framing as the first camera, but then also goes towards the centre with a tighter dead zone. You only see one dead zone and ideal framing location in the debug HUD because both cameras’ values for them end up being identical and equal to the blend of the “original” values.

None of this is ground-breaking — most camera systems do this. The interesting thing (to me) is attempting to make pre-blending into a first class concept of a data-driven workflow.

Camera Rig Merging and Future Work

Now you might ask: why even run both cameras, at this point? Why not just continue running the same camera, animating its input values from one set of values to another set of values?

That’s a great question! In the GPC plugin, that’s called “camera rig merging”. That is: if we see that both cameras run identical logic (by noting that they run the same camera rig asset), then we can indeed “merge” both entries on the blend stack and only run that logic once, with blended values. I’ll go into more detail in a future article, because you can only sometimes get away with it. It really depends on what sort of blend you want, and what situation you’re into.

The last thing for today is going back to something I mentioned earlier: the two cameras might be running similar logic but not the same logic. For instance, they may run two different setups (camera rigs), but both involve a panning framing camera node, and you want to pre-blend the dead zones or whatever.

I don’t have anything in GPC to handle this situation yet, but what I have in mind so far is a new asset tentatively called “camera parameter blend table”. As you can probably guess, this would be a table that establishes (pre)blending relationships between sets of parameters. For instance, you could add an entry that contains MyCamera01.DeadZone, OtherCamera02.GreenZone, and WhateverCam.Blah, enabling pre-blending between these three parameters from their three different camera rigs. Note that these parameters only need to be of the same type to be pre-blended. They don’t all need to map to the “Dead Zone” parameter of a panning camera node specifically. You could therefore pre-blend the dead zone of a panning camera node to that of a dolly camera node, or to any other parameter of any other type of node (including your own custom ones!) as long as that parameter is of type FCameraFramingZone.

My hope is that by making pre-blending a general purpose feature of the system (as opposed to something written for specific camera modes and properties by a programmer), we’ll see technical animators making up cool stuff I can’t even imagine!

Did it all make sense? Do you have a better term than “pre-blending” for the same concept? Do you think the idea of a “camera parameter blend table” would work? Feel free to get in touch and tell me what you think! Until next time, have fun making games!