Triager-bot/blender-bug-reports
1
0
Code Issues 53 Packages Projects Wiki

Calling b.node_or_null() in when declaring shader node changes the closure weight in EEVEE #76

New Issue
Open
opened 2026-04-13 15:49:13 +00:00 by Triager-bot · 7 comments
Triager-bot commented 2026-04-13 15:49:13 +00:00
Owner
Copy Link

Original bug report: https://projects.blender.org/blender/blender/issues/157280

System Information
Operating system: macOS-15.7.3-arm64-arm-64bit-Mach-O 64 Bits
Graphics card: Metal API Apple M4 Pro 1.2

Blender Version
Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-04-13 09:32, hash: b1f67602e773
Worked: (newest version of Blender that worked as expected)

Short description of error
Setting declaration_.is_context_dependent to true in a shader node declaration seems to modify the closure weight in EEVEE.

Exact steps for others to reproduce the error
Call b.node_or_null() inside node_declare() of a shader node, for example:

--- a/source/blender/nodes/shader/nodes/node_shader_subsurface_scattering.cc
+++ b/source/blender/nodes/shader/nodes/node_shader_subsurface_scattering.cc
@@ -38,6 +38,7 @@ static void node_declare(NodeDeclarationBuilder &b)
       .min(0.0f)
       .max(1.0f)
       .subtype(PROP_FACTOR);
+  b.node_or_null();
   b.add_input<decl::Float>("Anisotropy"_ustr)
       .default_value(0.0f)
       .min(0.0f)

And then check the render result of that shader node in EEVEE, for example render/sss/sss_concave_clamp.blend, and see that the render result changed.
If you print values of GPUNodeStacks in node_shader_gpu_subsurface_scattering(), you can see that the input that corresponds to Weight has changed.

Original bug report: https://projects.blender.org/blender/blender/issues/157280 **System Information** Operating system: macOS-15.7.3-arm64-arm-64bit-Mach-O 64 Bits Graphics card: Metal API Apple M4 Pro 1.2 **Blender Version** Broken: version: 5.2.0 Alpha, branch: main, commit date: 2026-04-13 09:32, hash: `b1f67602e773` Worked: (newest version of Blender that worked as expected) **Short description of error** Setting `declaration_.is_context_dependent` to `true` in a shader node declaration seems to modify the closure weight in EEVEE. **Exact steps for others to reproduce the error** Call `b.node_or_null()` inside `node_declare()` of a shader node, for example: ```diff --- a/source/blender/nodes/shader/nodes/node_shader_subsurface_scattering.cc +++ b/source/blender/nodes/shader/nodes/node_shader_subsurface_scattering.cc @@ -38,6 +38,7 @@ static void node_declare(NodeDeclarationBuilder &b) .min(0.0f) .max(1.0f) .subtype(PROP_FACTOR); + b.node_or_null(); b.add_input<decl::Float>("Anisotropy"_ustr) .default_value(0.0f) .min(0.0f) ``` And then check the render result of that shader node in EEVEE, for example `render/sss/sss_concave_clamp.blend`, and see that the render result changed. If you print values of GPUNodeStacks in `node_shader_gpu_subsurface_scattering()`, you can see that the input that corresponds to Weight has changed.
Triager-bot added the
Status
Needs review
 label 2026-04-13 15:49:13 +00:00
Triager-bot commented 2026-04-13 15:49:22 +00:00
Author
Owner
Copy Link

Report is clear

LLM Reasoning

Got it, let's analyze this bug report. The question is whether it clearly describes the issue. First, check the title: "Calling b.node_or_null() in when declaring shader node changes the closure weight in EEVEE" – that's clear. Then the body: short description says setting a flag modifies closure weight. Steps to reproduce are given with code diff and example file. The steps explain what to do (call b.node_or_null() in node_declare) and how to check (render result, print GPUNodeStacks). So the clarity is good. No major issues here. So the answer should be Yes.

JSON Data

{
"llm_judgement": true,
"processing_time": 8.908825
}

