| Age | Commit message (Collapse) | Author |
|---|
|
liboverride-resynced libs.
This extra info is not always needed/convinient to use, and requires
special attention to free the list, so allow not generating it.
|
|
|
|
linked scene.
LibOverride of scenes is not really supported currently, there are many
issues with it.
Will disable most user-accessible ways to create such overrides in a
following commit.
|
|
|
|
This makes the internal naming consistent with the public API. And also gives
us a visibility_flag rather than restrictflag that can be extended with more
flags.
|
|
Recent own rBabf3ce811f6e prevented any LayerCollection update during
the whole liboverride resync process, for both performances and feature
reasons.
However that means that the various runtime caches like the Base GHash
are not cleared anymore during ID remapping process, so we need to call
`BKE_main_collection_sync_remap` instead of `BKE_main_collection_sync`
when we finally are ready for this update.
Reported by @eyecandy (Andy Goralczyk) from Blender studio, thanks!
|
|
When the root of an override hierarchy disapears, there is no way to do
a proper resync, just abort.
Reported by studio, thx.
|
|
This is an easy & safe, yet not-so-nice way to address the
LayerCollections vs. Collections hierarchy resync problem.
Currently this resync is enforced everytime something changes in the
Collections hierarchy, which is extremely inneficient, and can even
produce 'loss' of LayerCollection data during complex Collection
processes.
Current example is during Library Overrides resync process. New code:
* Makes resync significantly faster (between 10 and 15%).
* Fixes 'disappearing' layer collections settings on sub-collections'
layers.
NOTE: This is not a proper fix for the underlying issue. However,
implementing and testing the 'lazy update' solution as proposed by
{T73411} requires a significant amount of time (especially in testing
and tracking all places where code would need to ensure LayerCollections
are up-to-date), which is not possible currently.
Differential Revision: https://developer.blender.org/D11889
|
|
This shows the text as part of the assertion message.
|
|
Also use doxy style function reference `#` prefix chars when
referencing identifiers.
|
|
|
|
Weird 'embedded for overrides' flag of embedded IDs (including ShapeKeys
in override context) was not properly cleaned up when making an override
fully local.
Reported by studio, thanks.
@jbakker should be backported to 2.93LTS if possible.
|
|
This change will ensure at least one 'local' collection can host the new
'local' override of all objects (indirectly) overridden by this
operation, such that no new override of object ends up in master
collection (which can become extremely messy in production files).
In practice, it means often at least one of the linked collection owning
those objects also has to be overridden.
NOTE: This only affect cases where root overridden linked object has
some dependencies outside of its own root linked collection. While this
situation should be avoided, it cannot always be, so we try to support
it as best as we can.
|
|
This reverts commit rB3a48147b8ab92, and fixes the issues with linking
etc.
Change compared to previous buggy commit (rBf8d219dfd4c31) is that
new `BlendFileReadReports` reports are now passed to the lowest level
function generating the `FileData` (`filedata_new()`), which ensures
(and asserts) that all code using it does have a valid non-NULL pointer
to a `BlendFileReadReport` data.
Sorry for the noise, it's always when you think a change is trivial and
do not test it well enough that you end up doing those kind of
mistakes...
|
|
This change crashes library linking operators, related tests and probably more.
This reverts commit f8d219dfd4c31a918e33cb715472d91a5cd3fd51.
Ref D11583
|
|
Add direct user feedback (as a warning report) to user when recursive
resync of overrides was needed.
And some timing (as CLOG logs) about main readfile process steps.
This is essentially adding a new BlendFileReadReport structure that wraps
BKE_reports list, and adds some extra info (some timing, some info about
overrides and (recursive) resync, etc.).
|
|
After looking into task isolation issues with Sergey, we couldn't find the
reason behind the deadlocks that we are getting in T87938 and a Sprite Fright
file involving motion blur renders.
There is no apparent place where we adding or waiting on tasks in a task group
from different isolation regions, which is what is known to cause problems. Yet
it still hangs. Either we do not understand some limitation of TBB isolation,
or there is a bug in TBB, but we could not figure it out.
Instead the idea is to use isolation only where we know we need it: when
holding a mutex lock and then doing some multithreaded operation within that
locked region. Three places where we do this now:
* Generated images
* Cached BVH tree building
* OpenVDB lazy grid loading
Compared to the more automatic approach previously used, there is the downside
that it is easy to miss places where we need isolation. Yet doing it more
automatically is also causing unexpected issue and bugs that we found no
solution for, so this seems better.
Patch implemented by Sergey and me.
Differential Revision: https://developer.blender.org/D11603
|
|
Under some circumstances using task isolation can cause deadlocks.
Previously, our task pool implementation would run all tasks in an
isolated region. Now using task isolation is optional and can be
turned on/off for individual task pools.
Task pools that spawn new tasks recursively should never enable
task isolation. There is a new check that finds these cases at runtime.
Right now this check is disabled, so that this commit is a pure refactor.
It will be enabled in an upcoming commit.
This fixes T88598.
Differential Revision: https://developer.blender.org/D11415
|
|
This `break` moved out of its braces at some point in the previous
fixes/refctors... :(
|
|
|
|
In some cases e.g. only objects would actually need resync, so
collections on the override character would not be resynced, and if some
objects were sharing relationships with others those could be
lost/destroyed.
|
|
|
|
Ensure 'virtual' linked override IDs generated by the recursive resync
process are tagged as indirectly linked data.
This is needed to avoid the 'missing data' messages on those virtual
data-blocks after saving and reloading.
|
|
cases.
Broken in recent refactor of (recursive)resync, reported by studio,
thanks.
|
|
Since we use them on linked data now as well, 'local' does not fit them
anymore.
|
|
This commit fixes two different issues:
* In some cases, when an object was added to a sub-collection and used
into a different subcollection, and the root common collection would
not need to be resynced, it would end up creating multiple overrides
of the new object. This was affecting both normal and recursive
resync.
* In recurisve resync case, the barrier code to define what is part or
not of a override group/hierarchy was wrong.
Note that the current solution for the first issue is sub-optimal (it
goes back to the root of the override hierarchy and resync the whole
thing), a better solution is TODO for now.
|
|
Reported by studio (@andy), thanks.
|
|
|
|
We need to re-evaluate what needs to be resynced after each step of
processing overrides from a given 'indirect level' of libraries.
Otherwise, recusrive overrides (overrides of linked overrides) won't
work.
Note that this should not change too much in practice currently, since
there are other issues with recursive overrides yet.
Also, checks (CLOG errors) added show that some ID (node trees) seem to
be detected as needing resynced even after beig just resynced, this
needs further investigation still. Could be though that it is due to
limit currently set on nodetrees, those are always complicated
snowflakes to deal with...
|
|
It wasn't obvious this function cleared the tag as well.
|
|
inter-dependencies.
This is not supposed to happen, but better be safe than sorry, and
assume it is beyond unlikely that someone would use chains of over 10k
linked libraries.
|
|
Very stupid mistake in libraries indirect-level building code, was not
skipping 'loop-back' ID pointers.
Note that we also need some level of checks for the case where there
would be an actual dependency loop between libraries, this is not
supposed to be possible, but better be safe than sorry. Will add in next
commit.
|
|
|
|
Recursive resync means also resyncing overrides that are linked from
other library files into current working file.
Note that this allows to get 'working' files even when their
dependencies are out of sync. However, since linked data is never
written/saved, this has to be re-done every time the working file is
loaded, until said dependencies are updated properly.
NOTE: This is still missing the 'report' side of things, which is part
of a larger task to enhance reports regarding both linking, and
liboverrides (see T88393).
----------
Technical notes:
Implementing this proved to be slightly more challenging than expected,
mainly because one of the key aspects of the feature was never done in
Blender before: manipulating, re-creating linked data.
This ended up moving the whole resync code to use temp IDs out of bmain,
which is better in the long run anyway (and more aligned with what we
generally want to do when manipulating temp ID data). It should also
give a marginal improvement in performances for regular resync.
This commit also had to carefully 'sort' libraries by level of indirect
usage, as we want to resync first the libraries that are the least directly
used, i.e. libraries that are most used by other libraries.
|
|
Embedded IDs do not own their own override data, but rather use the one
from their owner.
|
|
This is obviously not saved, and should never be editable, so was only a
waste of time.
|
|
|
|
|
|
|
|
this is a followup to rB2bd85d9cc623, we cannot forcefully delete
obsolete overrides of object data (meshes etc.), as this implies also
deleting their user object, which might still be a perfectly valid
override, albeit in conflict regarding its obdata ID pointer...
|
|
|
|
of resync.
Logs are not enough here, we need proper warning visible for the user.
|
|
This is the opposite of previous code, which would keep those
'deprecated' overrides arround (often in a dedicated collection), when
they were detected as user-edited.
While this is a safe-ish way to (try to) preserve user-edited data, this
tends to add too much 'trash' data to production scenes, which cleaning
becomes a burden.
Note that user will get warnings in thos cases, and can always choose
not to save the current blend file and go fix the library issue instead.
|
|
Code detecting overrides which reference linked data is missing was
actually missing many cases, leading to too much garbage data being kept
around after resync process.
|
|
One of current annoying limitations of Blender re Collections/Objects is
that objects are forbidden to not be instantiated in at least one
collection.
Code ensuring that as a pst-processing step of override creation/resync
operations would be a bit too eager to add those objects to an external
'ad-hoc' collection, which poses several issues (both in term of keeping
the scene well organized, and related to override hierarchy handling).
So now be very conservative and only generate and use external 'storage'
collection for those objects when it is absolutely mandatory.
In pratice, it means this should never happen anymore on any decently
organized data source.
|
|
|
|
Move the detection/decision of whether an ID pointer should be taken
into account in library override hierarchy processing to the LibQuery
area of code, by introducing a new callback flag.
This allows to factorize the test logic, be explicit in liboverride code
about ID relationships that can be ignored when exploring the override
hierarchy, and adds the possibility to do more checks about pointers to
be tagged as non-overridable in the future.
Note that all but the 'special' ID pointers (loop-back, embedded, etc.)
should be overridable. If some is not, relevant IDType 'foreach_id'
callback code is reponsible to tag it properly.
Python-defined IDProperties however are not systematicaly overridable
(yet), so this should allow us to detect that case and act accordingly
in an incomming commit.
No behavioral change expected in this commit.
|
|
Multi-overrides of a same linked ID in a same override hierarchy are
currently not supported and can cause all kind of issues.
In some cases they could lead to infinite loop trying to resync the same
ID over and over, this is now prevented.
Found in some Blender studio production files.
|
|
|
|
Linked override were not properly ignored in some part of the code,
leading to invalid resync results in some cases with recursive overrides
(i.e. overrides of overrides).
Reported by Andy @eyecandy from the studio.
|
