Having a centeral place to find a list of all library overrides should be
useful for managing production scenes where library overrides are used a lot.
This change adds the individually overridden properties of a data-block under
the data-block itself. Just how we show modifiers, constraints or pose channels
there. This way we can also expose library override operations/options better
in future.
There's also a filter option for the library overrides now, so they can be
hidden. It is only available in the View Layer display mode though, like the
other filter options.
One internal change this has to do is adding more informative return values to
undo pushes and the library override functions called by it. That way we can
send a notifier when library overrides change for the Outliner to know when to
rebuild the tree.
Differential Revision: https://developer.blender.org/D7631
Reviewed by: Andy Goralczyk, Bastien Montagne, William Reynish
Some weird proxies apparently can have a local collection instancing...
Not sure this is even really valid for proxies, but in any case we
cannot override that, just detect and properly cancel the operation
then.
Should be backported to 2.91.1 should we do it.
We do not generate overrides for missing data-blocks (aka placeholder
ones) anymore, and properly delete the remaining old overrides of those
during the resync process.
This should prevent constant 'missing data-blocks' messages when opening
blend files with overrides whose libraries have beed edited.
Issue reported by @andy from Blender studio, thanks.
Code was actually not applying any override operation over linked data.
Reasonn behind that was that if library file is saved with latest
override applied then this is not needed, since data saved for the
override in the lib file is already up to date.
But this is actually fully breaking in case someone update the lib file
of the lib file, without re-saving the libfile itself.
So now we alwaya apply overrides also on linked data.
Note that this will not fix the case where a resync is needed.
This was done as some sort of safety, but should not actually be needed,
and including tags like `ID_RECALC_POINT_CACHE` e.g. makes usage of
point caches impossible with liboverrides (since it would systematically
invalidate all cache on file load).
In theory we should not have to tag anything here in fact, RNA accessors
are supposed to take care of it, but for now we keep the
`ID_RECALC_COPY_ON_WRITE` one.
Part of first step of T82503: support disk cache in liboverrides.
From the backtrace it looks like in some cases file save (which triggers
a general override updates) is done before other code has a chance to
re-generate pose data, leading to rna accessing freed memory.
I was never able to reproduce that here, so this is a tentative fix in
master, if it proves to be working for the studio it will be
cherry-picked into 2.91 release branch later.
When we override a whole collection, we want to add non-instantiated
objects to a hidden sub-collection at the end of the process.
However, this makes no sense when instantiating an object, if other
dependencies objects get also overridden on the process, we should just
add them to the same collection owning the root object.
We can only re-apply overrides fron the old local overrides to the newly
generated ones after all IDs have been properly remapped and renamed.
Otherwise override operations based on ID names may fail.
Related to T81059, found while investigating it.
Part of the code handling deletion of old, not needed anymore local
override IDs, was not working properly, effectively only deleting one
ID ever.
New code should also be a bit faster, though this should not be really
visible from user perspective.
Related to T81059, found while investigating it.
Root of the issue is how we generate the storage ID for the differential
override operations.
However, since those are disabled anyway currently, simply comment out
creation of this copy for now, we can revisit this if/when we decide to
re-activate differential overrides.
Related to T81059, found while investigating it.
In the end the process is surpringly simple, we only need to manually
convert the proxy itself into an override (which is trivial), and then
run common code with the default 'make override' operation.
Fix T81059: Add operator to convert proxies to library overrides.
Some RNA setters require ID data they operate on to be in G_MAIN.
Unfortunately, when we apply overrides as part of a .blend file reading,
new Main is not yet made global one, so we have to do it temporarily
here.
This is a fairly ugly hack, but it should be harmless and safe.
This is a first step towards supporting conversion of proxies, done
separately to make it easy to pinpoint in case it would create problems.
It is not expected to cause any change in behavior currently.
Issue was with our dear posebones again... when applying overrides we
keep the same address/pointer for the IDs themselves, (which avoids us
the need to remap their usages), but their inner data is often
re-allocated.
Therefore, we need once again to go over armature objects and invalidate
their posebone pointers.
This should also be back-ported to Blender LTS 2.83.
Maniphest Tasks: T80078
Differential Revision: https://developer.blender.org/D8734
This will re-link all usages of a library override data-block
(including all of its override dependencies) to its reference linked
IDs, and delete those liboverrides.
As usual, it is available in the ID sub-menu of the outliner context
right-click menu.
Part of T76555.
Available from the usual ID submenu in the Outliner context menu.
The goal of this operator is to re-create the override from the linked
data, while preserving existing defined overrides.
This allows to update local opverrides when relations between datablocks
are changed in source library linked data.
Part of T76555.
This means that we delete all override properties except for those over
ID pointers *if* the assigned pointer matches the linked data hierarchy.
Then we reload affected datablocks.
