Add new `BKE_id_is_editable` helper in `BKE_lib_id.h`, that supercedes
previous check (simple `ID_IS_LINKED()` macro) for many editing cases.
This allows to also take into account 'system override' (aka
non-editable override) case.
Ref: {T95707}.
This patch increases the performance when remapping data.
{D13615} introduced a mechanism to remap multiple items in a single go.
This patch uses the same mechanism when remapping data inside ID datablocks.
Benchmark results when loading the village scene of sprite fright on AMD Ryzen 7 3800X 8-Core Processor
Before this patch 115 seconds
When patch applied less than 43 seconds
There is still some room for improvement by porting relink code.
Reviewed By: mont29
Maniphest Tasks: T95279
Differential Revision: https://developer.blender.org/D14043
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Part of T91671.
Not much else to say, this is mainly a massive deletion of code.
Note that a few cleanups possible after this proxy removal were kept out
of this commit to try to reduce a bit its size.
Reviewed By: sergey, brecht
Maniphest Tasks: T91671
Differential Revision: https://developer.blender.org/D13995
Some IDs (like text ones) can be linked and only kept around thanks to
editors, allow making such IDs local in `BKE_lib_id_make_local_generic`.
Also refactor logic checking whether ID should be made directly local or
copied into its own util function, so that we can remain sure all
special-cases 'make local' code still uses the same logic here.
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
Since our design is to always keep data-blocks marked as assets on exit,
and our technical design for this is to do this via fake users, ensure
the fake user is set for an appended asset.
Reviewed by: Bastien Montagne
Differential Revision: https://developer.blender.org/D13443
The main goal of this refactor is to make BPath module use `IDTypeInfo`,
and move each ID-specific part of the `foreach_path` looper into their
own IDTypeInfo struct, using a new `foreach_path` callback.
Additionally, following improvements/cleanups are included:
* Attempt to get better, more consistent namings.
** In particular, move from `path_visitor` to more standard `foreach_path`.
* Update and extend documentation.
** API doc was moved to header, according to recent discussions on this
topic.
* Remove `BKE_bpath_relocate_visitor` from API, this is specific
callback that belongs in `lib_id.c` user code.
NOTE: This commit is expected to be 100% non-behavioral-change. This
implies that several potential further changes were only noted as
comments (like using a more generic solution for
`lib_id_library_local_paths`, addressing inconsistencies like path of
packed libraries always being skipped, regardless of the
`BKE_BPATH_FOREACH_PATH_SKIP_PACKED` `eBPathForeachFlag` flag value,
etc.).
NOTE: basic unittests were added to master already in
rBdcc500e5a265093bc9cc.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13381
Two issues addressed here:
I) `asset_type_info` is sub-data, not a callback. Therefore, move it
before the callbacks in the `IDTypeInfo` struct.
II) More important, initialize this new attribute in *ALL* `IDTypeInfo`
instances. No member of this struct should ever be left implicitely
uninitilazed, ever.
Aftermath of rBa84f1c02d251.
During animation playback, data-blocks are reallocated, so storing
pointers to the resulting data is not okay. Instead, the data should
be retrieved from the context. This works when the applied search
item is the "dummy" item added for non-matches. However, it still
crashes for every other item, because the memory is owned by the
modifier value log, which has been freed by the time the exec function
runs.
The next part of the solution is to allow uiSearchItems
to own memory for the search items.
This is mainly for doversion code, when it needs to create new IDs those
should be considered as part of the same library as the current Main's
one.
No practical changes are expected here, this is more of a general
consistency fix, and a pre-requisite for {T92333}.
When appending an asset from the asset browser, its asset data needs to
be cleared.
However, linking an asset (or regular append from the file browser)
should not clear such data. In linking case, it would be there again
after a blend file reload anyway.
So this commit introduces a new `BLO_LIBLINK_APPEND_ASSET_DATA_CLEAR`
option.
NOTE: in case the appended ID needs to be copied from its linked data
(instead of making the later directly local), asset data is lost anyway
since it is never copied with the ID currently.
Ref. {T91749} and D11768.
This commit removes the implicit conversion from points to a mesh
that used to happen before the next modifier. It also removes the
implicit realizing of instances that happened before another modifier.
Now we have specific nodes for both of these operations, the
implicit conversions make less sense, and implicit instance
realizing has already been removed in other nodes.
This adds another geometry nodes modifier before modifiers that would
have realized instances implicitly before. Currently adding another
data-block during versioning after linking means that an assert needs
to be changed. That should be made unnecessary by T92333.
Differential Revision: https://developer.blender.org/D12722
Handling of RigidBody data in duplicate of scenes/collections was very
wrong. This commit:
- Add handling of duplication of RB collections when fully duplicating
a scene.
- Fix Object duplication trying to add duplicated RB objects to
matching RBW collections.
While the later behavior is desired when only duplicated objects, when
duplicating their collections and/or scenes it is actually very bad, as
it would add back new object duplicates to old (RBW) collections.
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
Mixing testing and actual action in a single function is just not a good
way to do things, and the 'testing' feature is not used anywhere
anymore, time to get rid of it.
This flag became a full duplicate of `IDTYPE_FLAGS_NO_LIBLINKING`, which
is a good thing (don't think we ever want to be able to link some data,
without being able to make it local...).
So we can now remove it and use `IDTYPE_FLAGS_NO_LIBLINKING` instead.
rB8cc3d2d6f51f introduced option to force make_local code to either copy
or actually make a linked ID local, but logic of boolean options
handling was broken.
This commit simplifies logic here and fixes the issue.
NOTE: Since those new options were not used yet this was a harmless bug.
This is to be used when calling code already knows whether the 'made
local' linked ID should be copied, or can directly be converted to a
local one.
Currently unused , this is preparation for rewrite of append code.
Even though the ID itself remain the same after being made local, from
depsgraph point of view this is a different ID. Hence we need to tag all
of its users for COW update, as well as rebuild depsgraph relationships.
Should be also backported to LTS 2.93 (and 2.83 if possible).
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 patch fixes many minor spelling mistakes, all in comments or
console output. Mostly contractions like can't, won't, don't, its/it's,
etc.
Differential Revision: https://developer.blender.org/D11663
Reviewed by Harley Acheson
This function would considere that there was a name conflict even in
case existing ID would be a linked one.
This is only a (symbolic) perforance improvement and logical fix, since
`BKE_id_new_name_validate` would not do that mistake anyway.
This is mandatory for liboverride resync, since this feature may imply
we have to create linked overrides in libraries, and there may be
several copies of those.
This is also a first step to a more general support of IDmanagement-editing
library data.
Note that this commit should have absolutely no effect on current code,
as the only function allowed to check unique names for linked IDs
currently is `BKE_libblock_management_main_add`, which is unused.
This commit also adds some basic testing for `BKE_id_new_name_validate`.
While this is still very fuzzy in current code, this old behavior makes
it close to impossible to efficiently use out-of-main temp data, as it
implies that we'd need to update refcounts everytime we add something
back into BMain (an 'un-refcount' ID usages when removing from BMain).
Now that we have two separate flags/tags for those two different things,
let's not merge them anymore.
Note that this is somewhat on-going process, still needs more checks and
cleanup. Related to T88555.
While this function should (currently) not be called on linked ID, there
is no reason to treat those differently than local IDs, for the part
that they have in common: needs to be properly sorted.
`id_sort_by_name` would simply not deal properly with linked IDs, could
lead to mixing IDs from different libraries, and unsorted IDs within the
same library.
Copying an ID outside of BMain should not assume that the datablocks it
uses are now directly linked. This would be wrong e.g. in case that new
no-main ID is copied from a linked data-block and is supposed to remain
a linked data.
Resolve ownership ambiguity with shared physics pointers.
Previously, LIB_ID_CREATE_NO_MAIN allowed pointer sharing with
the source ID so physics caches can be shared between original and
evaluated data: (Object.soft.shared & Object.rigidbody_object.shared).
This only worked properly for LIB_TAG_COPIED_ON_WRITE ID's,
as LIB_TAG_NO_MAIN can be used in situations where the original ID's
lifetime limited by it's original data.
This commit adds `LIB_ID_COPY_SET_COPIED_ON_WRITE` so ID's only share
memory with original data for ID's evaluated in the depsgraph.
For all other uses, a full copy of physics data is made.
Ref D11228#287094
