We’ve been integrating the Gameplay Cameras plugin and so far it has been a powerful tool. We just have some confusion regarding how the post process camera rig node interacts with post process volumes placed in the world, and how we can have tighter control over how they blend and which takes priority.
For context, we generally have post process set in a volume in world to define the look of the level, but we have a single camera rig for looking across a vista where some of the post process values would need to be altered to get the desired visual effect.
On the old Camera component, it had a “Post Process Blend Weight” value which would denote how it would be blend with the world post process, but this isn’t available in the camera rig node (that I can see, anyway).
We performed a small experiment where the world post process would apply a red square to the screen, and the camera rig post process would apply a different material. It seemed like both materials applied, but on other post process values it seemed one took priority over another.
How does the engine decide which is a priority, or does it combine the values where possible? How can we better control the priority and blending?
Hi! Thanks for checking out GameplayCameras (GPC).
As far as I can tell, the way that PPS ends up handled is exactly the same as with any CineCamera or other Camera Actor… that is: the Player Camera Manager runs the view target, grabs the FMinimalViewInfo from it, and that ends up in the SceneView at the end. The reason it’s handled the same is that actually, the GPC component takes the output of the camera system evaluation and writes it on a semi-hidden CineCamera component called OutputCameraComponent (which is created on start and parented under the GPC component). When you set the owning actor as the view target, the Player Camera Manager and Local Player only ever see this OutputCameraComponent (they’re not even aware of the GPC system). This is due to the default implementation of AActor::CalcCamera(), which usually just looks for a child camera component that is active. So it finds that OutputCameraComponent.
TL;DR: unless you’re doing something custom, or unless there’s a bug I haven’t seen yet, there should be no difference between a standard CineCamera’s PPS, and the PPS set from camera nodes inside a GPC Camera Rig. Are you seeing something different?
The Post Process Camera Node indeed doesn’t have a blend weight, since I thought (possibly naively) that if someone wanted less stuff, they would just ramp the settings down But I can definitely add a blend weight on there if there’s a use-case for it? I wonder how blending between Camera Rigs would work though? For instance, if one rig sets the Scene Color Tint to red with 30% weight, and it blends with another rig that sets the Scene Color Tint to blue with 20%… I suppose it should blend from red to blue, and ramp down the weight from 30% to 20%, right?
The engine decides priority in a… rather messy way. In `ULocalPlayer::CalcSceneView()`, it first grabs the viewpoint info, which would include the PPS of the OutputCameraComponent (and therefore the PPS evaluated by the whole GPC system). It keeps that on the side in `ViewInfo`. Then in `StartFinalPostprocessSettings()` it gathers all the active PP volumes in the world, which overrides the PPS accordingly. Then there are the PPS that the PlayerCameraManager gathered from, say, camera shakes and camera modifiers. They’re split in two, those applied before (VTBlendOrder_Base) and those applied after (VTBlendOrder_Override). And sandwiched between that are the PPS of the main PlayerCameraManager view target’s output, which we had kept on the side in `ViewInfo`… so basically, as far as I can tell, the order is (1) PP volumes, (2) any shakes/modifiers/etc. with VTBlendOrder_Base, (3) the main camera, (4) any shakes/modifiers/etc. with VTBlendOrder_Override. Does that help?
I’ll add the Blend Weight option for the next release then!
Which FX produced a pop though? Not all of them actually blend properly, so it might be a known limitation of the system, but I just want to double check there’s no extra/unexpected bug too.
Thanks for the in depth explanation, it’s very helpful to gain a better understanding of the priority, even if it’s somewhat messy.
I think we would definitely make use of a blend weight option were it available, blending between camera rigs as you described above. I have noticed a pop in of certain post process effects when blending from a rig with no post process to a rig with post process. Having a rig with a blend weight of zero and another with a higher blend weight could be a valid workaround. Alternatively if the blend weight could be linked to a variable in a camera variable collection, we could drive the blending manually.
In terms of the post process fx that produced a pop, I have a test scene here that is effecting Color Grading -> Temperature -> Tint.
In the world I have an infinite bounds PP volume, setting the tint value to -1.0 (a blueish colour).
I have 2 camera rigs:
Default, which is the starting camera rig and does not have a PP node.
Combat Camera, which applies when I walk in to the labelled volume. It has a PP node which sets the tint value to 1.0 ( a pinkish colour)
It looks like what’s happening is when I activate combat camera, the PP values are blended from the previous rig to the next rig, but because the previous rig has no PP node it uses default values, immediately setting the tint value to 0 and producing the pop. This happens in reverse when blending back to default camera, blending down to 0, and then popping to -1 once the blend is complete and the PP from the volume comes in to effect.
In an ideal world, if there was no post process on the previous camera rig it would blend from those world values, but I understand from your above messages that the PP stack is messy and this may not be doable. Given access to the blend weight and the ability to link it to a CVC I would be able to control the blend from level volume PP to camera PP manually and hopefully remedy this.
But I can definitely add a blend weight on there if there’s a use-case for it? I wonder how blending between Camera Rigs would work though? For instance, if one rig sets the Scene Color Tint to red with 30% weight, and it blends with another rig that sets the Scene Color Tint to blue with 20%… I suppose it should blend from red to blue, and ramp down the weight from 30% to 20%, right?