Armature driving other object visibility gets out of sync if the parent collection is hidden/shown again in viewport #102148

New Issue

Lucho · 2022-10-29T18:29:55+02:00

Lucho commented

2022-10-29 18:29:55 +02:00

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 522.25

Blender Version
Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: b292cfe5a9
Worked: Never

Short description of error
With a linked override library with some driver on some linked object (render or viewport visibility), if you disable viewport visibility for one parent collection of that object, when the file went open again the changes made to the linked armature gets messy and a resync is needed.
Note that it happens only if there is some driver on one of the linked objects.

Original file:
override_driver_original.blend
Linked file:
override_driver_linked.blend

Exact steps for others to reproduce the error

Open the file named "override_driver_linked.blend"
Move "Armature" somewhere
Enter in Pose Mode and move the Bone somewhere, exit from Pose Mode
Disable from viewport the parent collection, named "Collection.001" (Globally disable in viewport)
Save the file and exit
Re-open the file
Make the "Collection.001" visibile again, note that both the armature and the object are misplaced!
Enter in Pose Mode, note that the object move but the armature is still misplaced!
Make a Resync on the armature to replace all in the right position

**System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 3060/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 522.25 **Blender Version** Broken: version: 3.3.1, branch: master, commit date: 2022-10-04 18:35, hash: `b292cfe5a9` Worked: Never **Short description of error** With a linked override library with some driver on some linked object (render or viewport visibility), if you disable viewport visibility for one parent collection of that object, when the file went open again the changes made to the linked armature gets messy and a resync is needed. Note that it happens only if there is some driver on one of the linked objects. Original file: [override_driver_original.blend](https://archive.blender.org/developer/F13798902/override_driver_original.blend) Linked file: [override_driver_linked.blend](https://archive.blender.org/developer/F13798915/override_driver_linked.blend) **Exact steps for others to reproduce the error** - Open the file named "override_driver_linked.blend" - Move "Armature" somewhere - Enter in Pose Mode and move the Bone somewhere, exit from Pose Mode - Disable from viewport the parent collection, named "Collection.001" (Globally disable in viewport) - Save the file and exit - Re-open the file - Make the "Collection.001" visibile again, note that both the armature and the object are misplaced! - Enter in Pose Mode, note that the object move but the armature is still misplaced! - Make a Resync on the armature to replace all in the right position

Lucho commented

2022-10-29 18:29:55 +02:00

Added subscriber: @Lucho

Omar Emara commented

2022-11-09 08:21:59 +01:00

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

Bastien Montagne commented

2022-11-15 16:27:32 +01:00

Added subscriber: @mont29

Bastien Montagne commented

2022-11-15 16:27:32 +01:00

This has nothing to do with overrides, the same happens with purely local data (if you apply steps above to override_driver_original.blend)... For me objects goes back to where it belongs as soon as I start moving the bone in pose mode though.

Anyway, this is an update issue (would bet wrong/missing tagging from code toggling the collection visibility).

This has nothing to do with overrides, the same happens with purely local data (if you apply steps above to `override_driver_original.blend`)... For me objects goes back to where it belongs as soon as I start moving the bone in pose mode though. Anyway, this is an update issue (would bet wrong/missing tagging from code toggling the collection visibility).

Bastien Montagne commented

2022-11-15 16:49:10 +01:00

Added subscriber: @dr.sybren

Bastien Montagne commented

2022-11-15 16:49:10 +01:00

I'd actually like to get feedback from #dependency_graph team here too, maybe @dr.sybren would be interested, since this seems to involve armatures/drivers/depsgraph?

rna_Collection_flag_update only sets ID_RECALC_COPY_ON_WRITE on the affected collection, and then tags relations for updates. Not sure if that's supposed to be enough or even if that's how this is supposed to be handled.

I'd actually like to get feedback from #dependency_graph team here too, maybe @dr.sybren would be interested, since this seems to involve armatures/drivers/depsgraph? `rna_Collection_flag_update` only sets `ID_RECALC_COPY_ON_WRITE` on the affected collection, and then tags relations for updates. Not sure if that's supposed to be enough or even if that's how this is supposed to be handled.

Bastien Montagne changed title from ~~Library Override with driver gets messy if the parent collection is hidden~~ to Armature driving other object visibility gets out of sync if the parent collection is hidden/shown again in viewport

2022-11-15 16:50:14 +01:00

Sybren A. Stüvel commented

2022-11-15 17:20:55 +01:00

Added subscribers: @JacquesLucke, @Sergey

Sybren A. Stüvel commented

2022-11-15 17:20:55 +01:00

Bastien and I did a little digging, and as it turns out, the driver isn't strictly necessary. Having any animation data on the Cube viewport visibility is enough to trigger this behaviour.

When the Cube visibility is animated/driven, Cube and Armature are present in the depsgraph, even when the parent collection is disabled (and thus its contents are never visible, regardless of the animation). This is probably handled correctly during depsgraph evaluation, leaving them less-than-fully evaluated. When the parent collection is made visible again, it's likely that Cube and Armature don't get recomputed (we suspect because their direct visibility didn't change), hence the bad positioning.

@Sergey @JacquesLucke what would you think would be the right way to solve this?

Bastien and I did a little digging, and as it turns out, the driver isn't strictly necessary. Having any animation data on the Cube viewport visibility is enough to trigger this behaviour. When the Cube visibility is animated/driven, `Cube` and `Armature` are present in the depsgraph, even when the parent collection is disabled (and thus its contents are never visible, regardless of the animation). This is probably handled correctly during depsgraph evaluation, leaving them less-than-fully evaluated. When the parent collection is made visible again, it's likely that `Cube` and `Armature` don't get recomputed (we suspect because their direct visibility didn't change), hence the bad positioning. @Sergey @JacquesLucke what would you think would be the right way to solve this?

Sergey Sharybin commented

2022-11-15 17:49:57 +01:00

There was quite some work put into making it so depsgraph can properly "recover" from partially evlauated ID becoming visible. Think the main part is the D15498, and with some followup fixes. It might be possible that something is still not handled properly there.

Such a depsgraph reaction to visibility updates is not cheap, so there are some limiters set in place and only specific set of cases will trigger that code path. I think of is that the ID_RECALC_COPY_ON_WRITE tag on the collection does not trigger visibility update in the dependency graph. So a quick verification of where the root of the problem lies would be to tag scene for ID_RECALC_BASE_FLAGS next to the collection ID tag. If that solves the problem then we need to make depsgrapgh properly react for visibility changes when the collection changes. If that extra tag does not fix the issue a deeper investigation is needed.

There was quite some work put into making it so depsgraph can properly "recover" from partially evlauated ID becoming visible. Think the main part is the [D15498](https://archive.blender.org/developer/D15498), and with some followup fixes. It might be possible that something is still not handled properly there. Such a depsgraph reaction to visibility updates is not cheap, so there are some limiters set in place and only specific set of cases will trigger that code path. I think of is that the `ID_RECALC_COPY_ON_WRITE` tag on the collection does not trigger visibility update in the dependency graph. So a quick verification of where the root of the problem lies would be to tag scene for `ID_RECALC_BASE_FLAGS` next to the collection ID tag. If that solves the problem then we need to make depsgrapgh properly react for visibility changes when the collection changes. If that extra tag does not fix the issue a deeper investigation is needed.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Armature driving other object visibility gets out of sync if the parent collection is hidden/shown again in viewport #102148