Eevee Shading Error- Object's go completely black if they have a normal map. #61870

New Issue

Jac Rossiter · 2019-02-23T02:16:30+01:00

Jac Rossiter commented

2019-02-23 02:16:30 +01:00

System Information
Operating system:Wn10
Graphics card:gtx970

2.8 2019-02-22

Objects shading breaks if duplicated in wireframe mode(must have a normal map node)

Add a material to an object, set shader to 'Principled BSDF', Set normal to 'Normal Map', press shift+z, select object, alt+d to duplicate, press shift+z. the object should now be black. To fix, switch shading mode in the top right and then switch back to eevee.

You don't need to actually use a normal map, just setting up the material like so suffices.

**System Information** Operating system:Wn10 Graphics card:gtx970 2.8 2019-02-22 **Objects shading breaks if duplicated in wireframe mode(must have a normal map node)** **Add a material to an object, set shader to 'Principled BSDF', Set normal to 'Normal Map', press shift+z, select object, alt+d to duplicate, press shift+z. the object should now be black. To fix, switch shading mode in the top right and then switch back to eevee.** You don't need to actually use a normal map, just setting up the material like so suffices. ![image.png](https://archive.blender.org/developer/F6691378/image.png)

blender-admin commented

2019-02-23 02:16:30 +01:00

#62832 was marked as duplicate of this issue

blender-admin commented

2019-02-23 02:16:30 +01:00

#60477 was marked as duplicate of this issue

blender-admin commented

2019-02-23 02:16:30 +01:00

#59827 was marked as duplicate of this issue

blender-admin commented

2019-02-23 02:16:30 +01:00

#61623 was marked as duplicate of this issue

blender-admin commented

2019-02-23 02:16:30 +01:00

#60550 was marked as duplicate of this issue

blender-admin commented

2019-02-23 02:16:30 +01:00

#62085 was marked as duplicate of this issue

Jac Rossiter commented

2019-02-23 02:16:31 +01:00

Added subscriber: @JacRossiter

Jac Rossiter changed title from ~~Eevee Shading Error~~ to Eevee Shading Error- Object's go completely black if they have a normal map.

2019-02-25 14:46:31 +01:00

Sebastian Parborg commented

2019-02-25 16:06:21 +01:00

Added subscriber: @ZedDB

Sebastian Parborg commented

2019-02-25 16:06:21 +01:00

I can't reproduce this on my end. Is this still an issue with the latest blender beta?

If so, does it happen if you download this dll and copy it so its located in the same directory as 'blender.exe' and run Blender normally?

I can't reproduce this on my end. Is this still an issue with the latest blender beta? If so, does it happen if you download [this dll ](https://download.blender.org/opengl/software-emulation/windows64/opengl32.dll) and copy it so its located in the same directory as 'blender.exe' and run Blender normally?

Jac Rossiter commented

2019-02-25 17:32:09 +01:00

