Prior to 0df133559c, the `active_vert_` property was only ever
invalidated if the entire `SculptSession` was refreshed, even if the
cursor moved off of the mesh or if the underlying mesh type changed.
The Sculpt Expand operator was dependent on this value not being cleared
to still behave in a reasonable way from a user perspective
This commit introduces a new variable, `last_active_vert_` and
corresponding accessor methods to `SculptSession` to specifically fix
this usecase. When the active vert is cleared, if it had a valid value,
we store it in the new `last_active_vert_` variable.
Pull Request: https://projects.blender.org/blender/blender/pulls/127433
Part of #118145.
The attribute system should be used to store user-edited data, not
temporary caches during a stroke. It's simpler and more obvious to
just store this as part of the cache created for every brush stroke.
Pull Request: https://projects.blender.org/blender/blender/pulls/127463
For `SubdivCCG`, replace the dynamic array-of-struct data with separate
arrays for positions, normals, and masks. This decreases memory
bandwidth requirements for loops that only access one of these arrays.
It also significantly simplifies data access, making it more similar
to mesh data where it can just be accessed with indices.
In a simple test this change speeds up the multires sculpt brush
benchmark by 32%. It also slightly reduced BVH build time by about 12%.
In practice this means completely replacing usage of `CCGElem` for
`SubdivCCG`. The struct is still used in the older subsurf baking code
though. Removing that is a much trickier task that doesn't have short
term benefits.
Part of #118145.
Pull Request: https://projects.blender.org/blender/blender/pulls/127262
Structure the multires grids PBVH build to be similar to meshes,
splitting face indices into groups instead of grid indices. This
removes one step of indexing, decreases the amount of temporary
data, and allows sharing the majority of the implementation with
the mesh BVH build.
In a test file with 4 million faces at multires level 1, this reduced
BVH build time from 149 to 70 ms. The improvement will be
significantly lower for higher subdivision levels.
Pull Request: https://projects.blender.org/blender/blender/pulls/127429
Fix a crash that happens when drawing Action groups in the dope sheet, when
Blender is built without experimental features (hence without Action
slots) and it has loaded a blend file with slotted Actions.
Basically a pointer needs to be set to `nullptr` when reading such a file,
as it ensures that the rest of the code treats the group as "from a legacy
Action".
Pull Request: https://projects.blender.org/blender/blender/pulls/127339
Use `std::partition` instead of implementing something similar
ourselves. This is much easier to understand, and it's also much
faster and requires less memory during the build.
I observed a change in the runtime building a 16 million face
BVH from 492 to 389 ms, a 1.27x improvement (with a Ryzen
7950x).
`std::partition` is not multithreaded. I expect there would be
some improvement from multithreading this, at least for the
first few splits.
Currently this only applies to Mesh sculpting.
Pull Request: https://projects.blender.org/blender/blender/pulls/127332
Each time the face bounds are used after they're initially computed, we
recompute the center of the bounds. We only use the actual bounds to
calculate the bounds of each node to decide how it should be split.
This commit changes to store the bounds centers instead, and just use
the full bounds as a type for the parallel reduction.
In a test with a 16 million face grid on a Ryzen 7840U, I observed a
1.28x decrease in BVH build time, from 1072 to 836 ms.
I didn't apply a similar change to multires grids BVH building because
it's not clear the same bottleneck exists due to the lower ratio of
"primitives" (grids) to final subdivided vertices.
When I first developed the attribute filters they were just a `FunctionRef`
and thus could be stored by value in this struct. Now that they are a
virtual type, that is not possible anymore.
This PR allows users to select a GPU backend.
In the system tab of the user preferences the GPU backend can be selected in the `Display Graphics` panel.
It will require a restart of Blender before the changes become effective.
During startup minimum requirements are checked. Blender will switch automatically
to OpenGL when no compatible Vulkan device could be detected. A dialog will be shown
to inform the user.
The setting of the in the `Display Graphics` panel are still overridden when blender is started
using the `--gpu-backend` option. When starting blender with `--debug-gpu` the backend
detection will print to the console.
See PR for detailed information and screenshots of the UI.
Implements #126504
Pull Request: https://projects.blender.org/blender/blender/pulls/126545
Part of #118145.
In the future we want to move the ownership of the BVH tree to the
original mesh rather than `SculptSession`, in order to persist it
across some more general non-topology changing operations like
node tools. The first step of that change is replacing all places
that used `SculptSession::pbvh` for access with a function.
Add `.faces()`, `.verts()`,`.all_verts()`, and `.grids()` functions to nodes.
Don't change BMesh data access yet. More complex const correctness
makes that situation more difficult.
Pull Request: https://projects.blender.org/blender/blender/pulls/127201
As of 2a56403cb0, bevel weight data is stored as a generic
attribute. The bevel modifier is currently hard-coded to use the
`bevel_weight_edge` attribute as the data source for the weights.
This commit adds a string textbox where the user can specify alternate
attributes for the bevel's edge weights.
The string name field is added as a search button which provides a list
of all attributes in the original mesh. This is meant to work similarly
to geometry nodes, so mismatched attribute data types and domains are
automatically converted/interpolated as necessary. Attributes created
by previous modifiers can also be used, but they won't appear in the
search menu.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/117366
Currently each sculpt BVH node stores the indices of its triangles.
It also stores triangles of vertex indices local to the node, and also
potentially the indices of the face corners in the node.
The problem with this is that the leaf nodes store plenty of redundant
information. The triangles in each face aren't split up between multiple
nodes, so storing triangle instead of face indices is unnecesssary. For
the local vertex triangles, there is also duplicate information-- twice
the number of indices as necessary for quad meshes. We also often need
a node's faces, which is currently done with a triangle to face map
using 4 bytes per triangle.
This "double storage" results in extra processing too. For example,
during BVH builds we need to combine twice the number of "Bounds"
objects for a quad mesh. And we have to recalculate a node's face
indices every time we want them.
This commit replaces the PBVH triangle indices with face indices, and
replaces the local vertex triangles array by using a `VectorSet` to store
each node's vertex indices. This results in significant performance and
memory usage improvements.
| | Before | After | Improvement |
| ----------------- | -------- | -------- | ----------- |
| BVH build time | 1.29 s | 0.552 s | 2.3x |
| Brush stroke time | 3.57 s | 2.52 s | 1.4x |
| Memory usage | 4.14 GiB | 3.66 GiB | 1.3x |
All testing is done with a 16 million vertex grid and a Ryzen 7950x.
My guess is that the brush stroke time is improved by the added sorting
of node vertex indices, and by the overall increase in memory bandwidth
availability for mesh data. Personally I'm pleasantly surprised by the
whole improvement, since I usually try to avoid hash table data
structures for this sort of use case. But a lookup into this set ends up
just being a boolean and with an array lookup, so it's quite cheap.
Pull Request: https://projects.blender.org/blender/blender/pulls/127162
This introduces the concept of an #AttributeFilter. It's used to tell a geometry
algorithm which attributes it should process/propagate and which can be ignored.
We already had something similar before named
`AnonymousAttributePropagationInfo`. However, as the name implies, this was
specific to anonymous attributes. This had some downsides:
* A lot of code had to be aware of the concept of anonymous attributes even if
it did nothing special with anonymous attributes.
* For non-anonymous attributes we often had a separate `Set<std::string> skip`
parameter. It's not nice to have to pass two kinds of filters around and to
have to construct a `Set<std::string>` in many cases.
`AttributeFilter` solves both of these downsides.
Technically, `AttributeFilter` could also just be a `FunctionRef<bool(StringRef
attribute_name)>`, but that also has some issues:
* The `bool` return value is often ambiguous, i.e. it's not clear if it means
that the attribute should be processed or not. Using an enum works better.
* Passing function refs around and combining them works, but can very easily
lead to dangling references.
* The default value of a `FunctionRef` is "empty", i.e. it can't be called. It's
generally more nice to not have a special case for the default value. Now the
default `AttributeFilter` propagates all attributes without any extra handling
on the call-site.
Pull Request: https://projects.blender.org/blender/blender/pulls/127155
Move the functions
* `BKE_pose_apply_action_selected_bones`
* `BKE_pose_apply_action_all_bones`
* and `BKE_pose_apply_action_blend`
out of the blender kernel and into animrig.
This will allow solving #126969 without having to include
animrig code in the blender kernel.
Pull Request: https://projects.blender.org/blender/blender/pulls/126978
Between 2.93 & 3.2 a regression was introduced where evaluated
meshes from the modifier stack would always have their deformed_only
value set to false.
Resolve by enabling for meshes returned by
BKE_mesh_wrapper_from_editmesh and ensure the value is kept when the
modifier duplicates the cage mesh.
Resolves#123138.
Decreases BVH build runtime by approximately 6%.
Improve cache locality in the initial splitting loop and the finalization
of mesh leaf nodes by processing them in separate loops. The second
loop calculates the node's vertex indices.
Speeds up building the sculpt BVH tree by over 3x.
The total bounds for all the triangles/grids in the current node is
recalculated for every iteration of the node splitting algorithm that
builds the BVH tree. The first step was parallelized, but since the
number of elements is just divided in half every time, many of the
subsequent bounds calculations are significantly large to benefit from
parallelism too (actually all of them for mesh BVH currently, since the
leaf size is about 4000).
For historical reasons, the BVH tree considered face sharpness similar
to material indices and tried to make the value match for all faces in a
node. This is unnecessary because PBVH drawing supports mixed
sharpness within a node.
This commit rewrites the PBVH drawing using many of the principles from the
ongoing sculpt refactor. First of all, per BVH node overhead is minimized.
Previously the main entry point to the drawing API was per node, so there
was significant overhead fetching global data and maintaining caches on
a per-node basis. Now all of that "global" work happens for the entire
geometry.
We also now avoid creating wireframe index buffers and batches unless
the viewport actually requests wireframe data. This was theoretically
possible before, but the whole logic flow was so convoluted that the
optimization was too difficult. Similarly, multithreading is used more
consistently now. Because of OpenGL, flushing vertex/index buffers to
the GPU has to happen on the main thread, but everything else can be
multithreaded. With outer loops processing all relevant PBVH nodes,
it's now trivial to apply multithreading wherever possible.
Testing performance, overall this commit results in a 10% improvement in
the time between opening a file with a large mesh sculpt and the first
possible interaction. Specifically I measured a change from 8.4 to 7.6
seconds on a completely visible 16 million vertex mesh with a Ryzen 7950x.
I also measured a decrease in memory usage from 4.79 to 4.31 GB.
For multires I observed a similar improvement in memory usage,
though less of a performance improvement.
There are still significant opportunities for future improvement. #122775
would be particularly helpful. #99983 would be helpful too, though more
complicated, and #97665 describes the problems a bit more generally.
Part of #118145.
Pull Request: https://projects.blender.org/blender/blender/pulls/127002
- Use `float3` C++ vector instead of pointers
- Return directly instead of using temporary boolean variable
- Use separate loops for "original positions" case to simplify hot loops
