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
Check if either the memory is zero or already matches the default value,
and copy. This simplifies a common pattern to a single line.
Preparing for default initializers in DNA (#134531).
Pull Request: https://projects.blender.org/blender/blender/pulls/138830
It's not common for object data to reference it's object type
so name the struct member to make this clear.
Also remove BKE_curve_type_get which is no longer needed.
- Make Curve::type the source of truth for the curve type,
instead of Curve::vfont, since it's possible for this to be
set to null from RNA which effectively changed it's type.
See #138730.
- Update objects to match the curve type on file read.
Without this, an object may link to a curve in another file which
can be replaced by a curve data-block of a different type.
Note that updating the object type was already being done
when reloading library data and setting object data,
just not on file load.
Ref !139137
This adds a version of `BKE_id_new_nomain` that takes the ID type parameter as
template argument. This allows the function the return the newly created ID with
the correct type, removing the need to use `static_cast` on the call-site.
To make this work, I added a static `id_type` member to every ID struct. This
can also be used to create a similar API for other id management functions in
future patches.
```cpp
// Old
Mesh *mesh = static_cast<Mesh *>(BKE_id_new_nomain(ID_ME, "Mesh"));
// New
Mesh *mesh = BKE_id_new_nomain<Mesh>("Mesh");
```
Pull Request: https://projects.blender.org/blender/blender/pulls/138383
* 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
Caused by 06f6d77979.
Legacy curve objects have not taken the radius into account in the
past. Better to stick with that behavior and only affect the new
curve object type. This only affects non-instanced legacy curve
objects; generally generated curves are presented to the depsgraph
iterator as the new object type.
Pull Request: https://projects.blender.org/blender/blender/pulls/137852
It's safer to pass a type so that it can be checked if delete should be
used instead. Also changes a few void pointer casts to const_cast so that
if the data becomes typed it's an error.
Pull Request: https://projects.blender.org/blender/blender/pulls/137404
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
When using vertex parenting, an option for using the parent object
final evaluated indices is exposed in the Object Properties: Relations
panel. This allows the calculation of the parent vertex position to
ignore the the CD_ORIGINDEX layer and instead use the final indices
that may have been altered by the node tree evaluation.
The indices that will be used for the vertex parenting are also exposed
to the UI in the same panel, allowing them to be altered after the
vertex parent has been created.
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
The general idea is to keep the 'old', C-style MEM_callocN signature, and slowly
replace most of its usages with the new, C++-style type-safer template version.
* `MEM_cnew<T>` allocation version is renamed to `MEM_callocN<T>`.
* `MEM_cnew_array<T>` allocation version is renamed to `MEM_calloc_arrayN<T>`.
* `MEM_cnew<T>` duplicate version is renamed to `MEM_dupallocN<T>`.
Similar templates type-safe version of `MEM_mallocN` will be added soon
as well.
Following discussions in !134452.
NOTE: For now static type checking in `MEM_callocN` and related are slightly
different for Windows MSVC. This compiler seems to consider structs using the
`DNA_DEFINE_CXX_METHODS` macro as non-trivial (likely because their default
copy constructors are deleted). So using checks on trivially
constructible/destructible instead on this compiler/system.
Pull Request: https://projects.blender.org/blender/blender/pulls/134771
This applies to modifiers, constraints and shape keys.
Any driver on such data was not removed with it,
leaving invalid drivers on objects.
With this patch, the drivers are removed, but animation is left untouched.
This is because animation might be reused somewhere else and we don't
want to introduce potential side effects there.
This also adds unit tests for the fixed cases
Pull Request: https://projects.blender.org/blender/blender/pulls/134511
Remove GP legacy obtype and unused functions
Few hidden bugs are fixed with that:
- Outliner drag-drop for GP material/effect elements now works
- Correct stats are shown in status bar.
Pull Request: https://projects.blender.org/blender/blender/pulls/133957
Previously we generally expected CustomData layers to have implicit
sharing info, but we didn't require it. This PR clarifies that we do
require layers with non-null data to have implicit sharing info. This
generally makes code simpler because we don't have to have a separate
code path for non-shared layers. For example, it makes the "totelem"
arguments for layer freeing functions unnecessary, since shared data
knows how to free itself. Those arguments are removed in this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134578
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
Reason is that `BKE_camera_view_frame_fit_to_scene` cannot handle grease
pencil data [it used to, that was once added in 80d0b68290 but lost in
the switch to GPv3 (see 5c57e24fea)].
So to resolve, add back support for grease pencil in
`BKE_camera_view_frame_fit_to_scene` which is similar to what we do for
getting the bounding box.
Pull Request: https://projects.blender.org/blender/blender/pulls/132733
The type check there should not be necessary anymore nowadays. It looks like it
might have been necessary when it was introduced in
eed45d2a23. Back then the object was still passed
into `BKE_mesh_wrapper_ensure_subdivision`.
Pull Request: https://projects.blender.org/blender/blender/pulls/131857
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
These are converted on startup to the new type. There are still
some references left, mostly where it looked like there still needs
to be changes to properly deal with the new object type.
The "is edit mode" checks in the draw module have been simplified
to just check the object mode. We need to be a bit more careful to
avoid retrieving the original mesh from a non-mesh object.
This commit improves the "get pre-modified mesh" function with
better comments and checks that reflect the relatively recent cases
where the original and evaluated geometry data types don't match.
It's always called with a mesh object too.
Pull Request: https://projects.blender.org/blender/blender/pulls/130850
Currently replacing the Mesh during evaluation with the object info node
can cause us to use invalid original indices when the source object is
in edit mode. This is really a more fundamental problem though: we have
no way to tell whether an evaluated mesh actually corresponds to the
object's original mesh.
This commit changes to explicitly propagating the edit mesh pointer
through copied and changed meshes during modifier and nodes evaluation,
instead of just blindly copying the edit mode pointer from the original
mesh to the evaluated mesh. A benefit of not writing to the evaluated
mesh means it can be shared, potentially offering a future performance
improvement for uses of the object info node.
When we detect an invalid correspondence between the evaluated/original
meshes, we skip extracting the cage mesh's data and skip extracting edit
mesh data from the evaluated object.
This commit also moves the source of "object is in edit mode" truth in
the draw module from whether the evaluated mesh has an edit mode pointer
to the object's mode flag. That's a simplification that's also helpful
to reduce the strong linking between BMesh and edit mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/120999
Since all legacy Grease Pencil modifier are converted to regular modifiers
in versioning, we should never be in a position where we need to write the
old modifiers anymore.
Pull Request: https://projects.blender.org/blender/blender/pulls/130388
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
This was added 7 years ago as 'safe' preservation of previous behavior,
when ID copying was refactored and more control was added over its
behavior.
However, it was never removed since then, even though `NO_PREVIEW` flag
has been part of the `LOCALIZE` copying behavior since many years.
So time to remove this enforced bahevior and use the API as designed. If
this causes new issues, they will have to be fixed in code calling the
ID copy API (most likely by simply adding the `NO_PREVIEW` flag to the
copy options).
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.
