This will be needed in undo/redo case, since we do not re-read linked
IDs, their usercounts become total garbage (especially in 'used by local
ID' cases)...
No local work copy is expected to need preview data, at least it should
not. Part of copy flags cleanup, done in separate commit in case
something goes wrong here...
Those two first sets of flags should represent some common use cases.
The goal here is to reduce verbosity of calls to BKE_id_copy_ex, and
help make it more obvious the 'common behaviours' of ID copying across
codebase.
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...
This is a second attempt to get the crash fixed. The original fix
worked, but it was reverted by d3e0d7f082.
Now the logic goes as:
- All pointers which we can not have shared (the ones which are
owned by the runtime) are cleared.
- The rest of runtime stays untouched.
This seems to be enough to keep particles happy.
All localized datablocks are not supposed to have animation
data associated with them.
There was an easy way to reproduce assert failure: toggle
animation decorator for Viewport Display -> Color.
We already had a BKE_main.h header, no reason not to put there
Main-specific functions, BKE_library has already more than enough to
handle with IDs and library management!
Also reshuffle a bit that whole code, did some renaming,
`BKE_id_to_unique_string_key()` is now using same base code (instead of
using whole library filepath...), etc.
Basically just concatenates ID's name (including its IDtype code) and
that library's name, if any. This must give unique string in a given
Main database, suitable for GHash keys e.g.
This helps making things clearer and cleaner. Func returning filepath of
G.main is separate, so that we can easily track its usages, and
hopefully deprecate it at some point. Though that usage of G.main is
likely the less evil one, you nearly always want current blendfile path
in those cases anyway.
Those should be used in priority when you need to create either a new
datablock in Main, or a new temp one. Lower level BKE_libblock_...
should only be used when you need a very specific, uncommon behavior.
The workaround removal was wrong, the whole id->adt of a local
copy is to be NULL.
But now instead of modifying original datablock, we tell library
manager to not copy animation data.