<!-- ID: CLARITY_CHECK --> ### Report is clear <details> <summary>LLM Reasoning</summary> Got it, let's analyze this bug report. The question is whether it clearly describes the issue. First, check the title: "Calling b.node_or_null() in when declaring shader node changes the closure weight in EEVEE" – that's clear. Then the body: short description says setting a flag modifies closure weight. Steps to reproduce are given with code diff and example file. The steps explain what to do (call b.node_or_null() in node_declare) and how to check (render result, print GPUNodeStacks). So the clarity is good. No major issues here. So the answer should be Yes. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 8.908825 } </details>
Triager-bot commented 2026-04-13 15:49:33 +00:00
Author
Owner
Copy Link

Report is specific

LLM Reasoning

Got it, let's analyze this bug report. The title is "Calling b.node_or_null() in when declaring shader node changes the closure weight in EEVEE". The body describes a specific scenario: modifying a shader node declaration by adding b.node_or_null() and observing a change in closure weight in EEVEE. The exact steps include a code diff showing where to add that line, and a specific test case (render/sss/sss_concave_clamp.blend). This is about a specific issue because it's tied to a particular action (calling b.node_or_null() in node_declare) and a specific outcome (closure weight change in EEVEE). So the answer should be 'Specific'.

JSON Data

{
"llm_judgement": true,
"processing_time": 10.575964
}

<!-- ID: SPECIFIC_REPORT --> ### Report is specific <details> <summary>LLM Reasoning</summary> Got it, let's analyze this bug report. The title is "Calling `b.node_or_null()` in when declaring shader node changes the closure weight in EEVEE". The body describes a specific scenario: modifying a shader node declaration by adding `b.node_or_null()` and observing a change in closure weight in EEVEE. The exact steps include a code diff showing where to add that line, and a specific test case (render/sss/sss_concave_clamp.blend). This is about a specific issue because it's tied to a particular action (calling `b.node_or_null()` in node_declare) and a specific outcome (closure weight change in EEVEE). So the answer should be 'Specific'. </details> <details> <summary>JSON Data</summary> { "llm_judgement": true, "processing_time": 10.575964 } </details>
Triager-bot commented 2026-04-13 15:49:48 +00:00
Author
Owner
Copy Link

Report flagged as NOT a duplicate by LLM

Evaluate Closure in Shader Broken if no Closure is attached

https://projects.blender.org/blender/blender/issues/146521

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.88 Opengl Backend

Blender Version
Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-18 22:21, hash: c2766d205809
Worked: N/A as this is a new feature in Blender 5.0

Short description of error
Shader Vs. Geometry Nodes
image.png
image.png

Exact steps to reproduce the issue

  • Open the attached .blend file, it should be set to material preview mode
  • Notice that the material is always black.
    • This seems to be because the "Evaluate Closure" node has no closure to evalutate, and so it seems output nothing.
  • Switch to the geometry nodes editor, and enable the viewer node
    • Notice that the evaluate closure node is outputing a value, even through there is no closure to evaluate. So the behaviour of this node is different between Geometry nodes and Shader nodes.
LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps.

Bug Report 1: The issue is about calling b.node_or_null() in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (adding that function call) and checking render results, specifically the closure weight change.

Bug Report 2: The issue is about the "Evaluate Closure" node not working when no closure is attached, with different behavior between Shader nodes and Geometry Nodes. Steps include opening a .blend file, noticing black material in preview, then switching to geometry nodes editor to see output.

The core issues are different: one is about a specific function call (node_or_null()) affecting closure weight in EEVEE, the other is about an "Evaluate Closure" node's behavior when no closure is present. The descriptions and steps don't overlap. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 14.626986,
"duplicate_report_number": "146521"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Evaluate Closure in Shader Broken if no Closure is attached</summary> https://projects.blender.org/blender/blender/issues/146521 **System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.88 Opengl Backend **Blender Version** Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-18 22:21, hash: `c2766d205809` Worked: N/A as this is a new feature in Blender 5.0 **Short description of error** Shader Vs. Geometry Nodes ![image.png](/attachments/b49815b9-a240-4d3b-8a6f-eebedc8266fa) ![image.png](/attachments/8933adbe-6813-48d6-acfb-b858d0834b91) **Exact steps to reproduce the issue** - Open the attached .blend file, it should be set to material preview mode - Notice that the material is always black. - This seems to be because the "Evaluate Closure" node has no closure to evalutate, and so it seems output nothing. - Switch to the geometry nodes editor, and enable the viewer node - Notice that the evaluate closure node is outputing a value, even through there is no closure to evaluate. So the behaviour of this node is different between Geometry nodes and Shader nodes. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps. Bug Report 1: The issue is about calling `b.node_or_null()` in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (adding that function call) and checking render results, specifically the closure weight change. Bug Report 2: The issue is about the "Evaluate Closure" node not working when no closure is attached, with different behavior between Shader nodes and Geometry Nodes. Steps include opening a .blend file, noticing black material in preview, then switching to geometry nodes editor to see output. The core issues are different: one is about a specific function call (`node_or_null()`) affecting closure weight in EEVEE, the other is about an "Evaluate Closure" node's behavior when no closure is present. The descriptions and steps don't overlap. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 14.626986, "duplicate_report_number": "146521" } </details>
Triager-bot commented 2026-04-13 15:50:01 +00:00
Author
Owner
Copy Link

