Library Overrides: Usability issues/paper-cuts #76555

Closed
opened 2020-05-08 16:57:38 +02:00 by Julian Eisel · 11 comments
Member

#53500 gives an overview of what still needs to be done for library overrides as a whole, it suggests ways to address some of the points listed here.
Intend of this task is to take a step back and give a list of concrete usability paper-cuts that would be good to address. It is mostly based on a feedback video by @eyecandy. The possible solutions can be discussed here too.

  • There is no straightforward way to duplicate an override. (74ec37b70c)

  • The UI feedback on override status is unreliable (fd8d245e6a)

    To work around performance issues, only a single data-block is evaluated for UI feedback after calling the "Make Library Overrides" operator. Unfortunately this makes library overrides appear broken/buggy.

  • Collections must be linked as instances for "Make Library Overrides" to work on the entire collection contents. (680a81fc49)

    While not a big issue in practice, this could simply be addressed by letting the "Make Library Overrides" operator act on contents of a collection only, if the collection is not instanced.

  • After the "Make Library Overrides" operator is run on a collection instance, the entire hierarchy of the overriden collection is expanded by default. (417ebc3845)

    Collections are expanded by default, we should probably make an exception for linked ones, which tend to have many items. D7626

  • After the "Make Library Overrides" operator is run on a collection instance, the overriden collection gets placed in the scene collection; the instancer empty is still there, but typically unused. (bd3ab27410, 1743326889).

    The overriden collection could be placed in the parent of the instancer empty, and the empy unlinked (or remove if this was the only user). D7626

  • Materials are not linked with collections (so object materials can not be overriden) This is not part of this task, it's a later step in the roadmap.

  • When overriding an object within some linked (not instanced) collection, all its linked parent collections have to manually be overridden. (e3fd60b182, 680a81fc49)

    There could either be an operator(-option) to automatically override parent collections, or the code would always do this.

  • Library overrides can not be fully reset (i.e. removing all override operations, and reloading data from linked reference).

    Note that by default, this should not clear overrides of ID pointers, not even sure we want to give that option to the user? Would nuke all overrides in dependency hierarchy as well...

  • Library overrides can not be removed entirely (i.e. deleting the local override, and relinking its usages to the linked reference). 4aa04b6490

    Note that this will likely also require purging other overrides that were only used by the removed override.

  • Library overrides can not be regenerated from source linked data (to take into account e.g. changes in relationships between data-blocks...). aeaf2b0dd4

This requires doing a proper complete re-creation of the override, then copying existing valid overrides properties to new ones, remapping 'external' pointers to old overrides to new ones, and finally deleting old override data-blocks.

  • Library overrides can not be disabled This is not possible by design, overrides do not store any value, so it would not be possible to keep edited values from overrides and restore them when un-muted.

    The overrides should be listed in the outliner, with an eye icon to enable/disable them. D7631

  • Even if no value is actually overriden, a library is still marked as overriden. This is expected and required behavior, being an override is a major status info of a data-block, whether some of its data are actually changed or not is irrelevant.

(There are a few other issues mentioned in the video, but these may be bugs that are already addressed. Needs to be checked still.)

#53500 gives an overview of what still needs to be done for library overrides as a whole, it suggests ways to address some of the points listed here. Intend of this task is to take a step back and give a list of concrete usability paper-cuts that would be good to address. It is mostly based on a feedback video by @eyecandy. The possible solutions can be discussed here too. - [x] There is no straightforward way to duplicate an override. (74ec37b70cbc) - [x] The UI feedback on override status is unreliable (fd8d245e6a80) *To work around performance issues, only a single data-block is evaluated for UI feedback after calling the "Make Library Overrides" operator. Unfortunately this makes library overrides appear broken/buggy.* - [x] Collections *must* be linked as instances for "Make Library Overrides" to work on the entire collection contents. (680a81fc49) *While not a big issue in practice, this could simply be addressed by letting the "Make Library Overrides" operator act on contents of a collection only, if the collection is not instanced.* - [x] After the "Make Library Overrides" operator is run on a collection instance, the entire hierarchy of the overriden collection is expanded by default. (417ebc3845fd) *Collections are expanded by default, we should probably make an exception for linked ones, which tend to have many items.* [D7626](https://archive.blender.org/developer/D7626) - [x] After the "Make Library Overrides" operator is run on a collection instance, the overriden collection gets placed in the scene collection; the instancer empty is still there, but typically unused. (bd3ab27410, 1743326889). *The overriden collection could be placed in the parent of the instancer empty, and the empy unlinked (or remove if this was the only user).* [D7626](https://archive.blender.org/developer/D7626) - [x] ~~Materials are not linked with collections (so object materials can not be overriden)~~ *This is not part of this task, it's a later step in the roadmap.* - [x] When overriding an object within some linked (not instanced) collection, all its linked parent collections have to manually be overridden. (e3fd60b182, 680a81fc49) *There could either be an operator(-option) to automatically override parent collections, or the code would always do this.* - [x] Library overrides can not be fully reset (i.e. removing all override operations, and reloading data from linked reference). *Note that by default, this should not clear overrides of ID pointers, not even sure we want to give that option to the user? Would nuke all overrides in dependency hierarchy as well...* - [x] Library overrides can not be removed entirely (i.e. deleting the local override, and relinking its usages to the linked reference). 4aa04b6490 *Note that this will likely also require purging other overrides that were only used by the removed override.* - [x] Library overrides can not be regenerated from source linked data (to take into account e.g. changes in relationships between data-blocks...). aeaf2b0dd4 *This requires doing a proper complete re-creation of the override, then copying existing valid overrides properties to new ones, remapping 'external' pointers to old overrides to new ones, and finally deleting old override data-blocks.* - [x] ~~Library overrides can not be disabled~~ *This is not possible by design, overrides do not store any value, so it would not be possible to keep edited values from overrides and restore them when un-muted.* *The overrides should be listed in the outliner, with an eye icon to enable/disable them.* [D7631](https://archive.blender.org/developer/D7631) - [x] ~~Even if no value is actually overriden, a library is still marked as overriden.~~ *This is expected and required behavior, being an override is a major status info of a data-block, whether some of its data are actually changed or not is irrelevant.* *(There are a few other issues mentioned in the video, but these may be bugs that are already addressed. Needs to be checked still.)*
Julian Eisel self-assigned this 2020-05-08 16:57:38 +02:00
Author
Member

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

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

