Age | Commit message (Collapse) | Author |
|
Properly use given reference pointer in
`lib_override_library_create_post_process` when it is a Collection one
too.
|
|
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.
|
|
|
|
|
|
|
|
|
|
Adding another pass of ensuring valid up-to-date pose data in RNA
function itself...
|
|
|
|
Conflicts:
source/blender/blenkernel/intern/armature.c
|
|
Use new `BKE_pose_ensure` utils, and do so for reference linked object
too everywhere.
|
|
|
|
Finaly managed to reproduce, we not only have to ensure pose data is up
to date for the override armature, but also for the reference linked
data.
|
|
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.
|
|
No reasons to keep the new ID pointer as parameter here.
Part of T71219.
|
|
|
|
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.
|
|
Also use back-slash instead of '@'.
|
|
|
|
|
|
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.
|
|
|
|
It makes no sense to generate/update overrides from missing (broken
linked) reference data, just keep existing ones unchanged then.
|
|
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenkernel` module.
No functional changes.
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Needed for upcoming changes.
|
|
This commit mostly avoids following 'loop back' ID pointers, since those
should never define an actual relationship.
|
|
|
|
This is strictly forbidden, and sill cause crashes with undo in some
cases...
|
|
We need to do a full proper swap of those shape keys as well, previous
code ended up breaking relationships between data-blocks...
|
|
|
|
|
|
BKE_lib_override.
This code is fairly complex and can be used in more places, better not
duplicate that logic and just have it in BKE area.
|
|
|