CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree #113871

New Issue

michael campbell · 2023-10-18T03:38:43+02:00

michael campbell commented

2023-10-18 03:38:43 +02:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.99

Blender Version
Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-12 18:54, hash: 1c4b2ad17f5f
Worked: (3.6.3)

Short description of error

I'm aware that volumes can't generate AOV data, but to avoid breaking an addon, would it be possible for this to still be fixed?

In Cycles, if the material output node's volume socket is the only one wired, then the object or smoke domain will render black if there is also a shader AOV node in the material's node_tree. Only affects final render.

The world output node doesn't exhibit the same issue if only it's volume input is wired and there's a custom aov node in the world's node tree, although I did notice that if surface and volume have inputs, the hdri turns black if the principled volume's density is anything other than 0, which was unexpected (and happens even without an aov node present). I don't use volumes in the world node tree, so I'm not sure if that is a bug or not.

Exact steps for others to reproduce the error

Open the attached blend file, go to the compositor and render with f12.
The object and smoke domain appear black
connect something to the surface input of the material output node and re-render
the objects now render correctly.
remove connection to the surface input and delete the aovs group node and re-render
the objects now render

Viewport:

render:

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 536.99 **Blender Version** Broken: version: 4.0.0 Beta, branch: blender-v4.0-release, commit date: 2023-10-12 18:54, hash: `1c4b2ad17f5f` Worked: (3.6.3) **Short description of error** I'm aware that volumes can't generate AOV data, but to avoid breaking an addon, would it be possible for this to still be fixed? In Cycles, if the material output node's volume socket is the only one wired, then the object or smoke domain will render black if there is also a shader AOV node in the material's node_tree. Only affects final render. The world output node doesn't exhibit the same issue if only it's volume input is wired and there's a custom aov node in the world's node tree, although I did notice that if surface and volume have inputs, the hdri turns black if the principled volume's density is anything other than 0, which was unexpected (and happens even without an aov node present). I don't use volumes in the world node tree, so I'm not sure if that is a bug or not. **Exact steps for others to reproduce the error** 1. Open the attached blend file, go to the compositor and render with f12. 2. The object and smoke domain appear black 3. connect something to the surface input of the material output node and re-render 4. the objects now render correctly. 5. remove connection to the surface input and delete the aovs group node and re-render 6. the objects now render Viewport: ![image](/attachments/cbdd7bcb-bb84-4601-b810-8c0a5cacf4e0) render: ![image](/attachments/9a6d6313-3753-4819-bb8f-98d8fec32a30)

image.png

2.4 MiB

image.png

333 KiB

smoke domain renders black if material has custom aovs.blend

6.9 MiB

michael campbell added the

labels 2023-10-18 03:38:44 +02:00

michael campbell changed title from ~~CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree~~ to CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree

2023-10-18 05:55:29 +02:00

michael campbell changed title from ~~CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree~~ to CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree

2023-10-18 06:10:11 +02:00

Pratik Borhade commented

2023-10-18 07:58:01 +02:00

Hi, thanks for the report. Can confirm the regression.
@lichtwerk , can you help in bisecting?

Hi, thanks for the report. Can confirm the regression. @lichtwerk , can you help in bisecting?

Pratik Borhade added

Needs Info from Developers

and removed

labels 2023-10-18 07:58:16 +02:00

Philipp Oeser commented

2023-10-18 09:46:19 +02:00

Hi, thanks for the report. Can confirm the regression.
@lichtwerk , can you help in bisecting?

On it

> Hi, thanks for the report. Can confirm the regression. > @lichtwerk , can you help in bisecting? On it

Brecht Van Lommel referenced this issue from a commit

2023-10-18 17:23:31 +02:00

Fix #113871: Cycles shader with volume shader and AOV output renders black

Brecht Van Lommel closed this issue

2023-10-18 17:24:45 +02:00

Blender Bot added

Status

Resolved

and removed

Status

Needs Info from Developers

labels 2023-10-18 17:24:48 +02:00

michael campbell commented

2023-10-18 18:51:42 +02:00

@brecht , thanks for the quick fix, it's worked a treat for the render but I think the solution of adding a transparency bsdf leads to additional problems with the AOV data. The behaviour in 3.6 of the aov being ignored if only the volume socket was wired was preferable, because it allowed objects occluded by the volume that also write to the same AOV to still generate reasonably clean data.

scene (all objects have custom AOV):

render:

3.6 aov output:

4.0 with above commit:

I've modified the addon now to no longer create custom AOV's for volumes without surfaces, so I'm fine either way, but just thought I'd point it out in case it affects anyone elses 👍

@brecht , thanks for the quick fix, it's worked a treat for the render but I think the solution of adding a transparency bsdf leads to additional problems with the AOV data. The behaviour in 3.6 of the aov being ignored if only the volume socket was wired was preferable, because it allowed objects occluded by the volume that also write to the same AOV to still generate reasonably clean data. scene (all objects have custom AOV): ![image](/attachments/f6ac96b8-4a8c-4ad3-8a2a-466856ca535b) render: ![image](/attachments/52feffed-6f87-48ae-9dc3-c2ceaa9e9000) 3.6 aov output: ![image](/attachments/014fd6b0-36ca-4177-96c7-3bd992de8f4f) 4.0 with above commit: ![image](/attachments/328b1c73-cd2d-40dc-930d-01b3708184e5) I've modified the addon now to no longer create custom AOV's for volumes without surfaces, so I'm fine either way, but just thought I'd point it out in case it affects anyone elses 👍