I just tested with the latest version and with the opengl32 file(which for some reason slowed blender to an absolute crawl. It tool 4 attempts at opening blender to get something that didn't hang up. ShadingBug.blend I'm still getting the issue consistently and have also tried resetting to factory defaults. I've attached my blendfile and i've recorded a video demonstrating the issue. https://youtu.be/uVAivdGxDlU

I just tested with the latest version and with the opengl32 file(which for some reason slowed blender to an absolute crawl. It tool 4 attempts at opening blender to get something that didn't hang up. [ShadingBug.blend](https://archive.blender.org/developer/F6712466/ShadingBug.blend) I'm still getting the issue consistently and have also tried resetting to factory defaults. I've attached my blendfile and i've recorded a video demonstrating the issue. https://youtu.be/uVAivdGxDlU

Clément Foucault was assigned by Sebastian Parborg

2019-02-25 17:58:00 +01:00

Sebastian Parborg commented

2019-02-25 17:58:00 +01:00

I can reproduce this too now.

I've updated to description to mention that you are using the shift+z shortcut.
It's weird that it doesn't happen if you switch with the z pie menu instead of the shortcut.

I can reproduce this too now. I've updated to description to mention that you are using the shift+z shortcut. It's weird that it doesn't happen if you switch with the z pie menu instead of the shortcut.

Russell commented

2019-02-27 01:43:13 +01:00

Added subscriber: @Russ1642

Russell commented

2019-02-27 01:43:13 +01:00

I tried using the openGL32.dll. It still renders my normal mapped objects as black, just very very slowly. I'm on Windows Pro 64 bit with a GTX 1050.

Brecht Van Lommel commented

2019-03-01 18:30:46 +01:00

Added subscriber: @Denys-Ivanenko

Clément Foucault commented

2019-03-05 22:02:22 +01:00

Added subscribers: @Sergey, @brecht

Clément Foucault commented

2019-03-05 22:02:22 +01:00

This reveals a big issue. Everything in the batch cache is done right but the tangent layers are not updated / generated when doing this switching.

We added a hack to make it work when switching using the buttons and I can add the same hack to the operator too. This would fix it for this case but not the case of multiple viewport.

The hack comment reads :

		/* XXX Dependency graph does not support CD mask tracking,
		 * so we trigger  materials shading for until it's properly supported.
		 * This is to ensure material batches are all recreated when switching
		 * shading type. In the future DEG should replace this and just tag
		 * the meshes itself.
		 * This hack just tag BKE_MESH_BATCH_DIRTY_SHADING for every mesh that
		 * have a material. (see T55059) */

The real issue is that the depsgraph does not know what data to generate because data depends on a lots of things. The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use for this object (or even better, asks if this object is inside an active View or culled).

@brecht @Sergey What would be the best way to start this work?

This reveals a big issue. Everything in the batch cache is done right but the tangent layers are not updated / generated when doing this switching. We added a hack to make it work when switching using the buttons and I can add the same hack to the operator too. This would fix it for this case but not the case of multiple viewport. The hack comment reads : ``` /* XXX Dependency graph does not support CD mask tracking, * so we trigger materials shading for until it's properly supported. * This is to ensure material batches are all recreated when switching * shading type. In the future DEG should replace this and just tag * the meshes itself. * This hack just tag BKE_MESH_BATCH_DIRTY_SHADING for every mesh that * have a material. (see T55059) */ ``` The real issue is that the depsgraph does not know what data to generate because data depends on a lots of things. The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use for this object (or even better, asks if this object is inside an active View or culled). @brecht @Sergey What would be the best way to start this work?

Sergey Sharybin commented

2019-03-06 12:03:54 +01:00

Added subscriber: @mont29

Sergey Sharybin commented

2019-03-06 12:03:54 +01:00

@fclem, things are.. complicated. Will probably start with the simple answers which i know for sure.

or even better, asks if this object is inside an active View or culled).

This can not be done in the dependency graph. Dependency graph doesn't know anything about viewport, and its main goal is to make sure the scene as a whole is ready for display/use. Doing such culling tests will slow down navigation, and will make evaluation even more complicated (and slowerdue to more checks) to deal with cases when culled object is actually affecting something what is visible.

Maybe (maybe) something we can go into later, but is not a complexity i am looking forward at this point.

The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use

Think we've got quite everything for this: we already do similar thing for the modifiers evaluation (and @mont29 refactored some bits in D4407 which is ready to go in).

The annoying part is that currently those data masks are calculated and checked during relations update. So ideally we would need to separate those masks a bit: store "invariant" masks based on the depsgraph builder, and then have additionaly mask which will gather masks when shaging or viewport changes. And the outer world we will report a combined mask between those.

Is also possible to tag ID nodes which custom data mask changed.

Not sure what would be better: either have an explicit call like DEG_on_customdata_masks_changed_update() or by collecting masks prior to evaluation.
The first approach is annoying since requires an explicit call from all places which would affect the masks.
The second approach is annoying since it can't be easily optimized out by skipping traversal of all ID nodes, so it will be a lot of CPU ticks spent just to see that nothing has changed.

Maybe truth is somewhere in the middle, we will tag dependency graph for custom data masks update, and then actual update is done as first step of evaluation

@fclem, things are.. complicated. Will probably start with the simple answers which i know for sure. > or even better, asks if this object is inside an active View or culled). This can not be done in the dependency graph. Dependency graph doesn't know anything about viewport, and its main goal is to make sure the scene as a whole is ready for display/use. Doing such culling tests will slow down navigation, and will make evaluation even more complicated (and slowerdue to more checks) to deal with cases when culled object is actually affecting something what is visible. Maybe (maybe) something we can go into later, but is not a complexity i am looking forward at this point. > The best way would be to have a per object callback inside the depsgraph that asks what data layers the draw engines will use Think we've got quite everything for this: we already do similar thing for the modifiers evaluation (and @mont29 refactored some bits in [D4407](https://archive.blender.org/developer/D4407) which is ready to go in). The annoying part is that currently those data masks are calculated and checked during relations update. So ideally we would need to separate those masks a bit: store "invariant" masks based on the depsgraph builder, and then have additionaly mask which will gather masks when shaging or viewport changes. And the outer world we will report a combined mask between those. Is also possible to tag ID nodes which custom data mask changed. Not sure what would be better: either have an explicit call like `DEG_on_customdata_masks_changed_update()` or by collecting masks prior to evaluation. The first approach is annoying since requires an explicit call from all places which would affect the masks. The second approach is annoying since it can't be easily optimized out by skipping traversal of all ID nodes, so it will be a lot of CPU ticks spent just to see that nothing has changed. Maybe truth is somewhere in the middle, we will tag dependency graph for custom data masks update, and then actual update is done as first step of evaluation

Brecht Van Lommel commented

2019-03-08 17:17:26 +01:00

Added subscribers: @Mets, @fclem, @kpavicic, @andreymd87, @JacquesLucke, @acoimbraf