Showing the blendable won’t really help as it’s extremely complex… Lemme tell you what I’m trying to do and you’ll see exactly where the issue is. It’s not a bug, but so far I’ve been unable to work around it.
I’m using SceneCaptureComponents (HDR) as part of a seamless portal actor in my game. This is working fairly well, but there’s a coloration problem, as you can see from this image.
Note how in the first half, the background is much darker, especially in places that the emissive pink is not present .
I know why this is happening, and it’s my PostProcess blendable, which is a cel shader. I’ll save you the hassle of deciphering a massive screenshot and say that the reason is twofold:
- My postprocess needs to read the SceneDepth gbuffer to draw outlines, and
- It needs to read the BaseColor gbuffer to calculate the lighting intensity (dividing PostProcessInput0 by BaseColor, then banding this output)
You can see what the problem is: since there’s no SceneDepth or BaseColor information present in the captured result of the SceneCapture2D (which is expected, it’s writing a single texture file, not an entire series of render passes), the math being performed by the PostProcess on the portal’s visuals is incorrect. It treats it as a flat surface for its depth calculations, and it has no BaseColor since it’s an unlit (emissive) surface.
Now, it would be possible to work around this issue by applying the postprocess directly to the SceneCapture2D’s output that it’s writing to the surface. Since the portal is translucent it won’t write to SceneDepth, and since it’s unlit it won’t get processed by the cel shader.
BUT that leads to the second problem (which I believe is beyond my capacity to fix)
Since a SceneCapture2D can only be configured to apply postprocess blendables IF it’s set to LDR mode, the Tonemapper hits it twice.
