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
Previously, the `AttributeIDRef` wrapper was needed because it also had to
contain a pointer to an `AnonymousAttributeID`. However, since
b279a6d703 this is not necessary anymore.
Therefore we can use "raw" `StringRef` now which reduces the mental overhead
when working with attributes and also simplifies code.
Pull Request: https://projects.blender.org/blender/blender/pulls/127140
Resovle regression in [0].
Pointers in `action.chanbase` were used without first loading the
list-base. In this case the intention was to skip loading legacy
data, so clear the list instead.
[0]: c7bf1a697e
Copying an existing scene was creating a new scene where all the
caches were off. Likewise, "show missing media" flag and proxy
settings was not copied either.
Pull Request: https://projects.blender.org/blender/blender/pulls/126876
Make sure the deform normals caches stored in `SculptSession` are
cleared after topology changes. These should eventually be stored
in an actual mesh rather than `SculptSession` which would simplify
the situation.
This removes `AnonymousAttributeID` which was "attached" to every anonymous
attribute before. It adds more complexity than is justified for its
functionality.
It was originally introduced to keep the reference count of the anonymous
attribute so that it can be deleted automatically when the attribute is not
referenced anymore. For quite some time we have had deterministic attribute
life-times though which don't rely on the reference count anymore.
Anonymous attributes are sometimes shown in the UI as "friendly looking" string
like `"UV Map" from Cube`. Some information necessary for this was also stored
in `AnonymousAttributeID`. However, this can also be solved differently.
Specifically, this functionality has now been added directly to
`AttributeFieldInput`.
This refactor also allows removing `AttributeIDRef` which was mainly introduced
because we had to keep the `AnonymousAttributeID` attached with the attribute
name. Just using simple string types to identify attributes can reduce the
mental overhead quite significantly. This will be done as a separate refactor
though.
Pull Request: https://projects.blender.org/blender/blender/pulls/127081
The term "tool" is historic from before the actual tool system got
introduced. Since then the term was already a bit confusing, because it
wasn't directly related to the tool system, but there was still some
relationship between the two. Now brushes and their types are decoupled
much more from the tool system, with a single "Brush" tool supporting
all kinds of brushes (draw, grab, cloth, smooth, ...).
For a more clear terminology, use "brush type" instead of "tool".
For #126032 we need to write the brush type to the asset metadata (done
in !124618), so we can filter brushes based on the type (so the grease
pencil eraser tool only shows eraser brushes, for example). I'd like to
use future proof names for that to avoid versioning of asset metadata in
future, so I'd rather do the full naming change now.
RNA properties (thus BPY names) are not changed for compatibility
reasons. Can be done in 5.0, see blender/blender#124201.
Pull Request: https://projects.blender.org/blender/blender/pulls/126796
This commit mainly replaces a lot of `memset(0)` by empty value
initialization of `PointerRNA` and related data.
It also moves a few remaining areas from C alloc/free to C++ new/delete
memory hanlding.
Part of the effort to make PointerRNA non-trivial (#122431).
Scaling 2 points to 0 would assert. Remove the assertion
as this isn't an error.
Also ensure `anim_path_accum_length` is freed when a new
length isn't calculated.
This commit changes the raycasting code to store values as the
`ActiveVert` type instead of `PBVHVertRef` to avoid needing to check the
type of the PBVH when retrieving information.
It also fixes a case that did not reset the active vert when performing
a raycast.
Pull Request: https://projects.blender.org/blender/blender/pulls/127000
This commit essentially moves allocation of KeyMaps and Operators
PointerRNA data storage to use C++ new/delet, instead of C alloc/free.
Part of the effort to make PointerRNA non-trivial (#122431).
Pull Request: https://projects.blender.org/blender/blender/pulls/126935
With c20bb31325 the `active_vert` related
methods added a check against the relevant pbvh type. In certain
situations, the PBVH is freed but is not refreshed prior to the cursor
being drawn.
In the long term, we want the PBVH to be owned by the mesh, not the
`SculptSession`, so adding more logic around ensuring depsgraph tags
with PBVH changes to implicitly regenerate the PBVH is a step in the
wrong direction.
Additionally, it doesn't make sense that we don't ensure the PBVH exists
before accessing the `active_vert`, as its context is dependent on the
PBVH.
Therefore, this commit introduces multiple changes:
* Ensures that the PBVH exists prior to doing a raycast or other cursor
related actions
* Removes the checks against the PBVH type in `SculptSession` in
favor of debug asserts to avoid crashes and assist in finding other
situations where the state of the PBVH is ambiguous.
Pull Request: https://projects.blender.org/blender/blender/pulls/126953
This way we can query the brush types, e.g. to filter out eraser brushes
in the brush asset selector while the eraser tool is selected, see
https://projects.blender.org/blender/blender/issues/126032.
Technically a brush may have different brush types depending on the
mode. So we store a type for all supported modes.
Ideally the name of the custom metadata property would match the name of the
properties in RNA. They will match after #126796, the names here are the new
ones, to avoid having to version asset metadata.
Pull Request: https://projects.blender.org/blender/blender/pulls/124618
This node hashes various types into an integer. Note that hashes
cannot generally used as unique identifiers because they are not
guaranteed to be unique. It can be used to generate somewhat
stable randomness though in cases where White Noise does not
offer enough flexibility.
It uses hash functions from BLI_noise.hh. These are also used in
the White Noise node.
Pull Request: https://projects.blender.org/blender/blender/pulls/110769
This adds a new launch argument when building with
renderdoc support. It allows to trigger the capture
of a specific capture scope. This allows selective
capture of some commonly captured parts.
Pull Request: https://projects.blender.org/blender/blender/pulls/126791
The bug was probably harmless in current codebase.
Also added some basic testing of `BKE_main_namemap_get_name` itself,
and not only higher-level ID renaming code.
The issue was that the forward compatibility writing code for channel groups in
layered actions was building a temporary legacy listbase, but was not clearing
it properly afterwards. This was then getting caught by an assert that ensured
that layered-action groups didn't have legacy data in them.
The reason the listbase wasn't getting cleared properly is because the
prev/next listbase pointers were getting cleared using a `LISTBASE_FOREACH`
loop, and thus the loop never progressed past the first item.
Additionally, this mistake wasn't just in the channel groups writing code, but
also the forward compatibility writing code for fcurves.
This fixes the issue in both places by switching the loops to
use`LISTBASE_FOREACH_MUTABLE`.
Based on discussion with @dr.sybren, this also removes the assert that caught
the issue. The situation it guards against is actually completely benign, and
the existence of the assert is contrary to the comments in the forward-compat
writing code explaining why its approach is okay.
Pull Request: https://projects.blender.org/blender/blender/pulls/126970