Report flagged as NOT a duplicate by LLM

Crash viewing shader value from inside the closure

https://projects.blender.org/blender/blender/issues/146462

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.88 Opengl Backend

Blender Version
Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-16 23:41, hash: 858254aca46d
Worked: N/A as this is a new feature in 5.0

Short description of error
Linking to material output can cause crash, if not, pan inside the node editor.
image.png

Exact steps to reproduce the issue

  • Download and open Closure Crash test6.blend
  • Control + Shift + Left Click on the Evaluate Closure node inside the closure in the shader editor to preview it
  • Wait a few seconds and Blender should crahs
LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the description and steps for each.

Bug report 1 is about calling b.node_or_null() in a shader node's declaration changing closure weight in EEVEE. The steps involve modifying a shader node's code to add that call and checking render results.

Bug report 2 is about crashing when viewing a shader value from inside the closure, with steps involving opening a specific blend file and clicking an "Evaluate Closure" node.

The issues are completely different: one is about a change in closure weight due to a function call in node declaration (a rendering behavior issue), the other is a crash when previewing a closure (a stability issue). The descriptions and reproduction steps don't overlap. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 12.892607,
"duplicate_report_number": "146462"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Crash viewing shader value from inside the closure</summary> https://projects.blender.org/blender/blender/issues/146462 **System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 4070 SUPER/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 576.88 Opengl Backend **Blender Version** Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-16 23:41, hash: `858254aca46d` Worked: N/A as this is a new feature in 5.0 **Short description of error** Linking to material output can cause crash, if not, pan inside the node editor. ![image.png](/attachments/2dfda2e0-faef-4d33-bd3d-04e66042f068) **Exact steps to reproduce the issue** - Download and open [Closure Crash test6.blend](/attachments/65fa1546-62fa-4b82-976b-0959790b785e) - `Control + Shift + Left Click` on the `Evaluate Closure` node inside the closure in the shader editor to preview it - Wait a few seconds and Blender should crahs </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the description and steps for each. Bug report 1 is about calling `b.node_or_null()` in a shader node's declaration changing closure weight in EEVEE. The steps involve modifying a shader node's code to add that call and checking render results. Bug report 2 is about crashing when viewing a shader value from inside the closure, with steps involving opening a specific blend file and clicking an "Evaluate Closure" node. The issues are completely different: one is about a change in closure weight due to a function call in node declaration (a rendering behavior issue), the other is a crash when previewing a closure (a stability issue). The descriptions and reproduction steps don't overlap. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 12.892607, "duplicate_report_number": "146462" } </details>
Triager-bot commented 2026-04-13 15:50:14 +00:00
Author
Owner
Copy Link

Report flagged as NOT a duplicate by LLM

Geometry Nodes: Input Attribute Toggle disappears when evaluating closure

https://projects.blender.org/blender/blender/issues/153695

System Information
Operating system: Linux-6.8.0-94-generic-x86_64-with-glibc2.39 64 Bits, X11 UI
Graphics card: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 580.126.09 Opengl Backend

Blender Version
Broken: version: 5.1.0 Alpha, branch: physics-solver, commit date: 2026-01-30 09:59, hash: 1570c2cf60e3
Worked: (newest version of Blender that worked as expected)

