pbrt-v4
pbrt-v4 copied to clipboard
Issue/question about normal maps
Hello, When I add a normal map to my model, I get this strange shadow on the left side at the bottom of the cube, completely different from the expected result. This leads me to several questions:
-
Why this behavior?
-
Do the pbrt normal maps follow OpenGL or DirectX convention (https://www.texturecan.com/post/3/DirectX-vs-OpenGL-Normal-Map/)?
-
Why are normal maps not textures in pbrt, like bump maps (and like in most renderers)?
Many thanks in advance!
In the scene that you provide, the cube don't have normals data defined.
OK, thank you, I thought there was a recomputation mechanism in case they were not provided (as there was no error)! I'll try to add them... And what about the two other questions?
For q2: all textures in pbrt are defined with (0,0) at the lower-left corner. This is how it converts RGB to a tangent-space normal:
Vector3f ns(2 * normalMap.BilerpChannel(uv, 0, wrap) - 1,
2 * normalMap.BilerpChannel(uv, 1, wrap) - 1,
2 * normalMap.BilerpChannel(uv, 2, wrap) - 1);
it's not clear to me whether that corresponds to the opengl or dx convention.
The reason they're not pbrt textures is because pbrt is a spectral renderer. So, unlike before, the texture interfaces do not return an RGB but rather return the texture's value at the wavelengths given to it. That interface isn't really compatible with normal mapping, so we went with the expedient approach of making normal mapping special so that it could correctly operate on RGB values...
it's not clear to me whether that corresponds to the opengl or dx convention.
If you don't invert Green, I would say it's OpenGL, like in Blender (https://docs.blender.org/manual/en/2.79/render/blender_render/textures/properties/influence/bump_normal.html).
For normal mapping being special, I understand the rationale. However, to me, the flaw is you cannot apply transformation to the normal map, this way...