image.png

1.2 MiB

image.png

624 KiB

image.png

755 KiB

image.png

287 KiB

image.png

1.9 MiB

Brecht Van Lommel referenced this issue from a commit

2023-10-20 16:28:53 +02:00

Cycles: don't write surface AOVs when there is only a volume shader

Brecht Van Lommel commented

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

Ok, the AOV is no longer written when there is only a volume shader now.

michael campbell commented

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

Thanks. But this will cause the volume to render black again if there's volume only and a custom AOV.

I think the section of code your editing isn't responsible for the change in behaviour, so somewhere else in the code, to keep the same behaviour as 3.6 perhaps this would be better?

if (!has_surface && has_volume) {
#ignore custom AOV rather than creating a transparent bsdf to force it to write.

By the way, there's no need to add a transparent BSDF if there's neither surface of volume. The AOV will already render correctly without the transparent bsdf, and in that case it would be intentional for the material output node to render black.

Current behaviour with neither surface or volume

Thanks. But this will cause the volume to render black again if there's volume only and a custom AOV. I think the section of code your editing isn't responsible for the change in behaviour, so somewhere else in the code, to keep the same behaviour as 3.6 perhaps this would be better? if (!has_surface && has_volume) { #ignore custom AOV rather than creating a transparent bsdf to force it to write. By the way, there's no need to add a transparent BSDF if there's neither surface of volume. The AOV will already render correctly without the transparent bsdf, and in that case it would be intentional for the material output node to render black. Current behaviour with neither surface or volume ![image](/attachments/5f019d0f-3911-4dd0-9055-0a5e265bb6ef)

image.png

1.2 MiB

michael campbell commented

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

Perhaps in this function on line 562 in svm.cpp, only have it find the AOV if the output node isn't a (volume with no surface)

void SVMCompiler::find_aov_nodes_and_dependencies(ShaderNodeSet &aov_nodes,
                                                  ShaderGraph *graph,
                                                  CompilerState *state)
{
  if !(! has_surface && has_volume) {
    foreach (ShaderNode *node, graph->nodes) {
      if (node->special_type == SHADER_SPECIAL_TYPE_OUTPUT_AOV) {
        OutputAOVNode *aov_node = static_cast<OutputAOVNode *>(node);
        if (aov_node->offset >= 0) {
          aov_nodes.insert(aov_node);
          foreach (ShaderInput *in, node->inputs) {
            if (in->link != NULL) {
              find_dependencies(aov_nodes, state->nodes_done, in);
            }
          }
        }
      }
    }
  }
}

Perhaps in this function on line 562 in svm.cpp, only have it find the AOV if the output node isn't a (volume with no surface) ``` void SVMCompiler::find_aov_nodes_and_dependencies(ShaderNodeSet &aov_nodes, ShaderGraph *graph, CompilerState *state) { if !(! has_surface && has_volume) { foreach (ShaderNode *node, graph->nodes) { if (node->special_type == SHADER_SPECIAL_TYPE_OUTPUT_AOV) { OutputAOVNode *aov_node = static_cast<OutputAOVNode *>(node); if (aov_node->offset >= 0) { aov_nodes.insert(aov_node); foreach (ShaderInput *in, node->inputs) { if (in->link != NULL) { find_dependencies(aov_nodes, state->nodes_done, in); } } } } } } } ```

Brecht Van Lommel commented

2023-10-20 21:14:16 +02:00

But this will cause the volume to render black again if there's volume only and a custom AOV.

I can't confirm this. Are you sure you are testing a build with all the fixes applied?

> But this will cause the volume to render black again if there's volume only and a custom AOV. I can't confirm this. Are you sure you are testing a build with all the fixes applied?

michael campbell commented

2023-10-20 21:26:34 +02:00

No I was just reading the code, so I could be wrong. The previous commit fixed the black volume by adding a transparent bsdf if there was an aov without a surface. But the new commit undoes that because now it only adds the transparent bsdf if there is neither (which already worked properly). It doesn't seem to have anything in place if there is only a volume input.

Rather than adding a transparent BSDF, perhaps just not finding the AOV if it's only a volume would be better? That'd fix the original bug without the problem of volumes writing AOV data?

No I was just reading the code, so I could be wrong. The previous commit fixed the black volume by adding a transparent bsdf if there was an aov without a surface. But the new commit undoes that because now it only adds the transparent bsdf if there is neither (which already worked properly). It doesn't seem to have anything in place if there is only a volume input. Rather than adding a transparent BSDF, perhaps just not finding the AOV if it's only a volume would be better? That'd fix the original bug without the problem of volumes writing AOV data?

michael campbell commented

2023-10-20 21:34:18 +02:00

![image](/attachments/654695c9-6687-4c24-a911-db63e4d906cc)

image.png

14 KiB

image.png

15 KiB

michael campbell commented

2023-10-20 21:36:54 +02:00

unless that would break the current behaviour of the world node being able to write to AOVs if there's only a volume.

michael campbell commented

2023-10-20 21:56:46 +02:00

I suppose the real question is, why is it now necessary to add a transparent BSDF to prevent the volume rendering black if there's an AOV node, when it wasn't needed in 3.6.

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

CYCLES : in the final render, objects and smoke domains render black if the material output node's volume input is the only one in use and there are custom aov nodes in the node _tree #113871