Armature widgets from hidden collections are invisible. #93439

New Issue

Alexander Gavrilov · 2021-11-27T23:50:44+01:00

2021-11-27 23:50:44 +01:00

Blender Version
Broken: 3.0 8f2db94627
Worked: 3.0 2cc56495f3

Immediate cause: a07089dcb1

Short description of error

Armature widgets using objects from a collection that is excluded or hidden in viewport are invisible until the collection is temporarily unhidden.

Secondary, old but likely related issue: even before, modifiers on the widgets didn't work in the same exact circumstances.

Exact steps for others to reproduce the error

Add a Rigify metarig and generate a character rig, or open an existing file with a generated character. All control bone widgets are invisible.

Technical analysis

The root cause of the issue is likely that the widget objects aren't registered as dependencies for the rig, and aren't evaluated. Previously this manifested as modifiers (e.g. subsurf) often not working on such objects. However the referenced commit made the evaluated mesh mandatory for drawing the widgets, thus completely breaking them.

Test Plan

Test file: custom_shape_rigify.blend

Opening the attached file in 2.93 you'll see a 4-arrow "widget" (bone with a custom shape) in the center of coordinates. This is the correct behavior
Opening the file with the 3.0 branch at d2e6087335 will not show that "widget" visible. This is incorrect.

Screenshot of expected state:

