blender/blender

195

618

Fork 962

You've already forked blender

Code Issues 6.4k Pull Requests 1.1k Projects 22 Wiki Activity

Library Override (parent task) #53500

New Issue

Closed

opened 2017-12-07 14:54:04 +01:00 by Bastien Montagne · 53 comments

Bastien Montagne commented

2017-12-07 14:54:04 +01:00

Owner

Copy Link

Deprecated task, please see #73318 (Library overrides).

This task is here to explain current design behind lybrary overrides in #bf_blender_2.8, and to keep track of known limitations and TODOs.

Reminder: “library override” only allows overriding linked data. Since those do not change, we can evaluate library overrides once (when loading .blend, or re-loading a library). This could also be named 'partially localized data-blocks'. On the other hand, “dynamic override” would allow overriding local data, and would be handled by the depsgraph evaluation to generate final data.

This is not finalized project, but most (all) core concepts, API and code are expected to be final. Lots remain to be done mostly in adding overridable status to many more properties, and… stress-test all kind of complex corner cases!

Right now, only a few properties are overridable, among which object's and bone’s loc/rot/scale, you can test the code by:

linking an object;
make an override of it (through operator, type 'override' in space-bar search menu);
change e.g. location, rotation and/or scale of the override;
save file;
open file again, and see that changed location/rotation/scale were kept.

You may also note that non-overridable properties remain grayed-out in UI.

Finally, at least basic support of animation override is done and working (i.e. being able to add, or replace, animation of the local overriding ID).

TODO's for 2.81

Those are known tasks that should be addressed before we go into 2.81 beta phase (i.e. we create the release branch).

{icon circle color=red} #54652 (Static Override - Check and validate handling of ID Properties).

TODO's for 2.82:

{icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly).

TODO's for 2.83:

{icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly).
{icon circle color=red} #73156 (ID search menu issue with linked data-blocks)

TODO's for 2.90:

{icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly).
{icon circle color=yellow} #73154 (Library Overrides - UI: Add access to the 'auto override' flag of IDs)
{icon circle color=yellow} Add/extend operator to override chains of dependencies (you select an ID to override, and it automatically also overrides all/some of its linked users up to the first local data-block) - mostly for Outliner?
{icon circle color=yellow} Add an operator to fully revert an override to its linked data-block (it's basically ID remapping to linked data + deletion of the override).
{icon circle color=yellow} Add an operator to fully reset an override to its linked data-block state. Warning: likely more complicated than it looks, as this should not break the overridden pointers to other IDs in the same 'overriding family'.
{icon circle color=yellow} Add an operator to convert from existing proxies to new lib overrides.
{icon circle color=yellow} Solve/define a proper way to handle materials overrides?
{icon circle color=green} Add a setting similar to auto-keyframe to automatically generate an override when you edit a property? NOTE: this is likely very complex to get right, as by default linked IDs are fully non-editable...

TODO's for later:

{icon circle color=yellow} #72629 (Library Override: Support editing of animation data in overriden data-blocks.)
{icon circle color=green} #54762 (Library Overrides - investigate further performances issues.), partially addressed already, but it should be possible to improve things further still.
{icon circle color=green} #73250 (Override Library will always return to Object Mode after saving file in Pose Mode)

Technical Details

Here is a summary of how library overrides work.

Overrides are handled at RNA level That means we use RNA paths to control which property are overridden (much like animation in fact).
Overrides are 'rooted' at ID level That means that a given ID stores all its overriding, including those in “sub-data” structures.
Each overridden, local ID keeps a pointer to its (linked) reference ID.
Overrides behave exactly like any other local data-blocks, for 99% of Blender code. Only places that need to be aware of their status are:
- UI (through RNA, to give feedback to the user).
- Load and save code.

Some way to hook the auto-override creation when someone changes an override's property (done as part of undo step creation currently).

RNA changes.

The way RNA properties are compared was heavily rewritten to allow much more complex behavior. Aside from override-specific topics, this brings real comparison (and not only-equality one), and more importantly, the ability to have a custom callback for custom comparison process.

Override Creation

This is merely making a local copy of the linked datablock, and generate an empty override structure for it.

We need some advanced and complex behavior to be possible here (especially thinking about rigged chars, where you need to override armature and mesh objects, and relink the relations between them…).
Hook up override creation into UI (add menu entries, etc.). Easy, to be done once all known issues are fixed.

Auto-generating override operations

User can define/control overriding of properties by hand, but we also generate them automatically, by making some RNA-based comparison between reference and local IDs. RNA comparison code has been extensively enhanced to support that. Auto-generation is currently performed each time an undo step is generated.

Support for some collections (modifiers or constraints e.g.).
Refined handling of pointers. Pointers can be to other IDs (then we only want to compare pointer itself), or to some sub-data we own (in which case, we want to go further down the path), or to some other we do not own (we only want to compare pointer itself here too).
Try to improve performances (#54762) (for big production characters, this can add several hundreds of milliseconds to every undo step... we can live with it, but this could be improved). Partially addressed already, but it should be possible to improve things further still.

Override at .blend saving

We save local override 'as is', along with its override operations list. In case some operations are differential (add, sub, multiply), we compute and store the other operand in another datablock (storage one). This simplifies/sanitize write code (and most importantly, avoid having to temporarily modify real ID data during save process!), and also allows to get the 'overridden state' of the ID even when opening in an older Blender unaware of overriding process.

Right now we make full usual copy of the local overriding ID, which is not acceptable for huge datablocks (thinking especially about mesh data here!), we'll need a way to trim useless data (probably using a new copy flag). Not critical though, since Mesh (and other data) IDs are not overridden currently. Note however that removing actual geometry data will make file fully broken in case lib data is lost, or if loaded in an older blender version... Not sure how critical this is in either way.

Override at .blend loading

Once we have loaded the whole .blend file and all its libraries, we go over whole Main database and apply overrides. To do that without having to recreate, and remap, and rename whole IDs, we edit a copy of linked (reference) ID, and then swap its content with local one.

Would be nice to investigate improving a bit code efficiency here, if possible. E.g. we could make out-of-main copy, but this would then probably break ID refcounting… Rather low priority anyway, current code does not seem to be a serious bottleneck.

Known TODOs, Issues, etc.

This is not feature complete! By far… Only basic operations are implemented, several areas remain fuzzy, etc. However, core concepts and code should be mature enough to be merged in blender2.8, where ongoing development can go on. Also, current state is enough and needed for Asset Engine project.

Code Working on DNA

Mainly operators, but can be also a few buttons using low-level access to data…

This is a bit of a hairy issue, since overriding data-blocks are essentially local ones, any operator can go playing on their data with any knowledge about what they should be allowed to do!

A first half of the solution is done, which is adding a post-operation check to try to restore data from reference when needed (added as part of the auto-override generation in undo step).

This does not solve everything though, we cannot undo all changes from RNA. So second part of the solution will unfortunately be to add checks to operators. We probably can limit this to a general check over a datablock (at least for a start), to forbid some operators to work on overriding ones completely.

But reaching a full and perfect control on the situation here is likely to be very difficult and long, if possible at all… So question is, to what point can we accept to have some changed data in local overrides that shall not be different from their reference? Knowing that a save & reload of the .blend file (or a manual 'resync' from linked references) will restore things to their correct status?

Override Templates & Locked Override

Those features are partially implemented, but require more work to be usable by users. They are not high-priority currently, and are not being actively worked on.

Differential overrides (add/subtract, or multiplication factor, also binary operation for flags, etc.). Mostly implemented, but need some UI/UX design work.
Override templates: those are overrides defined in the library file. They give a default override “pattern” when creating a new override in final files (e.g. for a rig, it will allow to restrict which bones are editable in the overrides, and which will remain 'locked' for the end user - at least from UI, PyRNA API will allow to do everything of course).
Locked override: by defining a NO-OP (no operation) override operation for a given property, you can effectively prevent any overriding of that property (ensure it will always remain at same value as the linked overridden data-block).

IDProperties

#54652

Even though they were taken into account to some extent into new code, those are not supported currently. This needs to be addressed, but don’t think it's super-high priority for now.

Non-trivial cases - Rigged chars

While a lot of tests were done, and a lot of issues fixed, current code should not yet be considered fully ready to replace proxies.

Support complex rigs with lots of constraints, drivers and other nifty features.
Support production chars like Autumn (a.k.a uber-complex rigs, with sub-rigs etc.).

Non-trivial cases - Materials

The way materials are linked to object or obdata make them especially tricky to handle in override case.

Non-trivial cases - Nodes

Not yet checked, but fairly sure that the way nodetrees can be real or fake IDs (root trees of materials/compositing/etc.) will also be an issue…

Deprecated task, please see #73318 (Library overrides). ---------- This task is here to explain current design behind lybrary overrides in #bf_blender_2.8, and to keep track of known limitations and TODOs. Reminder: “library override” only allows overriding linked data. Since those do not change, we can evaluate library overrides once (when loading .blend, or re-loading a library). This could also be named 'partially localized data-blocks'. On the other hand, “dynamic override” would allow overriding local data, and would be handled by the depsgraph evaluation to generate final data. This is not finalized project, but most (all) core concepts, API and code are expected to be final. Lots remain to be done mostly in adding overridable status to many more properties, and… stress-test all kind of complex corner cases! Right now, only a few properties are overridable, among which object's and bone’s loc/rot/scale, you can test the code by: - linking an object; - make an override of it (through operator, type 'override' in space-bar search menu); - change e.g. location, rotation and/or scale of the override; - save file; - open file again, and see that changed location/rotation/scale were kept. You may also note that non-overridable properties remain grayed-out in UI. Finally, at least basic support of animation override is done and working (i.e. being able to add, or replace, animation of the local overriding ID). TODO's for 2.81 **** Those are known tasks that should be addressed before we go into 2.81 beta phase (i.e. we create the release branch). - [x] {icon circle color=red} #54652 (Static Override - Check and validate handling of ID Properties). TODO's for 2.82: ------------------- - [x] {icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly). TODO's for 2.83: ------------------- - [x] {icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly). - [x] {icon circle color=red} #73156 (ID search menu issue with linked data-blocks) TODO's for 2.90: ------------------- - [ ] {icon circle color=red} Define much more RNA properties as overridable (this is easy-monkey work mostly). - [ ] {icon circle color=yellow} #73154 (Library Overrides - UI: Add access to the 'auto override' flag of IDs) - [ ] {icon circle color=yellow} Add/extend operator to override chains of dependencies (you select an ID to override, and it automatically also overrides all/some of its linked users up to the first local data-block) - mostly for Outliner? - [ ] {icon circle color=yellow} Add an operator to fully revert an override to its linked data-block (it's basically ID remapping to linked data + deletion of the override). - [ ] {icon circle color=yellow} Add an operator to fully reset an override to its linked data-block state. *Warning: likely more complicated than it looks, as this should not break the overridden pointers to other IDs in the same 'overriding family'.* - [ ] {icon circle color=yellow} Add an operator to convert from existing proxies to new lib overrides. - [ ] {icon circle color=yellow} Solve/define a proper way to handle materials overrides? - [ ] {icon circle color=green} Add a setting similar to auto-keyframe to automatically generate an override when you edit a property? *NOTE: this is likely very complex to get right, as by default linked IDs are fully non-editable...* TODO's for later: -------------------- - [ ] {icon circle color=yellow} #72629 (Library Override: Support editing of animation data in overriden data-blocks.) - [ ] {icon circle color=green} #54762 (Library Overrides - investigate further performances issues.), partially addressed already, but it should be possible to improve things further still. - [ ] {icon circle color=green} #73250 (Override Library will always return to Object Mode after saving file in Pose Mode) Technical Details **** Here is a summary of how library overrides work. - **Overrides are handled at RNA level** That means we use RNA paths to control which property are overridden (much like animation in fact). - **Overrides are 'rooted' at ID level** That means that a given ID stores all its overriding, including those in “sub-data” structures. - Each overridden, local ID keeps a pointer to its (linked) reference ID. - Overrides behave exactly like any other local data-blocks, for 99% of Blender code. Only places that need to be aware of their status are: - UI (through RNA, to give feedback to the user). - Load and save code. ## Some way to hook the auto-override creation when someone changes an override's property (done as part of undo step creation currently). ### RNA changes. The way RNA properties are compared was heavily rewritten to allow much more complex behavior. Aside from override-specific topics, this brings real comparison (and not only-equality one), and more importantly, the ability to have a custom callback for custom comparison process. ### Override Creation This is merely making a local copy of the linked datablock, and generate an empty override structure for it. - [x] We need some advanced and complex behavior to be possible here (especially thinking about rigged chars, where you need to override armature and mesh objects, and relink the relations between them…). - [x] Hook up override creation into UI (add menu entries, etc.). Easy, to be done once all known issues are fixed. ### Auto-generating override operations User can define/control overriding of properties by hand, but we also generate them automatically, by making some RNA-based comparison between reference and local IDs. RNA comparison code has been extensively enhanced to support that. Auto-generation is currently performed each time an undo step is generated. - [x] Support for some collections (modifiers or constraints e.g.). - [x] Refined handling of pointers. Pointers can be to other IDs (then we only want to compare pointer itself), or to some sub-data we **own** (in which case, we want to go further down the path), or to some other we **do not own** (we only want to compare pointer itself here too). - [ ] Try to improve performances (#54762) (for big production characters, this can add several hundreds of milliseconds to every undo step... we can live with it, but this could be improved). *Partially addressed already, but it should be possible to improve things further still.* ### Override at .blend saving We save local override 'as is', along with its override operations list. In case some operations are differential (add, sub, multiply), we compute and store the other operand in another datablock (storage one). This simplifies/sanitize write code (and most importantly, avoid having to temporarily modify real ID data during save process!), and also allows to get the 'overridden state' of the ID even when opening in an older Blender unaware of overriding process. - [ ] Right now we make full usual copy of the local overriding ID, which is not acceptable for huge datablocks (thinking especially about mesh data here!), we'll need a way to trim useless data (probably using a new copy flag). Not critical though, since Mesh (and other data) IDs are not overridden currently. Note however that removing actual geometry data will make file fully broken in case lib data is lost, or if loaded in an older blender version... Not sure how critical this is in either way. ### Override at .blend loading Once we have loaded the whole .blend file and all its libraries, we go over whole Main database and apply overrides. To do that without having to recreate, and remap, and rename whole IDs, we edit a copy of linked (reference) ID, and then swap its content with local one. - [ ] Would be nice to investigate improving a bit code efficiency here, if possible. E.g. we could make out-of-main copy, but this would then probably break ID refcounting… Rather low priority anyway, current code does not seem to be a serious bottleneck. Known TODOs, Issues, etc. **** **This is not feature complete!** By far… Only basic operations are implemented, several areas remain fuzzy, etc. However, core concepts and code should be mature enough to be merged in blender2.8, where ongoing development can go on. Also, current state is enough and needed for Asset Engine project. ### Code Working on DNA Mainly operators, but can be also a few buttons using low-level access to data… This is a bit of a hairy issue, since overriding data-blocks are essentially local ones, any operator can go playing on their data with any knowledge about what they should be allowed to do! A first half of the solution is done, which is adding a post-operation check to try to restore data from reference when needed (added as part of the auto-override generation in undo step). This does not solve everything though, we cannot undo all changes from RNA. So second part of the solution will unfortunately be to add checks to operators. We *probably* can limit this to a general check over a datablock (at least for a start), to forbid some operators to work on overriding ones completely. But reaching a full and perfect control on the situation here is likely to be very difficult and long, if possible at all… So question is, to what point can we accept to have some changed data in local overrides that shall not be different from their reference? Knowing that a save & reload of the .blend file (or a manual 'resync' from linked references) will restore things to their correct status? ### Override Templates & Locked Override Those features are partially implemented, but require more work to be usable by users. They are not high-priority currently, and are not being actively worked on. - [ ] Differential overrides (add/subtract, or multiplication factor, also binary operation for flags, etc.). Mostly implemented, but need some UI/UX design work. - [ ] Override templates: those are overrides defined in the library file. They give a default override “pattern” when creating a new override in final files (e.g. for a rig, it will allow to restrict which bones are editable in the overrides, and which will remain 'locked' for the end user - at least from UI, PyRNA API will allow to do everything of course). - [ ] Locked override: by defining a NO-OP (no operation) override operation for a given property, you can effectively prevent any overriding of that property (ensure it will always remain at same value as the linked overridden data-block). ### IDProperties #54652 - [x] Even though they were taken into account to some extent into new code, those are not supported currently. This needs to be addressed, but don’t think it's super-high priority for now. ### Non-trivial cases - Rigged chars While a lot of tests were done, and a lot of issues fixed, current code should not yet be considered fully ready to replace proxies. - [x] Support complex rigs with lots of constraints, drivers and other nifty features. - [x] Support production chars like Autumn (a.k.a uber-complex rigs, with sub-rigs etc.). ### Non-trivial cases - Materials - [ ] The way materials are linked to object or obdata make them especially tricky to handle in override case. ### Non-trivial cases - Nodes - [ ] Not yet checked, but fairly sure that the way nodetrees can be real or fake IDs (root trees of materials/compositing/etc.) will also be an issue…

Bastien Montagne commented

2017-12-07 14:54:04 +01:00

Author

Owner

Copy Link

Added subscriber: @mont29

Danrae Pray commented

2017-12-07 15:27:40 +01:00

Copy Link

Added subscriber: @spockTheGray-4

Bastien Montagne self-assigned this 2018-04-16 10:24:47 +02:00

Brecht Van Lommel changed title from ~~Static Override~~ to Static Override (parent task)

2018-08-13 11:51:17 +02:00

Duarte Farrajota Ramos commented

2018-10-14 15:12:13 +02:00

Copy Link

Added subscriber: @DuarteRamos

Mauricio Marinho commented

2019-07-30 21:06:39 +02:00

Copy Link

Added subscriber: @MauricioMarinho

Sam Green commented

2019-08-06 16:30:44 +02:00

Copy Link

Added subscriber: @SamGreen

Joseph Brandenburg commented

2019-08-07 08:05:25 +02:00

Copy Link

Added subscriber: @Josephbburg

rollin commented

2019-08-08 18:27:27 +02:00

Copy Link

Added subscriber: @rollin

item412 commented

2019-08-27 13:29:18 +02:00

Copy Link

Added subscriber: @item412

Carlos Muñoz commented

2019-08-29 18:15:32 +02:00

Copy Link

Added subscriber: @carlosmu

Andrew Charlton commented

2019-09-05 00:25:23 +02:00

Copy Link

Added subscriber: @Scaredyfish

Andrew Charlton commented

2019-09-12 09:21:33 +02:00

Copy Link

I've been testing this a bit, and it works great! I've noticed shape keys don't seem to be overridable. Is this a limitation, or just something not implemented yet?

Bastien Montagne commented

2019-09-12 10:48:44 +02:00

Author

Owner

Copy Link

@Scaredyfish Thanks for testing! Shape keys are planned, yes, but not for 2.81, they are likely to give some "interesting" issues. ;)

Andrew Charlton commented

2019-09-12 22:14:15 +02:00

Copy Link

That's good to know. Thanks for the info!

Malcolm Reed commented

2019-09-14 10:14:10 +02:00

Copy Link

Added subscriber: @reed2000

Satish Goda commented

2019-09-19 02:52:27 +02:00

Copy Link

Added subscriber: @satishgoda1

ML commented

2019-10-03 16:11:59 +02:00

Copy Link

Added subscriber: @MarcelLegindi

B.E. commented

2019-10-06 21:28:17 +02:00

Copy Link

Added subscriber: @jiku

Demeter Dzadik commented

2019-10-10 15:04:03 +02:00

Member

Copy Link

Added subscriber: @Mets

Demeter Dzadik commented

2019-10-10 15:04:03 +02:00

Member

Copy Link

I'm super excited for this system and hope you can find time to fix the above thing, and make custom properties work for 2.82. I think that's basically all we would need to let this replace linking. And then if you figure out how to add shape key support... we will throw you a party at the studio.

I didn't want to submit a bug report for this(but let me know if I should), since I know this is work in progress, but it seems that the new Armature constraints don't play along well. I see it is indicated in the UI when a target ID is overriden, by a turqoise color. This doesn't seem to be the case for Armature constraint, so I guess that's meaningful to you. I'm super excited for this system and hope you can find time to fix the above thing, and make custom properties work for 2.82. I think that's basically all we would need to let this replace linking. And then if you figure out how to add shape key support... we will throw you a party at the studio.

Malcolm Reed commented

2019-10-11 14:46:32 +02:00

Copy Link

I've been using Library Overrides on a game character Armature to mostly great effect (some crashing, see below).

One issue I've had is when I needed to rename an attachment bone. When the rig updates in the animation scenes the animation still has the old name - how would it know to change I guess? Is there or would there be some smart way to re-target to the new name?

Also when exporting to FBX if the curve properties can't be found the animation export is broken completely.

So after deleting the old properties and saving the scene, the scene crashes on opening. I think it's dues to the library linking as I can move the blend file so it can't see the linked filed and it opens without crashing, but with errors about the missing link file. I've reported it as a bug here https://developer.blender.org/T70695

Lots of other things to add to this system I know, I hope it gets some more love soon as it has the potential to be really great.
One thing I found with the current capabilities is that whilst I can set TRS keys as an override, in the Graph Editor I can't set the value of a key in the properties panel.

I've been using Library Overrides on a game character Armature to mostly great effect (some crashing, see below). One issue I've had is when I needed to rename an attachment bone. When the rig updates in the animation scenes the animation still has the old name - how would it know to change I guess? Is there or would there be some smart way to re-target to the new name? Also when exporting to FBX if the curve properties can't be found the animation export is broken completely. So after deleting the old properties and saving the scene, the scene crashes on opening. I think it's dues to the library linking as I can move the blend file so it can't see the linked filed and it opens without crashing, but with errors about the missing link file. I've reported it as a bug here https://developer.blender.org/T70695 Lots of other things to add to this system I know, I hope it gets some more love soon as it has the potential to be really great. One thing I found with the current capabilities is that whilst I can set TRS keys as an override, in the Graph Editor I can't set the value of a key in the properties panel.

Bastien Montagne commented

2019-10-11 15:08:03 +02:00

Author

Owner

Copy Link

@Mets please make report(s), it’s waaaayyyyy easier to keep track of issues that way. ;)

