In this report, adding the "resolution" attribute didn't clear the
evaluated positions cache. In some cases capturing an attribute on
the mesh might just add the mesh rather than using an attribute
writer.
When manually setting a group's vertex weight, auto-normalization would
fail in some circumstances, such as when all other groups are locked.
The root cause of this issue was our approach for ensuring that the
weight specified by the user remained as-is when possible during
normalization. Rather than "when possible", it erroneously *always*
ensured the weight stayed as-is even when that made normalization
impossible. It came down to this:
1. Normalization is done as a post process, with no knowledge of what
changes were just made to the weights.
2. In order to (try to) make up for that and ensure that the just-set
weight remains as the user specified, the active group was
temporarily locked during normalization, which could prevent
normalization in some cases.
This PR fixes the issue by introducing a new internal-only concept of
"soft locked" vertex groups to the normalization functions, intended to
be used in exactly these cases where there are weights that have just
been set and we want to avoid altering them when possible. Soft-locked
groups are left untouched whenever normalization is achievable without
touching them, but are still modified if normalization can't be achieved
otherwise.
This has been implemented by introducing a new bool array alongside the
"locked" bool array in the core normalization functions. Although all
uses in this PR only ever specify a single group as "soft locked", using
a bool array will make it easy to use this concept in other weight
painting tools in the future, which may modify more than one group at
once.
Pull Request: https://projects.blender.org/blender/blender/pulls/141045
- Add code documentation.
- Use Span and references rather than pointers everywhere.
- Move all core normalization logic into
`BKE_defvert_normalize_lock_map()`, and have the other variants call
that. This keeps all the logic in one place, which will help make
future changes easier since they only need to be made in one place.
- Add unit tests for `BKE_defvert_normalize_lock_map()`.
- Refactor `vgroup_normalize_all()` to be clearer and avoid an
unnecessary `goto`.
- Make both `vgroup_normalize_all()` and `paint_weight_gradient_exec()`
only call into a single core vertex normalization function, rather
than branching into one of many.
No functional change intended.
When duplicating a layer with layer attribute, caught an assert hit
at `attribute_to_writer()` due to size mismatch between attribute
domain (layers count) and attribute length.
Now fixed by moving `add_node()` prior to `foreach_attribute()`. This way,
extra node already added to runtime data and layer count is updated
inside `ensure_nodes_cache` with the next layers() call
Noticed it during review of !141090
Pull Request: https://projects.blender.org/blender/blender/pulls/141722
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Add render category, which is automatically enabled when using -f or -a
command line flags for background rendering.
* Add extra logs to mention scene, view layer and frame ahead of time rather
than including it in every line.
* Remaining time was removed from Cycles, this will be added back for animations
at the render pipeline level.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
This is a basic armature deformation test for #141535 using Lattices instead of
Mesh as the target object type. Lattice deformation was briefly broken, which is
caught by this test.
The test adds the general-purpose `unit_test_compare` function to lattice object
data. It only compares lattice point counts and positions for now, more data can
be added later if necessary.
The `MeshTest` class did not support lattice object types yet, so needed some
changes. The Curves case was already supported, but only by full conversion to
mesh data, without actually using the `unit_test_compare` function specific for
curves geometry. This is unchanged, because applying constructive modifiers on
curves does not work. If it were not for this limitation the test could do
actual curves comparisons now.
For lattice support the `MeshTest` class comparison function has been
generalized to all supported object data types. It runs the appropriate
`unit_test_compare` api function and validation where supported (only meshes at
this point).
Pull Request: https://projects.blender.org/blender/blender/pulls/141546
Don't attempt to fill curve caps when the direction vector is invalid.
This prevents the crash in #141612 however the root cause of that
report isn't directly related to curve filling.
The check to prevent overly complex tessellation checked the objects
scale directly instead of the final evaluated scale.
Also corrects the scale check which wasn't accounting for negative axes.
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
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
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
