Maniphest T100420

HDRI reflections don't work properly with normal maps
Closed, Archived
Actions

Assigned To
None
Authored By
Pauan (Pauan)
Aug 15 2022, 8:34 PM
Tags
  • BF Blender
  • EEVEE & Viewport
Subscribers
Clément Foucault (fclem)
Gilberto Rodrigues (gilberto_rodrigues)
Miguel Pozo (pragma37)
Pauan (Pauan)
Richard Antalik (ISS)

Description

System Information
Operating system: Linux-5.15.46-x86_64-with-glibc2.34 64 Bits
Graphics card: AMD Radeon RX 6800 XT (sienna_cichlid, LLVM 13.0.1, DRM 3.42, 5.15.46) AMD 4.6 (Core Profile) Mesa 22.0.4

Blender Version
Broken: version: 3.1.0, branch: Unknown, commit date: Unknown Unknown, hash: rBUnknown
Worked: eevee - 2.92, cycles - never (2.79+)

Short description of error

I'm using a plane and a normal map to give the illusion that the plane is a sphere. This works fine:

However, if I reduce the Roughness to 0, then it looks hideously wrong:

Pay attention to the weird stretching on the outer edges of the circle:

I am using this HDRI, but I tested it with numerous HDRIs and they all have the same problem.

I get exactly the same results in both Eevee and Cycles. And this only happens when using an HDRI, when using standard lights everything works fine:

I also exported the scene to glTF and tested it in a couple glTF viewers. It works perfectly fine in ThreeJS:

And it also works perfectly fine in BabylonJS:

So this is a Blender-specific problem with how Blender is calculating normal maps with HDRIs.

Exact steps for others to reproduce the error

  1. Open the attached normal map.blend file.
  2. Render the scene.

normal map.blend5 MBDownload

normal map.glb711 KBDownload

Related Objects

Mentioned Here
rB1c22b551d0c1: EEVEE: Add ensure_valid_reflection to glossy closures
T56209: Normal map node produces wrong result after reflection fix patch

Event Timeline

Pauan (Pauan) created this task.Aug 15 2022, 8:34 PM
Richard Antalik (ISS) added a subscriber: Richard Antalik (ISS).Aug 16 2022, 5:18 AM

Seems to be same issue as T56209, so will merge

Richard Antalik (ISS) closed this task as a duplicate of T56209: Normal map node produces wrong result after reflection fix patch.Aug 16 2022, 5:18 AM
Pauan (Pauan) added a comment.EditedAug 16 2022, 4:29 PM

Are you sure it's the same? I get a completely different result compared to the screenshots in that issue.

That issue seems to be about normal maps in general, whereas my issue is specific to HDRIs, everything works fine with regular lighting.

That issue is using regular lighting, so I think it's a different issue.

In addition to that, my issue affects both Eevee and Cycles, but it sounds like that issue is only for Cycles.

Pauan (Pauan) added a comment.Aug 16 2022, 4:38 PM

I downloaded the cycles_normal_map_bug.blend file, and I confirmed that issue only affects Cycles, not Eevee. And they're not using an HDRI. So I'm 99% sure it's a different issue.

Pauan (Pauan) added a comment.Oct 10 2022, 9:38 PM

@Richard Antalik (ISS) I am now 100% completely sure that this is not a duplicate of T56209. That bug is about the normal map node.

But I was able to reproduce this bug even without the normal map node:

Babylon gives a particularly good result, whereas Blender gives the worst result.

This is a plane that has custom normals, it does not use a normal map:

normal reflection.blend5 MBDownload

normal reflection.glb1 MBDownload

T56209 only happens in Cycles, and it happens in all lighting situations, and it only happens with a normal map (not custom normals).

This bug happens in both Eevee and Cycles, and it only happens with HDRI, and it happens with all normals (including custom normals).

This is a different bug, it is not a duplicate.

Richard Antalik (ISS) added a comment.Oct 10 2022, 10:33 PM