Short description of error
Connecting a node group input to an Evaluate Closure node hides the "Input Attribute Toggle" in modifier settings.
image.png

Exact steps for others to reproduce the error

  1. Make a geometry nodes modifier
  2. Add a group input socket (shows the attribute toggle)
  3. Connect the input socket to an Evaluate Closure node inside the group. The attribute toggle disappears.

The structure type of the socket in the group or Eval Closure node does not matter. I don't see a logical reason why attribute input should be disabled in this case.

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce.

Bug report 1 is about calling b.node_or_null() in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (like Subsurface Scattering) and checking render results.

Bug report 2 is about Geometry Nodes: when connecting a group input to an Evaluate Closure node, the Input Attribute Toggle disappears. The steps are about geometry nodes modifier setup, not shader nodes or closure weight in EEVEE.

The issues are completely different—one is about shader node declaration affecting EEVEE's closure weight, the other is about geometry nodes attribute toggle disappearing when connecting to Evaluate Closure. So they're not the same issue.

JSON Data

{
"llm_judgement": false,
"processing_time": 12.804851000000001,
"duplicate_report_number": "153695"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Geometry Nodes: Input Attribute Toggle disappears when evaluating closure</summary> https://projects.blender.org/blender/blender/issues/153695 **System Information** Operating system: Linux-6.8.0-94-generic-x86_64-with-glibc2.39 64 Bits, X11 UI Graphics card: NVIDIA GeForce GTX 1660 Ti/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 580.126.09 Opengl Backend **Blender Version** Broken: version: 5.1.0 Alpha, branch: physics-solver, commit date: 2026-01-30 09:59, hash: `1570c2cf60e3` Worked: (newest version of Blender that worked as expected) **Short description of error** Connecting a node group input to an _Evaluate Closure_ node hides the "Input Attribute Toggle" in modifier settings. ![image.png](/attachments/b5fe4f45-8f18-40d8-b858-1adc21dd0c91) **Exact steps for others to reproduce the error** 1. Make a geometry nodes modifier 2. Add a group input socket (shows the attribute toggle) 3. Connect the input socket to an _Evaluate Closure_ node inside the group. The attribute toggle disappears. The structure type of the socket in the group or _Eval Closure_ node does not matter. I don't see a logical reason why attribute input should be disabled in this case. </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps to reproduce. Bug report 1 is about calling `b.node_or_null()` in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (like Subsurface Scattering) and checking render results. Bug report 2 is about Geometry Nodes: when connecting a group input to an Evaluate Closure node, the Input Attribute Toggle disappears. The steps are about geometry nodes modifier setup, not shader nodes or closure weight in EEVEE. The issues are completely different—one is about shader node declaration affecting EEVEE's closure weight, the other is about geometry nodes attribute toggle disappearing when connecting to Evaluate Closure. So they're not the same issue. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 12.804851000000001, "duplicate_report_number": "153695" } </details>
Triager-bot commented 2026-04-13 15:50:31 +00:00
Author
Owner
Copy Link

Report flagged as NOT a duplicate by LLM

EEVEE and EEVEE legacy | Subsurface Weight in Principled BSDF has no transition from 0 to 1

https://projects.blender.org/blender/blender/issues/114435

System Information
Operating system: Linux-6.5.9-arch2-1-x86_64-with-glibc2.38 64 Bits, X11 UI
Graphics card: NVIDIA GeForce GT 1030/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.113.01

Blender Version
Broken: version: 4.1.0 Alpha, branch: main, commit date: 2023-11-02 14:55, hash: 0f5abc5a8bc0
Worked: (newest version of Blender that worked as expected)

Short description of error
Subsurface Weight in the Principled BSDF has no between or blending values in EEVEE. So A full SSS weight is capped at .001 or .0001 instead of 1. I've also tried it out in EEVEE Legacy and Blender version 4.0 with no luck. I went back as of Alpha versions from September 17th trying to find if it broke along the way. However Eevee and Eevee(legacy) has had this problem since Subsurface Weight was put in.

Anyway, issue also causes a problem if someone tries to use b/w masks to tell if a surface is skin or not. Specially if someone switches between Cycles and Eevee.

No problems with Cycles though. Blending and influence for Subsurface Weight works like intended.

Exact steps for others to reproduce the error

  1. Use factory startup or you can use my blend file; *4.+SSS_issue-EEVEEnext&legacy.blend
  2. Make sure you're in the Shading Workspace.
  3. In the 3D Viewport Editor set Rendering Mode to "Rendered"
  4. Inside the Shader Editor, make sure you expand the Subsurface panel inside the Principled BSDF node
  5. Set Scale Slider to 2m
  6. Set Weight to 1
  7. Check mesh inside the 3D Viewport Editor; Subsurface scattering is working.
  8. Adjust Weight to .001 in the Principled BSDF node in the Shader Editor.
  9. Check back to the 3D Viewport to see no difference to the Subsurface shading on the mesh.
  10. While in the Shader Editor, try plugging a Checker Texture node into the Subsurface Weight.
  11. Switch over to Cycles to see what it does with my steps.

*My blend file is based on a factory startup and without much added stuff other than lights and a Suzanne head

LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the descriptions and steps.

Bug report 1 is about calling b.node_or_null() in a shader node's declaration changing closure weight in EEVEE. The steps involve modifying a node's declare function and checking render results.

Bug report 2 is about Subsurface Weight in Principled BSDF not transitioning from 0 to 1 in EEVEE, with steps involving adjusting the weight slider and seeing no change.

The key here: Report 1 is about a specific code change (calling node_or_null) affecting closure weight, while Report 2 is about the Subsurface Weight parameter not working as expected (no transition). These are different issues—one is a regression from a code modification in node declaration, the other is a persistent problem with the Principled BSDF's subsurface weight. So they're not duplicates.

JSON Data

{
"llm_judgement": false,
"processing_time": 16.376005,
"duplicate_report_number": "114435"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>EEVEE and EEVEE legacy | Subsurface Weight in Principled BSDF has no transition from 0 to 1</summary> https://projects.blender.org/blender/blender/issues/114435 **System Information** Operating system: Linux-6.5.9-arch2-1-x86_64-with-glibc2.38 64 Bits, X11 UI Graphics card: NVIDIA GeForce GT 1030/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 535.113.01 **Blender Version** Broken: version: 4.1.0 Alpha, branch: main, commit date: 2023-11-02 14:55, hash: `0f5abc5a8bc0` Worked: (newest version of Blender that worked as expected) **Short description of error** Subsurface Weight in the Principled BSDF has no between or blending values in EEVEE. So A full SSS weight is capped at .001 or .0001 instead of 1. I've also tried it out in EEVEE Legacy and Blender version 4.0 with no luck. I went back as of Alpha versions from September 17th trying to find if it broke along the way. However Eevee and Eevee(legacy) has had this problem since Subsurface Weight was put in. Anyway, issue also causes a problem if someone tries to use b/w masks to tell if a surface is skin or not. Specially if someone switches between Cycles and Eevee. No problems with Cycles though. Blending and influence for Subsurface Weight works like intended. **Exact steps for others to reproduce the error** 1. Use factory startup or you can use my blend file; *[4.+SSS_issue-EEVEEnext&legacy.blend](/attachments/b3899875-67c3-4dc5-a3e5-ec5598ec5145) 2. Make sure you're in the **Shading** Workspace. 3. In the **3D Viewport Editor** set Rendering Mode to "Rendered" 4. **Inside the Shader Editor**, make sure you expand the Subsurface panel inside the Principled BSDF node 5. Set Scale Slider to `2m` 6. Set Weight to `1` 7. Check mesh inside the **3D Viewport Editor**; Subsurface scattering is working. 8. Adjust Weight to .001 in the Principled BSDF node in the Shader Editor. 9. Check back to the 3D Viewport to see no difference to the Subsurface shading on the mesh. 10. While in the Shader Editor, try plugging a Checker Texture node into the Subsurface Weight. 11. Switch over to Cycles to see what it does with my steps. _*My blend file is based on a factory startup and without much added stuff other than lights and a Suzanne head_ </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the descriptions and steps. Bug report 1 is about calling `b.node_or_null()` in a shader node's declaration changing closure weight in EEVEE. The steps involve modifying a node's declare function and checking render results. Bug report 2 is about Subsurface Weight in Principled BSDF not transitioning from 0 to 1 in EEVEE, with steps involving adjusting the weight slider and seeing no change. The key here: Report 1 is about a specific code change (calling `node_or_null`) affecting closure weight, while Report 2 is about the Subsurface Weight parameter not working as expected (no transition). These are different issues—one is a regression from a code modification in node declaration, the other is a persistent problem with the Principled BSDF's subsurface weight. So they're not duplicates. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 16.376005, "duplicate_report_number": "114435" } </details>
Triager-bot commented 2026-04-13 15:50:45 +00:00
Author
Owner
Copy Link

Report flagged as NOT a duplicate by LLM

Node wrangler resetting closure input causes crash

https://projects.blender.org/blender/blender/issues/146946

System Information
Operating system: Windows-10-10.0.17763-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 566.14 Opengl Backend

Blender Version
Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-25 01:22, hash: 2f3e6e69dfe1
Worked: none (new 5.0 feature)

Short description of error
Node wrangler resetting closure input causes crash.
Using node wrangler reset operation bpy.ops.node.nw_reset_nodes() on modified closure input causes crash. Resetting unmodified closure input or output destroys zone (similar to for each and repeat)

Exact steps for others to reproduce the error
default startup

  1. Enable Node wrangler
  2. Add geometry node to cube
  3. Add closure
  4. Add any input socket to closure
  5. Reset closure input node with backspace
LLM Reasoning

Got it, let's analyze these two bug reports. First, look at the description and steps for each.

Bug report 1 is about calling b.node_or_null() in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (adding that function call) and checking render results.

Bug report 2 is about Node Wrangler resetting a closure input causing a crash. The steps are using Node Wrangler to reset a closure input node, leading to a crash.

The key here is the core issue: one is about a specific function call in shader node declaration affecting EEVEE's closure weight, the other is about Node Wrangler resetting a closure input causing a crash. These are different issues—one is a rendering behavior change due to code modification, the other is a crash from a UI operation (Node Wrangler reset). So they're not the same.

JSON Data

{
"llm_judgement": false,
"processing_time": 13.837802,
"duplicate_report_number": "146946"
}

<!-- ID: CHECK_DUPLICATE --> ### Report flagged as NOT a duplicate by LLM <details> <summary>Node wrangler resetting closure input causes crash</summary> https://projects.blender.org/blender/blender/issues/146946 **System Information** Operating system: Windows-10-10.0.17763-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 566.14 Opengl Backend **Blender Version** Broken: version: 5.0.0 Alpha, branch: main, commit date: 2025-09-25 01:22, hash: `2f3e6e69dfe1` Worked: none (new 5.0 feature) **Short description of error** Node wrangler resetting closure input causes crash. Using node wrangler reset operation `bpy.ops.node.nw_reset_nodes()` on modified closure input causes crash. Resetting unmodified closure input or output destroys zone (similar to for each and repeat) **Exact steps for others to reproduce the error** default startup 1. Enable Node wrangler 2. Add geometry node to cube 3. Add closure 4. Add any input socket to closure 5. Reset closure input node with `backspace` </details> <details> <summary>LLM Reasoning</summary> Got it, let's analyze these two bug reports. First, look at the description and steps for each. Bug report 1 is about calling `b.node_or_null()` in a shader node's declaration affecting closure weight in EEVEE. The steps involve modifying a shader node's code (adding that function call) and checking render results. Bug report 2 is about Node Wrangler resetting a closure input causing a crash. The steps are using Node Wrangler to reset a closure input node, leading to a crash. The key here is the core issue: one is about a specific function call in shader node declaration affecting EEVEE's closure weight, the other is about Node Wrangler resetting a closure input causing a crash. These are different issues—one is a rendering behavior change due to code modification, the other is a crash from a UI operation (Node Wrangler reset). So they're not the same. </details> <details> <summary>JSON Data</summary> { "llm_judgement": false, "processing_time": 13.837802, "duplicate_report_number": "146946" } </details>
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
Status
Bad Judgement
Status
Good judgement
Status
Needs review
Status
Uncertain Judgement
Trager-Bot Will Send Comment
No Label
Status
Needs review
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
Triager-bot
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: Triager-bot/blender-bug-reports#76
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?