**Blender Version** Broken: 3.0 8f2db94627d5 Worked: 3.0 2cc56495f3ce Immediate cause: a07089dcb1 **Short description of error** Armature widgets using objects from a collection that is excluded or hidden in viewport are invisible until the collection is temporarily unhidden. Secondary, old but likely related issue: even before, modifiers on the widgets didn't work in the same exact circumstances. **Exact steps for others to reproduce the error** Add a Rigify metarig and generate a character rig, or open an existing file with a generated character. All control bone widgets are invisible. **Technical analysis** The root cause of the issue is likely that the widget objects aren't registered as dependencies for the rig, and aren't evaluated. Previously this manifested as modifiers (e.g. subsurf) often not working on such objects. However the referenced commit made the evaluated mesh mandatory for drawing the widgets, thus completely breaking them. **Test Plan** Test file: [custom_shape_rigify.blend](https://archive.blender.org/developer/F12655552/custom_shape_rigify.blend) - Opening the attached file in 2.93 you'll see a 4-arrow "widget" (bone with a custom shape) in the center of coordinates. This is the correct behavior - Opening the file with the 3.0 branch at d2e60873350 will not show that "widget" visible. This is incorrect. Screenshot of expected state: ![expected.png](https://archive.blender.org/developer/F12655784/expected.png)

Alexander Gavrilov commented

2021-11-27 23:50:44 +01:00

Added subscriber: @angavrilov

Alexander Gavrilov commented

2021-11-27 23:56:10 +01:00

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

Hans Goudey was assigned by Alexander Gavrilov

2021-11-27 23:56:10 +01:00

Alexander Gavrilov commented

2021-11-27 23:56:10 +01:00

Added subscribers: @dr.sybren, @dfelinto
Removed subscriber: @angavrilov

Added subscribers: @dr.sybren, @dfelinto Removed subscriber: @angavrilov

Alexander Gavrilov commented

2021-11-27 23:56:10 +01:00

Relevance of the commit confirmed by reverting, which fixes the immediate regression.

Hans Goudey commented

2021-11-28 04:41:30 +01:00

Maybe a simple fix is using the original mesh if the object is a mesh object and the evaluated mesh isn't found.

Alexander Gavrilov commented

2021-11-28 11:10:46 +01:00

Of course the better solution is to figure out the suspected dependency issue. As I said, there is a secondary long-existing issue that modifiers don't work in the same circumstances, and this change likely just made the same root problem worse and more obvious.

Alexander Gavrilov commented

2021-11-28 11:46:32 +01:00

Added subscribers: @fclem, @Sergey

Alexander Gavrilov commented

2021-11-28 11:46:32 +01:00

Maybe @fclem or @Sergey would have an idea of the proper fix for the suspected dependency issue (TLDR: custom shape objects aren't evaluated unless independently visible).

However unless the fix is obvious and safe it's probably something for master, and 3.0 regression can be safely fixed by temporarily reverting the commit.

Maybe @fclem or @Sergey would have an idea of the proper fix for the suspected dependency issue (TLDR: custom shape objects aren't evaluated unless independently visible). However unless the fix is obvious and safe it's probably something for master, and 3.0 regression can be safely fixed by temporarily reverting the commit.

Hans Goudey commented

2021-11-28 16:04:39 +01:00

Hmm, the commit fixed another import issue though. So I still think a simple fix would be using the original mesh if necessary and possible.

As I mentioned in the commit, I think the proper fix is using the instancing system to generate the widgets. A dependency could be added in the depsgraph, and the instances could be marked to only display in the viewport.

Hmm, the commit fixed another import issue though. So I still think a simple fix would be using the original mesh if necessary and possible. As I mentioned in the commit, I think the proper fix is using the instancing system to generate the widgets. A dependency could be added in the depsgraph, and the instances could be marked to only display in the viewport.

Sergey Sharybin commented

2021-11-29 10:01:28 +01:00

I am confused about the technical analysis. And the lack of simple .blend file makes it harder to investigate from my side. You already have demo file ready to be tested, just upload them here and save some repro steps ;)

The dependency graph ensures that if the rig is visible the object used for the custom shape is evaluated (see the deg_builder_nodes_rig.cc around the if (pchan->custom != nullptr) {).

I've tested the system with the attached file and. it seems to work fine in both 2.93 and 3.0. The handling of visibility in depsgraph did not change during 3.0 cycle, so to me is not immediately obvious that the depsgraph side is not doing what it's supposed to.

custom_shape.blend

If someone can upload same level of complexity of file demonstrating the issue that'd make troubleshooting from depsgraph side.

As for reverting I'm not sure about it. I'll trade one regression with another, which isn't very great.

I am confused about the technical analysis. And the lack of simple .blend file makes it harder to investigate from my side. You already have demo file ready to be tested, just upload them here and save some repro steps ;) The dependency graph ensures that if the rig is visible the object used for the custom shape is evaluated (see the `deg_builder_nodes_rig.cc` around the `if (pchan->custom != nullptr) {`). I've tested the system with the attached file and. it seems to work fine in both 2.93 and 3.0. The handling of visibility in depsgraph did not change during 3.0 cycle, so to me is not immediately obvious that the depsgraph side is not doing what it's supposed to. [custom_shape.blend](https://archive.blender.org/developer/F12646961/custom_shape.blend) If someone can upload same level of complexity of file demonstrating the issue that'd make troubleshooting from depsgraph side. As for reverting I'm not sure about it. I'll trade one regression with another, which isn't very great.

Hans Goudey was unassigned by Sergey Sharybin

2021-11-29 10:42:07 +01:00

Sergey Sharybin self-assigned this 2021-11-29 10:42:07 +01:00

Sergey Sharybin commented

2021-11-29 10:42:07 +01:00

Added subscriber: @HooglyBoogly

blender-admin commented

2021-11-29 11:57:31 +01:00

This issue was referenced by aa7051c8f2

This issue was referenced by aa7051c8f21a6b7e2b413b40317502e69764fa05

Sybren A. Stüvel commented

2021-11-29 14:38:16 +01:00

The test file in the task description should really get an explanation, ideally with a screenshot of what it ought to look like. Right now I can open it, and I see only a camera and a light. Should there be custom bone shapes visible? Given the report I think so, but a screenshot would help a lot. If anything else, it would remove guesswork and provide a clear picture (literally) of the expected/correct situation.

The test file in the task description should really get an explanation, ideally with a screenshot of what it ought to look like. Right now I can open it, and I see only a camera and a light. Should there be custom bone shapes visible? Given the report I *think* so, but a screenshot would help a lot. If anything else, it would remove guesswork and provide a clear picture (literally) of the expected/correct situation.

Sergey Sharybin commented

2021-11-29 14:49:59 +01:00

@dr.sybren Added a simple test plan with a screenshot of an expected state. Also removed lamp and camera to make things less distracting in the viewport. Hope it clarifies things.

Sergey Sharybin commented

2021-11-29 17:09:44 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Sergey Sharybin closed this issue

2021-11-29 17:09:44 +01:00

Thomas Dinges added this to the 3.0 milestone 2023-02-08 15:58:47 +01:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Armature widgets from hidden collections are invisible. #93439