GBuffer / Render To Texture Oddities?
(I'm using UE 4.12.5 in this context.)
Edit: See my comment below for a workaround when using the Render To Texture Toolset with materials including roughness.
I was experimenting with rendering materials to texture and found some things that didn't make sense to me. Let me show some screenshots to set up the scenario.
Generate a gradient and send the same output to several material pins ...
GBuffers: Roughness visibly different from BaseColor, Metallic and Specular
I'm assuming roughness is being gamma corrected to some color space (although it shouldn't be any more than any of the other linear math driven inputs like metallic or specular should it?)
\Engine\Content\ArtTools\RenderToTexture\ tools show the same issue.
I used the Render To Texture Toolset I exported the GBuffers from the material above to OpenEXR files.
I then directly imported those files as uncompressed HDR textures without modifying them in anyway (I only renamed them).
You can again see the same issue with Roughness. I'm not getting out the same values I'm putting in.
(For what it's worth doing a Pow(.45454545) gives me a somewhat close approximation of the original input so this does seem related to colorspace. However, it again confuses me why color space/gamma corrections for only roughness would come into play here. Everything should be in linear space from my understanding, or at least roughness, metallic and specular should all be ouput in the same color space).
I setup some nodes to illustrate the differences
(You'll likely need to open the image above in a new browser tab and zoom in 200% or more to see the differences discussed below.)
In the center of the image I have the four uncompressed HDR textures lined up side by side. BaseColor, Specular and Metallic appear identical (although they're not exactly, i'll explain that below) and look like the original input gradient. However the roughness is again clearly different from it's original source.
In the top right of the image I use blend_difference nodes to compare the source input to the roughness texture and the base color texture. As we know roughness is very different. Happily, BaseColor is extremely similar to the original source. My guess is the difference is due to the the limited 512 resolution of the BaseColor texture compared to the infinite resolution of the procedural source.
Below that I compare the BaseColor texture to the Metallic Texture. They are very close but there are differences where I would expect them to be digitally exact copies. Below that I compare Metallic to Specular and they are digitally exact copies as expected.
So the final questions are ..
1.) Why is roughness being shown in the GBuffer view (and exported via Render To Texture toolset/HighRes Screenshot feature) so drastically different than metallic/specular/basecolor when feed the same inputs?
2.) Why is BaseColor very similar too, but not identical to the Metallic and Specular outputs (which are identical) given all three had the same input?
My hunch is question #1 relates to an actual bug as it prevents getting anywhere near the same output as input for roughness when using Render To Texture toolset.
Question #2 is likely something subtle I don't understand about differences in the BaseColor, Metallic and Specular GBuffers (although i'd like to understand what that difference is if it can be explained easily).
So I actually stumbled onto the source of this. Within the Engine Content under \BufferVisualization\ folder you'll find the various post process materials used to display the GBuffers. If you open the one for Roughness you'll see it is going through a power(2.2) node (approximating an sRGB to linear color conversion).
As expected from the experiments described above none of the other gbuffer visualization materials do this. So I really can't say why this is this way, maybe there was a good reason. But the down side is that these materials are also used for the Render To Texture Toolset.
A work around is simply to bypass that power(2.2) node as shown while using Render To Texture Toolset as shown in this screenshot.
When you do that, the four material attribute HDR images output by the RTTT look correct.
answered Aug 02 '16 at 01:47 AM
I was able to reproduce this issue and I agree that this is unexpected behavior. I have logged a bug report in order to notify our developers to investigate this issue further. I have simplified the material slightly just to reduce the steps needed to reproduce this issue. We plan to release a public bug tracker for users to view soon and I will link it once it is live.
Thank you for posting this issue!
answered Jul 25 '16 at 08:52 PM
Follow this question
Once you sign in you will be able to subscribe for any updates here