Added subscriber: @JulianEisel

Added subscriber: @JulianEisel
Author
Member

Added subscriber: @eyecandy

Added subscriber: @eyecandy

Added subscriber: @mont29

Added subscriber: @mont29

Added subscriber: @DuarteRamos

Added subscriber: @DuarteRamos

Added subscriber: @Scaredyfish

Added subscriber: @Scaredyfish

Added subscriber: @reed2000

Added subscriber: @reed2000
Member

Regarding the Make Library Override operator (and the menu it brings up):
As far as I can tell the operator is meant to replace the Make Proxy option we had before, which was specifically made for 'popping out' rigs from Groups to allow local manipulations. The user selects the rig which will be placed next to the collection for easy access.

image.png

This is not the case with overrides because the internal hierarchy of the overriden collection will (and should) stay intact. The rig stays in the same place, even if it's in a subcollection. To make Make Library override behave more in the same way (and provide similar legacy behavior) it should link the object, which was selected in the dialog before to the same level as the new collection object.

image.png

This would make it a more adequate replacement of the old workflow.

However, I don't think this is the right workflow for overriding characters for animation for the following reasons:

  • Instances can be moved on the object level, but when overridden, the objects will move back to the origin. this is confusing.
  • The name of the operator suggests a general function, but in reality it is really just for easy access to rigs in instanced collections.
  • To instance a collection into an empty just to make it accessible to edits via overrides (and as a result removing the instance) is kind of convoluted.

My suggestion for a better workflow is this:

  • The library collection is linked in without instancing and gets put in the active collection like usual.
  • The user selects the rig object in the viewport (or the outliner) and calls Make Library Override

The operator overrides the collection hierarchy the object is in and all data that is affected by it

This is already very close to the current behavior, just that it's afaik not possible to use the Make Library Overrides operator on an object in a non-instanced collection. Also, the internal hierarchy of a rigged character would have to be clean enough to make it intuitive to select a rig and navigate the asset (something that riggers and character authors should definitely be mindful of).

I hope I have explained this clear enough!

Andy

Regarding the **Make Library Override** operator (and the menu it brings up): As far as I can tell the operator is meant to replace the **Make Proxy** option we had before, which was specifically made for 'popping out' rigs from Groups to allow local manipulations. The user selects the rig which will be placed next to the collection for easy access. ![image.png](https://archive.blender.org/developer/F8527701/image.png) This is not the case with overrides because the internal hierarchy of the overriden collection will (and should) stay intact. The rig stays in the same place, even if it's in a subcollection. To make **Make Library override** behave more in the same way (and provide similar legacy behavior) it should link the object, which was selected in the dialog before to the same level as the new collection object. ![image.png](https://archive.blender.org/developer/F8527705/image.png) This would make it a more adequate replacement of the old workflow. **However**, I don't think this is the right workflow for overriding characters for animation for the following reasons: - Instances can be moved on the object level, but when overridden, the objects will move back to the origin. this is confusing. - The name of the operator suggests a general function, but in reality it is really just for easy access to rigs in instanced collections. - To instance a collection into an empty just to make it accessible to edits via overrides (and as a result removing the instance) is kind of convoluted. My suggestion for a better workflow is this: - The library collection is linked in **without** instancing and gets put in the active collection like usual. - The user selects the rig object in the viewport (or the outliner) and calls **Make Library Override** # The operator overrides the collection hierarchy the object is in and all data that is affected by it This is already very close to the current behavior, just that it's afaik not possible to use the **Make Library Overrides** operator on an object in a non-instanced collection. Also, the internal hierarchy of a rigged character would have to be clean enough to make it intuitive to select a rig and navigate the asset (something that riggers and character authors should definitely be mindful of). I hope I have explained this clear enough! Andy
Contributor

Added subscriber: @RedMser

Added subscriber: @RedMser
Julian Eisel removed their assignment 2020-08-10 15:11:54 +02:00
Bastien Montagne was assigned by Julian Eisel 2020-08-10 15:11:54 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'

One done. :)

One done. :)
Thomas Dinges added this to the 2.91 milestone 2023-02-08 16:21:50 +01:00
Sign in to join this conversation.
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
7 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#76555
No description provided.