Inconsistent Behavior with Material Shader Node Tree between different versions of Blender #99212

New Issue

sn0w75-4 · 2022-06-27T18:40:52+02:00

sn0w75-4 commented

2022-06-27 18:40:52 +02:00

System Information
Operating system: Debian Linux (Testing Branch)
Graphics card: RX 6700 XT

Blender Version
Broken: Blender 3.2, 3.3.0-alpha+master.4c3b984b3daa
Worked: Blender 2.93

Short description of error
A material shader node tree that uses math to zero out the alpha channel when both back and front faces are visible behaves differently/does not work correctly on newer versions of Blender.

Exact steps for others to reproduce the error
Open attached .blend file, switch to Rendered view, on version 2.93 you'll find the shadow volume works correctly, on versions 3.2 and 3.3.0-alpha you'll find it behaves differently/incorrectly.
shadow-volume-shader.blend

Here's how it looks in Blender 2.93:

Here's how it looks in Blender 3.2 and 3.3.0-alpha:

To be clear, this shader is essentially an implementation of Stencil Shadows/Shadow Volumes,
except the alpha channel is used in lieu of the stencil buffer, since Blender does not provide access to the stencil buffer to the best of my knowledge.
It can be used for a variety of interesting effects not limited to shadows, for an additional use-case example, see here: https://youtu.be/iAX0T7yxDSM?t=78

