Struct members loc/size were misleading as they read as if the object
data stored object level transform channels. Rename these to match RNA
with a `texspace_*` prefix to make it clear these struct members only
apply to texture-space transform.
Also rename ME_AUTOSPACE & ME_AUTOSPACE_EVALUATED to
ME_TEXSPACE_FLAG_AUTO & ME_TEXSPACE_FLAG_AUTO_EVALUATED.
Use a consistent style for declaring the names of struct members
in their declarations. Note that this convention was already used in
many places but not everywhere.
Remove spaces around the text (matching commented arguments) with
the advantage that the the spell checking utility skips these terms.
Making it possible to extract & validate these comments automatically.
Also use struct names for `bAnimChannelType` & `bConstraintTypeInfo`
which were using brief descriptions.
Effectively this disables two volume modifiers for the new curves
object and the point cloud object types. The aim is to simplify the
process of using these object types to prove out a node-group-based
workflow integrated with the asset browser. We're making the assumption
that these two modifiers were used very rarely on the new curves type
since that wasn't its purpose, so this breaks backwards compatibility.
**Changes**
As described in T93602, this patch removes all use of the `MVert`
struct, replacing it with a generic named attribute with the name
`"position"`, consistent with other geometry types.
Variable names have been changed from `verts` to `positions`, to align
with the attribute name and the more generic design (positions are not
vertices, they are just an attribute stored on the point domain).
This change is made possible by previous commits that moved all other
data out of `MVert` to runtime data or other generic attributes. What
remains is mostly a simple type change. Though, the type still shows up
859 times, so the patch is quite large.
One compromise is that now `CD_MASK_BAREMESH` now contains
`CD_PROP_FLOAT3`. With the general move towards generic attributes
over custom data types, we are removing use of these type masks anyway.
**Benefits**
The most obvious benefit is reduced memory usage and the benefits
that brings in memory-bound situations. `float3` is only 3 bytes, in
comparison to `MVert` which was 4. When there are millions of vertices
this starts to matter more.
The other benefits come from using a more generic type. Instead of
writing algorithms specifically for `MVert`, code can just use arrays
of vectors. This will allow eliminating many temporary arrays or
wrappers used to extract positions.
Many possible improvements aren't implemented in this patch, though
I did switch simplify or remove the process of creating temporary
position arrays in a few places.
The design clarity that "positions are just another attribute" brings
allows removing explicit copying of vertices in some procedural
operations-- they are just processed like most other attributes.
**Performance**
This touches so many areas that it's hard to benchmark exhaustively,
but I observed some areas as examples.
* The mesh line node with 4 million count was 1.5x (8ms to 12ms) faster.
* The Spring splash screen went from ~4.3 to ~4.5 fps.
* The subdivision surface modifier/node was slightly faster
RNA access through Python may be slightly slower, since now we need
a name lookup instead of just a custom data type lookup for each index.
**Future Improvements**
* Remove uses of "vert_coords" functions:
* `BKE_mesh_vert_coords_alloc`
* `BKE_mesh_vert_coords_get`
* `BKE_mesh_vert_coords_apply{_with_mat4}`
* Remove more hidden copying of positions
* General simplification now possible in many areas
* Convert more code to C++ to use `float3` instead of `float[3]`
* Currently `reinterpret_cast` is used for those C-API functions
Differential Revision: https://developer.blender.org/D15982
If we change the radius of a point or spot lamp, we also change the area lamp size.
As shown in T102853, this is bad for animating the lamp type.
The solution is to make the property point to another member of the DNA
struct `Light`.
Differential Revision: https://developer.blender.org/D16669
Expose `BKE_pose_apply_action_blend` and a simplified pose backup system
to RNA. This will make it possible to easily create some interactive
tools in Python for pose blending.
When creating a backup via this API, it is stored on the
`Object::runtime` struct. Any backup that was there before is freed
first. This way the Python code doesn't need access to the actual
`PoseBackup *`, simplifying memory management.
The limitation of having only a single backup shouldn't be too
problematic, as it is meant for things like interactive manipulation of
the current pose. Typical use looks like:
- Interactive operator starts, and creates a backup of the current pose.
- While the operator is running:
- The pose backup is restored, so that the next steps always use the
same reference pose.
- Depending on user input, determine a blend factor.
- Blend some pose from the pose library into the current pose.
- On confirmation, leave the pose as-is.
- On cancellation, restore the backup.
- Free the backup.
`BKE_pose_apply_action_blend` is exposed to RNA to make the above
possible.
An alternative approach would be to rely on the operator redo system.
However, since for poses this would use the global undo, it can get
prohibitively slow. This change is to make it easier to prototype
things; further into the future the undo system for poses should be
improved, but that's an entire project on its own.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D16900
Remove most of the old (pre-3.0) pose library:
- Remove The entire `editors/armature/pose_lib.c` file
- Deprecate `Object::poselib` in DNA
- Remove Operators marked as deprecated in T93405
- Remove RNA property `Object.pose_library`
- Add comment to clarify that the call `BLO_read_id_address(reader,
ob->id.lib, &ob->poselib);` handles deprecated data.
Note that this functionality has been documented as deprecated since
Blender 3.2.
What remains of the old pose library: The DNA for action markers
(`bAction::markers`) and the corresponding Python API. This will allow
future versions of Blender to still convert old pose libraries to new
ones (via the Pose Library panel in the Action editor).
Manifest task: T93406
Regression in [0], however the primary purpose of that code was to
cycle away from the active object (behavior which was intentionally
removed, see: T96752).
This broke weight-paint + pose-selection (Ctrl-LMB)
when the GPU depth picking preference was disabled.
Causing selection to pick the mesh object instead of the pose bones.
This de-selected the armature, making the pose bones unselectable
instead of selecting the pose bone as intended.
Adding the old code back (restricting it to weight-paint mode)
fixes the bug but reintroduces fairly involved logic unnecessarily.
Instead, prioritize bone selecting when in weight-paint & pose mode
(previously this was only done in pose-mode).
[0]: b1908f2e0b
The goal is to improve clarity and readability, without
introducing big design changes.
Follows the recent obmat to object_to_world refactor: the
similar naming is used, and it is a run-time only rename,
meaning, there is no affect on .blend files.
This patch does not touch the redundant inversions. Those
can be removed in almost (if not all) cases, but it would
be the best to do it as a separate change.
Differential Revision: https://developer.blender.org/D16367
Motivation is to disambiguate on the naming level what the matrix
actually means. It is very easy to understand the meaning backwards,
especially since in Python the name goes the opposite way (it is
called `world_matrix` in the Python API).
It is important to disambiguate the naming without making developers
to look into the comment in the header file (which is also not super
clear either). Additionally, more clear naming facilitates the unit
verification (or, in this case, space validation) when reading an
expression.
This patch calls the matrix `object_to_world` which makes it clear
from the local code what is it exactly going on. This is only done
on DNA level, and a lot of local variables still follow the old
naming.
A DNA rename is setup in a way that there is no change on the file
level, so there should be no regressions at all.
The possibility is to add `_matrix` or `_mat` suffix to the name
to make it explicit that it is a matrix. Although, not sure if it
really helps the readability, or is it something redundant.
Differential Revision: https://developer.blender.org/D16328
Add the eModifierMode_Editmode to the required modes for curves modifier
evaluation. Only this way the modifier can be skipped in evaluation.
Maniphest Tasks: T101888
Differential Revision: https://developer.blender.org/D16280
This commit replaces the `Mesh_Runtime` struct embedded in `Mesh`
with `blender::bke::MeshRuntime`. This has quite a few benefits:
- It's possible to use C++ types like `std::mutex`, `Array`,
`BitVector`, etc. more easily
- Meshes saved in files are slightly smaller
- Copying and writing meshes is a bit more obvious without
clearing of runtime data, etc.
The first is by far the most important. It will allows us to avoid a
bunch of manual memory management boilerplate that is error-prone and
annoying. It should also simplify future CoW improvements for runtime
data.
This patch doesn't change anything besides changing `mesh.runtime.data`
to `mesh.runtime->data`. The cleanups above will happen separately.
Differential Revision: https://developer.blender.org/D16180
This is the conventional way of dealing with unused arguments in C++,
since it works on all compilers.
Regex find and replace: `UNUSED\((\w+)\)` -> `/*$1*/`
When a change happens which invalidates view layers the syncing will be postponed until the first usage.
This will improve importing or adding many objects in a single operation/script.
`BKE_view_layer_need_resync_tag` is used to tag the view layer to be out of sync. Before accessing
`BKE_view_layer_active_base_get`, `BKE_view_layer_active_object_get`, `BKE_view_layer_active_collection`
or `BKE_view_layer_object_bases` the caller should call `BKE_view_layer_synced_ensure`.
Having two functions ensures that partial syncing could be added as smaller patches in the future. Tagging a
view layer out of sync could be replaced with a partial sync. Eventually the number of full resyncs could be
reduced. After all tagging has been replaced with partial syncs the ensure_sync could be phased out.
This patch has been added to discuss the details and consequences of the current approach. For clarity
the call to BKE_view_layer_ensure_sync is placed close to the getters.
In the future this could be placed in more strategical places to reduce the number of calls or improve
performance. Finding those strategical places isn't that clear. When multiple operations are grouped
in a single script you might want to always check for resync.
Some areas found that can be improved. This list isn't complete.
These areas aren't addressed by this patch as these changes would be hard to detect to the reviewer.
The idea is to add changes to these areas as a separate patch. It might be that the initial commit would reduce
performance compared to master, but will be fixed by the additional patches.
**Object duplication**
During object duplication the syncing is temporarily disabled. With this patch this isn't useful as when disabled
the view_layer is accessed to locate bases. This can be improved by first locating the source bases, then duplicate
and sync and locate the new bases. Will be solved in a separate patch for clarity reasons ({D15886}).
**Object add**
`BKE_object_add` not only adds a new object, but also selects and activates the new base. This requires the
view_layer to be resynced. Some callers reverse the selection and activation (See `get_new_constraint_target`).
We should make the selection and activation optional. This would make it possible to add multiple objects
without having to resync per object.
**Postpone Activate Base**
Setting the basact is done in many locations. They follow a rule as after an action find the base and set
the basact. Finding the base could require a resync. The idea is to store in the view_layer the object which
base will be set in the basact during the next sync, reducing the times resyncing needs to happen.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15885
Related to {D15885} that requires scene parameter
to be added in many places. To speed up the review process
the adding of the scene parameter was added in a separate
patch.
Reviewed By: mont29
Maniphest Tasks: T73411
Differential Revision: https://developer.blender.org/D15930
Use `verts` instead of `vertices` and `polys` instead of `polygons`
in the API added in 05952aa94d. This aligns better with
existing naming where the shorter names are much more common.
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7, 410a6efb74). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
When allocating new `CustomData` layers, often we do redundant
initialization of arrays. For example, it's common that values are
allocated, set to their default value, and then set to some other
value. This is wasteful, and it negates the benefits of optimizations
to the allocator like D15082. There are two reasons for this. The
first is array-of-structs storage that makes it annoying to initialize
values manually, and the second is confusing options in the Custom Data
API. This patch addresses the latter.
The `CustomData` "alloc type" options are rearranged. Now, besides
the options that use existing layers, there are two remaining:
* `CD_SET_DEFAULT` sets the default value.
* Usually zeroes, but for colors this is white (how it was before).
* Should be used when you add the layer but don't set all values.
* `CD_CONSTRUCT` refers to the "default construct" C++ term.
* Only necessary or defined for non-trivial types like vertex groups.
* Doesn't do anything for trivial types like `int` or `float3`.
* Should be used every other time, when all values will be set.
The attribute API's `AttributeInit` types are updated as well.
To update code, replace `CD_CALLOC` with `CD_SET_DEFAULT` and
`CD_DEFAULT` with `CD_CONSTRUCT`. This doesn't cause any functional
changes yet. Follow-up commits will change to avoid initializing
new layers where the correctness is clear.
Differential Revision: https://developer.blender.org/D15617
Those collections were so far mainly just tagged as fake user (even
though a few places in code already incremented usercount on them).
Since we now clear the fakeuser flag when linking/appending data, ensure
that these collections are preserved by making these usages regular ID
refcounting ones.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15783
The operator bpy.ops.object.modifier_copy_to_selected()
does not work for the new Curves objects.
This is because it isn't added to BKE_object_supports_modifiers.
Differential Revision: https://developer.blender.org/D15439
Even if the driver is not dependent on time the modifiers were always
re-evaluated during playback. This is due to the legacy nature of the
check whether modifier depends on time or not: it was simply checking
for sub-string match for modifier in the F-Curve and drivers RNA paths.
Nowadays such dependencies are created by the dependency graph builder,
which allows to have more granular control over what depends on what.
The code is now simplified to only check for "static" dependency of the
modifier form time: for example, Wave modifier which always depends on
time (even without explicit animation involved).
This change also fixes missing relation from the animation component to
the shader_fx modifiers, fixing race condition.
Additional files used to verify relations:
- Geometry: F13257368
- Grease Pencil: F13257369
- Shader FX: F13257370
In these files different types of modifiers have an animated property,
and the purpose of the test is to verify that the modifiers do react
to the animation and that there is a relation between animation and
geometry components of the object. The latter one can only be checked
using the dependency graph relation visualization.
The drivers are not tested by these files. Those are not typically
depend on time, and if there were missing relation from driver to
the modifier we'd receive a bug report already. As well as if there
was a bug in missing time relation to a driver we'd also receive a
report.
Differential Revision: https://developer.blender.org/D15358
Regression in [0] which didn't account for the bounds of empty objects.
Add support support calculating bounds from empty draw-type to use in
pose-bone culling.
[0]: 3267c91b4d
Instead of directly accessing constraint-specific callbacks
in code all over blender, introduce two wrappers to retrieve
and free the target list.
This incidentally revealed a place within the Collada exporter
in BCAnimationSampler.cpp that didn't clean up after retrieving
the targets, resulting in a small memory leak. Fixing this should
be the only functional change in this commit.
This was split off from D9732.
Differential Revision: https://developer.blender.org/D13844
Crash happened because code could not find a valid base in current scene
after adding the object, added some checks for that.
Root of the issue was wrong assumptions in `BKE_object_add` logic, which
would pick the first valid ancestor collection in case initially
selected collection was not editable. In some case, this could pick a
collection not instanced in the current scene's view layer, leading to
not getting a valid base for the newly added object.
Addressed this by adding a new variant of `BKE_collection_object_add`,
`BKE_collection_viewlayer_object_add`, which ensures final collection is
in given viewlayer.
This changes is needed to give more control to modifiers' writing
callback when defined. It will allow to implement better culling of
needless data when writing e.g. modifiers from library overrides.
Ref. T97967.
Reviewed By: brecht, JacquesLucke
Differential Revision: https://developer.blender.org/D14939
When the object's position depends on the geometry and the geometry
depends on the object's position, we can't count on the object's
evaluated geometry to be available. Lattices and mesh objects have
equivalent checks in this vertex parenting function.
Differential Revision: https://developer.blender.org/D14781
The original mistake I made in b9febb54a4 was thinking
that the input curve object data to `BKE_displist_make_curveTypes`
was already copied from the original. I think I misread some of its
`ID` flags. This commit places the result of curves evaluation in a
duplicated curve instead, and copies the edit mode pointers
necessary for drawing overlays. `Curve` needs to know not to
free those pointers.
I still don't have a full understanding of why some of the tactics I've
used work and others don't. I've probably tried around 8 different
solutions at this point, and this is the best I came up with.
The dependency graph seems to have some handling of edit mode
pointers that make the edit mode overlays work if the evaluated
result is only an empty curve created by the evaluated geometry set.
This doesn't work with the current method and I need to set the
edit mode pointers at the end of evaluation explicitly.
We're constrained by the confusing duality of the old curves system
combined with the new design using the evaluated geometry set.
Older areas of Blender expect the evaluated `Curve` to be a copy
of the original, even if it was replaced by some arbitrary evaluated mesh.
Differential Revision: https://developer.blender.org/D14561
This was projecting the unnormalized z scale axis onto the plane defined
by the view vector. If object scale was very small, this made the empty
still visible at viewing angles far from the object axis.
Now use the normalized z scale axis to make this work the same at all
object scales.
Fixes T97004.
Maniphest Tasks: T97004
Differential Revision: https://developer.blender.org/D14557
**Relevant to Artists:** This patch adds an option to the Parenting
menu, `Object (Keep Transform Without Inverse)`, and Apply menu, `Parent
Inverse`. The operators preserve the child's world transform without
using the parent inverse matrix. Effectively, we set the child's origin
to the parent. When the child has an identity local transform, then the
child is world-space aligned with its parent (scale excluded).
**Technical:** In both cases, the hidden parent inverse matrix is
generally set to identity (cleared or "not used") as long as the parent
has no shear. If the parent has shear, then this matrix will not be
entirely cleared. It will contain shear to counter the parent's shear.
This is required, otherwise the object's local matrix cannot be properly
decomposed into location, rotation and scale, and thus cannot preserve
the world transform.
If the child's world transform has shear, then its world transform is
not preserved. This is currently not supported for consistency in the
handling of shear during the other parenting ops: Parent (Keep
Transform), Clear [Parent] and Keep Transform. If it should work, then
another patch should add the support for all of them.
Reviewed By: sybren, RiggingDojo
Differential Revision: https://developer.blender.org/D14581
The "dir" argument to `BKE_where_on_path` was only actually
used in a few places. It's easier to see where those are if there
isn't always a dummy argument.
This adds missing cases to detect edit mode for Curves objects.
Unlike other object types, Curves do not have specific edit data,
rather we edit the original data directly, and rely on `Object.mode`.
For this, `BKE_object_data_is_in_editmode` had to be modified to
take a pointer to the object. This affects two places: the outliner
and the dependency graph. For the former place, the object pointer
is readily available, and we can use it. For the latter, the object
pointer is not available, however since it is used to update edit
mode pointers, and since Curves do not have such data, we can
safely pass null to the function here.
This also fixes the assertion failure that happens when closing a file
in edit mode.
Differential Revision: https://developer.blender.org/D14330
