Deleting an unused light group caused the environment light group to render to another light group #117586

New Issue

Mark Stead · 2024-01-28T11:15:44+01:00

Mark Stead commented

2024-01-28 11:15:44 +01:00

System Information
Operating system: Windows-10-10.0.19045-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.17

Blender Version
Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: 9be62e85b727
Worked: (newest version of Blender that worked as expected)

Short description of error
When persistent data enabled, deleting an unused light group caused the environment light group to render to another light group

Exact steps for others to reproduce the error
Ok, I've figured out how to reproduce. I needed to have Persistent Data enabled. I've attached a file that demonstrates the problem.

Render the scene once. Observe the different lightgroup render layers. The Combined_Environment layer has the default world illumination.
Delete the Unused Light Group.
Render the scene again.
Observe that the Combined_Environment is now black. Instead that pass is now part of Combined_Green.

117586 Light Group Delete Problem.blend

Anyway, given I cannot reproduce in a standalone file, I'm happy to analyse and debug the problem myself.
Using the Python console, I've tried to look through all the data structures but cannot see anything that looks strange.
Looking at the C++ code (BKE_view_layer_remove_lightgroup()) it only appears to change the active lightgroup, then remove the selected record from the linked list. Maybe some other part of the code is using a pointer to that linked list record - though doesn't seem logical that it would then render to a different lightgroup.
I'll get the latest version of the code compiling and run it in the debugger tomorrow.
However my gut feel is that the blend file is a bit messed-up or inconsistent - it's gone through many different Blender versions.
Is there anything specific I should look at in Python or C++?

