This commit adds to ID struct a new optional 'weak reference' to a
linked ID (in the form of a blend file library path and full ID name).
This can then be used on next append to try to find a matching local ID
instead of re-making the linked data local again.
Ref. T90545
NOTE: ID re-use will be disabled for regular append for the time being
(3.0 release), and only used for assets. Therefore, this commit should
not change anything user-wise.
Differential Revision: https://developer.blender.org/D12545
ID data-blocks that could be accessed from Python and weren't freed
using BKE_id_free_ex did not release the Python reference count.
Add BKE_libblock_free_data_py function to clear the Python reference
in this case.
Add asserts to ensure no Python reference is held in situations
when ID's are copied for internal use (not exposed through the RNA API),
to ensure these kinds of leaks don't go by unnoticed again.
Code would end up freeing some of the newly created overrides, which
were assigned to the matching linked ID's `newid` pointer, accessed
again further down the code.
Note that this is not a normal expected situation, and it won't give a
proper resync result anyway, but it might happen in some complicated
corner cases, and also quite often when dealing with older .blend files.
The `MAX_LIBARRAY` define was an annoying doublon to the `INDEX_ID_MAX` enum value
now defined in `DNA_ID.h`, and it is no more useful.
And comments were somewhat outdated. Also added an explanation about
chosen order for the `INDEX_ID_<IDTYPE>` order.
This was rather obscure and non-critical issue, but in some cases ID
usercount of some deleted IDs from batch-deletion code would not be
properly nullified, which would then assert later in actual deletion
code.
Sometimes multiple calls to `bpy.data.orphans_purge()` are needed to
delete all orphans, because a call can turn previously-used datablocks
into orphans. Returning the number of deleted datablocks makes it
possible to keep looping until nothing can be deleted any more.
This patch keeps track of deletions in `id_delete()` so that it can be
returned up the call stack.
Reviewed By: mont29
Differential Revision: https://developer.blender.org/D9918
Asset metadata is what turns a regular data-block into an asset. It is a small
data-structure, but a key part of the technical design of the asset system.
The design foresees that asset data-blocks store an `ID.asset_data` pointer of
type `AssetMetaData`. This data **must not** have dependencies on other
data-blocks or data-block data, it must be an independent unit. That way we can
read asset-metadata from .blends without reading anything else from the file.
The Asset Browser will use this metadata (together with the data-block name,
preview and file path) to represent assets in the file list.
Includes:
* New `ID.asset_data` for asset metadata.
* Asset tags, description and custom properties.
* BKE code to manage asset meta-data and asset tags.
* Code to read asset data from files, without reading IDs.
* RNA for asset metadata (including tags)
Part of the first Asset Browser milestone. Check the #asset_browser_milestone_1
project milestone on developer.blender.org.
Differential Revision: https://developer.blender.org/D9716
Reviewed by: Bastien Montagne, Brecht Van Lommel
This reverts commit 2ddecfffc3.
The correct fix is to compile with -fno-strict-aliasing on
release/relwithdebinfo builds also.
See the last commit/ {D9372}.
Maniphest Task T81077
This looks like a optimizer bug where it makes wrong assumptions.
The code inside lib_id_delete:264 on rBafd13710b897cc1c11b
`for (id = last_remapped_id->next; id; id = id->next) {..}`
is not executed in release/relwithdebinfo builds.
This can be "fixed" by several ways:
- Adding a line that prints the `last_remapped_id->name` right before
the said for-loop starts.
- Turning off optimization for the whole function `id_delete`:
`#pragma clang optimize off/on` Ray Molenkamp
- Marking `last_remapped_id` volatile. Julian Eisel
- Marking `tagged_deleted_ids` volatile. But it adds a warning when
calling `BLI_addtail`: discards volatile qualifier. Discovered by
accident.
Fix T81077
Reviewed By: mont29
Maniphest Tasks: T81077
Differential Revision: https://developer.blender.org/D9315
Trying to get shape key pointer after having unlinked its owner from
Main data-base is rather useless... So those shapekeys ended up never
being deleted.
Consistency with e.g. copying (copying a mesh also duplicates its
shapekey typically).
Baby step towards getting rid of this horrible ID, some day...
Note that for now we only do that when taking BMain into account, fancy
code dealing with non-main IDs and such has to deal with those itself.
This removes grease pencil brush creation/dat-block delete on load,
since this causes duplicate data-blocks.
Add assert to prevent this happening in the future
since the error is isn't obvious.
The `BKE_animsys.h` and `anim_sys.c` files already had a an "AnimData
API" section. The code in that section has now been split off, and
placed into `BKE_anim_data.h` and `anim_data.c`.
All files that used to include `BKE_animsys.h` have been adjusted to
only include the animation headers they need (sometimes none).
No functional changes.
This has been long standing TODO...
Note that remaining usages of BKE_xxx_delete should all be carefully
checked for and utilmately nuked in favor of `BKE_id_delete()`, think we
still have quiet a few bugs hidden in those (code seems to usually
assume those functions do a full ID deletion, which is not the case).
Only covers direct usages of new callbacks from IDTypeInfo.
We still have a lot of those switch/case, many can probably go away
with minimal refactor now, but that will be for later.
This was particularly strange because we had a _free_data() function.
But still the one I replaced was of course the _free() one.
And we should rename the _free_data_ function later to avoid confusions.
