The main goal of these changes are to improve static (i.e. build-time)
checks on whether a given data can be allocated and freed with `malloc`
and `free` (C-style), or requires proper C++-style construction and
destruction (`new` and `delete`).
* Add new `MEM_malloc_arrayN_aligned` API.
* Make `MEM_freeN` a template function in C++, which does static assert on
type triviality.
* Add `MEM_SAFE_DELETE`, similar to `MEM_SAFE_FREE` but calling
`MEM_delete`.
The changes to `MEM_freeN` was painful and useful, as it allowed to fix a bunch
of invalid calls in existing codebase already.
It also highlighted a fair amount of places where it is called to free incomplete
type pointers, which is likely a sign of badly designed code (there should
rather be an API to destroy and free these data then, if the data type is not fully
publicly exposed). For now, these are 'worked around' by explicitly casting the
freed pointers to `void *` in these cases - which also makes them easy to search for.
Some of these will be addressed separately (see blender/blender!134765).
Finally, MSVC seems to consider structs defining new/delete operators (e.g. by
using the `MEM_CXX_CLASS_ALLOC_FUNCS` macro) as non-trivial. This does not
seem to follow the definition of type triviality, so for now static type checking in
`MEM_freeN` has been disabled for Windows. We'll likely have to do the same
with type-safe `MEM_[cm]allocN` API being worked on in blender/blender!134771
Based on ideas from Brecht in blender/blender!134452
Pull Request: https://projects.blender.org/blender/blender/pulls/134463
Previously we generally expected CustomData layers to have implicit
sharing info, but we didn't require it. This PR clarifies that we do
require layers with non-null data to have implicit sharing info. This
generally makes code simpler because we don't have to have a separate
code path for non-shared layers. For example, it makes the "totelem"
arguments for layer freeing functions unnecessary, since shared data
knows how to free itself. Those arguments are removed in this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/134578
Caused by 0b891a68b1
In certain cases, we need to perform a whole-geometry update to the
underlying mesh data. The prior commit cleared the paint BVH but did not
tag the depsgraph for geometry updates, causing incorrect data to be
used while rendering.
Pull Request: https://projects.blender.org/blender/blender/pulls/134597
Currently node tools always adds a dependency graph update tag. In
sculpt mode this causes the paint BVH to be rebuilt, which causes a
complete rebuild of the sculpt mode draw data. Both are quite expensive
relative to most other operations. Also, node tools currenly always
uses the "geometry" sculpt undo type, which causes its own depsgraph
update tag.
Arguably a depsgraph geometry reevaluation shouldn't cause a rebuild of the
BVH and draw data, but that's a limitation that's out of scope for now.
Most tools in sculpt mode avoid adding a depsgraph tag when they don't
change mesh topology for this reason.
This PR gives node tools the ability to check if the output mesh has a
different topology than the input. When the topology is the same,
we can use one of the specialized sculpt undo types for positions,
masks, or face sets. Though when more than one of these attributes changes,
we're still forced to still use the geometry undo type because sculpt undo
steps can only handle a single type of change.
In the end this results in much better performance for most simple node
tools that just deform the mesh or change masks or face sets.
Pull Request: https://projects.blender.org/blender/blender/pulls/133842
The `Plane` brush type does not use the original plane/normal
parameters. However, these parameters can be incorrectly retained when
switching type to `Plane` from another brush type where they were
enabled. This commit ensures that they are ignored for the `Plane` brush
type.
Pull Request: https://projects.blender.org/blender/blender/pulls/134255
This patch introduces the `Plane` brush, a generalization of the
existing `Flatten`, `Fill` and `Scrape` brushes, with the objective of
providing more flexibility when sculpting.
This brush has the following key features:
* `Height` and `Depth` parameters to control the range of the brush in
the local z-axis.
* Stabilizers for the normal and center of the brush plane.
When inverting, the user can choose between two options:
* `Invert Displacement`: Identical to the existing behavior, displacing
vertices away from the plane.
* `Swap Height and Depth`: Exchanges the roles of `Height` and `Depth`.
For example a brush with `Height` = 0.7 and `Depth` = 0.3 behaves as
if it had `Height` = 0.3 and `Depth` = 0.7. In particular, this
ensures that a scrape brush (`Height` = 1, `Depth` = 0) becomes
equivalent to a fill brush (`Height` = 0, `Depth` = 1) when inverted,
and viceversa.
In the existing planar brushes, the influence on a vertex is determined
by the 3D Euclidean distance between the vertex and the cursor position,
multiplied by the vertex's distance from the brush plane (and other
factors common to all brushes).
In the `Plane` brush, the 3D distance is between the vertex and the
plane center instead of the cursor position.
The Plane brush introduces two parameters — `Stabilize Normal` and
`Stabilize Plane`. These can be thought of as the non-binary version of
the `Original Normal` and `Original Plane` options found in existing
brushes. These values are a weighted moving average across a window of
previous stroke steps.
Pull Request: https://projects.blender.org/blender/blender/pulls/132723
The `BRUSH_INVERT_TO_SCRAPE_FILL` check inside `brush_flip` applies to
any brush instead of just the Fill and Scrape brush, this means that if
an asset is in a weird state where the user has enabled this flag but
switched away from the brush type, the flag still applies even though
the option is no longer visible.
This commit checks the brush type to ensure it only applies to the
specified types.
Pull Request: https://projects.blender.org/blender/blender/pulls/134014
Remove the need for a temporary array of colors.
Just put the data directly into the translations vector.
This should provide a small performance improvement.
Prior to the brush refactor in 4.3, the cavity automasking feature
had an implicit dependency on stable position values. In many cases,
such as during brush evaulation, this was upheld by the usage of the
proxy system, which meant that even if a vertex's neighbor was changed
during a stroke in paralell, these changes would not be accessed until
after a stroke finished.
With the new method of brush evaulation removing the proxy system, this
introduced subtle artifacts on BVH node boundaries, as vertices were
guaranteed to change and cause differences as there was no temporary
storage to use the "old" position data. This effect was most noticable
in 4.3 and beyond in multires sculpting, though similar artifacts can be
seen when using the mesh filter in all prior versions.
To fix these issues, instead of calculating the internal cavity factor
during a stroke or during deformations, we calculate it ahead of time
based on the affected nodes of a stroke. This has the benefit of now
behaving consistently for a given mesh and given brush or filter
application.
From a performance perspective, this change should have no noticeable
impact, as each BVH node, and by extension each vertex, only has its
corresponding cavity factor calculated once, when the stroke would
affect the node.
Related: #102745
Pull Request: https://projects.blender.org/blender/blender/pulls/133224
In Sculpt, Vertex Paint, and Weight Paint, the operator used while
painting (`SCULPT_OT_brush_stroke`, `PAINT_OT_vertex_paint`, and
`PAINT_OT_weight_paint`) can currently be executed in python as they
define `exec` methods. However, each of them has a implicit dependency
on the `OperatorStrokeElement` struct containing a `location`
corresponding to the object space location of the stroke daub.
This limits the usefulness of the operator in non-interactive
situations, as determining the actual location of a stroke on a 3D
object requires access to the Paint BVH to perform a raycast and project
the mouse from 2D region space into object space.
To allow users to define a stroke in region space coordinates, this
commit adds a new parameter to the associated operators,
`reproject_stroke` which indicates whether or not the current `location`
data should be discarded and replaced with newly calculated positions.
Ref: #132960
Pull Request: https://projects.blender.org/blender/blender/pulls/132974
Previously, in 4.2, the `has_face_set` method always returned `true` for
whether or not a given vert had a given face set with dyntopo enabled.
This logic was updated to be more complete in 4.3, but the fallback
logic for when a mesh didn't have any face set data was not.
To fix this, if the corresponding BMesh doesn't have the face set
attribute, we check whether or not thet requested face set is
`SCULPT_FACE_SET_NONE`
Pull Request: https://projects.blender.org/blender/blender/pulls/132523
Certain color-related operators and brushes are only relevant for certain
modes. Historically, we have performed this check by inspecting the BVH
tree type. To avoid this as a hard requirement and avoid needing to
ensure that the tree is built in these scenarios, this commit changes
the `color_supported_check` to inspect the source of truth for dyntopo
(`SculptSession.bm`) and multires (`BKE_sculpt_multires_active`).
Pull Request: https://projects.blender.org/blender/blender/pulls/132086
Introduced in 750e3a6fba
The commit above incorrectly passes the `grids` `Span` into the
`calc_front_face` function, causing the calculation to miss vertices in
certain cases, as the function attempts to index instead of reading the
`normals` `Span` directly.
This has the potential to cause crashes too, as the indices of the grid
are not guaranteed to be bounded by the size of the `factors` array.
Pull Request: https://projects.blender.org/blender/blender/pulls/131886
When "Developer Extras" is disabled, the experemental options
must not be used.
Some checks for experemental options weren't using the macro which
checks both are set.
Add comment to avoid this happening in the future.
With the brush system refactor in 4.3, the mesh filter tool was changed
to remove the `no_orig_co` `FilterCache` property. This change and
subsequent refactors had the unintended effect of breaking the filter
tool "repeat" functionality. The expected state of most filter modes
is to use the current position, not the original position.
To fix this behavior, in all modes except Sharpen, Smooth, and Relax
that used the original position data, this commit removes resetting
the transform by the distance from the original position, instead
updating this only when the modal is operating.
Unfortunately, the smooth filter is rather complicated in how it
expects this data, when running as a modal, we always use the original
data, but when the repeat parameter is being used, we need to instead
use the current position on any step that isn't the first one as the
undo step is not "committed" until the user is finished tweaking the
panel.
Additionally, many of the filter modes clipped the resulting posistions
based on the original position data instead of the new, transformed
position, this was also fixed.
Pull Request: https://projects.blender.org/blender/blender/pulls/131469
Currently we calculate neighbors for vertices in batches. The idea is
to access topology data all at once, storing the result in a local node-
sized vector that can fit in CPU caches. Currently we use
`Vector<Vector<int>>` for storing the neighbors, and that works well
enough when the number of neighbors fits into the inline buffer, but
whenever it doesn't it causes many vector reallocations and scatters
the neighbor storage in arbitrary memory locations.
This commit changes to using a `GroupedSpan` to store the neighbors, in
other words contiguous storage split into groups by an array of offset
integers. This reduces local per-vertex memory usage by 20 bytes and
makes memory access more predictable.
I observed a 1.39x performance improvement for the mesh smooth filter
on a large triangulated mesh, and a 1.14x improvement for a mesh of
mostly quads. In the brush benchmark on a quad mesh the difference I
observed is a small slowdown. I'm not sure why that happens but I trust
the results from the filter a bit more.
Resolves#130797.
Pull Request: https://projects.blender.org/blender/blender/pulls/130941
The call to `sculpt_apply_texture` is not thread safe and as such is a
major bottleneck in brush stroke processing. In previous versions, we
avoided calculating this if the vertex position was outside of the brush
radius.
To fix this, we add a check for the factor already being 0 and prevent
further texture calculations.
Pull Request: https://projects.blender.org/blender/blender/pulls/131256
As part of the overall sculpt brush refactor project, the `corner_tris`
attribute was removed from the PBVH and accessed directly from the mesh
runtime data.
A new set of methods was introduced to the `TrianglesCache` `struct` to
prevent tagging the cache as dirty and requiring a subsequent evaluation
because the performance hit while in sculpt mode was significant. This
was enabled upon entering sculpt mode and disabled upon exiting it.
Unfortunately, there are some operations inside Sculpt mode which can
cause either the Mesh object itself or the MeshRuntime object to be
recreated, effectively unfreezing the cache. A few examples that cause
this are:
* Undoing the first brush operation on file load
* Performing a remesh operation
To fix this issue, this commit checks and re-freezes the cache if it
is detected to be in a bad state prior to tagging the cache as dirty.
Further changes to fix this on a more fundamental level are well
outside of the scope of a fix needed for 4.3.1.
Pull Request: https://projects.blender.org/blender/blender/pulls/130709
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
Make use of the struct and patterns from 005e02d008 to make
the view places that deform shape keys more similar. While they each are
slightly different for valid reasons, with this change they follow the
same structure and use the same helper struct.
Pull Request: https://projects.blender.org/blender/blender/pulls/129901
The impetus is removing the `BKE_subdiv_ccg.hh` include from
`BKE_paint.hh`, but I also think this is a bit of a simplification in
general. There's often no need for a special type to reference a
`SubdivCCG` vertex, which is a lot like `Mesh` but with a different
topology format.
Pull Request: https://projects.blender.org/blender/blender/pulls/129687
Prior to this commit, the brush action was determined on a step by step
basis by peeking at the `StrokeCache` `bstrength` property and
determining which brush to use based on if the value was negative or
not. The sign of this value, however, was not static across the
entirety of a brush stroke, as it is calculated from three separate
fields, one of which could vary over the course of a stroke when using a
tablet, the `pen_flip` property.
To fix this issue, this commit ensures the `pen_flip` field of the
`StrokeCache` is only updated at the beginning of the stroke. It also
adds a new boolean to store the initial direction of the stroke to
reduce further ambiguity when comparing the sign of the brush strength.
Additionally, the operator level `pen_flip` property is moved to the
generic paint stroke operator instead of being defined as a property of
the `OperatorStrokeElement` struct. This value is now only calculated
at the beginning of the stroke instead of before each stroke step.
Pull Request: https://projects.blender.org/blender/blender/pulls/129559
The PBVH struct is now called `bke::pbvh::Tree`. Expanding the acronym
in the file name just a little should help developers find things and make
the connection to the "paint" concept that loosely ties sculpt mode and
other painting modes together a little stronger.
This rename also lets us replace the weird `_api.hh` historical part of
the file name without reusing the old `BKE_pbvh.hh` file name, which
would have probably made understanding the git history a bit harder.
Pull Request: https://projects.blender.org/blender/blender/pulls/129684
Prior to this commit, the brush action was determined on a step by step
basis by peeking at the `StrokeCache` `bstrength` property and
determining which brush to use based on if the value was negative or
not. The sign of this value, however, was not static across the
entirety of a brush stroke, as it is calculated from three separate
fields, one of which could vary over the course of a stroke when using a
tablet, the `pen_flip` property.
To fix this issue, this commit ensures the `pen_flip` field is only
updated at the beginning of the stroke and also adds a new boolean to
store the initial direction of the stroke to reduce further ambiguity
when comparing the sign of the brush strength.
Pull Request: https://projects.blender.org/blender/blender/pulls/129184
We would have to use task isolation here because of the use of
`EnumerableThreadSpecific`. Anyway, nested threading isn't
helpful because of the relatively small node sizes.
Pull Request: https://projects.blender.org/blender/blender/pulls/129222
Any brush that used the `restore_position_from_undo_step` codepath (i.e.
brushes that use `OrigPositionData` to calculate their deformations) had
the possibility to cause artifacts due to the nested tbb parallelization
causing incorrect usage of TLS data.
To fix this we add a call to `threading::isolate_task` to prevent thread
stealing.
Pull Request: https://projects.blender.org/blender/blender/pulls/129020
The brush does not use the value calculated from brush_strength, this
commit silences the assert by just handling the case statement for this
brush type with a static value of 0.0f.
Pull Request: https://projects.blender.org/blender/blender/pulls/128936
Brushes that restored from undo step data on every brush
iteration triggered a performance regression because of
missing filtering of unchanged nodes after recent changes
to the PBVH dirty positions tagging system. There was a
TODO comment left from 76c322047e that
I had forgotten about.
Part of #118145.
Prior to this commit, for each node that a brush step affected, we would
look up the `.sculpt_mask` and `.hide_vert` attributes. To avoid this
overhead, this commit creates a helper struct to hold commonly used
attributes and reduces the frequency that they are accessed.
Pull Request: https://projects.blender.org/blender/blender/pulls/128286
Part of #118145.
This PR introduces a number of helper methods used across the brush
implementations to reduce duplication when calculating a base value for
the `factors` array.
Not all brushes have been ported to use these helper methods - a
conservative approach was taken to avoid adding complexity for the
common case.
Pull Request: https://projects.blender.org/blender/blender/pulls/128235
A combination of a few changes:
- Don't apply hardness again, the "cube tip" calculation already factors it in.
- Avoid multiplication by brush radius, just use the 0-1 distances from the
cube tip calculation directly.
- Add filtering by brush radius to fix the second part of #128004.
- Change brush radius filtering to be consistent with previous code using
less than or equal instead of less than.
Note that the current radius filtering in BKE_brush_calc_curve_factors is
unnecessary since we already filter by the radius in a separate step.
