Page MenuHome

Eevee Shading Error- Object's go completely black if they have a normal map.
Closed, ResolvedPublic

Description

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.

Event Timeline

Jac Rossiter (Jakro) renamed this task from Eevee Shading Error to Eevee Shading Error- Object's go completely black if they have a normal map..Feb 25 2019, 2:46 PM
Sebastian Parborg (zeddb) triaged this task as Needs Information from User priority.

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 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.

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

Sebastian Parborg (zeddb) raised the priority of this task from Needs Information from User to Confirmed, Medium.

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 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 (brecht) raised the priority of this task from Confirmed, Medium to Confirmed, High.Mar 4 2019, 6:38 PM

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 Van Lommel (brecht) @Sergey Sharybin (sergey) What would be the best way to start this work?

@Clément Foucault (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 @Bastien Montagne (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