UE5 Gameplay Cameras: Upgrading to 5.7

Oh hey, look at the time! Another post in my developer diary for the Unreal Engine camera system, and a whole release went by that I haven’t posted anything about. Oh well, let’s see if I can pick the pace back up later. In the meantime, here are some notes and highlights for the Gameplay Cameras (“GPC”) plugin in the Unreal Engine 5.7 release that just went out.

Once again, while the GPC plugin is flagged “experimental” and, therefore, we don’t guarantee any backwards compatibility for it, I made a reasonable effort to keep most things working. Still, there are a couple of breakages we’ll talk about here. Also, if everything goes according to plan, the plugin will graduate to “beta” in 5.8, so fingers crossed!

Pre-Blended Parameters and Resaving Assets

TL;DR: After you run PIE, you’ll find a bunch of your camera assets may have been marked as “modified”, and the editor will ask you to save them. Just humour it and save them.

TL;DR 2: However, you may also find that some assets always ask to be re-saved. That’s due to a bug that will be fixed in 5.7.1. Sorry about that!

The main annoyance you’ll get with GPC 5.7 is due to the combination of a breaking change regarding camera rig parameters’ “pre-blended” setting, and how we now build camera assets before launching PIE.

On the one hand, I changed the default value for the “pre-blended” option on camera rig parameters, which is now disabled by default. It was stupid of me to enable it for boolean values, and it made things more confusing than helpful for other types. Handling this in a backwards-compatible way would have been a bit of a pain (custom asset versions and all) and wouldn’t have been as helpful in my opinion, so this was a rare occurrence of taking advantage of the “experimental” state of the plugin to make a breaking change.

On the other hand, I also changed how camera assets are built when running PIE. The new code does something similar to the auto-compilation of Blueprints: it looks at any currently loaded camera asset and builds those if they’re not up-to-date. This means the build coverage is a lot better than the old code, which prevents bugs related to outdated assets. However, it also means it will rebuild most of your camera assets the first time because they now have all kinds of camera rig parameters set to not pre-blend anymore (as mentioned above). This means the built data is slightly different, and therefore those camera assets will be marked as modified.

There is a bug with Property Bags (a variant of Instanced Structs) that also means that some of these camera assets might end up always getting modified on build. That bug will be fixed in 5.7.1.

Blueprints and Parameterization

The game studios I’m working with have embraced dynamic parameterization of camera rigs quite deeply, so some work has gone into Blueprint nodes to that effect. The main change here are the new “getter” nodes, which do what you expect them to do. Also, the “setter” nodes now return the set value for easier chaining of logic.

I plan to make it easier to do some sorts of value processing directly inside camera rigs, so hopefully that aspect of the system will get better and quite different in 5.8.

Camera Debugger Binding

Each Gameplay Camera Actor and Gameplay Camera Rig Actor may be running its own instance of the camera system, so you now need a way to specify which of these camera systems you want to “bind” to when displaying debug info if there are multiple instances in the level. The Camera Debugger tool has therefore gained the ability to do just that:

The “auto-bind” option tries to look up the Player Camera Manager and the current View Target to give you some useful default behaviour.

Note that there will be some cool new stuff regarding the GPC Player Camera Manager in 5.8 that allow using a “centralized” camera system for advanced transitions with “scattered” GPC actors — something we sort of lost in 5.6 when I deprecated the Camera System Actor. More on this later.

Asset Family Shortcuts

One of the problems with having re-usable assets is that things tend to get spread across many of them. For instance, a simple action/adventure Camera Asset might have a dozen of assets in total, between its Camera Director and the various Camera Rigs it can choose from.

This is a similar problem that character animators face, having to juggle meshes, skeletons, animation clips, physics, and more across as many assets. So taking “inspiration” from animation editors, I added some “asset family shortcuts” to all camera assets. They show up in the top-right corner of the editor tab, and look similar to the animation ones:

Generally speaking, you get shortcuts for Camera Assets, Camera Directors, Camera Rigs, and Camera Rig Proxies. The editor tries to figure out what other camera-related assets reference the current tab’s asset, or are referenced by it. The idea is that it should help you navigate back and forth between related assets.

For instance, a Camera Rig that is referenced by two Camera Directors:

Or a Camera Asset that references several Camera Rigs via its own Camera Director:

The version that ships in 5.7 only looks for direct references, which breaks down when you use intermediate assets like a Chooser Table or something. In 5.8 the reference searching goes a bit deeper and the shortcuts are more accurate.

As you might expect, there are a whole bunch of other little improvements and bug fixes. The full list is buried inside the “Gameplay” section of the release notes. And once again, please note that this whole system is 98% written by just one dev (myself) and that I’m not even full time on it: I’m also part of the Sequencer team, spending half my time there on cinematics. Hence the slow pace of development.

Big thanks go to the two game studios I’ve been working with over the past few months, and to the many people who reached out to me with questions, feedback, and kind words. My reply time is generally measured in days or weeks because <waves at… everything>, so I appreciate everybody being nice and patient.

Until next time, remember: game-dev is supposed to be fun! 😊