Bone collections can be added to system-overridden (i.e. non-user-editable) armatures #115310
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#115310
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Blender Version
Broken: version: 4.1.0 Alpha, branch: main, commit date: 2023-11-22 21:44, hash:
a13696a242fbCurrent operators managing bone collections do not check if the Armature ID is a system liboverride, or a 'regular' liboverride. The former should not be editable directly by the user, while the later is.
Original report:
Short description of error
After linking, making override on this particular armature object and adding bone collections, I can't rename them.
Exact steps for others to reproduce the error
bug_collection_override_rename.blend
bug_collection_override_rename_linked.blend
HI @Mets.
I can't repro the issue.
Collections in link armature with overrides can be renamed without any problems here when I tested.
Can you provide any additional information about the steps you took or specific details related to the armature and bone collections?
My bad, I lied about this happening with the default armature because I just assumed it would, sorry.
It only seems to happen on one particular armature object that happens to be our main character's rig. So, maybe some setting is causing this? But it beats me.
File with two armatures authored at the same time, one of them work, the other doesn't:
bug_collection_override_rename.blend
Video:
A bit of a guess, I suspect it might be an interface problem when it has many items.
I've seen problems somehow... maybe... related to the interface:
#113703: UI does not show that a Vertex Group does not exist (beyond a search limit of 10 items)
With these steps, there is no library override on the Armature data-block, and thus you can't even add a new bone collection.
There is no file attached to the issue description directly, though, so I tested this with the file in the above comment. I can't reproduce the issue there either, as both armatures work fine when I link them into an empty Blend file and create overrides on the Armatures (so not the armature Object, but the Armature data-block itself).
The video goes too fast for me with too little explanation to see exactly what's going on.
@Mets you did update the issue description to account for this, right?
I forgot, but Germano did when he left his comment 2 weeks ago, thank you Germano!
I tried reducing the repro steps now by adding an extra file where the armatures are already linked in and overridden, and describing the issue in the objects' names. Hope that helps to reproduce.
I've tried to reproduce, but I can't. I'll pop by your desk to see it happen first hand.Never mind, I can't read.There's some magic going on in the UIList that I don't quite understand. Suffice to say, later this week I should be able to land #115945 which replaces the flat list with a tree, and that doesn't seem to have this bug.
If you want, you could test with https://builder.blender.org/download/patch/PR115945/ , it should work just fine™.
Cannot rename inserted bone collections on overridden armatures.to Cannot rename inserted bone collections on overridden armaturesTested the nested bone collections branch, indeed that new UI list element doesn't have this issue. So I'd say that's a good enough fix as far as the Animation Module is concerned. So as far as I'm concerned, this can be closed when that feature gets merged.
Will still ping UI(@JulianEisel) and Core(@mont29) modules to also take a glance at this though, since this might pop up in different areas that still use the old list UI. Not saying it needs to be fixed until a real issue actually pops up, just poking to make sure people are aware this might pop up again in future.
I do not think that this should be closed without further thinking, especially without understanding the current issue.
uiList is not the problem here, the problem is that, for 'some reason', the liboverride collections'
nameproperties of one armature are detected as read-only (can be easily checked by runningC.object.data.collections[-1].is_property_readonly("name")from python console for each armature object).Why this is the case is... still an (interesting) mystery.
On a side (minor) note, the
"collections"RNA property of armatures should have itsPROP_EDITABLEset by default I think - otherwise UIList do not detect these items as editable, and do not show the"Double click to rename"tooltip for them.And... the mystery is solved!
The armature which liboverride bone collections cannot be edited is... a system override, so indeed, user is not expected to edit it.
So the actual bug here is that the operators allow adding bone collections to a system liboverride armature.
Cannot rename inserted bone collections on overridden armaturesto Bone collections can be added to system-overridden (i.e. non-user-editable) armaturesHmm, on the video I actually apparently had to override the data of one of the objects as a separate step, the other one appeared to already have an editable overridde, but I guess it didn't? Is it expected that the Make Library Override operator sometimes makes an editable override of the object data and sometimes it doesn't?
@Mets I would expect you to be able to answer to that question yourself honestly...
META-mikassaArmature ID has no dependency to its object, so by default it's left as linked data when overriding the object. When you manually create an override for the Armature ID, it is by definition a user override, and thus editable.RIG_mikassaArmature ID has a dependency (somehow, did not check where) to its object, and thus has to be overridden together with its object. Since this is an automated override only necessary for technical reasons, it is by default a system override, not editable by the user. You need to explicitly make it a user override to be able to edit it.It's not like these relationships are straight forward at all. I realize now that drivers on pose bones don't create a dependency from the armature to the object because pose bones are stored on the object in the first place, whereas drivers on data bones do create that dependency, and that bone visibilities are stored on the data bones for some completely arbitrary reason which makes that fact very easy to forget, since in the UI it's all drawn in one place. So I guess since there are 4 bones in there with a driven visibility (the IK lines between limbs and their poles), the data becomes dependent on the object, therefore when creating an override of the object, an override of the data must also be created. Gotcha.
You flatter me if you think I could figure that out without a nudge in the right direction, so easily that it warrants a patronizing response! :D
This makes me realize that that dependency could be avoided on my end. It won't help much, but I'll make that change just to reduce the relationships in my rigs.
Thanks @mont29 for the help. Maybe we should do another "technical documentation day" collaboration on this, as we sorely need a "developer how-to" for writing code with stable/correct liboverride handling in mind.
To add some more techincal detail for the devs (mostly: me) looking into this: we need many more checks for
const bool is_system_override = BKE_lib_override_library_is_system_defined(bmain, &id);in the code that would otherwise just use theID_IS_OVERRIDE_LIBRARY(&id)macro.Thanks for the pointer. I've implemented this in
3e6139cc30.