* Remove `DEG_get_evaluated_object` in favor of `DEG_get_evaluated`.
* Remove `DEG_is_original_object` in favor of `DEG_is_original`.
* Remove `DEG_is_evaluated_object` in favor of `DEG_is_evaluated`.
Pull Request: https://projects.blender.org/blender/blender/pulls/138317
Previously spell checker ignored text in single quotes however this
meant incorrect spelling was ignored in text where it shouldn't have
been.
In cases single quotes were used for literal strings
(such as variables, code & compiler flags),
replace these with back-ticks.
In cases they were used for UI labels,
replace these with double quotes.
In cases they were used to reference symbols,
replace them with doxygens symbol link syntax (leading hash).
Apply some spelling corrections & tweaks (for check_spelling_* targets).
The goal here is to avoid having to cast to and from `ID` when getting the
evaluated or original ID using the depsgraph API, which is often verbose and not
type safe. To solve this, there are now `DEG_get_original` and
`DEG_get_evaluated` methods which are templated on the type and use a new
`is_ID_v` static type check to make sure it's only used with valid types.
This allows removing quite some verbosity on all the call sites. I also removed
`DEG_get_original_object`, because that does not have to be a special case
anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/137629
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/136134
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 `Library.runtime` to be a pointer, move the related
`LibraryRuntime` struct to `BKE_library.hh`. Similar to e.g.
Mesh.runtime, that pointer is expected to always be valid, and is
allocated at readtime or when creating a new Library ID.
Related smaller changes:
* Write code now uses standard ID writing codepath for Library IDs too.
* Runtime pointer is reset to nullptr before writing.
* Looking up a library by its absolute path is now handled through a
dedicated utils, `search_filepath_abs`, instead of using
`BLI_findstring`.
Pull Request: https://projects.blender.org/blender/blender/pulls/134188
Previously, the owner-id on localized node trees, like the one created in
`GPU_material_from_nodetree` would have `bNodeTree::owner_id` set, even though
they were independent. The leads to asserts when using `BKE_id_owner_get` on the
localized node tree.
The `node_tree_localize` already took a `ID *new_owner_id` parameter. However,
if it was `nullptr` it was ignored instead actually clearing the `owner_id`.
This patch changes the parameter to `std::optional<ID *> new_owner_id`. Now,
`std::nullopt` means that the value is ignored and when `nullptr` is passed in,
the `owner_id` will be cleared on the localized tree.
Since `node_tree_localize` indirectly uses other functions, the same function
signature change is done in `BKE_libblock_copy_in_lib` and `BKE_id_copy_in_lib`.
The callers have been updated to pass in `nullopt` instead of `nullptr`.
Pull Request: https://projects.blender.org/blender/blender/pulls/133002
Action Slots point to the IDs they animate, and after swapping IDs they
also need some swappage (as the Action that first animated `id_a` will
now animate `id_b`, and vice versa).
Instead of doing this in the `id_swap()` function (and requiring
knowledge of how that's supposed to be done), just mark these pointers
as dirty so that they're rebuilt at first use.
This commit contains a little more code than strictly necessary, to add
a function in BKE for this cache invalidation. This avoids having to
have a dependency on the animrig module just for this purpose.
Fixes: #130136
Pull Request: https://projects.blender.org/blender/blender/pulls/131809
Mistake in 5f9f3116db, ID name needs to be removed from the runtime ID
name cache data _before_ its library pointer is modified.
Library is an important part of an ID 'namesapce', so trying to remove
it after its library has been changed is trying to remove it from the
wrong namespace, leaving it in the original one.
Pull Request: https://projects.blender.org/blender/blender/pulls/132080
Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
Now that another ID can be renamed (again), it also needs to be properly
tagged as needing resync in the depsgraph too.
This commit:
* Moves/add depsgraph tagging to `BKE_id_rename`.
* Moves the WM notifier creation to `ED_id_rename`.
Pull Request: https://projects.blender.org/blender/blender/pulls/130596
* Early return in case the given `id` is already in the same library as
its target `owner_id` (in addition to both being local data).
* Assert with message AND return in case the given `id` is a linked ID
from a different library.
The second point somewhat mitigates the severity of #130194.
For C/C++ doc-strings should be located in headers,
move function comments into the headers, in some cases merging
with existing doc-strings, in other cases, moving implementation
notes into the function body.
This commit adds low-level logic in BKE to support three behaviors in
case of name conflict when renaming an ID:
1. Always tweak new name of the renamed ID (never modify the other ID
name).
2. Always set requested name in renamed ID, modifying as needed the
other ID name.
3. Only modify the other ID name if it shares the same root name with the
current renamed ID's name.
It also adds quite some changes to IDTemplate, Outliner code, and
RNA-defined UILayout code, and the lower-level UI button API, to allow
for the new behavior defined in the design (i.e. option three from above list).
When renaming from the UI either 'fails' (falls back to adjusted name) or forces
renaming another ID, an INFO report is displayed.
This commit also fixes several issues in existing code, especially
regarding undo handling in rename operations (which could lead to saving
the wrong name in undo step, and/or over-generating undo steps).
API wise, the bahavior when directly assigning a name to the `ID.name`
property remains unchanged (option one from the list above). But a new
API call `ID.rename` has been added, which offers all three behaviors.
Unittests were added to cover the new implemented behaviors (both at
BKE level, and the RNA/Py API).
This commit implements #119139 design.
Pull Request: https://projects.blender.org/blender/blender/pulls/126996
This adds a new `BKE_id_name` function. It should be used in places where we
currently do something like `id.name + 2`.
This patch just adds the function and uses them in a small subset of possible
cases. Given that there are >700 cases that need to be replaced, I'd rather to
that in chunks instead of all at once.
Pull Request: https://projects.blender.org/blender/blender/pulls/127410
std::sort() requires a strict weak ordering, i.e. `x < x` must be false. Therefore `id_order_compare(ID *a, ID *b)` must return false for `a.name == b.name`
Pull Request: https://projects.blender.org/blender/blender/pulls/127794
BKE_id_copy_in_lib took an argument `r_newid` which was was to
initialize `new_id` in the functions body.
While this may not have caused any user visible bugs, it's error prone,
one caller even passed in an uninitialized pointer.
- Rename `r_newid` to `new_id_p` since it's not a return argument.
- Initialize the value from all callers.
Use snake style naming for all the kernel nodes functions.
Omit kernel prefix in the names since of the using namespace.
Use full forms of the terms
('iter' -> 'iterator', 'ntree' -> 'node_tree', 'rem' -> 'remove', ...).
Pull Request: https://projects.blender.org/blender/blender/pulls/126416
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
Match function and declaration names, picking names based on
consistency with related code & clarity.
Also changes for old conventions, missed in previous cleanups:
- name -> filepath
- tname -> newname
- maxlen -> maxncpy
The new `LIB_ID_MAKELOCAL_INDIRECT` option will force indirectly linked
data to also be made local. Note that this was already the case when a
whole library was made local.
Also some cleanup of options for 'make local', and pass
`IDWALK_IGNORE_MISSING_OWNER_ID` to the ID copying code for ID
management, since typically the owner pointer of embedded IDs at that
point is not yet set to its valid value.
There is no behavioral changes expected from this commit (even though
technically it does affect existing ID copying's behavior, there should
be no change in practice).
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
When copying a local ID into a library, or a linked ID into a different
library, the 'linked' tags would not be properly preserved or set, and
the relative file paths would not be properly remapped.
These issues were not currently exposed (no existing code could trigger
them), but some of these fixes are needed for upcoming refactor of the
partial write code.
NOTE: not very happy with the split in library handling between
`BKE_id_copy_in_lib` and `BKE_libblock_copy_in_lib`, this will have to
be solved at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/123247
Fixes#107880.
When making a linked asset local, you typically wouldn't want this new
data-block to suddenly be part of the asset libraries this file is in. To the
user it seems like making such a data-block local also implicitly makes it an
asset. Appending an asset already handles this, and clears the asset data by
default.
This patch modifies the `bpy.types.ID.make_local()` method, as well as all
internal calls to the make local functions, so that asset data is cleared by
default. The Python method has a new `clear_asset_data` parameter (optional,
true by default). Maybe this should not be optional.
Pull Request: https://projects.blender.org/blender/blender/pulls/110197
For the brush assets, this mechanism makes brush, texture, node tree and
image datablocks editable even when library linked.
This commit should introduce no functional change yet, as the code to
actually tag such libraries as editable will come later.
* These libraries and their datablocks are preserved when loading a new
blend file, much like the UI can be preserved.
* Operators that create new datablocks to be assigned to such datablocks
will put the datablocks in the same library immediately. This was
implemented for datablocks relevant for brush assets.
* RNA does not allow assignment of pointers from such linked datablocks
to local datablocks.
Co-authored-by: Bastien Montagne <bastien@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121920
* Linked datablocks should not point to local datablocks.
* Main datablocks should not point to non-main datablocks.
This is checked now both in the poll function for UI lists, and in the
pointer assignment code used by the Python API.
Add new ID_IS_EDITABLE macro that checks if the ID can be edited in the
user interface. Replace usage of ID_IS_LINKED where it is used with this
meaning.
Also add a corresponding ID.is_editable property for Python.
This prepares for the ability to edit some linked datablocks for brush
assets.
Pull Request: https://projects.blender.org/blender/blender/pulls/121838
Move all header file into namespace.
Unnecessary namespaces was removed from implementations file.
Part of forward declarations in header was moved in the top part
of file just to do not have a lot of separate namespaces.
Pull Request: https://projects.blender.org/blender/blender/pulls/121637
This allows node groups to have a description that is shown in the add menu
or when hovering over the node header.
This new description is stored in `bNodeTree.description`. Unfortunately, it
conflicts a bit with `ID.asset_data.description`. The difference is that the latter
only exists for assets. However, it makes sense for node groups to have
descriptions even if they are not assets (just like `static` functions in C++ should
also be able to have comments). In some cases, node groups are also generated
by addons for a specific purpose. Those should still have a description without
being reusable to make it easier to understand for users.
The solution here is to use the asset description if the node group is an asset,
and to use `bNodeTree.description` otherwise. The description is synced
automatically when marking or clearing assets.
A side benefit of this solution is that appended node group assets can keep their
description, which is currently always lost.
Pull Request: https://projects.blender.org/blender/blender/pulls/121334
