Details
Diff Detail
- Repository
- rB Blender
- Branch
- fix_T100754 (branched from master)
- Build Status
Buildable 23594 Build 23594: arc lint + arc unit
Event Timeline
To make that work, I think we have to gather v3d->local_view_uuid from all 3D viewports, and then do the test like this:
/* Test if object is visible through default view layer visibility, or per 3D viewport local visibility overrides. */
is_enabled = object->base_flag & BASE_ENABLED_VIEWPORT) &&
((object->base_flag & BASE_VISIBLE_VIEWLAYER) ||
(object->base_local_view_bits & v3d_all_local_uuid))`As well as do appropriate depsgraph updates when local visibility is edited.
However there's another problem, which is that BASE_VISIBLE_DEPSGRAPH no longer indicates which objects have been evaluated by the depsgraph, and there's various places in the code assuming that.
This test to check if an object is visible in any 3D viewport could be moved earlier, so BKE_layer_collection_sync sets BASE_VISIBLE_DEPSGRAPH based on that, and then the depsgraph could use it.
To make that work, I think we have to gather v3d->local_view_uuid from all 3D viewports, and then do the test like this:
The "all 3d viewports" leads to a much broader and annoying change which will require notifying the dependency graph about screen layout changes.
But then there is also base->local_collections_bits and v3d->local_collections_uuid. Which makes this story even more interesting.
So all in all there is no proper evaluated state of base flags, and all of them have different degree of context within which they are trustworthy.
However there's another problem, which is that BASE_VISIBLE_DEPSGRAPH no longer indicates which objects have been evaluated by the depsgraph, and there's various places in the code assuming that.
This is already violated. And the semantic which you've described about this flag is just wrong. This is something I've been bringing up in the comment of the initial change D5992#143878
At this point I am not sure I have motivation to try to make sense of the code which semantics you don't want to explain.
If you expect BASE_VISIBLE_DEPSGRAPH to have any relation to what exactly happens in the dependency graph you have to be clear of what this flag is actually supposed to mean and leave maintenance of the flag to the dependency graph. If this flag is not to be maintained by the dependency graph you have to rename it to something else. And in any case its meaning in the comment is to be clarified.