cycles normal shading issue with normalmaps and heightmaps #95729
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
13 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#95729
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
System Information
Operating system: Windows 10
Graphics card: NVIDIA GeForce RTX 3070/PCIe/SSE2
Blender Version
Broken: I believe all the versions from 2.80 official to 3.1 beta v31.0263c8238bda (tested: 2.80, 2.90.1, 2.93.8, 3.0.1, 3.1 beta)
Worked: 2.79b
Short description of error
Normalmap shading in cycles is wrong. It looks like all the normals going above 45 degree in respect to the geometry normal get clamped at 45 degree.
Exact steps for others to reproduce the error
I rendered a normalmap from the leftmost sphere cylinder and plane you can see in the viewport. Then I applied the normalmap to the plane in the center, using a simple diffuse shader for all the objects. I set the light paths to direct light, added a shadeless sun lamp and an orthogonal camera. You can see the result in the two viewports at the bottom: eevee renders correctly but cycles doesn’t. It looks as the sphere sides is straightend and it makes it look somewhat like a cone with a curved top. I added two deformed sphere and cylinder on the right to try to get the same result as in the wrong shading. It seems that the normals get clamped at a 45 degrees angle in respect to the geometry normal.
please see the attached blend file:
map test.blend
I get the same result with a height map
height test.blend
The output of the normal node seems to be good
Instead the bump node seems to output clamped normals
Added subscriber: @ErvinWeber
Added subscriber: @Baardaap
Changed status from 'Needs Triage' to: 'Confirmed'
There's something strange going on indeed. Setting the strength to .5 makes it look better in cycles (not necessarily 'correct' though).
It looks like the normal in cycles can't get past 45 degrees.
Added subscriber: @Quver
#88368
Also see this, it might not be related to this bug but normals don't work currently
Added subscriber: @SteffenD
Added subscriber: @ThomasKole
I'm getting similar results.
As you can see, the geometry version looks very similar in Eevee and Cycles.
The Normalmap version seems to hold up well in Eevee Diffuse, but in Cycles a clear slope cutoff can be seen.
As for glossy, the Normalmap version is broken in both Eevee and Cycles.
At an angle, the result becomes a bit more distorted:
Added subscriber: @EAW
Likely a duplicate of #56209 (Normal map node produces wrong result after reflection fix patch), will investigate further when I get in front of my computer.
I've recently written a thread on twitter summarizing this issue.
Overall, it's very surprising that an issue as large as this has seemingly recieved no response from the developers. Alot of other artists I've interacted with have also encountered this issue.
The issue seems to stem from a patch that was merged over 5 years ago, as linked earlier.
The thread can be found here: https://twitter.com/HotdogNugget/status/1629249904920117248
Please note: the below theory is all conjecture from briefly studying the code. However I think it's still useful to get a bit into the 'why' of the normals being weird.
What that patch is (trying) to fix is that when you have a reflecting material on a normal map and you use the normal map 'as is' the reflected ray can pass under the surface/intersect with the surface. For a ray coming from straight above any normal with an angle larger than 45 degrees reflects as a ray that intersects it's own reflection surface. Rays intersecting their own reflection surface lead to those black spots/stripes, I guess. Another way (what most games do) would be to disable self-reflections.
However, for calculating lighting the whole 'prevent reflected rays intersecting' doesn't matter I'd think. So it's a pity this fix is not optional or separated into 'reflection rays only'. It looks like this is what EEVEE does.
If you look at the images ThomasKole posted above you can see that the glossy reflections you get from geometry are impossible to recreate using a flat plane with a normalmap, unless you would disable self-reflection. With self reflection every pixel that in the geometry reflects something below the plane would turn out black in the normal map case.
The original patch is really successful at fixing the self-intersecting reflections, but it had two unintended side effects which both deserve a discussion, in my opinion:
1 - Clamping the normals for diffuse rays in cycles.
I'm not entirely sure what problem it is trying to solve, however it does clamp rays that don't intersect with the surface or cause any indesirable artefacts. It also introduces a disparity with Eevee, other renderers and normal map authoring tools.
In the image above, the rays that get clamped out wouldn't have caused any issue, I don't think. Using the displacement node in bump-only mode is a work-around for height maps, but there is currently no way to avoid the above behaviour with normal maps in Cycles.
2 - Clamping the reflection normals in Eevee.
Eevee has a large NPR audience and clamping the reflections normals is limiting some use cases. Often the surface properties are completely faked in shader and don't correspond at all with the actual surface normals. Currently this works well with diffuse lighting but creative shading for reflections is limited by the clamped normals. An option to disable the clamping would be greatly appreciated, I'm happy to list some use cases if needed.
Encountered same issue…
So we do not have normal normals sincs 2.79?
This issue seems to have existed for a long time, but why haven't the developers addressed it? Is there a more proactive approach we can take to make the developers aware of it?
Additionally, version 2.79 can perform general high-low poly baking for displacement using a cage, but versions 2.8 and above cannot (I know it can be done through the Multiresolution Modifier) .
Resolved by
dfe7b839bc@ThomasKole
While being similar, what you mention here is actually another issue, please submit a separate report for it.
To prevent black pixels from appearing as a result of normal maps that add small geometric details, certain normal manipulation is necessary. However, such manipulation is not designed for normal maps that completely alter the shape of an object. Even if we do not modify the normals, your scene would still not resemble a real sphere. What you are requiring here is self-intersection, it is non-physical and would cause issues. We could consider allowing self-intersection in some cases, but we typically avoid adding too many options, and a good generic solution for this type of issue does not currently exist.
@weizhen We do keep reporting it as separate bugs, but it keeps getting closed as a duplicate: #100420 #105927
Can we please get this triaged properly? There is currently no open issues for this bug, despite several issues being opened (and then promptly closed as duplicates).
@weizhen please, reopen. Issue exists, and strikes to many pipelines and projects.
Normals everywhere and they aren`t normal.
At least this behavior should be optional, at least per project, but better per material.
Exact same issue with direct math instruction. Math do correct positions with GN and wrong normals in shader. Yes, for 1m radius sphere position = normal
sph normal math. blend.blend
Perhaps {88848} related to this issue too…
Another test with flat normal and flat mirror side by side
sph normal math2. blend.blend
Open file and rotate arrow around Y
Here what happens:
2023-03-23_22-40-01.mp4
And now I am sure it is related to 88848
Okay. After reading all, i understand, that it is intended clipping, makes new issue to fix another issue.
So let users decide, what do they want: full normal control, casual normal clamp, or make their own clamp with full normal control.
btw Pixar somehow fixed it (Renderman), so the solution exists at least for path tracing engine.
I don't think this should be considered a bug, nor is it really an issue at this point. The normal clamping makes total sense for glossy reflections, as the only alternative would be to make the shader black in those areas (which it did before the patch that created this). The issue originally was that this was applied to diffuse shaders too, and that has recently been fixed. It makes sense for this report to be closed at this time.
@Alex-R-Heskett It is absolutely a bug. We've provided a lot of examples which are clearly broken, and which differ from the results of other non-Blender renderers. Even extremely simple and correct normal maps are broken in Blender. Other renderers handle this fine, so I disagree with your claim that it's impossible to fix this. There must be a proper solution.
The characteristics you have described were intentionally implemented, not the result of a bug or error in the code. Normal maps are inherently an approximation of detail, they cannot accurately handle self-reflection because there is no actual displaced geometry. I can assure you that for glossy surfaces, the only other option is to disable self reflection entirely which isn't optimal for most situations.
Different rendering engines have their own solution to this issue, but none are without their own unique faults. There is no perfect solution to this issue, because as I mentioned before normal maps only serve as an approximation of real displaced geometry. At grazing angles, light rays are reflected into the surface, creating black artifacts. This can be alleviated for glossy surfaces by clamping the reflected vectors to avoid the surface, creating the effect you've observed. It's either this, or the black artifacts visible in older versions.
I agree that it could possibly be convenient to have a toggle for this, but it certainly isn't a massive bug or anything. Just an intentional fix for an unavoidable issue.
@Alex-R-Heskett We have shown very basic examples which do not have self-reflection or grazing angles, but they are broken in Blender, despite working in every other renderer. This is causing a lot of problems for many people, especially for NPR rendering. It needs to be fixed, or else people will leave Blender and use other programs which are behaving correctly.
By definition, a bug is incorrect behavior, regardless of why that behavior is happening. All code is intentionally written, but that does not matter, it is still a bug. You seem to think only crashes count as bugs, but that is not the definition of a bug.
I'm not sure what you mean by "do not have self-reflection or grazing angles", all examples that have been given of glossy surfaces with the issue present are examples of normals being clamped at grazing angles where light rays are reflected into the surface, as I described.
As for it "working in every other renderer", this is just false. Every single rendering engine that I know of has this issue to some degree, some have different solutions than others though. Attached are examples in ue5, arnold, and karma. Redshift also has a similar fix to karma and cycles.
I suggest you take a look at this blogpost: https://www.artstation.com/blogs/andreasmischok/WYVG/fake-vs-true-displacement-part-22
it outlines the issue pretty extensively and gives examples of how other render engines tackle it.
Here is a handy diagram included in the blogpost linked previously, explains the issue pretty well.
@Alex-R-Heskett I see, so that's what you meant by "self-intersection".
I am unable to test any of those renderers, but here are the renderers I have tested:
ThreeJS works fine:
BabylonJS works fine:
Godot works fine:
LuxCore works fine:
Every one of them works fine, but Blender is horrendously broken in both Eevee and Cycles:
This is clearly not intentional behavior, this is clearly a bug. You claim that the only way to fix this is to introduce black spots, but there are no black spots in any of the other renderers. So there must be a proper solution. There are other possible solutions, Blender's clamping is not the only solution, it is not a false dichotomy.
The examples you have given are not from raytracing engines, and do not have raytraced reflections and illumination like cycles does. All examples I gave were, and the reasoning for why the issue occurs is directly tied to the engine being a raytracing engines. In eevee, I totally agree that this shouldn't occur at all.
I would heavily recommend checking out the blogpost I linked earlier.
Renderman — idk, but i suppose so.
Both can do better. Renderman gives best result with diffuse shader, luxcore with glossy one.
Like I said before, it was recently changed in cycles to only apply the clamping to glossy shading. So cycles doesn't have this issue with diffuse shading anymore.
Thats good.
But if glossy will have high roughness it will work more like duffuse. Guess where is what
Hi everyone,
I've always noticed a strange behavior of normal maps in general with cycles, recently it starts to affect pretty badly my workflow.
I don't know if the problem that I'm going to report is caused by the same issue discussed in this thread.
I've noticed that I can't properly use Quixel Megascan 3d models due to a wrong behavior encountered in Cycles and not in Eevee.
As you can see in the images attached, the artifact produced in shades smooth configuration that in theory should be solved by the normal map (in eevee everything seems to work fine) is not in cycles.
In general, I noticed that all normal maps look a bit dull in cycles and not as crisp as in Eevee or in other real-time renderers.