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.
IDs like embedded ones (master collections, root node trees) cannot be
linked, and thus cannot be real override themselves.
Since they are managed by their owner ID, that one will also have the
overrides for their locally edited properties.
We still need a way to mark them as overridden though, for various UI
and override-internal purposes, this is done using a new ID flag.
Note that since Shae Keys are not linkable, and their pointers are not
editable in RNA, they are also considered as embedded from override
point of view.
This will not give any noticeable improvements in common editing tasks,
since then usually only a very few IDs are changed and checked for
override updates.
However, it makes full override diffing process several times faster
(happens usually when saving a .blend file, but could also help e.g.
when multi-editing several override objects at the same time...).
By using own path construction instead of handy printf-like functions,
we get a 10% improvement on overall diffing process!
This remains way to slow on some complex production characters, but
always good to have still.
Now all overrides are handled that way. Performances of the process look
decent enough, even with production characters...
If performance issues still arise, we'll investigate other solutions.
This should also make T73154 obsolete now.
This commit enables basic copy of overrides on generic ID level, as well
as from (deep) copy operators for objects and collections.
So e.g. if your linked overridden caracter is in a collection, you can
now (from the outliner) Duplicate that override collection to get a new
overriding copy of the character.
We still need operators (new or modifying existing ones) to handle that
from 3DView e.g.
Note that deep copy code for objects/collections (and incidently
animdata) had to be modified to avoid duplicating/making local IDs that
remain linked ones being used by overrides ones.
Local datablocks (including overrides) need to have a unique name, which
can then differ from the reference linked one (especially when there are
several local overrides of a same linked data).
Issue is, ID name is a 'rna name property', and as such used as
reference when dealing with override of collections of IDs, so we cannot
have a changing name.
The solution implemented here should work and is simple, but it may have
some issues in corner cases (time will say), it is not really robust.
Alternative solution would be to store ID pointers as reference in
override operations, instead of there name. But that would potentially
add quiet a lot of overhead to foreach looping in `lib_query.c`.
Note this only changes cases where the variable was declared inside
the for loop. To handle it outside as well is a different challenge.
Differential Revision: https://developer.blender.org/D7320
