Page MenuHome

Fix T99151: Cycles not updating on Object Type visibility change
ClosedPublic

Authored by Lukas Stockner (lukasstockner97) on Oct 16 2022, 1:00 AM.

Details

Summary

I'm uploading this as a patch for sanity checking since I don't really know anything about depsgraph stuff. Fixes the issue, though.

Diff Detail

Repository
rB Blender
Branch
fix-T99151 (branched from master)
Build Status
Buildable 24329
Build 24329: arc lint + arc unit

Event Timeline

Lukas Stockner (lukasstockner97) requested review of this revision.Oct 16 2022, 1:00 AM
Lukas Stockner (lukasstockner97) created this revision.
Sergey Sharybin (sergey) requested changes to this revision.Oct 17 2022, 11:26 AM

I am not aware of any part of the code in the dependency relations builder which will rely on the viewport settings. So from this point of view tagging for relations update seems wrong.
Also, Eevee and the workbench engines respond correctly to the changes in the viewport, so to me it does not seem to be the dependency graph problem.

To me it seems the root of the issue is somewhere else. Also, what is exactly you expect from the reviewers at this state of the patch?

This revision now requires changes to proceed.Oct 17 2022, 11:26 AM
Brecht Van Lommel (brecht) requested changes to this revision.Oct 17 2022, 11:28 AM

Updating this visibility does not require a depsgraph relations update. We only need to notify the render engines to refresh, not actually do this relatively expensive update.

Maybe DEG_id_type_tag(bmain, ID_OB) works? It's used in VIEW3D_OT_localview which is a similar type of 3D viewport visibility setting.

Also, Eevee and the workbench engines respond correctly to the changes in the viewport, so to me it does not seem to be the dependency graph problem.

From what I can tell, this is because they query BKE_base_is_visible/BKE_object_is_visible_in_viewport in every iteration, while Cycles only does when the object gets tagged for updating. By default, however, b_depsgraph.updates in BlenderSync::sync_recalc is empty after toggling the visibility option, so Cycles doesn't update (until you change something else).

Also, what is exactly you expect from the reviewers at this state of the patch?

To get feedback on whether my approach makes sense, which is what I got, so thanks ;)

Maybe DEG_id_type_tag(bmain, ID_OB) works?

Yep, that one also works. I'll update the patch. I originally got the DEG_relations_tag_update idea from rna_Object_hide_update.

Sorry, I must have forgotten to rebuild or something, I just checked again before merging and DEG_id_type_tag doesn't work after all.

Another call from localview *does* work, though: DEG_id_tag_update(&scene->id, ID_RECALC_BASE_FLAGS).

Mark arguments as unused.

This revision was not accepted when it landed; it landed in state Needs Review.Oct 20 2022, 2:40 AM
This revision was automatically updated to reflect the committed changes.

@Lukas Stockner (lukasstockner97) Please stop committing patches which are in the Needs Review state.

You can not ignore "Requested Changes" from any of the reviewers, even if some other reviewers did accept the change.

@Lukas Stockner (lukasstockner97) Please stop committing patches which are in the Needs Review state.

You can not ignore "Requested Changes" from any of the reviewers, even if some other reviewers did accept the change.

Ah, okay, I thought that was just Phabricator being weird.

I am not sure why one would consider Phabricator weird when we literally use it daily, and would surely resolve its weirdness if that was the case.

As for the change itself, it is semantically wrong to fake updates like that just to implicitly trigger a specific code path in Cycles. The current state of the code violates the intended use of depsgraph API. There needs to be more proper way of explicitly communicating what's changed, because otherwise making such workarounds work will just get in a way of development.