@reed2000 Indeed I would not expect miracles if you rename some bones in your rig, when doing this on a regular local data-block the releated code already has to go in a rather complex 'check every reference to old name and remap it to new name' process, but this is essentially impossible to do on an override… So things like anim curves, drivers etc. will need manual fixing in those cases am afraid.

And I expect many fixing work, and do have some more improvements ideas for library overrides in the future. :)

@Mets please make report(s), it’s waaaayyyyy easier to keep track of issues that way. ;) @reed2000 Indeed I would not expect miracles if you rename some bones in your rig, when doing this on a regular local data-block the releated code already has to go in a rather complex 'check every reference to old name and remap it to new name' process, but this is essentially impossible to do on an override… So things like anim curves, drivers etc. will need manual fixing in those cases am afraid. And I expect many fixing work, and do have some more improvements ideas for library overrides in the future. :)

Malcolm Reed commented

2019-10-11 17:50:08 +02:00

Copy Link

Hey Bastien, understand on the name change issue.

Maybe an area for someone to write a tool at some point to find anim curves for missing bones and ask what to do with them (hmm maybe it exists somewhere - I'll have a hunt). Fix path by renaming or delete for example. Changes to rigs can happen quite often during game dev - often gets locked down when you finish the project!

Anyway Overrides/Referencing is great and something I used heavily back in my dark days as a Maya user, so I'm backing Library Overrides all the way. Look forward to future additions.

Hey Bastien, understand on the name change issue. Maybe an area for someone to write a tool at some point to find anim curves for missing bones and ask what to do with them (hmm maybe it exists somewhere - I'll have a hunt). Fix path by renaming or delete for example. Changes to rigs can happen quite often during game dev - often gets locked down when you finish the project! Anyway Overrides/Referencing is great and something I used heavily back in my dark days as a Maya user, so I'm backing Library Overrides all the way. Look forward to future additions.

Alexander Gavrilov commented

2019-10-14 18:54:41 +02:00

Member

Copy Link

Added subscriber: @angavrilov

Alexander Gavrilov commented

2019-10-14 18:54:41 +02:00

Member

Copy Link

The way overrides are applied for a character is by using a run-once operator that recursively overrides a collection with all its child collections and contained objects, patching references within the override set to refer to overridden objects. The initial result of this is perfectly fine, but it cannot cope with any new references between objects added to the library file after the override setup was already created, as well as new objects. This is because the handling of references between the objects was applied by the operator, and after that the override system itself has no idea that these objects are supposed to be inter-related.

Basically, in practical terms, after an override of a character is created in a scene, it is no longer possible to add new child objects to the character in the library, new constraints/modifiers to the child objects (that reference the armature), new drivers to child objects (referencing the armature, e.g. for new shape keys). All these references will require fixing in every scene that already has an override for the character.

Fixing this requires supporting deep overriding of collections at the override system level, rather than an operator. Something like:

Internally the override system has to support override groups: every override in a group implicitly overrides all references to its original ID in all overrides of the group (including itself).

Implicit means that no explicit property override records are created at ID level - being in the group is sufficient. An override rule on the ID itself would only be created if the reference is changed by the user to something different, because per-property overrides prevent propagating reference changes in the library.
Any override ID is effectively always in a group with itself. That is, self-references are also patched implicitly. Currently they already seem to be automatically patched, but override rules are also created, which is redundant.
When an ID override belongs to a group, it should be possible to override a reference into the same group, in addition to the existing global and one reference only options.
It's probably enough to support one group per override instance, and no hierarchy between groups; although maybe some clever use of that kind of things could be found in the future.

Collection overrides get a 'deep override' mode, in which case the override system will automatically create overrides for all objects and sub-collections of the original collection. Sub-collections become deep overrides themselves.

A root deep collection override creates and owns an override group. All overrides inside the collection and its children are assigned to the group.
The operator proposed to be the replacement to Make Proxy simply creates a root deep collection override, and populates it, without any complex one-time logic.
It probably should be impossible to unlink an override from such collections just in case.

So, after playing with overrides for a trivial character (bouncing ball with a rig), I noticed a big issue that in my view makes the current implementation not very good for complex characters that are not 100% perfect and finalized. The way overrides are applied for a character is by using a run-once operator that recursively overrides a collection with all its child collections and contained objects, patching references within the override set to refer to overridden objects. The initial result of this is perfectly fine, but it cannot cope with any new references between objects added to the library file after the override setup was already created, as well as new objects. This is because the handling of references between the objects was applied by the operator, and after that the override system itself has no idea that these objects are supposed to be inter-related. Basically, in practical terms, after an override of a character is created in a scene, it is no longer possible to add new child objects to the character in the library, new constraints/modifiers to the child objects (that reference the armature), new drivers to child objects (referencing the armature, e.g. for new shape keys). All these references will require fixing in every scene that already has an override for the character. Fixing this requires supporting deep overriding of collections at the override system level, rather than an operator. Something like: 1. Internally the override system has to support *override groups*: every override in a group *implicitly* overrides all references to its original ID in all overrides of the group (including itself). * Implicit means that no explicit property override records are created at ID level - being in the group is sufficient. An override rule on the ID itself would only be created if the reference is changed by the user to something different, because per-property overrides prevent propagating reference changes in the library. * Any override ID is effectively always in a group with itself. That is, self-references are also patched *implicitly*. Currently they already seem to be automatically patched, but override rules are also created, which is redundant. * When an ID override belongs to a group, it should be possible to override a reference into the same group, in addition to the existing global and one reference only options. * It's probably enough to support one group per override instance, and no hierarchy between groups; although maybe some clever use of that kind of things could be found in the future. 1. Collection overrides get a 'deep override' mode, in which case the override system will automatically create overrides for all objects and sub-collections of the original collection. Sub-collections become deep overrides themselves. * A root deep collection override creates and owns an override group. All overrides inside the collection and its children are assigned to the group. * The operator proposed to be the replacement to Make Proxy simply creates a root deep collection override, and populates it, without any complex one-time logic. * It probably should be impossible to unlink an override from such collections just in case.

Luc Revardel commented

2019-10-14 21:24:20 +02:00

Copy Link

Added subscriber: @luc

Ivan Cappiello commented

2019-10-15 11:16:10 +02:00

Member

Copy Link

Added subscriber: @icappiello

Yash Pal Goyal commented

2019-11-01 08:30:50 +01:00

Copy Link

Added subscriber: @anonym

Bastien Montagne changed title from ~~Static Override (parent task)~~ to Library Override (parent task)

2019-11-08 10:29:32 +01:00

Luc Revardel commented

2019-11-13 22:19:59 +01:00

Copy Link

Added subscriber: @lrevardel

Luc Revardel commented

2019-11-13 22:20:44 +01:00

Copy Link

Removed subscriber: @luc

Pipeliner commented

2019-11-28 18:30:52 +01:00

Copy Link

Added subscriber: @Pipeliner

Julien Leménicier commented

2019-12-08 12:11:34 +01:00

Copy Link

Added subscriber: @lemenicier_julien

Swann Martinez commented

2020-01-16 10:40:42 +01:00

Copy Link

Added subscriber: @slumber

Aditia A. Pratama commented

2020-01-21 01:16:14 +01:00

Member

Copy Link

Added subscriber: @AditiaA.Pratama

Luciano Muñoz Sessarego commented

2020-01-27 19:21:30 +01:00

Member

Copy Link

Added subscriber: @LucianoMunoz

Andrew Charlton commented

2020-01-30 09:09:11 +01:00

Copy Link

I don't think this is a bug per-se, but it would be very handy for library overrides to support NLA strips. I feel like this is a good use case for library overrides since the main advantage currently is the ability to link the same character multiple times, and the ability to mix a set of existing animations for those characters is a good feature.

Let me know if you want this logged as a bug, or if this is a harder problem that is not a priority.

David Andrade commented

2020-02-16 17:39:23 +01:00

Copy Link

Added subscriber: @davidandrade

Erkan Ozgur Yilmaz commented

2020-02-17 11:04:38 +01:00

Copy Link

Added subscriber: @eoyilmaz

Blazer Silving commented

2020-02-20 22:56:31 +01:00

Contributor

Copy Link

Added subscriber: @breakingspell

Jesús Moral commented

2020-03-05 12:19:27 +01:00

Copy Link

Added subscriber: @jesusmabas

Karlis Stigis commented

2020-03-09 06:35:27 +01:00

Copy Link

Added subscriber: @karlisstigis

mantissa commented

2020-04-03 15:30:16 +02:00

Copy Link

Added subscriber: @Mantissa

Emir Sinan Gürlek commented

2020-04-15 21:55:58 +02:00

Copy Link

Added subscriber: @filibis

Daniel Grauer commented

2020-04-21 17:01:40 +02:00

Member

Copy Link

Added subscriber: @DanielGrauer

Bastien Montagne commented

2020-06-22 17:18:35 +02:00

Author

Owner

Copy Link

Closed as duplicate of #73318

Bastien Montagne closed this issue

2020-06-22 17:18:35 +02:00

Carlos Muñoz commented

2020-08-21 18:09:53 +02:00

Copy Link

Removed subscriber: @carlosmu

Mariusz commented

2020-09-16 20:34:34 +02:00

Copy Link

Added subscriber: @mpocztowski

Matt Curtis commented

2020-11-03 15:38:16 +01:00

Copy Link

Added subscriber: @MattCurtis

Matt Curtis commented

2020-11-03 15:39:16 +01:00

Copy Link

Removed subscriber: @MattCurtis

Xury Greer commented

2020-11-22 22:54:18 +01:00

Copy Link

Added subscriber: @Xury46

Gehrig commented

2021-04-10 04:06:29 +02:00

Copy Link

Added subscriber: @Gehrig

Vladimir Frantiichuk commented

2021-05-03 20:21:36 +02:00

Copy Link

Added subscriber: @fldbots

Vladimir Frantiichuk commented

2021-05-03 20:21:37 +02:00

Copy Link

When I started using Linked Object/Library Overriding I save a lot energy and achieved good structure for projects. Recently I removed also lighting objects from my scenes and the structure of files is are more clean. I use Radiance HDR maps that baking in another .blend file using panoramic camera. I think that the idea of lights autobaking is interesting feature. Is it possible to use the Panoramic camera output (linked .blend) as a input for the Equirectangular texture in World Shader Editor in a another file?

johan tri handoyo commented

2021-06-20 06:46:32 +02:00

Copy Link

Added subscriber: @JohanTriHandoyo

Thomas Dinges added this to the 2.90 milestone 2023-02-08 16:27:56 +01:00

Richard Antalik referenced this issue

2023-08-04 01:34:01 +02:00

Library overrides #73318

No Branch/Tag Specified

main

manifold

npr-prototype

blender-v4.2-release

blender-v3.6-release

blender-v4.4-release

remote-asset-library-monolithic

blender-v4.3-release

temp-sculpt-dyntopo

blender-v3.3-release

brush-assets-project

pr-extensions-tidy-space

blender-v4.0-release

universal-scene-description

blender-v4.1-release

blender-v3.6-temp_wmoss_animrig_public

gpencil-next

blender-projects-basics

sculpt-blender

asset-browser-frontend-split

asset-shelf

blender-v3.5-release

blender-v2.93-release

sculpt-dev

bevelv2

xr-dev

v4.4.1

v4.2.9

v3.6.22

v4.4.0

v4.2.8

v4.2.7

v3.6.21

v4.2.6

v3.6.20

v4.2.5

v3.6.19

v4.3.2

v4.3.1

v4.3.0

v4.2.4

v3.6.18

v4.2.3

v3.6.17

v4.2.2

v3.6.16

v4.2.1

v3.6.15

v4.2.0

v3.6.14

v3.3.21

v3.6.13

v3.3.20

v3.6.12

v3.3.19

v4.1.1

v3.6.11

v3.3.18

v4.1.0

v3.3.17

v3.6.10

v3.6.9

v3.3.16

v3.6.8

v3.6.7

v3.3.14

v4.0.2

v4.0.1

v4.0.0

v3.6.5

v3.3.12

v3.6.4

v3.6.3

v3.3.11

v3.6.2

v3.3.10

v3.6.1

v3.3.9

v3.6.0

v3.3.8

v3.3.7

v2.93.18

v3.5.1

v3.3.6

v2.93.17

v3.5.0

v2.93.16

v3.3.5

v3.3.4

v2.93.15

v2.93.14

v3.3.3

v2.93.13

v2.93.12

v3.4.1

v3.3.2

v3.4.0

v3.3.1

v2.93.11

v3.3.0

v3.2.2

v2.93.10

v3.2.1

v3.2.0

v2.83.20

v2.93.9

v3.1.2

v3.1.1

v3.1.0

v2.83.19

v2.93.8

v3.0.1

v2.93.7

v3.0.0

v2.93.6

v2.93.5

v2.83.18

v2.93.4

v2.93.3

v2.83.17

v2.93.2

v2.93.1

v2.83.16

v2.93.0

v2.83.15

v2.83.14

v2.83.13

v2.92.0

v2.83.12

v2.91.2

v2.83.10

v2.91.0

v2.83.9

v2.83.8

v2.83.7

v2.90.1

v2.83.6.1

v2.83.6

v2.90.0

v2.83.5

v2.83.4

v2.83.3

v2.83.2

v2.83.1

v2.83

v2.82a

v2.82

v2.81a

v2.81

v2.80

v2.80-rc3

v2.80-rc2

v2.80-rc1

v2.79b

v2.79a

v2.79

v2.79-rc2

v2.79-rc1

v2.78c

v2.78b

v2.78a

v2.78

v2.78-rc2

v2.78-rc1

v2.77a

v2.77

v2.77-rc2

v2.77-rc1

v2.76b

v2.76a

v2.76

v2.76-rc3

v2.76-rc2

v2.76-rc1

v2.75a

v2.75

v2.75-rc2

v2.75-rc1

v2.74

v2.74-rc4

v2.74-rc3

v2.74-rc2

v2.74-rc1

v2.73a

v2.73

v2.73-rc1

v2.72b

2.72b

v2.72a

v2.72

v2.72-rc1

v2.71

v2.71-rc2

v2.71-rc1

v2.70a

v2.70

v2.70-rc2

v2.70-rc

v2.69

v2.68a

v2.68

v2.67b

v2.67a

v2.67

v2.66a

v2.66

v2.65a

v2.65

v2.64a

v2.64

v2.63a

v2.63

v2.61

v2.60a

v2.60

v2.59

v2.58a

v2.58

v2.57b

v2.57a

v2.57

v2.56a

v2.56

v2.55

v2.54

v2.53

v2.52

v2.51

v2.50

v2.49b

v2.49a

v2.49

v2.48a

v2.48

v2.47

v2.46

v2.45

v2.44

v2.43

v2.42a

v2.42

v2.41

v2.40

v2.37a

v2.37

v2.36

v2.35a

v2.35

v2.34

v2.33a

v2.33

v2.32

v2.31a

v2.31

v2.30

v2.28c

v2.28a

v2.28

v2.27

v2.26

v2.25

Labels

Clear labels

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Library Override (parent task) #53500

TODO's for 2.82:

TODO's for 2.83:

TODO's for 2.90:

TODO's for later:

Some way to hook the auto-override creation when someone changes an override's property (done as part of undo step creation currently).

RNA changes.

Override Creation

Auto-generating override operations

Override at .blend saving

Override at .blend loading

Code Working on DNA

Override Templates & Locked Override

IDProperties

Non-trivial cases - Rigged chars

Non-trivial cases - Materials

Non-trivial cases - Nodes