Hi Tavis,
Sorry for the delay yet again, we have Epic summer break now and I had a load of deadlines to wrap up, apologies for not responding to this sooner as a result but I’ve investigated this thoroughly now and I believe I have the solution required.
So to start off: I concur with all of your findings here, I can see how the data is coming back from the Viewport on readback, and how we are manipulating it. I think your concern about the fix being hacky is probably not something to worry about because the code itself appears to be a Frankenstein’s monster of combinations of hacks for different use cases. I think your approach to fixing this was hence along the right lines.
I did investigate the mask pathway of the code and a CustomStencil approach actually is an alternative to changing code here if you were to enable that process, but I think there’s 2 issues with that: 1) you would have to setup stencils for your scene to achieve this (maybe you could get away with setting the entire scene in an entire artificial skybox featuring the black background and only adding the stencil mask to that skybox?) and then 2) there appears to be some issues with this path, which I also encountered:
https://forums.unrealengine.com/t/high-res-screenshot-with-custom-depth-mask-not-working/572033
Anyway, it may still work if fully setup in this way, but regardless to be on the safe side, I spent a bit more time today fleshing out the implementation I anticipate is required if we are going to fix this in the engine. Please see perforce shelf 43945730.
This shelf adds an additional option to the high res screenshot config struct which tells the output to either stomp with 255 or simply adjust the existing value for the appropriate output:
[Image Removed]The image attached is the output from this setting being disabled.
To answer question 2: I’m not entirely clear on why the alpha is inverted to begin with but from my investigation I am pretty sure what is actually happening is you have a default black background in unreal with alpha pre-set to 255, and meanwhile the opaque base pass is not outputting the alpha for the material (emissive color is RGB only), so we may just be setting that to default to 0, and I know that the base pass occurs prior to translucent pass, so it may just be that the alpha is always ignored there. I think this is the most likely explanation.
The stomping of the alpha is a different answer, so interestingly because we have the way we write out the base pass I just mentioned, it means all the colours are essentially semi transparent. I believe this is accounted for in the Unreal pipeline, but for mapping to a screenshot/png file for example, those values are interpreted differently, hence the scene will be entirely black in the png if the alpha is not inverted. The 255 stomp hack (which turns out is not caused by me, which I was grateful to discover haha) is to account for this, when really this inversion process may be more appropriate (although questionable, just feels like more hacks).
Anyway, didn’t want to leave you in limbo over the two week summer break, I hope this gets you unblocked. Also, out of concern that you may not have perforce access (really hoping you do), here are some screenshots of the items required to get this additional option in the UI:
[Image Removed][Image Removed][Image Removed]Note: also needs the head file declaration ofc
[Image Removed]Note: the alpha multiplier must still be applied to account for any data mismatch in alpha channels (I believe that’s why you see the greyed out pink box in the final image).
Thanks, and I hope this gets you unblocked until we are back from summer break on July 14th.
Jon