Page MenuHome

Library Overrides: Usability issues/paper-cuts
Closed, ResolvedPublicTO DO

Description

T53500 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 @Andy Goralczyk (eyecandy). The possible solutions can be discussed here too.

  • There is no straightforward way to duplicate an override. (74ec37b70cbc)
  • 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.
  • Collections must be linked as instances for "Make Library Overrides" to work on the entire collection contents. (rB680a81fc4907)

    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. (417ebc3845fd)

    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. (rBbd3ab27410ef, rB174332688936).

    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. (rBe3fd60b182f6, rB680a81fc4907)

    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...

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.)

Related Objects

StatusSubtypeAssignedTask
ConfirmedTO DOBastien Montagne (mont29)
DuplicateDESIGNBastien Montagne (mont29)
ResolvedDESIGNBastien Montagne (mont29)
ResolvedBastien Montagne (mont29)
ResolvedBastien Montagne (mont29)
ResolvedBastien Montagne (mont29)
ResolvedBastien Montagne (mont29)
ResolvedDESIGNBastien Montagne (mont29)
ResolvedBUGBastien Montagne (mont29)
ResolvedBUGBastien Montagne (mont29)
ResolvedTO DOBastien Montagne (mont29)
ResolvedTO DOBastien Montagne (mont29)
ConfirmedDESIGNNone
ResolvedTO DOBastien Montagne (mont29)

Event Timeline

Julian Eisel (Severin) changed the task status from Needs Triage to Confirmed.May 8 2020, 4:57 PM
Julian Eisel (Severin) created this task.
Julian Eisel (Severin) changed the subtype of this task from "Report" to "Design".

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.

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.

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:

  1. The library collection is linked in without instancing and gets put in the active collection like usual.
  2. The user selects the rig object in the viewport (or the outliner) and calls Make Library Override
  3. 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

Julian Eisel (Severin) changed the subtype of this task from "Design" to "To Do".
Bastien Montagne (mont29) updated the task description. (Show Details)
Bastien Montagne (mont29) updated the task description. (Show Details)

One done. :)