UE5 Gameplay Cameras: Asset Changes
In this second developer diary post about Unreal Engine’s Gameplay Cameras plugin, I want to talk about the most visible change you’ll see in 5.6, which is how camera assets are organized.
In UE 5.5, you have the Camera Asset which contains the Camera Director, the Shared Transitions, and a list of Camera Rigs that it can use (see bottom left panel in the screenshot below).
The problem is that Camera Rigs could also be their own assets, as Camera Rig Prefabs, so that you could make re-usable bits of camera logic. For instance, there are three Camera Rig Prefabs in the screenshot below, one of which is re-used by most of the Camera Rigs listed in the previous screenshot:
Some people got confused about this — that Camera Rigs were sometimes objects within a Camera Asset, and sometimes standalone assets.
The other problem was that this required implementing a bunch of custom “picker widgets” for picking Camera Rigs inside a Camera Asset:
After a while, it started to feel like I had to fight against the way the Unreal Editor wants to work. So a few people finally convinced me to change this and make all Camera Rigs into standalone assets.
As a result, if you have some Camera Assets in 5.5, the first thing you’ll see when upgrading to 5.6 is a dialog that tells you it will break it apart into several assets:
The created standalone Camera Rig assets are automatically named, but you can rename them as usual via the Content Browser afterwards.
There are pros and cons about this change. The positive points about the new asset organization are:
- Camera Directors are now free to activate any Camera Rig found in your Content Browser, not just the Camera Rigs from their Camera Asset. If you like something, you don’t have to create a “private” Camera Rig that wraps the desired one in a camera node, so that sometimes saves you several clicks.
- It removes a lot of bespoke code for the aforementioned special “picker widgets”. These were only implemented for Blueprints and State Tree anyway so if you wanted to make a custom Camera Director, you had to implement some custom widgets to make its UI work right.
- There were problems with those “picker widgets” anyway, as this workflow was a bit lame for some use-cases like shared Camera Directors.
The negative points are:
- You now have a lot more tabs to open and manage. If your camera has half a dozen Camera Rigs, that’s how many tabs you might end up opening if you’re working on it.
- It’s harder to figure out the “scope” of a camera. Before, if you wanted to know how “big” a camera is, you just had to look at its list of Camera Rigs. Now, you just don’t know… does its Camera Director potentially activate two dozen different Camera Rigs? Or only a couple? Which ones? You don’t know until you either inspect the Camera Director’s logic, or use the Reference Viewer.
- You may now end up modifying a Camera Rig used by another camera. Before, that was pretty much impossible, since Camera Rigs were “private” to a Camera Asset. It’s only when you started editing a Camera Rig Prefab asset that you knew it was potentially shared between multiple assets. Now there’s a risk that as you fix one camera, you break another.
I knew about these pros and cons back when working on 5.5, but I didn’t make the right decision regarding which pros and which cons were most important. What happened with the internal 5.5 feedback was that:
- People actually like being able to reference anything and everything across the Content Browser. That’s sort of the “Unreal way”, I guess. So from the pros/cons lists above, pro 1 was way more important than con 3.
- Pros 2 and 3 turned out to be bigger deals than I originally anticipated, as I kept adding more code to handle “private” Camera Rigs here or there.
- Cons 1, 2 and 3 turned out to be problems that the animation framework people were starting to look at in a general way, because animation assets are also spread all over the Content Browser. I talked to them and realized that I can leverage the UI solution they’re working on, and make the camera workflows consistent with other future animation workflows. It’s not clear yet however if that will be ready for 5.6.
So there you have it, asset management is somewhat different for camera assets in 5.6. I hope it all made sense. See you next time, and have fun!