UE5 Gameplay Cameras: The Basic Design

This is the seventh post in my developer diary for the Unreal Engine camera system. Since the last post was a super high level view of what the system is supposed to be, I figured I would just go down one step for this article and share some notes about the general design. This might be particularly useful since the official Unreal Engine documentation doesn’t usually cover “experimental” plugins, and we’re probably one release away from upgrading GPC to “beta”.

Camera Director, Camera Rigs, Camera Nodes

The basic design is pretty simple at first glance. There’s a Camera Director, which decides what Camera Rig(s) to run. A Camera Rig implements a desired camera behaviour, such as “follow a character, a bit to the side, with some lag”. This is implemented with Camera Nodes, where each element of the desired camera behaviour might be a Node, like, say, a Follow Node, an Offset Node, and a Lag Node.

Camera Rigs typically run inside a Blend Stack. When the Camera Director changes its mind and wants a different Camera Rig to run, the new one is pushed on the Blend Stack so that the resulting point of view smoothly transitions to this new camera behaviour.

The logic of the Camera Director is an implementation detail: the camera system doesn’t care about it, as long as it can produce a decision every frame or, well, once in a while at least (if no decision is produced, the system keeps running the same Camera Rig). Your Camera Director may be a state machine, a priority queue, some Blueprint spaghetti logic, custom C++, etc… or a combination of all of the above! (but we won’t go into this now)

Camera Rigs produce a point of view by running a tree of Camera Nodes. These Nodes act as a sort of “pipeline”, each taking the output of a previous Node as their input. So the Follow Node would set the point of view to the location of the character, the Offset Node adds an offset from there, the Lag Node dampens this offset position, and so on.

I usually love using this next picture as an analogy, because I’m a sucker for some Kubrick references:

This is of course Stanley Kubrick (left) and Garrett Brown (right), on the set of The Shining (1980). Brown is carrying his Steadycam prototype, which was extensively used in the movie and was still pretty ground-breaking at the time. The overall picture describes the system pretty well:

• Brown and his Steadycam are a Rig, with the Nodes being, say, Brown’s legs, the Steadycam’s harness, the articulated arm, the gimbal, and so on.
• Kubrick is the Director, calling for a specific shot (e.g. follow Danny through the maze at a distance) and then a different shot (e.g. push into a waist-up framing of Danny) or cutting to something else altogether (e.g. looking at Jack or Wendy). Okay that last one is done during editing much later in reality, but this happens all at the same in a real-time application. I didn’t say the analogy was perfect!

Camera Data Pipeline

As I said above, the Camera Nodes act like a sort of “pipeline”, where camera data passes through each one of them, and they each do one thing to it. But a notable thing here is that the camera data isn’t just, say, a Transform and a Field Of View.

The camera data also includes body and lens data (sensor size, focal length, focus distance, etc.), Post Process Settings, a Variable Table (containing arbitrary blendable values), a Context Data Table (containing arbitrary non-blendable data), some information on the Camera Rig’s “structure” (such as pivots, or degrees of freedom), and so on. This lets Nodes and clients of the camera system process and harvest richer data, including custom, game-specific information.

Putting It Together

That’s pretty much all there is to it at first glance. The Gameplay Cameras system runs a Camera Director and a Root Camera Node: Blend Stacks are Camera Nodes too so the system doesn’t even have to know much about them, and it’s therefore all under that Root Camera Node.

Of course, there’s more going on if you look closer, and the camera system API has a few extra bits, like the Evaluation Context Stack (which you could summarize as a stack of Camera Directors, for pushing/popping control overrides) or the Evaluation Services (which run general logic). But the general design of Directors, Rigs, and Nodes is really the simple heart of the system.

Nothing much to add here — it’s a pretty simple and straightforward design after all. Devil’s in the details and all that, of course. But until we get to that, have fun!