When the layer tree in the evaluated state of the Grease Pencil object changed,
the code would fail to get the crazyspace deformation.
Currently we rely on a 1 to 1 index mapping of the original and evaluated
layers. For obvious reasons, this is very weak and can easily break.
The new implementation works as follows:
* Caller that wants to get the crazyspace deformation passes the evaluated and original
object + the original drawing to get the deformation of.
* Fallback deformation are the original positions.
* If there are drawing edit hints in the evaluated geoemtry set, then
* find the edit hint that corresponds to the original drawing
* use the positions in the edit hint.
To create the drawing edit hints, we need to know what evaluated layer corresponds
to which original layer. Currently, this simply stores the original layer index on the
evaluated layer runtime data.
The solution is not ideal and there are some possible improvements like:
* Find a way to solve the more general case, e.g. when there are multiple original
IDs involved.
* Propagate the "mapping" to original layers even when the type of geometry is
changed, like going to curve instances and back.
Pull Request: https://projects.blender.org/blender/blender/pulls/139285
This commit introduces the extension modes to the transform node and
further streamlines the node properties by wrapping all props in a node
storage. Therefore, the interpolation mode has been removed from the
custom properties of the node and moved into the node storage.
Pull Request: https://projects.blender.org/blender/blender/pulls/141487
The memfile undo data-block change detection didn't work for meshes
because we ended up writing a new pointer every time. In practice the
array the pointer references is always empty anyway, so we can just add
a check and write null instead.
Unfortunately this fix only applies to 4.5, since the attribute DNA
data (which is actually used at runtime in 5.0) is created temporarily
specifically for writing, so it gets a new address every time.
We'll probably need to solve #127706 in 5.0 to fix this.
Pull Request: https://projects.blender.org/blender/blender/pulls/141457
This commit takes the previously defined `Paint_Runtime` struct and
moves it into the BKE namespace, initializing it on demand instead of it
being a default-allocated member. This data does not need to be
persisted and is runtime only.
Pull Request: https://projects.blender.org/blender/blender/pulls/141413
Improved readability of `armature_deform.cc` high level API functions
by using spans, references, and optional values instead of raw pointers.
Threading callbacks are reorganized to avoid unused function parameters
in code branches and makes it easier to verify which parts of the code
are executed for given input arguments.
Pull Request: https://projects.blender.org/blender/blender/pulls/141453
Using armature deformation with a lattice object that doesn't have
vertex groups creates an invalid span that crashes during deformation.
This was caused by refactoring which replaced raw pointers with spans,
but has to check for nullptr to avoid creating an invalid span.
Pull Request: https://projects.blender.org/blender/blender/pulls/141538
**Problem Description**
Blender's current mesh data layout often lacks spatial coherence,
causing performance bottlenecks during BVH construction for sculpting
and painting operations. Each time a BVH is built, the system must
recompute spatial partitioning and vertex groupings from scratch,
leading to redundant calculations and suboptimal memory access patterns.
**Proposed Solution**
This patch implements pre-computed spatial organization of mesh data
through a new `mesh_apply_spatial_organization()` function that:
- Reorders vertices and faces based on spatial locality using recursive
spatial partitioning.
- Stores pre-computed MeshGroup hierarchies in MeshRuntime for reuse.
- Enables the BVH system to bypass expensive spatial computation when
pre-organized data is available.
This approach separates the expensive spatial computation from more
frequent BVH rebuilds, providing sustained performance improvements
across multiple sculpting operations.
**Limitations**
- Requires manual invocation (occurs automatically only during remesh
operations).
- Additional memory overhead for storing MeshGroup metadata.
- One-time computational cost during initial organization.
- Spatial group references are not yet stored in files.
**User Interface**
The feature is accessible via a new "Reorder Mesh Spatially" operator in
the Mesh Data Properties panel under the Geometry Data section. Users
can invoke it manually when needed, or it will be applied automatically
during quadriflow and voxel remesh operations. The operator provides
feedback confirming successful spatial reordering.
Pull Request: https://projects.blender.org/blender/blender/pulls/139536
The main armature deform functions compute a vector and/or matrix from
a weighted sum of bone deformations. This can be done either with
linear interpolation or using dual quaternions.
The linear and dual-quaternion methods were mixed together in the same
functions, which makes the code unnecessarily hard to follow. This patch
introduces a "Mixer" concept (similar to attribute math) that abstracts
the process of adding bone influence to the target vector/matrix. It also
takes care of finalizing the value. This way the code iterating over the
vertex group and/or bone envelopes can be agnostic of the target data.
The ArmatureUserData also receives significant refactoring to remove
unnecessary variables, utilize modern math classes, and generally improve
variable naming.
Pull Request: https://projects.blender.org/blender/blender/pulls/141348
This commit changes the `SubdivCCGAdjacentEdge` and
`SubdivCCGAdjacentVertex` structs to be simple wrappers around standard
container types, avoiding the need for manual memory management.
Pull Request: https://projects.blender.org/blender/blender/pulls/141163
Tune the grain size used for the parallel_for to alleviate excessive
mutex contention inside `handle_fan_result_and_custom_normals`.
I happened to notice that the 4004 Moore Lane USD scene[1] experienced a
load time regression compared to the prior release. It looks due to the
grain size used and here are some 3-run averages for the import:
```
Grain | Time in seconds
256 (main) | (14.6+14.6+14.8)/3 = 14.6667
1024 | (13+12.8+12.9)/3 = 12.9
4096 | (13.3+13.1+13.1)/3 = 13.1667
16384 | (12.2+12+ 12.5)/3 = 12.2333
65536 | (9.4+9.2+9.6)/3 = 9.4
131072 | (7.9+7.7+8)/3 = 7.8667
262144 | (7.3+7.1+7.2)/3 = 7.2
max(16384, #verts/2) (PR) | (7.1+6.9+6.8)/3 = 6.9333
```
This PR gets the scenario loading in just under 7 seconds now compared
to over 14 originally.
[1] https://dpel.aswf.io/4004-moore-lane/
Pull Request: https://projects.blender.org/blender/blender/pulls/141249
As noted in [0], locking or atomics are not required for merging
requests for a single mesh, because there is no multithreaded iteration
over objects that will process the same mesh in multiple threads. This
locking was added preemptively over the years and has made code
needlessly complicated, even while the final design for parallel object
iteration isn't completely clear. This PR removes the locks to simplify
some changes necessary for mesh attribute storage refactors.
[0]: b6764e77ef
Pull Request: https://projects.blender.org/blender/blender/pulls/141405
When moving a handle so its length is 0, the other handle was automatically set to 0 as well.
Cancelling the action didn't move the other handle back to 0, but set its length to 1.
The reason for that was that the code tries to maintain the relation between the two handles,
but that would lead to a divide by 0 when either of the handles has a length of 0.
So it would set the handle length to 1 in that case.
The fix is to ensure that the length of a handle is never 0. This is done by clamping it at the key
position with a threshold of 0.001 and an extra floating point step to support large floating
point values.
This should not affect animation in any way.
This was discussed in the animation & rigging module meeting
https://devtalk.blender.org/t/2025-06-26-animation-rigging-module-meeting/41272#p-153605-patches-review-decision-time-5
Co-authored by Nathan Vegdahl
Pull Request: https://projects.blender.org/blender/blender/pulls/141029
Add three new RNA functions to `bpy.types.CollectionExports`:
- `collection.exporters.new('IO_FH_alembic', name="Alembic")`
- `collection.exporters.remove(exporter)`
- `collection.exporters.move(0, 1)`
which allow to respectively create, remove, and reorder collection
exporters. Previously, they were only achievable using operators and
not the Python data API.
Example usage:
```python
C.collection.exporters.new("test")
# Traceback (most recent call last):
# File "<blender_console>", line 1, in <module>
# TypeError: CollectionExports.new(): error with argument 1, "type" -
# enum "test" not found in ('IO_FH_alembic', 'IO_FH_usd',
# 'IO_FH_obj', 'IO_FH_ply', 'IO_FH_stl', 'IO_FH_fbx')
usd_exporter = C.collection.exporters.new('IO_FH_usd')
usd_exporter.filepath = "//exp.usd"
stl_exporter = C.collection.exporters.new('IO_FH_stl')
C.collection.exporters.move(0, 1)
C.collection.exporters.remove(stl_exporter)
```
The exporter UIList was updated to add arrows calling the move
operator.
Co-authored-by: Pratik Borhade <pratikborhade302@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/141076
Allows to use regular constructor/destructors. And standard CPP data
like string, maps, etc.
Main is defined as non-movable and non-copyable for the time being.
The existing creating/deleting API is kept as-is, moving to direct
MEM_new/MEM_delete usages in the code is kept as a later cleanup commit.
The 'ListBase' of split-by-libraries Mains has been replaced by a VectorSet.
This is an unfortunate consequence of making Main a non-trivial C++
struct: it is no more guaranteed that next/prev pointers required for
ListBase remain immediately at the top of the struct anymore - and on
Windows they indeed don't.
So move to a more modern form of storage for split-by-libraries mains,
with a few other related changes to internal readfile code.
WARNING: This is quite a sensitive change, extensively tested locally
(including library-related changes across undos and redos, in complex
production scenes).
Pull Request: https://projects.blender.org/blender/blender/pulls/141086
The `CurvesGeometry::resize` function would not work properly when
passing a new size of zero.
1) The `CustomData_realloc` would allocate an array with zero size.
2) A new size of 1 is passed to `implicit_sharing::resize_trivial_array`
for the curve offsets when it should pass 0.
3) A value is written out-of-bounds to `curve_offsets`
This fixes the issues in the following ways:
1) `CustomData_realloc` now doesn't allocate any data when the new
size is 0 and sets the `layer->data` to `nullptr`.
2) When the new number of curves is 0, resize the `curve_offsets` to 0
not to 1. This also ensures that the data pointer is `nullptr`.
3) Make sure to only write the first and last curve offset when the
number of curves is greater than 0.
Pull Request: https://projects.blender.org/blender/blender/pulls/141333
This replaces the Move/Link to Collection operator popup with a menu,
allowing this to be able to search collection to move and to expand
this menu from other menus.
This removes the expected memory leak of using the popup.
Move to Collection operator now uses `session_uid` to identify
target collection, this now allows to target a collection from another
scene, however, is not exposed throw UI)
Resolves#133772
Pull Request: https://projects.blender.org/blender/blender/pulls/140883
We do not do any audio time stretching when doing time remapping.
As we also use the audio to keep track of time passed, we should always
pass the actual timestamp we are starting playback from.
The issue was that the old logic would try to undo time remapping on cfra.
However cfra is already correct and is not remapped. I'm guessing that
this changed at some point and we forgot to fix it up in the sound code.
Pull Request: https://projects.blender.org/blender/blender/pulls/141288
Detection of whether an object is in Edit mode can rely on checking its
obdata ID status (for meshes e.g.), which will falsly make remapping
code think it is remapping the obdata of an edited object.
Somewhat work around the issue by forcing such remapping for the time
being. On the long run, check should be updated to only rely on the
Object's status.
Adds NURBS weight, radius and tilt to Transform panel.
To avoid code duplication code is a bit refactored and `struct TransformMedian_GreasePencil` is removed.
Also GP case has a race condition in existing version. It is fixed using `std::atomic`.
Pull Request: https://projects.blender.org/blender/blender/pulls/141079
Change `eCustomDataType` to `bke::AttrType` for uses of the attribute
API (the `AttributeAccessor` one anyway). I didn't touch any values that
might be saved in files; those should be handled on a case by case basis.
Part of #122398
Pull Request: https://projects.blender.org/blender/blender/pulls/141301
