We also need to rebuild the whole collection/viewlayer object cache
thing when we relink an objector collection in a collection (since it
might be part of a view layer).
Again, usual disclaimer about how inneficient this is currently, needs a
serious refactor to only tag caches as dirty, and actually rebuild the
whole thing on access.
The problem was that the object and collection pointers in Base and
LayerCollection would get lost of file read. Normally such ID pointers would
be resolved by pointing to an ID_ID placeholder which has the datablock name,
and then replacing it will the real datablock. However ID_ID is only written
for directly linked datablocks.
This adds the concept of an indirectly linked datablock with a weak reference
to it. For this we write an ID_ID_WEAK_REF code, which is a reference that
will only be resolved if the datablock was read for another reason.
Differential Revision: https://developer.blender.org/D4416
Make a distinction between flush sculpt changes for rendering, and forcing
sculpt data structures to be rebuilt after mesh changes. Also don't use PBVH
for renders.
This reverts commit b0b2546d4a.
Please do not sweept the dirt under the carpet like that! If there is a
bug, either report it or fix it, but do not silence it!
Better to make internal code naming match official/UI naming to some
extent, this will reduce confusion in the future.
This is 'breaking' scripts and files that would use that feature, but
since it is not yet officially supported nor exposed in 2.80, as far
as that release is concerned, it is effectively
a 'no functional changes' commit.
That would break proxy behavior after a library reload.
The usual super-annoying loop-back pointers... At least that one is
easily detectable and can be fixed in-place.
Found while investigating T64764.
Those are two cases where keeping infamous backward `parents` pointers
of collections in sync is kind of impossible to do... So rebuilding
those relationships from scratch instead.
Fixes e.g. a crash when undoing, then reloading a library, and likely
many more weird ones like that.
Uncovered while investigating T64764.
On file read we need to update group nodes in case the group they refer to
has changed its inputs and outputs. This had O(n^2) time complexity and was
updating all datablocks even if they did not change.
libquery code has some specific handling for IDs tagged as 'no_main',
among which to never consider them as refcounted/refcounting other IDs.
This is fine, but it also means we have to be careful when moving an ID
from main to out-of-main status, to do all id remapping we need
//before// we tag it as no_main.
That was a bit tedious to track down, we'll have to be careful that all
the corner cases we have to take care of, do not end up in a giant soup
of expections to exceptions, where nobody can find its way anymore...
Convention was not to but after discussion on 918941483f we agree its
best to change the convention.
Names now mostly follow RNA.
Some exceptions:
- Use 'nodetrees' instead of 'nodegroups'
since the struct is called NodeTree.
- Use 'gpencils' instead of 'grease_pencil'
since 'gpencil' is a common abbreviation in the C code.
Other exceptions:
- Leave 'wm' as it's a list of one.
- Leave 'ipo' as is for versioning.
Looks like something forgotten at some point, define in callback flags
was there, just not used at all.
Added most obvious cases now (we are probably still missing some), and
proper handling for it in remapping code (when we hit such case, we
'convert' new_id to NULL and go on with it).
Related (as in, exposed by) T62076, but not the actual cause of that bug.
Patch by @sergey.
Note that this is really a bad thing actually, ideally we should never
get that situation (IDs in Main referencing temp IDs outside of it).
That can lead to many possible similar cases...
Fixing that is not trivial though, so for now we'll have to live with
it, until we have migrated *all* of our temp datablocks generation
outside of Main's.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
BF-admins agree to remove header information that isn't useful,
to reduce noise.
- BEGIN/END license blocks
Developers should add non license comments as separate comment blocks.
No need for separator text.
- Contributors
This is often invalid, outdated or misleading
especially when splitting files.
It's more useful to git-blame to find out who has developed the code.
See P901 for script to perform these edits.
Main idea is to remove IDs to be deleted from Main, to avoid looping on
them to remove other deleted IDs usage (this is the most expensive
process in ID deletion, by far).
Speed improvements when deleting a large amount of IDs from a Main
containing a lot of them is quite significant, some examples for Objects:
* Removing 1k from 10k: 32% quicker (2.5s to 1.7s).
* Removing 10k from 20k: 60% quicker (59s to 23s).
* Removing 20k from 20k: 99.5% quicker (82s to 0.4s)!
Note however that this process is more risky/touchy, since we by-pass
some safety checks from regular ID removal here.
So will only give access to that code from python API for now (in
separate commit), so that it gets really tested. Also still need to
think about how to hook it up in UI (probably mostly for Outliner),
since we often do higher-level operations there...
Add 'missing' bpy code from BKE_libblock_free_ex(), now both functions
do exactly the same thing, only the later is less flexible (fewer
'exotic' behaviors supported, like handling IDs outside of bmain etc.).
Next step: nuke usages of BKE_libblock_free functions, makes no sense to
have twice the same code around!
The issue was caused by a special code in node tree freeing function
which will free extra fields in the case when tree is not in bmain.
This is how old code was dealing with "nested" trees, but is now
making behavior different from other datablocks. This is exactly
what was confusing copy-on-write logic.
Ideally, ntreeFreeTree() need to behave same as all other datablocks,
ad freeing of data of nested trees should be up to the owner of the
tree (this way it's all explicit and does not depend on check of
some special flag.
There were at least three copies of those:
- OB_RECALC* family of flags, which are rudiment of an old
dependency graph system.
- PSYS_RECALC* which were used by old dependency graph system
as a separate set since the graph itself did not handle
particle systems.
- DEG_TAG_* which was used to tag IDs.
Now there is a single set, which defines what can be tagged
and queried for an update. It also has some aggregate flags
to make queries simpler.
Lets once and for all solve the madness of those flags, stick
to a single set, which will not overlap with anything or require
any extra conversion.
Technically, shouldn't be measurable user difference, but some
of the agregate flags for few dependency graph components did
change.
Fixes T58632: Particle don't update rotation settings
