Mix and Match Normalmap Packing

Harald

Glad to hear that it works as expected now! 🙂

Anisoft wrote
I assume the ability to force stuff to be linear or not is useful beyond just normals for if I have a linear texture I wanted copied over too (so maybe something like a emissive texture?, actually I'm not fully sure what its other uses could be)

Emissive textures are a pitfall here - they shall be declared as sRGB textures. This thread on the Allegorithmic forum (you know them from Substance Designer and Painter) summarizes it quite well:
https://forum.substance3d.com/index.php?topic=8745.0

Wes McDermott wrote
The simplest way to look at it is that if its color we see, then its to be treated as sRGB and the gamma needs to be removed. This is albedo, diffuse, base color, specular. [..] Yes, emissive should be sRGB. A good way to look at is like this...

If it's a color that you see then it's sRGB. Everything else is linear. Basecolor contains diffuse reflected color and metal reflectance values. Both represent light rays bouncing back and picked up by our eyes. Emissive is the same.

Hm, and Unity seems to expect Metallic textures to have the sRGB property checked (for whatever reason, maybe filtering as mentioned in the forum thread):
https://forum.unity.com/threads/metallic-map-linear-vs-gamma.425872/#post-2752018

One exception to the "if you see color, it's sRGB" rule is if it's .exr or .hdr files or other floating point formats, which will not be gamma-encoded, the content is already stored in linear space. I assume Unity will ignore the sRGB property at these files anyway, so it should not become a problem.

Anisoft wrote
Tbh I'm not really sure what the usage of checking stuff not to be srgb in the texture importer is for too

When the project is set to Linearcolor space, all color and lighting computations will take place in Linear color space. When the sRGB property is enabled at a texture in its import settings, it declares that the 8bit per channel color data was encoded in sRGB color space typically for viewing on a monitor (a.k.a. "my dark values are important") and will be converted to linear space color (a.k.a. "light adds up and multiplies this way") when sampling a texel.

Regarding normalmaps:
Note that when using Photoshop in a default setup, the color chooser's 0-255 values are showing sRGB values. Now a normalmap's red channel is authored as "0 sRGB is left, 128 sRGB is neutral, 255 sRGB is right". Although when storing it as a .png image it is stored in sRGB color space, you want the 8bit integer values to be interpreted directly as 0, 128, 255 and you don't want any gamma correction being removed from these colors. It is true that the colors of the normalmap after being interpreted as linear would look brighter, but we do not want to preserve the "visual look" of the color image, but instead it's integer data values must stay the same. When you enable sRGB in the import settings, you declare that the "visual look" shall stay the same and the data values representing it shall be interpreted accordingly, leading to different data values at the texel than the ones you originally chose in sRGB space.

Ill be sure to share when I finish it.

Great! 🙂

Anisoft

Thanks for the detailed explanation!

It is true that the colors of the normalmap after being interpreted as linear would look brighter, but we do not want to preserve the "visual look" of the color image, but instead it's integer data values must stay the same.

Interesting, that's good to know. I do apply correction for any input textures in my compute shader or the normals are completely wrong.

I found it strange that for the renderTexture, applying a final gamma/linear correction was needed for the visualization of the RT to look like the ref (or it was too bright).

However when exporting to an actual Texture2D I found no visual difference to the output texture whether the final output was corrected or not...

I'm curious if I should be setting my Texture2D there to be linear..

So in all very confusing haha, hopefully I wrap my head around this soon. Ill re-read ur explanation a few times and do more testing and see if I can fully get it (cause as of now its a lot of trial and error)

To clarify I apply a RgbGammaToLinear (taken from another post here) to any textures I add to my compute shader so that the normals output a correct looking image.

I don't apply any conversion beyond that to the final output tho due to me saying the output to Texture2D from the RenderTexture appears the same in both either way...

So the RT is super bright, but the Texture2D isn't (if i apply a LinearToGamma, it fixes the RT and appears to have no effect on the final outputted Texture2D from that RT...)

curious as to why that is... (maybe i just think it looks the same... tho it really doesn't 100% look the same)

Harald

Anisoft wrote
Interesting, that's good to know. I do apply correction for any input textures in my compute shader or the normals are completely wrong.

Do they behave completely wrong, or do they just look wrong?
I would test this by replacing the shader code of the sampled texture value with float3(0.5, 0.5, 1.0), as a reference "straight up" normal color (the neutral violet in sRGB).

Anisoft wrote
I found it strange that for the renderTexture, applying a final gamma/linear correction was needed for the visualization of the RT to look like the ref (or it was too bright).

That would make sense to me - if the render texture was linear (or/and a floating point texture) and the visualisation part did not apply any additional LinearToGammaSpace conversion.

Unfortunately, there are quite a lot of possible combinations of how things can be configured and where automatic conversions could take place.
As as summary, I would always test with some hard-coded reference values and see if sampling the texture also returns similar values. I would not rely on the visual appearance.

Anisoft

Sorry it took so long to get back, so I found the issue...

It was wrong...because of my color settings.

If you have the game set to gamma or linear (as we discussed) it changes how unity imports stuff. So changing the maps I import for the shader to be linear solved that issue. (Otherwise like you said the import would be different based on the color mode)

I discovered this because my compute shader light profile normal generator was getting diff results in another test project. That test project being gamma instead of linear.

Setting all the imported textures to linear solved both cases.

Just wanted to make sure I followed up. Sorry for the delay, I didn't get around to testing your questions until a few days ago.

Harald

Thanks for letting us know! Glad it all behaved consistently in the end.

« Pagina precedente