Makes it possible to use non-trivial C++ types in `FileListEntryCache`.
I'm planning to use this for blender/blender!130543, to store status
information about downloaded previews. While it's possible to use
C-style types instead, this is easier and a worthwhile general
improvement.
I turned `FileList.filelist_cache` into an allocated pointer, so
`FileList` doesn't have to be ported to be a non-trivial type as well.
We probably want to do that too at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/141411
In rotation-based transform operations, the rotation axis can be
determined in two ways:
1. Through "orient_axis" (X, Y or Z)
2. Through "constraint_axis"
When the axis is obtained through the constraint, "orient_axis" is
ignored, and the angle may be negated depending on the view orientation
to match the mouse movement.
However, "orient_axis" never has its angle negated. Since the default
orientation is "View", the Z axis is inverted by default, aligning with
the mouse movement but not with the constraint axis.
This causes problems in the Redo Panel because the constraint fields
are hidden in the Rotation operation, so they need to be unset for the
Axis field to work. However, if you change the value of the Rotation
field, the object may have its rotation negated unexpectedly.
This issue was partially shown in #93078. Commit c30e6a37b0 attempted
to fix it by unsetting the constraint property when the Axis was
changed. However, this solution is incomplete: if the Axis is changed
and then reverted, the negative rotation issue reappears. In addition,
it has not been implemented in all operations.
This commit resolves the issue by reverting c30e6a37b0, aligning the
behavior of "orient_axis" and "constraint_axis", and unsetting
"constraint_axis" in `saveTranform`.
A downside of this solution is that it may break operators invoked from
Python that rely on "orient_axis" as the rotation axis, as the rotation
value now needs to be negated.
Pull Request: https://projects.blender.org/blender/blender/pulls/141101
**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 soft eraser could leave points with zero opacity. To fix this issue
for now, we apply a post-process step when the stroke is done to remove
these points.
In the future, it would be better to refactor the eraser a bit more and
delete points during the stroke.
Part of #131686.
Pull Request: https://projects.blender.org/blender/blender/pulls/141454
Add support to select multiple tree view elements (similar to outliner/anim channels)
`Ctrl + LMB` to select+activate element under the mouse
`Shift + LMB` to select all items between active and clicked item.
As of now, only Shape key has support for multi-select. (straightforward to include
other views). `KEYBLOCK_SEL` flag is used for storing selection state.
Pull Request: https://projects.blender.org/blender/blender/pulls/138979
You could basically not interact with the animation (except for
keyframes in the main region), channels region was totally empty, NLA
could not be used, ...
It is not something users will animate a lot, but we should still have
animation editors in mind when adding a new object type.
Just missing from cc31d7bb49
Pull Request: https://projects.blender.org/blender/blender/pulls/141449
Adjust angle threshold defaults to dissolve verts as before,
while preserving selected geometry.
The new behavior works as follows:
- If a dissolve terminates on an edge loop or the the corner vert of a
face, do the dissolve.
- If a set of dissolve edges (either a chain, or a set of 3+ edges)
crosses a loop cut, do the dissolve.
- If a chain of dissolve edges touch the corner of an unselected face,
and then leave in a different direction without crossing a loop cut,
preserve that vert. Just because the selection touches it doesn't mean
it should be altered.
- If a dissolve edge is separating two triangles,
then the face join creates a quad. Users generally prefer
and strive to create meshes that contain quads.
Instead of destructively dissolving the corners of the quad and
automatically turning it to a triangle or wire,
instead prefer to preserve the quad.
Ref !141097
Cursor is actually wrapped at the beginning with the help of function
`WM_cursor_grab_enable`. Though the `ND_MODE` event notifier added
inside `editmode_enter/exit_ex` further calls `region_cusor_set()`.
This resets the cursor to default at the bottom of
`ED_region_cursor_set()`. Such sitution could be avoided by creating a
dummy cursor function for hud region. But issue remains when we call
redo panel from F9. As Julian suggested, add condition for `grabcursor`
to avoid changing cursor when editing buttons.
Pull Request: https://projects.blender.org/blender/blender/pulls/133529
Use fixed speed values for translations in Fly mode to constant
values for each axis. Until now, after switching to the Fly mode,
the latest speed value calculated based on RegionView3D::dist
was used for translations.
Now, the translation speed in Fly mode is an adjusted constant
for each axis.
Ref !141285
It was applying the bounds clamp to each object individually,
which changed spatial relationships between objects. Make the logic
match what used to be done in the Python OBJ importer back in the day.
Pull Request: https://projects.blender.org/blender/blender/pulls/141446
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
As mentioned in 98c7e75897, the idea of "pinning" was to have certain
animation always visible (regardless of object selection -- e.g.
animating camera movement even while animating something else).
dea7ef4dd9 added a special case that would also
include the object regardless of it being selected or not if its
**object data** is animated and pinned.
It only fully implemented that for Cameras though (that was the primary
request at that time), leaving ugly blank/empty space (pin icon missing)
for other object data types.
It is understandable that it only did it for Cameras a that time, but
there is no reason to **not** do it for other (viewport selectable)
object data types as well (animators might as well be interested in
pinning other types as well for timing reference) -- which is what this
PR does.
Adding this to 4.5 (since it fixes the blank space (even though it is
somewhat adding a feature as well...)
Pull Request: https://projects.blender.org/blender/blender/pulls/141396
Seems like a mistake in dea7ef4dd9
The decision to display an object or not in animation filtering is done
in `animdata_filter_base_is_ok`
So e.g. if an **object** has `AnimData` and that one is pinned
(`ADT_CURVES_ALWAYS_VISIBLE`) it would be included regardless of it
being selected or not. dea7ef4dd9 added a special case that would also
include the object regardless of it being selected or not if its
**object data** is animated and pinned.
What dea7ef4dd9 did wrong though in that special case was that it also
required the object to **not** have animation.
This seems wrong, the object can have animation which itself is not
pinned (ultimately causing `animdata_filter_base_is_ok` to return
`false`).
So to resolve, remove the check for NULL object animation, it should be
entirely enough to have object data animation which is pinned to include the
object in animation filtering.
Pull Request: https://projects.blender.org/blender/blender/pulls/141379
- Add PyObject_GetOptionalAttrString (only available in Python 3.13).
- When registering RNA classes use optional attribute access to avoid
raising and clearing exceptions.
- Refactor macro that handles substituting Python's built-ins
with a `for` loop for better readability.
If `__name__` or `__doc__` were None, the property would be detected as
being set when checking if the property is set (for required properties).
This is more of a technical correction as its unlikely developers would
run into this in practice since `__name__` should never be None and
the description is not a required property.
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
When a paint stroke is executed instead of processed via the modal
handler, prior to this commit, the `paint_brush_update` function was
not called. This method handles initialization of some temporary stroke
data inside `UnifiedPaintSettings`, which is used by dyntopo when
performing edge collapse.
This had the result of causing a divide by 0 with certain uninitalized
settings when using a brush with dyntopo enabled and calling the
operator from the python API (e.g. from unit testing), resulting in
nonsensical deformations.
There are a number of weak points with the current design:
* This issue was only exposed because of the refactor to the
`UnifiedPaintSettings`, indicating that despite these values being
runtime-only, they were still persisted in some cases in .blend files
* The data stored as individual stroke steps is not sufficient to
reconstruct a paint stroke given a list of screen-space locations, and
this data is populated outside of the common `stroke` callbacks.
Both of the above issues are wider reaching than this PR is intended to
fix.
This commit ensures that `paint_brush_update` is called in the `exec`
codepath and updates the related test image.
Pull Request: https://projects.blender.org/blender/blender/pulls/141314
External render engines, like Cycles, do not use the paint BVH for
rendering. As part of the stroke update process, normal caches are
tagged as dirty. These normals need to be recalculated to be valid on
the next stroke step.
This commit is a mitigation for the reported issue, but does not
fully fix the underlying issue that causes the cycles data to
be in this state.
Pull Request: https://projects.blender.org/blender/blender/pulls/140503
This renames `UI_block_layout` API as `blender::ui::block_layout`,
following uiLayout refactors.
This function now returns a layout reference instead of pointer,
this changes applies this return type where the layout can be used
as such reference.
Changes includes the use of `blender::ui::LayoutDirection` and
`blender::ui::LayoutType` as typed enum parameters.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141401
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
