This mainly adds DNA level IDProp storage for system properties, their
handling in data management code, and the forward-versioning code
copying back content from system properties into 'all-in-one' single
IDProperties storage, for data types that will support both in Blender
5.0.
There is no user-facing changes expected here.
Part of #123232.
Pull Request: https://projects.blender.org/blender/blender/pulls/139257
Note: This commit is essentially non-behavioral change, expect in some
fairly rare edge cases.
This commit does a few things:
* Move the whole BKE_main_namemap code to modern C++.
* Split API calls to work with the global namemap, or the local ones.
* Simplify and make the code easier to follow and understand.
* Reduce 'default' memory usage by using growing BitVector for numeric
suffix management, instead of a fixed 1K items.
* Fix inconsistent handling of 'same base name and numeric suffix,
different name' issues (e.g. 'Foo.1' and 'Foo.001'), see
`re_create_equivalent_numeric_suffixes` new unittest.
* Fix completely broken handling of `global` namemaps. This was
(probably!) OK so far because of their currently very limited
use-cases.
It also adds a few minor improvements to existing behavior (essentially
in exotic rare edge cases):
* Names that get too long are now only shortened by one char at a time,
trying to modify the requested base name as little as possible.
* Names that are short, but for which all the manageable numeric suffixes
are already in use, are extended with an (increasing) number, instead
of being shortened.
This work also allowed to detect a few (apparently harmless?) bugs in
existing code, which have been fixed already in 4.4 and main, or in this
commit as well when they depend on changes in namemap code itself.
About performances: This commit introduces a minor slow-down. Some tests
heavily relying on this code (like `bl_id_management` and `blendkernel`
e.g.) get slightly slower (resp. about 1% and 5%). This seems to come
mostly from the added complexity to handle correctly multiple different
names with the same base and numeric suffix value ('Foo.1' and
'Foo.001', but also in the global namemap context where IDs from
different libraries can have the same name).
Pull Request: https://projects.blender.org/blender/blender/pulls/135199
This replaces the `set_listbasepointers` function with `BKE_main_lists_get`
which returns an array of `ListBase *`. This simplifies the caller a bit. In
some cases, it can be simplifed further by changing the order in which we iterate
over the listbase. For historical reasons, we iterate from the back to front in
most cases but sometimes the order does not matter. I did keep the iteration order
in this patch though, to avoid regressions.
Pull Request: https://projects.blender.org/blender/blender/pulls/134242
Move the `ID_TAG_ID_LINK_PLACEHOLDER` bit of `id->tag` to
`id->runtime.readfile_data->tags.is_id_link_placeholder`. It also
introduces the necessary stucts and allocation/freeing code.
Old code:
```cpp
if (id_tag & ID_TAG_ID_LINK_PLACEHOLDER) {
```
New code:
```cpp
if (readfile_id_runtime_tags(id).is_id_link_placeholder) {
```
where `readfile_id_runtime_tags(id)` is a getter for
`id->runtime.readfile_data->tags` that is null-safe for
`id->runtime.readfile_data`. The `readfile_data` is not allocated in
these cases:
1. When reading undo steps, because that doesn't have to deal with
versioning or linking (which are the sole purposes for this
struct).
2. When linking from another file (for example from the 'Link...'
operator). The just-linked IDs will have the `readfile_data`
struct, but already-loaded IDs will already have had those freed.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/132169
Design Task: #131695
Deleting ID would systematically call `BKE_main_collection_sync_remap`,
which would invalidate all collection caches. This should only be needed
when deleting a Scene, Collection or Object ID.
Pull Request: https://projects.blender.org/blender/blender/pulls/127866
Previously, values for `ID.flag` and `ID.tag` used the prefixes `LIB_` and
`LIB_TAG` respectively. This was somewhat confusing because it's not really
related to libraries in general. This patch changes the prefix to `ID_FLAG_` and
`ID_TAG_`. This makes it more obvious what they correspond to, simplifying code.
Pull Request: https://projects.blender.org/blender/blender/pulls/125811
There is no reason to deal with layer collections resync in non-main
case, deletion code should never trigger it anyway.
This will avoid quite a lot of the non-main-thread calls to
`BKE_layer_collection_resync_forbid` (detected and 'fixed' in previous
commit).
So far, when deleting a library (either explicitely, or through e.g.
relocation), its dependencies would get a `nullptr` parent, and
therefore become 'directly used' libraries.
This commit adds a new util to rebuild the libraries hieararchy, and
calls it when a Library ID is deleted.
NOTE: While logic is somewhat similar to what liboverride resync does to
sort the libraries by indirect levels
(`lib_override_libraries_index_define`), there are some key differences
here, notably the fact that if a library has a valid `parent` pointer,
it is not replaced, even if a 'better' parent (less indirect library)
could be found.
This commit essentially:
* Remove the 'delete single ID' code path.
The multi-deletion code has now be around for a long while, so we
should be able to assume it is mature enough. It is also several times
faster when deleting a lot of IDs at once.
* Move away from using `LIB_TAG_DOIT` ID tag in internal code, using a
Set instead to store the IDs to be deleted.
Potential side-effects:
* The 'delete single ID' codepath (removed by this commit) was making
some dangerous assumptions regarding order of IDs in Main and 'strong'
dependencies between them. While these assumptions where presumably
correct in current code/data model context, they were logically wrong
and could have randomly cause bugs in the future.
* The sanitiing check on usercount performed in the case of the single
ID deletion cannot be done anymore. Should not be that usefull
anymore, as there are other places where IDs usercounts are validated.
* Performances:
* The batch-deletion did not show any significant difference in speed.
* Massively deleting IDs one by one however, showed a surprising 10%
speedup.
Pull Request: https://projects.blender.org/blender/blender/pulls/118283
Existing code would allow tagging on request IDs which had a 'never
null' usage potentially cleared by the remapping operation (e.g. if an
Object obdata would have been set to `nullptr`).
While this worked for the current extremely restricted usecase (ID
deletion), this was not the best design, as it forced the ID remapping
user code to be very careful about its own usages of the `LIB_TAG_DOIT`
tag.
This commit replaces internal tagging by adding such IDs to a Set in
`IDRemapper` class, which user code can then use to find which IDs
(would have) had a 'never null' ID pointer cleared.
There are two additional changes induced by this commit:
* `BKE_libblock_unlink` `do_flag_never_null` parameter is removed.
As it is not used in current codebase, simpler to remove than update
the code to support it.
* `ID_REMAP_FLAG_NEVER_NULL_USAGE` option is renamed to
`ID_REMAP_STORE_NEVER_NULL_USAGE`.
In addition, its behavior is slightly modified:
* Before, the owner ID would systematically be tagged if it had such
'never null' ID usages, regardless of whether said ID usages (would)
have actually been remapped to `nullptr`.
* Now, the owner ID is only added to the `never_null_users` set if its
'never null' usages (would) have been cleared.
The ID remapper code was already largely defined in a CPP struct
(IDRemapper). Make this an actual class, and remove the C API wrapper
around.
This makes the code cleaner, easier to follow, and easier to extend or
modify in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/118146
Along with the 4.1 libraries upgrade, we are bumping the clang-format
version from 8-12 to 17. This affects quite a few files.
If not already the case, you may consider pointing your IDE to the
clang-format binary bundled with the Blender precompiled libraries.
- Pass Span by value. It is a small struct, and passed by reference
it acts as a pointer to a pointer.
- Remove unnecessary `= {}`. Vector has a default constructor.
- Use initializer list Span constructor to avoid temporary array.
Pull Request: https://projects.blender.org/blender/blender/pulls/115635
Batch deletion of IDs could lead to deleting ObData ones while keeping
the related ShapeKeys.
Orphaned shape keys are not allowed anymore in Blender, they are checked
against in both file write and read code.
This would lead to assert (and crash) e.g. in the liboverride code.
This commit forcefully add shapekeys of deleted meshes, curves etc.,
when calling e.g. `BKE_id_multi_tagged_delete`.
Note that deleting the shapekey when deleting the obdata ID was already
implemented in single ID deletion (`BKE_id_delete` & co), in the
underlying private `id_free`. But this is skipped in `no main` case.
which is used by the batch deletion code for performance optimizations.
This is a nasty gathering of several issues, main one being that 'local
collections' of 3DViews are still updated immediately instead of the
deferred update used for all other viewlayer cases.
The change in a16bcb6576 led to internal references to the Scene's
master collection to become invalid, which is the expected behavior.
But this turns the Scene's view_layers into invalid state too.
Ideally, there should never be resync of viewlayers of a scene being
deleted anyways.
For now, take the (hopefully!) safe approach of explicitely forbidding
any viewlayer update during ID deletion process, and deferring it at the
end of the process.
Note that this change may also give some marginal gerformance
improvements in some rare edge cases (like deleting a very heavy scene
with many collections and 'local collection' 3DViews ?).
Listing the "Blender Foundation" as copyright holder implied the Blender
Foundation holds copyright to files which may include work from many
developers.
While keeping copyright on headers makes sense for isolated libraries,
Blender's own code may be refactored or moved between files in a way
that makes the per file copyright holders less meaningful.
Copyright references to the "Blender Foundation" have been replaced with
"Blender Authors", with the exception of `./extern/` since these this
contains libraries which are more isolated, any changed to license
headers there can be handled on a case-by-case basis.
Some directories in `./intern/` have also been excluded:
- `./intern/cycles/` it's own `AUTHORS` file is planned.
- `./intern/opensubdiv/`.
An "AUTHORS" file has been added, using the chromium projects authors
file as a template.
Design task: #110784
Ref !110783.
Also see #103343.
Couldn't move two files yet:
* `softbody.c`: The corresponding regression test fails. It seems like the
conversion to C++ changes floating point accuracy, but it's not clear where that happens exactly.
* `writeffmpeg.c`: Is a bit more complex to convert because of the static array in `av_err2str`.
Pull Request: https://projects.blender.org/blender/blender/pulls/110182
