Page MenuHome

Normal map node produces wrong result after reflection fix patch
Confirmed, NormalPublicKNOWN ISSUE

Description

System Information
Windows 10 64bit & Radeon RX 480

Blender Version
Broken: After this commit d6e769d32e79
Worked: Before that commit

Short description of error
After patch D2574 merged, normal map node produces very inaccurate results. For example in this screenshots below.
Before patch:


After patch:

Normal map used:

I know reflection fix can be useful in certain cases, but I think it should be optional. It can be a toggle or enum on the normal map node itself.

Blend file:

Event Timeline

Yusuf Umar (ucupumar) renamed this task from Normal map produces wrong result after reflection fix patch to Normal map node produces wrong result after reflection fix patch.Aug 2 2018, 10:03 AM
Yusuf Umar (ucupumar) updated the task description. (Show Details)
Bastien Montagne (mont29) lowered the priority of this task from 90 to Normal.

After D3816 patch, it still produce wrong result compared to Blender 2.79. I still think this reflection fix should be optional.

Sybren A. Stüvel (sybren) changed the task status from Confirmed to Needs Information from User.Feb 11 2020, 11:58 AM

I can't reproduce this issue with the latest Blender (master @ be8879718e24e417d299eb298b8a9d4d2ca324ee); I get the "before patch" result.

@Yusuf Umar (ucupumar) Please re-test this with the latest Blender build from https://builder.blender.org/ and let us know if this is still an issue. If it is, please provide clear steps to reproduce.

I've already tested with the latest build and the bug is still there, you should render the scene using cycles.

Philipp Oeser (lichtwerk) changed the task status from Needs Information from User to Confirmed.Feb 11 2020, 1:20 PM

After D3816 patch, it still produce wrong result compared to Blender 2.79. I still think this reflection fix should be optional.

@Sybren A. Stüvel (sybren): I am also seeing the above ^
So will confirm, not sure though if this should be classified a bug?

note: since this is about ensure_valid_reflection, this is also an issue with it T57109: Flickering artifacts in (animated) DOF areas

@Philipp Oeser (lichtwerk) I think it still classified as bug since it's a wrong normal result for a standard 3d application. Currently there's no way to get correct normal map value using cycles. My suggestion is to give checkbox on normal map node to use correct normal map or normal map with reflection fix.

I'll defer to the Cycles team for further handling of this.

Brecht Van Lommel (brecht) changed the subtype of this task from "Report" to "Known Issue".Feb 11 2020, 3:45 PM

Hi, just wanted to say it's still an issue in some cases. For example when you use Bump node to get a derivative of something and use that value for a math operation. In that case you need the actual normal.
Or to give a concrete example, there's a method for even line thickness using Bump node - which only works in Eevee (as Luca Rood and Kolupsy noticed) because of this.

So I agree with Yusuf - would it be possible to add something like a Limit Angle checkbox that's perhaps checked on by default?