**System Information** Operating system: Debian Linux (Testing Branch) Graphics card: RX 6700 XT **Blender Version** Broken: Blender 3.2, 3.3.0-alpha+master.4c3b984b3daa Worked: Blender 2.93 **Short description of error** A material shader node tree that uses math to zero out the alpha channel when both back and front faces are visible behaves differently/does not work correctly on newer versions of Blender. **Exact steps for others to reproduce the error** Open attached .blend file, switch to Rendered view, on version 2.93 you'll find the shadow volume works correctly, on versions 3.2 and 3.3.0-alpha you'll find it behaves differently/incorrectly. [shadow-volume-shader.blend](https://archive.blender.org/developer/F13232915/shadow-volume-shader.blend) Here's how it looks in Blender 2.93: ![Screenshot from 2022-06-27 11-48-38.png](https://archive.blender.org/developer/F13232916/Screenshot_from_2022-06-27_11-48-38.png) Here's how it looks in Blender 3.2 and 3.3.0-alpha: ![Screenshot from 2022-06-27 11-48-40.png](https://archive.blender.org/developer/F13232918/Screenshot_from_2022-06-27_11-48-40.png) To be clear, this shader is essentially an implementation of Stencil Shadows/Shadow Volumes, except the alpha channel is used in lieu of the stencil buffer, since Blender does not provide access to the stencil buffer to the best of my knowledge. It can be used for a variety of interesting effects not limited to shadows, for an additional use-case example, see here: https://youtu.be/iAX0T7yxDSM?t=78

sn0w75-4 commented

2022-06-27 18:40:52 +02:00

Added subscriber: @sn0w75-4

Germano Cavalcante commented

2022-06-28 18:28:43 +02:00

Added subscriber: @mano-wii

Germano Cavalcante commented

2022-06-28 18:28:43 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Germano Cavalcante commented

2022-06-28 18:28:43 +02:00

If we compare with the result seen in Cycles, I would say that the correct result is the current one, the one shown in the first image is actually wrong.
So I wouldn't say there's a bug here (there must have been a fix).

Could you provide an even more simplified version of the shader so that we can verify that this is indeed a bug?

If we compare with the result seen in Cycles, I would say that the correct result is the current one, the one shown in the first image is actually wrong. So I wouldn't say there's a bug here (there must have been a fix). Could you provide an even more simplified version of the shader so that we can verify that this is indeed a bug?

sn0w75-4 commented

2022-06-29 04:08:50 +02:00

My apologies, I forgot to mention: The above two pictures are when using the EEVEE render engine (this shader is not designed for use with Cycles).
Pretty important point to note given that the way EEVEE and Cycles handle alpha is most likely very different.

I'm not sure if I can simplify the shader beyond how it stands currently, but I may try in the near future if you'd still like me to now knowing this bug report is directed at EEVEE rather than Cycles.
To try and explain what the shader is attempting to do as simply as possible:
(Using Alpha Blending, assuming the Blend operation is GL_FUNC_ADD/VK_BLEND_OP_ADD)
If we are shading a Back face, set Alpha to -1 and render the fragment with -1 alpha to the screen.
If we are shading a Front face, set Alpha to +1 (or desired transparency value) and render the fragment with +1 to the screen.

Back Face Only: Alpha = -1 (transparent)
Back + Front Face: Alpha = 0 (transparent)
Front Face Only: Alpha = 1 (opaque)

Given the above, I think the result of the above shader should be that only fragments/pixels of the sphere that intersect with the floor plane should be rendered (the result of the first image/Blender 2.93 EEVEE),
because the back faces of the sphere fail the depth test only where they are hidden behind the floor plane, leaving only the front faces to be rendered to the screen.

My apologies, I forgot to mention: The above two pictures are when using the EEVEE render engine (this shader is not designed for use with Cycles). Pretty important point to note given that the way EEVEE and Cycles handle alpha is most likely very different. I'm not sure if I can simplify the shader beyond how it stands currently, but I may try in the near future if you'd still like me to now knowing this bug report is directed at EEVEE rather than Cycles. To try and explain what the shader is attempting to do as simply as possible: (Using Alpha Blending, assuming the Blend operation is GL_FUNC_ADD/VK_BLEND_OP_ADD) If we are shading a Back face, set Alpha to -1 and render the fragment with -1 alpha to the screen. If we are shading a Front face, set Alpha to +1 (or desired transparency value) and render the fragment with +1 to the screen. Back Face Only: Alpha = -1 (transparent) Back + Front Face: Alpha = 0 (transparent) Front Face Only: Alpha = 1 (opaque) Given the above, I *think* the result of the above shader should be that only fragments/pixels of the sphere that intersect with the floor plane should be rendered (the result of the first image/Blender 2.93 EEVEE), because the back faces of the sphere fail the depth test only where they are hidden behind the floor plane, leaving only the front faces to be rendered to the screen.

Germano Cavalcante commented

2022-06-29 06:12:49 +02:00

Added subscriber: @fclem

Germano Cavalcante commented

2022-06-29 06:12:49 +02:00

If we are shading a Back face, set Alpha to -1 and render the fragment with -1 alpha to the screen.
If we are shading a Front face, set Alpha to +1 (or desired transparency value) and render the fragment with +1 to the screen.

Back Face Only: Alpha = -1 (transparent)
Back + Front Face: Alpha = 0 (transparent)
Front Face Only: Alpha = 1 (opaque)

If this is the case, the material could be simplified to:

But using negative value in the mix shader to get transparency with "alpha -1", is not conventional. And from 80859a6cb2, Eevee's Mix Shader is now clamped (just like Cycles).

That was an intentional change, so not really considered a bug.

If you want to get transparency values beyond the limit, you can simply increase the intensity of the transparency color:

This even has the advantage of working in Cycles.

So unless it proves to have a real advantage in unclamping the Mix Shader so that it behaves as before, I don't think it needs to be changed. (Cc @fclem)

> If we are shading a Back face, set Alpha to -1 and render the fragment with -1 alpha to the screen. > If we are shading a Front face, set Alpha to +1 (or desired transparency value) and render the fragment with +1 to the screen. > > Back Face Only: Alpha = -1 (transparent) > Back + Front Face: Alpha = 0 (transparent) > Front Face Only: Alpha = 1 (opaque) If this is the case, the material could be simplified to: ![Captura de Tela 2022-06-29 às 00.48.55.png](https://archive.blender.org/developer/F13235961/Captura_de_Tela_2022-06-29_a_s_00.48.55.png) But using negative value in the mix shader to get transparency with "alpha -1", is not conventional. And from 80859a6cb2, Eevee's `Mix Shader` is now clamped (just like Cycles). That was an intentional change, so not really considered a bug. If you want to get transparency values beyond the limit, you can simply increase the intensity of the transparency color: ![Captura de Tela 2022-06-29 às 00.55.23.png](https://archive.blender.org/developer/F13235975/Captura_de_Tela_2022-06-29_a_s_00.55.23.png) This even has the advantage of working in Cycles. So unless it proves to have a real advantage in unclamping the `Mix Shader` so that it behaves as before, I don't think it needs to be changed. (Cc @fclem)

sn0w75-4 commented

2022-06-29 23:40:42 +02:00

Agreed, the only thing(s) that might be worth doing are:

Mention in the documentation that the output of the Mix Shader is clamped.
and/or
Add a visual cue in the UI (a greyed out checkbox?) that makes it clear to the user that the output of the Mix Shader is being clamped.

Agreed, the only thing(s) that might be worth doing are: 1. Mention in the [documentation](https://docs.blender.org/manual/en/latest/render/shader_nodes/shader/mix.html) that the output of the Mix Shader is clamped. and/or 2. Add a visual cue in the UI (a greyed out checkbox?) that makes it clear to the user that the output of the Mix Shader is being clamped.

Germano Cavalcante commented

2022-06-29 23:57:18 +02:00

Changed status from 'Needs User Info' to: 'Archived'

Germano Cavalcante closed this issue

2022-06-29 23:57:18 +02:00

Germano Cavalcante commented

2022-06-29 23:57:18 +02:00

I don't think it is necessary to indicate in the manual on every slide in the Blender interface whether it is clamped or not.
If the user puts -1 and 0 appears it should be clamped.

But it looks like this change wasn't mentioned in the release notes: https://wiki.blender.org/wiki/Reference/Release_Notes/3.2
A mistake.

I don't think it is necessary to indicate in the manual on every slide in the Blender interface whether it is clamped or not. If the user puts -1 and 0 appears it should be clamped. But it looks like this change wasn't mentioned in the release notes: https://wiki.blender.org/wiki/Reference/Release_Notes/3.2 A mistake.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Inconsistent Behavior with Material Shader Node Tree between different versions of Blender #99212