Slots can now be deleted from an Action via the channel list in the Action
editor. As with all deletions there, it deletes the associated F-Curves
from the Action without any warnings.
Pull Request: https://projects.blender.org/blender/blender/pulls/127112
Refactor `if (ale->type == ANIMTYPE_GROUP)` into `switch (ale->type)`
with a single `case` filled out. This will make an upcoming commit
cleaner, as it simply adds another case.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/127112
Add a method to remove a slot from an Action. This is also exposed as
`Action.slots.remove(slot)` to RNA/Python.
Removing a slot deletes all its associated animation data in the Action.
It also un-assigns the slot from any ID that was animated by it. The
Action reference is left untouched.
Pull Request: https://projects.blender.org/blender/blender/pulls/127112
If voxel sizes were big, code could run into clamping at 1.0f, making it
look like nothing was happening, also even though the "step size" was
taking into account the initial voxels size (only in relative mode,
absolute mode was, well... absolute, no matter what object this was
happening on, also see 5946ea938a).
So previously, a reasonable voxels size could not achieved using this
operator for e.g. a terrain-size mesh.
Now code allows for bigger/smaller meshes to behave predictably.
This is done by storing a reasonable min and max voxel size (this is
taken from the bounding plane which is also displayed to the user),
making the max the length of the longer side of the bounding plane and
the min a fraction of it (based on `VOXEL_SIZE_EDIT_MAX_GRIDS_LINES` --
smaller voxels would not display anyways...)
Based on the above, we can have a reasonable range to base the change on
which is done moving the mouse.
Because this is more predictable than before, we can even remove the
`relative` mode (dont think it makes too much sense now anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/127109
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
GPU depth picking was not working on all GPUs. When a GPU requires a
DEPTH32F to store depths the conversion to unsigned normalized could
wrap around. Making depths of 1.0 become 0. In stead of MAX_DEPTH.
This solves depth picking issues on Intel and AMD GPUs.
This makes the logs fairly verbose, but it is not displayed by default
anyway, and it is the only easy way to find out exactly which file or ID
is breaking the test.
This PR enabled backend specific rendertest for EEVEE and Workbench.
Some changes that have been made are:
- Add suffix to the test identifying the backend (_opengl, _vulkan, _metal)
- Vulkan render tests are compared with the opengl results.
Most EEVEE tests run as expected there are some issues in the Vulkan
backend that needs to be addressed:
- Fully smooth reflective materials miss lighting.
- Tangent normals are off
None of the workbench tests pass. It has to do with downloading the depth
buffer. In Workbench they are stored as GPU_DEPTH32F_STENCIL8 and downloaded
as FLOAT. We didn't implement it in the vulkan backend yet and currently asserts.
The Vulkan render test run faster compared to OpenGL. On my system around
25-50% faster.
Pull Request: https://projects.blender.org/blender/blender/pulls/126784
This PR introduces disk cache for static pipelines. The pipelines are
stored in `<cache folder>/vk-pipeline-caches/static-shaders.bin`.
Due to limitations in some drivers we add a custom header to the
cache file to identify if the cache file was created by the same driver
for the same GPU for the same Blender.
Reading/writing the cache is skipped when running blender with
`--debug-gpu` as that would generate different shader modules. For
now that isn't a problem, but the final implementation would check
before compiling a shader if a certain key is in the pipeline cache if
that is the case the compilation step is skipped and the cached shader
module is used.
Reference: #126229
Pull Request: https://projects.blender.org/blender/blender/pulls/127110
Base pipelines are used to optimize the vulkan pipeline creation.
Instead of building each pipeline from scratch a base pipeline can
be used to share resources and faster code-paths.
We used to overwrite the base pipeline with the last created pipeline.
This PR doesn't overwrite the base pipeline after it was initially set
giving less confusion when working with base pipelines.
Pull Request: https://projects.blender.org/blender/blender/pulls/127181
Add Action + Action Slot selectors to various Property Editor tabs.
This follows the pattern established in
f917b60036.
Support for `CacheFile` data-blocks is not included here. That needs
some discussion, as currently its interface is part of the Modifier
stack (and thus implemented in C++ and not Python, and using a
different layout).
Since this PR is about adding to the Property Editor, some data-blocks
that have no representation there are thus excluded (like `Mask`).
Even when they could actually use an Action+Slot selector somewhere.
Pull Request: https://projects.blender.org/blender/blender/pulls/127074
The new Action selector (51fd355c01) avoids the need to use
`space_data.action` in the dope sheet (that attribute was a bit of a
hack; the new Action selector was made to avoid that). It failed to take
the dope sheet's shape key mode into account properly, though. This is
now fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/127177
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
e420caab19 already fixed this for "manually" changing visibility, but
if this change comes through animation, these notifiers dont fire (rna
callbacks dont run).
So to resolve, also redraw on `ND_FRAME`, this is something every region
in animation editors listens to anyways, so probably right for
consistency (and to solve this bug), even though it might eat away some
ticks.
Pull Request: https://projects.blender.org/blender/blender/pulls/127145
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.
In preparation for adding big-endian tests, disable them on macOS
where many are failing, although it looks like the cause of failure
may not relate to endian conversion, it needs further investigation.
Generate all pointer (mouse) events from the "frame" callback as this
is the intended behavior according to the wl_pointer_listener docs.
In practice it's unlikely users would notice any difference however
there are potentially subtle differences because events were previously
created before all the pointer data had been collected.
This also has some minor advantages as each frame event no longer
needs to detect if scrolling is needed and in the case of motion events:
calculate the time-stamp twice.
This shows the docking feedback very similar to how tooltips are shown
elsewhere. It describes the operation and also includes the icon and
name of the moving/changing area.
Pull Request: https://projects.blender.org/blender/blender/pulls/126898
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).
Adds an option to the "Clear Recent Files List" operator to allow it
to remove only items that are not found. By default it clears "All
Items" but this can be changed to "Items Not Found".
Pull Request: https://projects.blender.org/blender/blender/pulls/127024
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.
