RoughnessTest: 0.33 roughness doesn't match between texture and constant versions #98
Description
For the RoughnessTest I am seeing problems with the 0.33 roughness band, in both usdview 0.25.5 and in NVIDIA's Omniverse Kit 107.3.0.
Here's usdview, moving the view to show the dome light reflecting off the surfaces:
Note the discontinuity between the textured and constant roughness value strip for 0.33 roughness. That is, the texture's roughness value gives a different highlight than the constant value. The point of this test is to check if a roughness applied as a texture looks the same as the constant roughness value. So, either usdview has a bug, the roughness test file has a bug, or both have bugs.
Note that on the page about this test it notes "usdview is rendering the mesh as semi-transparent, which is incorrect" - this seems to be fixed; it's now the texturing that's wrong. So, a separate issue is, once this mismatch is corrected, this passage and the usdview image on the page should be updated.
If in usdview I turn on just the Default Camera Light (light at the eye) and turn off the other two, I get:
Again, the 0.33 roughness strip does not match between textured and constant.
Trying the same model in Omniverse Kit 107.3.0 with the interactive renderer, and a light at the camera:
A different sort of result, but, again, the strip does not match at 0.33, which leads me to believe that the test itself is faulty.
I dug a bit into the files in the test. The roughness.tga holds the roughness values 0, 0.33, and 0.66 in separate RGB channels, and is a solid color (same roughness regardless of location on the texture). The values stored are 0, 153, 211. These are not linear values, e.g., 153/255 = 0.60 and 211/255 = 0.83. The reason is that the sourceColorSpace (for both textures used) is indeed sRGB. So a quick-and-dirty conversion of 0.333^(1/2.2) = 0.61 and 0.666^(1/2.2) = 0.83, the values we see stored in the texture. The texture seems to check out.
If linear [0.0,1.0] values were stored in the texture, the color values would be 0, 85, 170 (e.g., 0.333 ~= 85/255). Just to be sure sRGB was being honored, I tried an experiment of replacing roughness.tga with this new triplet of values. The result in usdview, with the light at the camera, still did not match:
I also used Omniverse Kit to examine the surface normals, to make sure there wasn't in fact a discontinuity with the underlying geometry and interpolated normals. These check out fine:
So, I am at a loss as to why the constant and textured roughnesses for 0.33 don't match in appearance - they should. In Omniverse Kit it's a bit subtle, but 0.66 roughness also doesn't seem to quite match between textured and constant (hard to see any difference in usdview):
I will report this bug to the NVIDIA Omniverse rendering team. I hope that the authors of this test can determine if the test itself is at fault, or the usdview viewer (or both?), and take appropriate actions. The fact that the same sort of flaw appears on two different viewers makes it feel like the file is at fault, but I haven't (yet) found anything in the file itself to explain it.