Page MenuHome

Eevee: strange discrepancy in handling of 32 bit floating point textures
Confirmed, NormalPublicBUG

Description

System Information
Operating system: Linux 5.4.10-arch1-1
Graphics card: GTX980Ti

Blender Version
Broken: 2.83 (01d9a2f71b56be9354ce31564e3dddb6af4a0757)
Worked: N/A

Short description of error
When using a 32 bit floating point normal map with Eevee, it looks as if Eevee resamples the image and reduces quality:

The same image and material used with Cycles seem to work fine. Also, slightly different setups in Eevee (e.g. manually generating (some of the) same data) do not produce the same issue.
More information in this video.

Exact steps for others to reproduce the error

  1. Load the above .blend file.
  2. Observe banding on the surface in Eevee material preview.
  3. Switch to render preview (Cycles): surface will become smooth.
  4. Try the other two materials and note that they do not exhibit the same problem in Eevee.
  5. Try baking normals using the ManualTangentNM material (see video for details). When baked with no range compression, Eevee does not seem to have an issue.

Event Timeline

Richard Antalik (ISS) changed the task status from Needs Triage to Confirmed.Mon, Jan 13, 10:25 PM

I can confirm this. Seems to be caused by enabling Object Data > Normals > Auto Smooth.

I don't think that that is the case. Re-baking with the whole mesh smooth-shaded without custom normals and sharp edges will still show the issue in Eevee (but not in Cycles), although of course the normals in general would be wrong.
E.g., with Auto-Smooth disabled one can still use the 'ObjectNM' material. Eevee will preview it without banding. But, baking tangent space normals with that material, switching back to the 'TangentNM' material and plugging the new texture instead of the original TS normal map will bring back banding in Eevee (but not Cycles). Even a few seams along triangulation edges would show in Eevee (on the flat sides).