The goal of this meeting was to review the current main issues and showstoppers in Library Overrides project, in the context of the Blender Studio production pipeline. The following topics were discussed:
Conflict Handling
Conflicts happen when the reference linked data does not match the local override one, and there is no way to fix things automatically.
Users must be able to manually fix conflicts when they happen.
In practice, conflicts do not happen often.
Current tools are good enough for now.
Recursive Re-syncing
Recursive library overrides are local overrides made from linked data that are also overrides of other linked data. For example, an character can be linked from the library into the anim work file, overridden to animate it, and then that overridden animated version of the asset can be linked from the anim work file into the lighting file.
This is currently one of the main bottleneck, as artists need to ensure all production file in the chain of dependencies are properly re-synced. E.g. if the character in the library is modified, then the anim file needs to be opened and re-synced for the lighting file to be usable again.
Solution is to support ‘recursive re-sync’, i.e. also re-syncing linked data when needed.
The main draw-back is performances, since the results of those linked data re-sync cannot be saved, it has to be performed over and over every time the .blend file is reloaded.
There should be a clear communication to the user that a linked data re-sync was necessary, with information like which linked file needs to be re-synced, and the cost (time) spent on that.
Inter-Overrides Dependencies
E.g. if you want to parent one character to another override character. Currently this is not supported (as it breaks the override hierarchy handling).
Supporting this is considered as a known TODO.
There is a simple work-around (using local data as ‘intermediary’ relationship between two different overrides), so this is not a very urgent problem.
Orphaned Data
When re-syncing happens, it can detect that an obsolete local override data has been edited by the user, and then currently keeps that data around to avoid potential losses, instead of deleting it.
While this ensures that no user-generated data can be lost, it can generate a large quantity of ‘garbage’ data over time, which clutters production files.
So it was decided to switch to an ‘auto purge’ model instead, where local overrides with no valid reference anymore in the linked data always get deleted.
Effective data loss will only happen when actually saving the current .blend file.
User will be informed of the issue, they can then decide to not save the current file and instead fix the issue in the linked data.
This decision can be re-assessed later if better ways to handle those left-over data can be designed.
Conclusion
The switch in how orphaned override data is handled will be tackled first, as it is a very quick and straight-forward change.
Then the recursive re-sync support will get full high priority.
Awesome that this is being tied up carefully like that. I’ve been using overrides for my past project but I’ve had to make characters local in a few scenes because I needed to change something in the material. Considering drivers on node properties don’t work right now I couldn’t even have the rig controlling the material.
I also think the UI should be streamlined a bit. But at least I can have as many linked turtles as I want in a given scene, it’s great. There’s also a problem with some action datablocks (from the rig file) being absent of the list when trying to link them to the character from the anim file. I assume this is well known ?
Just wondering, would that mean that if I load a file which links data from another file located on a server, and the server is temporarily unavailable (i.e. linked data can not be found at loading time), all overrides of said data would be purged upon file save?
Have been doing rigging for a team of animators recently. We used overrides for the first time. With implied complexity it’s a big achievement that overrides are working for characters. Which is awesome as is the idea itself!
Among observations there are a few minor hickups regarding updating and UI:
When adding a new control bone in source character file, a resulting new bone in linking file may come up without custom shape and/or without assigned bone group color.
File version updating isn’t exactly obvioius. We used “relocate library”, as it seems that just replacing the source character file isn’t always enough (and there is some vagueness to it described below). Which might be fine, but “relocate library” leaves the old file link hanging unless manually deleted, leading to some degree of confusion on which files are being actually used and whether the operation executed successfully and there are no links to the old file left.
Executing “Re-sync hierarchy”/“Reload file” sometimes destroys the related overridden data. I might’ve been doing something wrong or that might’ve been the intended behavior, but such details might be more obvious. For example, by reminding that “… . Overridden data will be preserved” or “replaced” in a tool tip. Wording “Rebuild this local override…”, while is technically accurate, requires one to have a solid knowledge background and matching understanding of terms to predict exactly what the correct result should look like, which is a bit much to ask from someone that needs a tooltip.
There is Outliner “Reload” and “Relocate” library, and then there are outliner “Resync LO” and “Reset LO”,. Since these are used in related scenarios, it would be great to be more explicit in UI or Tooltips how these relate to each other. Will a “Reload” affect overridden data? Will it refresh linked objects? Etc.
There is Viewport->Object->Relations->Make Library Override, and there is Outliner ID data->Add library override. From Outliner it can be seen that these produce different results, but there’s no way for a new user to predict how and understand why. If they aren’t intended as the same function, shouldn’t both be visible in both places? Otherwise, maybe something chould be added to the name, to hint the difference. Note: Linking is usually done via linking a collection that includes the necessary elements, which may be a reason for even greater difference between those functions.