Vector displacement on top of adaptive subdivision breaks normal #111588

New Issue

YimingWu · 2023-08-27T16:59:31+02:00

YimingWu commented

2023-08-27 16:59:31 +02:00

System Information
Operating system: Windows 10 / Ubuntu 22.04
Graphics card: NVidia A6000 / K5100M

Blender Version
Broken: 4.0
Worked: never

Short description of error

Vector displacement on top of adaptive subdivision breaks normal.

Exact steps for others to reproduce the error

Open attached file, switch to render preview in viewport.
It's in adaptive subdivision, where the vector displacement is connected.
- Wrong normal in the "hanging over" side (in black).
If unmute the Geometry "True Normal" node, the normal seems to be correct but it lacks smooth interpolation (observable upon close inspection.
Add a displacement modifier (thus disabling the adaptive subdivision), and remove the displacement output link in the material.
Set the displacement modifier to the displacement texture (use RGB to XYZ mode).
- Vector displacement renders normal correctly.

VD on adaptive subdiv	VD on adaptive subdiv (with true normal)	VD modifier on regular subdiv (correct)

**System Information** Operating system: Windows 10 / Ubuntu 22.04 Graphics card: NVidia A6000 / K5100M **Blender Version** Broken: 4.0 Worked: never **Short description of error** Vector displacement on top of adaptive subdivision breaks normal. **Exact steps for others to reproduce the error** - Open attached file, switch to render preview in viewport. - It's in adaptive subdivision, where the vector displacement is connected. - Wrong normal in the "hanging over" side (in black). - If unmute the Geometry "True Normal" node, the normal seems to be correct but it lacks smooth interpolation (observable upon close inspection. - Add a displacement modifier (thus disabling the adaptive subdivision), and remove the displacement output link in the material. - Set the displacement modifier to the displacement texture (use RGB to XYZ mode). - Vector displacement renders normal correctly. | VD on adaptive subdiv | VD on adaptive subdiv (with true normal) | VD modifier on regular subdiv (correct) | |---|---|---| | ![图片](/attachments/2d602724-523d-4c5e-861e-90f569625c73) | ![图片](/attachments/98d0cf1a-89bd-4fdd-bbc2-9da9a17fe06f) | ![图片](/attachments/22a57cd8-d72f-4712-b99e-2be698c78fb8) |

图片.png

54 KiB

图片.png

74 KiB

Vector Displacement -----_ Adaptive Subdivision----_ Normal Error .blend

1.7 MiB

图片.png

47 KiB

YimingWu added the

labels 2023-08-27 16:59:50 +02:00

Alaska commented

2023-08-31 09:30:48 +02:00

I can confirm the issue and quickly looked into investigating it but couldn't figure out exactly what's causing it. But just for reference, here are a few things I found:

This only occurs when Displacement + Bump is enabled in the material, suggesting the issue is caused by the bump mapping applied on top of the displacement.
This doesn't appear to be an issue with adaptive subdivsion. Turning off adaptive subdivsion and just using a plane with many faces shows the same issue. This contradicts the original report. So I don't know what's going on here.
Enabling OSL fixes it. Likely a difference between how some math is done in OSL vs SVM. Likely a good place to start to help identify the issues for anyone looking into fixing it. Although, if you set the object to "Flat Shading", OSL looks a bit broken compared to SVM. So I'm not sure if OSL is 100% correct here.

I can confirm the issue and quickly looked into investigating it but couldn't figure out exactly what's causing it. But just for reference, here are a few things I found: 1. This only occurs when Displacement + Bump is enabled in the material, suggesting the issue is caused by the bump mapping applied on top of the displacement. 2. This doesn't appear to be an issue with adaptive subdivsion. Turning off adaptive subdivsion and just using a plane with many faces shows the same issue. This contradicts the original report. So I don't know what's going on here. 3. Enabling OSL fixes it. Likely a difference between how some math is done in OSL vs SVM. Likely a good place to start to help identify the issues for anyone looking into fixing it. Although, if you set the object to "Flat Shading", OSL looks a bit broken compared to SVM. So I'm not sure if OSL is 100% correct here.

Alaska commented

2023-09-01 06:41:09 +02:00

Another update. The black faces issues is caused by the normals of select faces pointing in directions that result in the face rendering incorrectly (as would be expected). I just wanted to explicitly point this out since similar reports to this had NaN faces due to divide by 0. This is not the case here.

Now about the differences with OSL vs SVM.
It seems OSL and SVM are doing basically the same math, but they're working with different values.

Specifically dP.dx and dP.dy in svm_node_set_bump() from /intern/cycles/kernel/svm/displace.h are different from dPdx and dPdy from node_bump() in /intern/cycles/kernel/osl/shaders/node_bump.osl

The difference in these values tells us why OSL and SVM behave differently. But I'm not knowledgeable enough in this area to know which one is correct. Someone else will have to look into this issue. But I hope this helps as a starting point. Just to recap:

The black faces are caused by the bump mapping applied after displacement.
The bump mapping is causing some of the normals of faces to point weird directions causing them to render black.
SVM and OSL behave differently with this issue. This is caused by dP being different between the two. Which one's correct? I don't know. But they need to be aligned.
There could still be issues else where. For example, maybe the math for bump mapping is wrong? Maybe the math is right and this is an expected artifact? Maybe subtle floating point precision issues are causing issues in this scene?

Another update. The black faces issues is caused by the normals of select faces pointing in directions that result in the face rendering incorrectly (as would be expected). I just wanted to explicitly point this out since similar reports to this had NaN faces due to divide by 0. This is not the case here. Now about the differences with OSL vs SVM. It seems OSL and SVM are doing basically the same math, but they're working with different values. Specifically `dP.dx` and `dP.dy` in `svm_node_set_bump()` from `/intern/cycles/kernel/svm/displace.h` are different from `dPdx` and `dPdy` from `node_bump()` in `/intern/cycles/kernel/osl/shaders/node_bump.osl` The difference in these values tells us why OSL and SVM behave differently. But I'm not knowledgeable enough in this area to know which one is correct. Someone else will have to look into this issue. But I hope this helps as a starting point. Just to recap: 1. The black faces are caused by the bump mapping applied after displacement. 2. The bump mapping is causing some of the normals of faces to point weird directions causing them to render black. 3. SVM and OSL behave differently with this issue. This is caused by dP being different between the two. Which one's correct? I don't know. But they need to be aligned. 4. There could still be issues else where. For example, maybe the math for bump mapping is wrong? Maybe the math is right and this is an expected artifact? Maybe subtle floating point precision issues are causing issues in this scene?

👀 1

Alaska commented

2023-09-17 02:47:56 +02:00

@LukasStockner I noticed you've been doing a bit of work related to normals and OSL recently. Maybe you could take a look at this issue if you have the time and knowledge?

👀 1

Lukas Stockner self-assigned this 2023-09-27 23:46:13 +02:00

Lukas Stockner commented

2023-09-28 00:16:33 +02:00

This is caused by the compact differential representation that was added a while ago to help with GPU memory usage.

With OSL, the full dPdx/dPdy differentials are tracked in ShaderGlobals, so node_bump gets the correct ones.

With SVM, svm_node_enter_bump_eval gets the full differentials from attributes, but then only stores a compact form. When svm_node_set_bump expands the compact form again, it ends up with the wrong value.

Two possible solutions: Either pack the full differentials into the bump state and pass its offset into svm_node_set_bump through the SVM compiler, or re-fetch the undisplaced position attribute in svm_node_set_bump.

This is caused by the compact differential representation that was added a while ago to help with GPU memory usage. With OSL, the full dPdx/dPdy differentials are tracked in `ShaderGlobals`, so `node_bump` gets the correct ones. With SVM, `svm_node_enter_bump_eval` gets the full differentials from attributes, but then only stores a compact form. When `svm_node_set_bump` expands the compact form again, it ends up with the wrong value. Two possible solutions: Either pack the full differentials into the bump state and pass its offset into `svm_node_set_bump` through the SVM compiler, or re-fetch the undisplaced position attribute in `svm_node_set_bump`.

Lukas Stockner referenced a pull request that will close this issue

2023-09-28 02:53:07 +02:00

Fix #111588: Cycles: Vector displacement with adaptive subdiv breaks normal #112987

Lukas Stockner referenced this issue from a commit

2023-10-02 02:20:00 +02:00

Fix #111588: Cycles: Vector displacement with adaptive subdiv breaks normal

Lukas Stockner closed this issue

2023-10-02 02:20:02 +02:00

Blender Bot added

Status

Resolved

and removed