Open erich666 opened 5 months ago
Filed as internal issue #USD-9472
I should note that the analysis for https://github.com/PixarAnimationStudios/OpenUSD/blob/release/pxr/usdImaging/usdImagingGL/testenv/testUsdImagingGLMaterialXBasic/normalMapFiles/normalMap.png shows problems around its fringes, but these are minor and so I didn't bother reporting it as not-so-great. Just FYI, here's the analysis:
Image file 'normalMap.png' may be a standard normals texture. Reason: no Z -1 to 1 range values are negative. Reason: the percentage of XYZ's that do not form normalized vectors for Z -1 to 1 is 0.234222% (614 texels), smaller than the error tolerance of 2%. 99.7658% of normals are valid for range -1 to 1, 64.9563% are valid for range 0 to 1. WARNING: input file has 16 bits of precision per channel, but this program currently outputs only 8 bits per channel. Normals that point essentially straight up: 63.4941% (166446 texels). The X and Y coordinates form vectors 2 levels longer than 1.0 for 0.00038147% of the texels (1 texels), and 1 level longer for 0.31395% (823 texels). The first percentage is less than the error tolerance of 2% of the texels. *Problem: bad normals, with the Z values (assuming range -1 to 1) found to be as far off as 42 levels in expected value. 99.7482% of the XYZ normals are normalized well (261484 texels), 0.0175476% are close (46 texels), and 0.234222% are pretty bad (614 texels). Normal lengths found in the file, assuming Z -1 to 1: minimum 0.847304 and maximum 1.0059 (these should be near 1.0). The lowest Z value found was 0.0117648 Average XYZ values, assuming Z -1 to 1: X 0.00172644, Y 0.0017014, Z 0.872954 XYZ values ranges, assuming Z -1 to 1: X -1 to 1 Y -1 to 1 Z 0.0117648 to 1 Color channels range: r 0 to 255; g 0 to 255; b 129 to 255.
The error (heatmap) image shows problems only along the fringes.
Description of Issue
The normalMap.png file used for testing PreviewSurface and MaterialXvsNative has around 3000 texels that are poorly normalized.
Steps to Reproduce
This texture is mostly flat, so the 3162 texels detected to be of incorrect length are significant. I would submit a fixed image, but I do not have tools that work with 16-bit-per-channel PNGs. As important, the texture's flat areas are suspect. Look at any of the many texels in this image that are supposed to be flat and you'll see values (at texel (0,0)) of (127,124,255) - a truly flat texel will have 127 or 128 for its X and Y values. It would be better to rederive and check this image from its original heightfield image. If the conversion tool is broken, it could be repaired.
Here is a diff using BeyondCompare, showing blue as "somewhat wrong" and red as "significantly wrong" - more than 20 levels of difference between the original and the rough corrected image (8-bit).
the "not quite pointing up" normals are left as-is here, since the cleaned-up image fixes only normal lengths.
I checked the UsdPreviewSurface test file and it is using standard normal bias and scale values, meaning Z should indeed be between -1 and 1. I know a bit about this area, having contributed this test file elsewhere.
The analysis program I used is my own NormalTextureProcessor, which is fairly well tested and I believe is pretty reliable (if it's not, I certainly want to know). Its analysis in full:
Here is a view showing various types of errors in colors (explained at the end of this section:![image](https://github.com/PixarAnimationStudios/OpenUSD/assets/803995/899e82de-416a-4c10-addc-33b16d613bce)
The point is that, though there are "only" 614 texels that are noticeably wrong, given the flatness of the texture, these are fairly significant.
System Information (OS, Hardware)
Windows 10, though this is mostly irrelevant. The bug can be seen by inspection of its data.
Package Versions
N/A
Build Flags
N/A