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.
Similar to other removed UI layout functions, this removes uiItemEnumO*
functions and replaces them by calling `uiLayout::op` and writing enum
properties to the returned RNA pointer.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141632
* 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
**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
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
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
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
This replaces uiItemMContents, uiItemDecoratorR* and
uiItemProgressIndicator API with uiLayout methods following
uiLayout refactors and the Python API.
`eButProgressType` is changed to a typed enum class
`blender::ui::ButProgressType`
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141189
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
It seemed "stuck" if the initial voxel size value under the remesh tab
was larger than or equal to the longer side of the bounding plane. It
actually was not stuck, but needed long mouse travels to get into the
range that we were clamping to (behavior from 4221f827cf clamps to
"sane" values on modal that make sense for differently sized meshes).
The "sane" sizes are kept, but this PR makes sure we actually start off
with an `init_voxel_size` that is already based on the clamped minimum/
maximum (so we dont have to mousetravel that far)
Pull Request: https://projects.blender.org/blender/blender/pulls/141208
#138435 was an attempt to fix the issue in #138168 where the Smooth
Operator modifies locked vertex groups. Unfortunately, the fix actually
changed some already-correct code to be incorrect to compensate for the
buggy code in the Smooth Operator.
This reverts that fix and applies a correct fix, which is to exclude
locked vertex groups in the Smooth Operator's code itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/141093
Move number shortcut keys for isolating collection to outliner space.
Resolves#140651
Same operator is also used in the collection list from the view3d N-panel,
video demonstration includes that part as well to ensure it is unaffected.
Pull Request: https://projects.blender.org/blender/blender/pulls/140653
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
Previously in 308292b5d7 an error message
was added to notify that some selected objects are not valid for mesh
data transfer, that message didn't take account that src==dst is also a
case where the transfer is skipped, that doesn't mean the object is
invalid. So update the logic for this.
Pull Request: https://projects.blender.org/blender/blender/pulls/140463
Historically, the `UnifiedPaintSettings` struct has been used to
provide users the ability to set brush values at a scene level. Examples
of such attributes are the brush size, strength, and color, to name a
few.
Instead of these values being shared across all of the grease pencil,
mesh painting, and curves sculpting modes. This commit migrates the
data to the `Paint` struct, meaning that each individual mode (e.g.
Sculpt, Vertex Paint, Grease Pencil Draw) now has the ability to change
these values without affecting other modes.
While this change is large, the majority of the work is simply
refactoring access to the `UnifiedPaintSetting` struct. to ensure the
correct property is being retrieved.
Resolves#134077
Pull Request: https://projects.blender.org/blender/blender/pulls/139766
This removes the include `UI_interface_layout.hh` from
`UI_interface_c.hh`, and in many places this swaps the include
from `UI_interface.hh` to `UI_interface_layout.hh`.
Also, cleanups some `UI_interface.hh` includes with
`UI_interface_icons.hh` or `UI_interface_types.hh`
Two issues here:
- if only one bone is selected blender would create an **Empty** as
target (does not make sense as a target for an armature constraint
though)
- if other bones are also selected, none would be set up as a real
target for the Armature Constraint
So to resolve, change behavior in the following way:
- if only one bone is selected -> dont create a "dummy" target at all
(just like for `Clamp To` or `Spline IK`, does not really make sense to
create a default Curve / Armature in this case since the user would
always use something else)
- if you have another bone selected -> set it up as bone target in the
armature constraint for the user
For the second to work properly, we have to add a target to the armature
constraint "manually" (since armature constraints dont have a target by
default)
Pull Request: https://projects.blender.org/blender/blender/pulls/140200
Currently the mode transfer overlay has to check whether it should
draw for every single object. For scenes with many instances even
that small amount of work per object can be significant. I observed
the overlay taking 1.8% of the samples in a profile.
This commit removes the mode transfer timer and stores it in a
global map instead. Besides the benefit of removing 8 bytes per
object, the main improvement is that it's now trivial to check
whether the overlay can be completely disabled.
Pull Request: https://projects.blender.org/blender/blender/pulls/140374
Remove the last uses of `BKE_boundbox_init_from_minmax` in
favor of the newer `bounds::corners`. Besides clearer naming
and better ergonomics, it's also inline-able which seems to be a
good thing for such a simple function.
In order to get the same behavior as before I changed the
C++ bounds function to give the same vertex order as the
older function.
Pull Request: https://projects.blender.org/blender/blender/pulls/140401
A few reports used string formatting in a way which made translation
awkward, by splitting the message into several individually translated
submessages, instead of just one message with formatting markers.
Pull Request: https://projects.blender.org/blender/blender/pulls/139895
Auto normalization used to not work on assign/remove vertex group
operator, this was due to `BKE_object_defgroup_validmap_get` and
`vgroup_parray_alloc` did not handle grease pencil type objects. Now
added grease pencil cases in them and auto normalization works as
expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/139912
Replace Listbase with a VectorList for duplist generation.
Performing one heap allocation for each dupli becomes very costly on
scenes with many instances.
Using a VectorList can make playback up to 15% faster.
Most scenes will have lower performance improvements,
but none of the ones I tested were slower.
VectorLists also have the advantage of being able to query the size of
the duplilist.
Pull Request: https://projects.blender.org/blender/blender/pulls/138947
This prevents the use of unaligned data types in
vertex formats. These formats are not supported on many
platform.
This simplify the `GPUVertexFormat` class a lot as
we do not need packing shenanigans anymore and just
compute the vertex stride.
The old enums are kept for progressive porting of the
backends and user code.
This will break compatibility with python addons.
TODO:
- [x] Deprecation warning for PyGPU (4.5)
- [x] Deprecate matrix attributes
- [x] Error handling for PyGPU (5.0)
- [x] Backends
- [x] Metal
- [x] OpenGL
- [x] Vulkan
Pull Request: https://projects.blender.org/blender/blender/pulls/138846
