* 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
Callbacks: exec invoke & modal now use a typed enum wmOperatorStatus.
This helps avoid mistakes returning incompatible booleans or other
values which don't make sense for operators to return.
It also makes it more obvious functions in the WM API are intended
to be used to calculate return values for operator callbacks.
Operator enums have been moved into DNA_windowmanager_enums.h
so this can be used in other headers without loading other includes
indirectly.
No functional changes expected.
Ref !136227
This commit moves generated `RNA_blender.h`, `RNA_prototype.h` and
`RNA_blender_cpp.h` headers to become C++ header files.
It also removes the now useless `RNA_EXTERN_C` defines, and just
directly use the `extern` keyword. We do not need anymore `extern "C"`
declarations here.
Pull Request: https://projects.blender.org/blender/blender/pulls/124469
It looks like the "user edited flag propagation" node built for the geometry
nodes modifier is unchanged after modifiers are removed. My guess is this
is now a more general problem when modifiers are removed-- I guess the
depsgraph nodes for an object have to be rebuilt when that happens now.
Maybe there is a more general fix, but to fix the crash mentioned in the
report, I tagged the depsgraph for a relations update, which rebuilds the
problematic modifier node.
Pull Request: https://projects.blender.org/blender/blender/pulls/124252
The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
Move the public functions from the editors/object (`ED_object.hh`)
header to the `blender::ed::object` namespace, and move all of the
implementation files to the namespace too. This provides better code
completion, makes it easier to use other C++ code, removes unnecessary
redundancy and verbosity from local uses of public functions, and more
cleanly separates different modules.
See the diff in `ED_object.hh` for the main renaming changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/119947
The `object_to_world` and `world_to_object` matrices are set during
depsgraph evaluation, calculated from the object's animated location,
rotation, scale, parenting, and constraints. It's confusing and
unnecessary to store them with the original data in DNA.
This commit moves them to `ObjectRuntime` and moves the matrices to
use the C++ `float4x4` type, giving the potential for simplified code
using the C++ abstractions. The matrices are accessible with functions
on `Object` directly since they are used so commonly. Though for write
access, directly using the runtime struct is necessary.
The inverse `world_to_object` matrix is often calculated before it's
used, even though it's calculated as part of depsgraph evaluation.
Long term we might not want to store this in `ObjectRuntime` at all,
and just calculate it on demand. Or at least we should remove the
redundant calculations. That should be done separately though.
Pull Request: https://projects.blender.org/blender/blender/pulls/118210
This adds a new `ModifierData.persistent_uid` integer property with the following properties:
* It's unique within the object.
* Match between the original and evaluated object.
* Stable across Blender sessions.
* Stable across renames and reorderings of modifiers.
Potential use-cases:
* Everywhere where we currently use the name as identifier. For example,
`ModifierComputeContext` and `ModifierViewerPathElem`.
* Can be used as part of a key in `IDCacheKey` to support caches that stay
in-tact across undo steps.
* Can be stored in the `SpaceNode` to identify the modifier whose geometry node
tree is currently pinned (this could use the name currently, but that hasn't been
implemented yet).
This new identifier has some overlap with `ModifierData.session_uid`, but there
are some differences:
* `session_uid` is unique within the entire Blender session (except for duplicates
between the original and evaluated data blocks).
* `session_uid` is not stable across Blender sessions.
Especially due to the first difference, it's not immediately obvious that the new
`persistent_uid` can fulfill all use-cases of the existing `session_uid`. Nevertheless,
this seems likely and will be cleaned up separately.
Unfortunately, there is not a single place where modifiers are added to objects currently.
Therefore, there are quite a few places that need to ensure valid identifiers. I tried to catch
all the places, but it's hard to be sure. Therefore, I added an assert in `object_copy_data`
that checks if all identifiers are valid. This way, we should be notified relatively quickly if
issues are caused by invalid identifiers.
Pull Request: https://projects.blender.org/blender/blender/pulls/117347
The issues was a missing depsgraph tag after adding the hook modifier.
Because of this, the depsgraph did not make a new copy of the object,
which led to a discrepancy between the number of modifiers on the original
and evaluated object.
The term `looptri` was used ambiguously for both single & arrays.
The term `tri` was also used, causing `tri->tri`.
Use terms:
- `looptris` for an array or when dealing with multiple items.
- `looptri` is used when dealing with a single item.
- `lt` for a single MLoopTri variables & arguments.
This was already a convention but not followed closely.
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
This was noted in code comments and checked in Python documentation
generation but not at build time.
Since these enums are identifiers that end up included in various places
enforce the `rna_enum_*_items` convention which was noted as
the convention but not followed strictly.
Partially reverts [0], avoids having to deal with multiple prefix types.
[0]: 3ea7117ed1
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
This moves the following `editors/*` directories to C++:
- animation, armature, lattice, mesh, metaball, object, scene.
Much of the changes in this commit (inserting casts in particular)
was automated. Further changes like switching to functional style
casts can be done separately by existing automated scripts.
See #103343
Pull Request: https://projects.blender.org/blender/blender/pulls/109715