Sorry, I must have missed your earlier comment, will re-check

Richard Antalik (ISS) added a comment.Oct 11 2022, 5:44 PM

Indeed this seems to be different issue. For eevee this is regression from version 2.92.
For cycles it's also not same issue it seems there is change from 2.93 to 3.0, but probably wouldn't call it regression.

Richard Antalik (ISS) reopened this task as Confirmed.Oct 11 2022, 5:46 PM
Richard Antalik (ISS) updated the task description.
Richard Antalik (ISS) added a project: EEVEE & Viewport.
Miguel Pozo (pragma37) closed this task as Archived.Nov 14 2022, 1:11 PM
Miguel Pozo (pragma37) added subscribers: Clément Foucault (fclem), Miguel Pozo (pragma37).

I just checked this with @Clément Foucault (fclem) and this is actually the intended behavior.
Reflection vectors are clamped in Cycles to avoid rays going below the surface of the mesh, and EEVEE matches the Cycles behavior.

So this can actually be considered as a duplicate of T56209.

Pauan (Pauan) added a comment.Nov 14 2022, 4:57 PM

@Miguel Pozo (pragma37) But then why am I unable to reproduce T56209 in Eevee?

And why does T56209 only break with a normal map, but this bug breaks with all normals?

And why does T56209 happen in all lighting conditions, but this bug only happens with HDRIs (not normal lighting)?

When you say that this is "intended behavior", do you mean that it won't be fixed, even though it produces incorrect and ugly results compared to other renderers?

Miguel Pozo (pragma37) added a comment.Nov 14 2022, 5:32 PM

Here you can see examples of why this is needed: https://developer.blender.org/rB1c22b551d0c13ad90bdc6145e6fa7db763038523

In Cycles this check is needed for diffuse lighting too because everything is ray-based, that's why the behavior is different.

If it's critical for you, then you can disable this by compiling Blender yourself adn commenting out this line of code:
https://developer.blender.org/diffusion/B/browse/master/source/blender/draw/engines/eevee/shaders/closure_eval_glossy_lib.glsl$56

Pauan (Pauan) added a comment.Nov 14 2022, 5:38 PM

@Miguel Pozo (pragma37) Thanks for the info, but that doesn't answer any of my questions. From my testing, this bug seems very different from T56209 (though perhaps related).

Blender's behavior in this case is wrong, so a different solution is needed. Perhaps Blender can copy the solution that other renderers use.

Clément Foucault (fclem) added a comment.Nov 14 2022, 6:19 PM

In reply to @Pauan (Pauan)

From my testing, this bug seems very different from T56209 (though perhaps related).

This is related because T56209 is concerning this specific behavior for both diffuse and reflection.

And why does T56209 only break with a normal map, but this bug breaks with all normals?

T56209 does affect all normals, even smooth normals. But it might have not been reported as such.

And why does T56209 happen in all lighting conditions, but this bug only happens with HDRIs (not normal lighting)?

Because EEVEE's lighting evaluation is much more fragmented than Cycles and uses different techniques. Some of which are not covered (and do not need to be) by the modified normal behavior.
This "fix" need to be applied only on BxDF that will shoot rays (to avoid shooting rays below the surface). In cycles, that's pretty much everything. For EEVEE, only reflection and refraction rays for indirect lighting are traced.

When you say that this is "intended behavior", do you mean that it won't be fixed, even though it produces incorrect and ugly results compared to other renderers?

EEVEE's goal is to be as close as Cycles as possible. The other renderers you mentioned do not provide raytraced reflections (AFAIK) and choose to ignore the issue of normals behind the surface for HDRI lighting.

The other solution to this problem is to do what cycles used to do in the past: don't shoot the rays and set indirect light contribution to black as we cannot trace inside the object (or we would have self intersection which is also bad).

Gilberto Rodrigues (gilberto_rodrigues) added a subscriber: Gilberto Rodrigues (gilberto_rodrigues).Dec 22 2022, 5:25 AM