We do not want to re-generate auto-overrides until everything that
needed to be resynced has been resynced. Otherwise it's a waste of time
and guaranteed loss of some override properties.
Mistake in rB9947f2095610 earlier today.
Instead of storing those in scne's master collection, which is fairly
annoying, we now add them to a (hidden) specific collection. Easy to
ignore, or check and cleanup.
This is not only potentially extremely expensive, it is also fairly
futile, and code is not designed to handle it currently anyway (could
easily end up in inifinite loops and other crashes).
Problem is, when a collection is excluded from the scene, none of its
objects are technically instantiated.
This should not happen when *creating* an override, but can be fairly
common during resync process.
For now, use a lesser precise check in resync case, only relying on
object usercount. This might lead to some objects being left without any
collection in some rare weird case, but this cannot really be avoided
currently.
Attempt to work around some full-corruption cases created at the studio.
Not clear how those were created, so not really fixing anything here,
just detecting and 'solving' as best as possible some high corruption of
local overrides.
This is good to have in general anyway, might help prevent further
corruption to happen too.
This is basically done by ignoring override operations from old override
affecting ID pointer properties, when the new (destination) one is not
NULL.
Fix T86501: New object added to overridden collection doesn't show up in linking file on Resync.
This is more of a work-around actually, since there is no real way to
fix the issue in a fully automated and consistent way, it is caused by
older blender files being saved with 'broken' overrides.
WARNING: This cannot ensure that some purposedly edited/overridden ID
pointer properties won't be lost in the process.
`BKE_lib_override_library_main_resync` uses
`LIB_TAG_LIB_OVERRIDE_NEED_RESYNC` tags set by RNA override apply code,
and perform detection for the remaining cases (those were new overrides
need to be created for data that was not present before in the library).
And then it actually resync all needed local overrides.
Part of T83811 & D10649.
We can fairly easily detect some resync-needed cases when applying the
overrides operations on a Pointer RNA property.
This should cover all cases where an existing override's ID pointer is
changed in its linked data.
We still have to add code to detect when a not-yet-overridden linked ID
needs to become overridden (because its relations to other data-blocks
changed in a way that requires it).
Part of T83811 & D10649.
This potentially could fix some missed cases in dependency tagging (when
dealing with overrides hierarchies), since relying on tag in ID itself
is not a good idea to check whether an ID has been propcessed or not
(exterior code may have forced that tag on some IDs e.g., which would
prevent them from ever being processed properly).
This potentially could fix some missed cases in dependency tagging (when
dealing with overrides hierarchies), since relying on tag in ID itself
is not a good idea to check whether an ID has been propcessed or not
(exterior code may have forced that tag on some IDs e.g., which would
prevent them from ever being processed properly).
Invalid override properties ( i.e. invalid RNA paths) are not strictly
speaking errors, many things can lead to that situation. Just ignore and
skip those cases.
Properly fully extract
`lib_override_hierarchy_dependencies_recursive_tag` from
`lib_override_linked_group_tag`.
Was supposed to be that way already (see comment of
`lib_override_linked_group_tag`), for some reasons this case was missed.
When we have a local override, its linked reference may not be detected
as needing to be overridden anymore.
In that case, if there is no actual override defined by the user, assume
that we can get rid of this local override as part of the resync
process, and use the linked data directly instead.
First step towards a better handling of relationships between IDs in
override context, especially when a resync is needed.
First, introduce a new flag to override operations,
`IDOVERRIDE_LIBRARY_FLAG_IDPOINTER_MATCH_REFERENCE`, for ID pointers.
It keeps track of whether an RNA ID pointer has been kept to its
'natural overriden ID' (in override hierarchy context), or has actually
been re-assigned to some other data-block.
Second, refactor how we deal with relationships between IDs in override
hierarchy code, especially in resync case. This will fixe several cases
listed in T83811, especially the case where an ID pointer to an existing
override needs to be updated to a new one due to a matching change in
linked data.
`bmain.relations` is used to store temp data of relations between IDs,
to speed-up some complex processes heavily relying on such information.
Previous implementation was failry unclear/confusing, and required a
not-so-nice hack to 'tag' some ID as processed.
New code changes as such:
* Using `from`/`to` naming (instead of `user`/`used`).
* More clear separation between `to` `id_pointer` and `from` one,
using an union instead of hacking around difference between `ID *` and
`ID **` pointers.
* Adds storage of `session_uuid` informations (mainly useful as
debug/ensuring proper consistency of data currently).
* Adds a structure per ID in the mapping. This enables possibility of
storing tags (and potentially more data in the future) per-ID,
without polluting the IDs themselves with very short-life info.
Differential Revision: https://developer.blender.org/D10164
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.
