Cycles: modifying properties through the Python console does not trigger updates. #96829

New Issue

System Information
Operating system: Windows-10-10.0.19042-SP0 64 Bits
Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12

Blender Version
Broken: version: 3.1.0 Beta, branch: master, commit date: 2022-02-18 21:28, hash: 93cc892470
Worked: (newest version of Blender that worked as expected)

Load a scene with a 16k hdri
with viewport rendering happening, try and rotate the hdri environment using a mapping node:

now change the world surface setting sampling method to manual, and the map resolution to 1024

message will appear:

now rotate the hdri again. It'll be much more responsive.

now in the python console enter:
bpy.data.scenes['Scene'].world.cycles.sample_map_resolution = 15360

Notice the message 'updating lights' didn't appear in the viewport.

rotate again, it's still responsive because cycles is still using the 1024 manually entered.

Now restart the viewport render by clicking on solid viewport mode and back to rendered viewport mode

Rotate again. Still responsive. Even though the viewport has been restarted, cycles is still using the last manually entered value of 1024.

NOTE: no updates seem to be triggered for the properties. The only update triggered seem to be for the console's current line which is modified after executing the entered line.

**System Information** Operating system: Windows-10-10.0.19042-SP0 64 Bits Graphics card: NVIDIA GeForce GTX 1070/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 472.12 **Blender Version** Broken: version: 3.1.0 Beta, branch: master, commit date: 2022-02-18 21:28, hash: `93cc892470` Worked: (newest version of Blender that worked as expected) Load a scene with a 16k hdri with viewport rendering happening, try and rotate the hdri environment using a mapping node: ![image.png](https://archive.blender.org/developer/F12952410/image.png) now change the world surface setting sampling method to manual, and the map resolution to 1024 ![image.png](https://archive.blender.org/developer/F12952413/image.png) message will appear: ![image.png](https://archive.blender.org/developer/F12952425/image.png) now rotate the hdri again. It'll be much more responsive. now in the python console enter: bpy.data.scenes['Scene'].world.cycles.sample_map_resolution = 15360 Notice the message 'updating lights' didn't appear in the viewport. rotate again, it's still responsive because cycles is still using the 1024 manually entered. Now restart the viewport render by clicking on solid viewport mode and back to rendered viewport mode Rotate again. Still responsive. Even though the viewport has been restarted, cycles is still using the last manually entered value of 1024. ------- NOTE: no updates seem to be triggered for the properties. The only update triggered seem to be for the console's current line which is modified after executing the entered line.

Added subscriber: @3di

#98617 was marked as duplicate of this issue

#96856 was marked as duplicate of this issue

This only appears to affect viewport rendering. Final renders seem to use the correct value regardless of how it was set.

i've tried update_tag(), resetting the frame to the current frame. Not having any luck at all.

I've also checked the blender source code to see if the properties call another function via an update parameter, but they don't.

Added subscriber: @lichtwerk

Changed status from 'Needs Triage' to: 'Confirmed'

Can confirm.

I have not traced how exactly light_map.add_or_update() works in Cycles, but seems like a session update is not caught if changed from python, we are just not getting there in the first place.
Seems to be more general, also not logged in the info editor.
There is no RNA update defined on the property, not exactly sure where the update comes from tbh, Cycles probably has another mechanism to spot changes.
Not sure if there is a way to force an update

Can confirm. I have not traced how exactly `light_map.add_or_update()` works in Cycles, but seems like a session update is not caught if changed from python, we are just not getting there in the first place. Seems to be more general, also not logged in the info editor. There is no RNA update defined on the property, not exactly sure where the update comes from tbh, Cycles probably has another mechanism to spot changes. Not sure if there is a way to force an update

Added subscriber: @kevindietrich

Note for developers. I investigated a bit. First of all, when modifying a property (either through Python or through the UI) rna_property_update is called. If there is an update callback set an the property (either with RNA_def_property_update in the C code, or by setting an update callback when creating a corresponding bpy.props), this callback is called. Then, if the ID that owns the property (PointerRNA.owner_id) is covered by copy on write (CoW), the dependency graph is tagged for an evaluation.

In this case, when updating from the UI, the owner of the property is set to be the World (scene.world), which is covered by CoW so the depsgraph is tagged for an update. However, when called from the Python console, the owner ID is set to be the Screen or its layout (I see ID.name is SRLayout), which is not covered by CoW, so the depsgraph is not tagged for an update, so Cycles does not see the new world data.

I am not sure how this can be fixed yet, as I don't know the details of the Python console.

In #96856, it is the same, except that the owner is the Light in the UI, but still SRLayout in the Python console. Since the issue has the same root, and this report is slightly older, I'll merge the report into this one.

Note for developers. I investigated a bit. First of all, when modifying a property (either through Python or through the UI) `rna_property_update` is called. If there is an update callback set an the property (either with `RNA_def_property_update` in the C code, or by setting an update callback when creating a corresponding `bpy.props`), this callback is called. Then, if the ID that owns the property (`PointerRNA.owner_id`) is covered by copy on write (CoW), the dependency graph is tagged for an evaluation. In this case, when updating from the UI, the owner of the property is set to be the World (`scene.world`), which is covered by CoW so the depsgraph is tagged for an update. However, when called from the Python console, the owner ID is set to be the Screen or its layout (I see `ID.name` is `SRLayout`), which is not covered by CoW, so the depsgraph is not tagged for an update, so Cycles does not see the new world data. I am not sure how this can be fixed yet, as I don't know the details of the Python console. In #96856, it is the same, except that the owner is the Light in the UI, but still `SRLayout` in the Python console. Since the issue has the same root, and this report is slightly older, I'll merge the report into this one.

Added subscribers: @DeanKJones, @PratikPB2123

Added subscriber: @Raimund58

Added subscriber: @unwave

@kevindietrich I'm not sure the title is correct now. Modifying some properties via python does trigger a cycles update. For example modifying the cycles.sample_clamp_direct and cycles.sample_clamp_indirect via python does trigger a cycles update. Perhaps investigating why those work could lead to a swift/easier identification of the problem & resolution?

Although when modifying the clamp via python, only the new clamp values are reflected in the updated viewport render. The lightmap resolution which was modified before the clamp values, still dont take effect in the viewport even though cycles has updated courtesy of the clamp changes.

@kevindietrich I'm not sure the title is correct now. Modifying some properties via python does trigger a cycles update. For example modifying the cycles.sample_clamp_direct and cycles.sample_clamp_indirect via python does trigger a cycles update. Perhaps investigating why those work could lead to a swift/easier identification of the problem & resolution? Although when modifying the clamp via python, only the new clamp values are reflected in the updated viewport render. The lightmap resolution which was modified before the clamp values, still dont take effect in the viewport even though cycles has updated courtesy of the clamp changes.

@3di I cannot seem to reproduce the successful update that you talk about. Maybe I am doing it wrong. However, it seems like my initial diagnosis for this report is wrong as there simply does not seem to be an update triggered for custom Cycles properties.

Interesting. Can you think of a good solution?

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Cycles: modifying properties through the Python console does not trigger updates. #96829