**System Information** Operating system: Windows-10-10.0.19045-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3080/PCIe/SSE2 NVIDIA Corporation 4.6.0 NVIDIA 546.17 **Blender Version** Broken: version: 4.0.2, branch: blender-v4.0-release, commit date: 2023-12-05 07:41, hash: `9be62e85b727` Worked: (newest version of Blender that worked as expected) **Short description of error** When persistent data enabled, deleting an unused light group caused the environment light group to render to another light group **Exact steps for others to reproduce the error** Ok, I've figured out how to reproduce. I needed to have Persistent Data enabled. I've attached a file that demonstrates the problem. 1. Render the scene once. Observe the different lightgroup render layers. The `Combined_Environment` layer has the default world illumination. ![image](/attachments/83cce85f-a51b-4f63-a206-2acfb611c20c) 2. Delete the Unused Light Group. ![image](/attachments/46ce68e1-6c18-4b19-a059-e57f098ce1d7) 3. Render the scene again. 4. Observe that the `Combined_Environment` is now black. Instead that pass is now part of `Combined_Green`. [117586 Light Group Delete Problem.blend](https://projects.blender.org/attachments/9f5cd1f8-b15b-4ef2-9070-20e6d55da96a) Anyway, given I cannot reproduce in a standalone file, I'm happy to analyse and debug the problem myself. Using the Python console, I've tried to look through all the data structures but cannot see anything that looks strange. Looking at the C++ code (BKE_view_layer_remove_lightgroup()) it only appears to change the active lightgroup, then remove the selected record from the linked list. Maybe some other part of the code is using a pointer to that linked list record - though doesn't seem logical that it would then render to a different lightgroup. I'll get the latest version of the code compiling and run it in the debugger tomorrow. However my gut feel is that the blend file is a bit messed-up or inconsistent - it's gone through many different Blender versions. Is there anything specific I should look at in Python or C++?

image.png

15 KiB

Mark Stead added the

labels 2024-01-28 11:15:45 +01:00

Mark Stead commented

2024-01-29 08:38:30 +01:00

Ok, I've figured out how to reproduce. I needed to have Persistent Data enabled. I've attached a file that demonstrates the problem.

Render the scene once. Observe the different lightgroup render layers. The Combined_Environment layer has the default world illumination.
Delete the Unused Light Group.
Render the scene again.
Observe that the Combined_Environment is now black. Instead that pass is now part of Combined_Green.

Another workaround would be to turn off/on Persistent Data.

In the code, Film::update_lightgroups() assigns a numeric index to each lightgroup. This successfully detects the change, and returns true.
The function Scene::device_update() applies some tag updates but not to the background.
Later Background::device_update() checks is_modified() (using socket_modified) and returns without updating any settings.
Specifically this code is not executed - which leaves dscene->data.background.lightgroup with the old (wrong) value.

/* Light group. */
auto it = scene->lightgroups.find(lightgroup);
if (it != scene->lightgroups.end()) {
  kbackground->lightgroup = it->second;
}
else {
  kbackground->lightgroup = LIGHTGROUP_NONE;
}

I've looked at why the code works successfully when you clear/set the World Light Group. That functionality is part of BlenderSync::sync_world() which appears to detect changes to the lightgroup name, and set the socket_modified flag. Of course in my scenario the Environment lightgroup name is unchanged, however the assigned index has changed.

Ok, I've figured out how to reproduce. I needed to have Persistent Data enabled. I've attached a file that demonstrates the problem. 1. Render the scene once. Observe the different lightgroup render layers. The `Combined_Environment` layer has the default world illumination. ![image](/attachments/83cce85f-a51b-4f63-a206-2acfb611c20c) 2. Delete the Unused Light Group. ![image](/attachments/46ce68e1-6c18-4b19-a059-e57f098ce1d7) 3. Render the scene again. 4. Observe that the `Combined_Environment` is now black. Instead that pass is now part of `Combined_Green`. Another workaround would be to turn off/on Persistent Data. In the code, `Film::update_lightgroups()` assigns a numeric index to each lightgroup. This successfully detects the change, and returns true. The function `Scene::device_update()` applies some tag updates but not to the background. Later `Background::device_update()` checks `is_modified()` (using `socket_modified`) and returns without updating any settings. Specifically this code is not executed - which leaves `dscene->data.background.lightgroup` with the old (wrong) value. ``` /* Light group. */ auto it = scene->lightgroups.find(lightgroup); if (it != scene->lightgroups.end()) { kbackground->lightgroup = it->second; } else { kbackground->lightgroup = LIGHTGROUP_NONE; } ``` I've looked at why the code works successfully when you clear/set the World Light Group. That functionality is part of `BlenderSync::sync_world()` which appears to detect changes to the lightgroup name, and set the `socket_modified` flag. Of course in my scenario the Environment lightgroup name is unchanged, however the assigned index has changed.

117586 Light Group Delete Problem.blend

955 KiB

image.png

9.7 KiB

image.png

9.2 KiB

Pratik Borhade commented

2024-02-01 07:01:17 +01:00

Hi, thanks for the report. I can confirm.
cc @LukasStockner

Hi, thanks for the report. I can confirm. cc @LukasStockner

Pratik Borhade added

and removed

labels 2024-02-01 07:01:31 +01:00

Lukas Stockner referenced this issue from a commit

2024-02-04 16:44:54 +01:00

Fix #117586: Cycles: World Lightgroup not updated when creating/deleting LGs

Lukas Stockner closed this issue

2024-02-04 16:44:55 +01:00

Blender Bot added

and removed

labels 2024-02-04 16:44:57 +01:00

Lukas Stockner commented

2024-02-04 16:45:52 +01:00

@MarkStead-2 Thanks for the extensive writeup!

Pratik Borhade commented

2024-02-05 04:45:02 +01:00

@LukasStockner hi, can we backport the fix to 3.6/3.3 LTS? Looks straightforward to me

Lukas Stockner referenced this issue from a commit

2024-03-07 17:08:40 +01:00

Fix #117586: Cycles: World Lightgroup not updated when creating/deleting LGs

Lukas Stockner referenced this issue from a commit

2024-03-07 20:27:55 +01:00

Fix #117586: Cycles: World Lightgroup not updated when creating/deleting LGs

Lukas Stockner commented

2024-03-07 20:30:34 +01:00

@LukasStockner hi, can we backport the fix to 3.6/3.3 LTS? Looks straightforward to me

Good point, thanks:

3.6: 8508d6992b
3.3: 603b88f188

> @LukasStockner hi, can we backport the fix to 3.6/3.3 LTS? Looks straightforward to me Good point, thanks: - 3.6: 8508d6992b30756192626f4d8fad89af78cd0c3f - 3.3: 603b88f188aba1326bae5637885c2945611a1801

Pratik Borhade commented

2024-03-08 04:03:44 +01:00

Thanks for backporting them :D
For future, you can add commits in backporting list then Philipp/Thomas will backport them to 3.3/3.6LTS:

Thanks for backporting them :D For future, you can add commits in backporting list then Philipp/Thomas will backport them to 3.3/3.6LTS: - https://projects.blender.org/blender/blender/issues/100749 - https://projects.blender.org/blender/blender/issues/109399

Philipp Oeser referenced this issue

2024-03-11 13:29:01 +01:00

Blender LTS: Maintenance Task 3.6 #109399

Philipp Oeser referenced this issue

2024-03-12 12:47:48 +01:00

Blender LTS: Maintenance Task 3.3 #100749

Sign in to join this conversation.