corresponding data layers and using their values for computations.
Avoiding that should increase performance in many operations that
would otherwise have to read, write, or propagate these values.
It also means decreased memory usage-- not just for sculpt mode
but for any mesh that was in sculpt mode. Previously the mask, face set,
and hide status layers were *always* allocated by sculpt mode.
Here are a few basic tests when masking and face sets are not used:
| Test | Before | After |
| Subsurf Modifier | 148 ms | 126 ms |
| Sculpt Overlay Extraction | 24 ms every redraw | 0 ms |
| Memory usage | 252 MB | 236 MB |
I wouldn't expect any difference when they are used though.
The code changes are mostly just making sculpt features safe for when
the layers aren't stored, and some changes to the conversion to and
from the hide layers. Use of the ".hide_poly" attribute replaces testing
whether face sets are negative in many places.
Differential Revision: https://developer.blender.org/D15937
For copy-on-write, we want to share attribute arrays between meshes
where possible. Mutable pointers like `Mesh.mvert` make that difficult
by making ownership vague. They also make code more complex by adding
redundancy.
The simplest solution is just removing them and retrieving layers from
`CustomData` as needed. Similar changes have already been applied to
curves and point clouds (e9f82d3dc7, 410a6efb74). Removing use of
the pointers generally makes code more obvious and more reusable.
Mesh data is now accessed with a C++ API (`Mesh::edges()` or
`Mesh::edges_for_write()`), and a C API (`BKE_mesh_edges(mesh)`).
The CoW changes this commit makes possible are described in T95845
and T95842, and started in D14139 and D14140. The change also simplifies
the ongoing mesh struct-of-array refactors from T95965.
**RNA/Python Access Performance**
Theoretically, accessing mesh elements with the RNA API may become
slower, since the layer needs to be found on every random access.
However, overhead is already high enough that this doesn't make a
noticible differenc, and performance is actually improved in some
cases. Random access can be up to 10% faster, but other situations
might be a bit slower. Generally using `foreach_get/set` are the best
way to improve performance. See the differential revision for more
discussion about Python performance.
Cycles has been updated to use raw pointers and the internal Blender
mesh types, mostly because there is no sense in having this overhead
when it's already compiled with Blender. In my tests this roughly
halves the Cycles mesh creation time (0.19s to 0.10s for a 1 million
face grid).
Differential Revision: https://developer.blender.org/D15488
This commit moves the hide status of mesh vertices, edges, and faces
from the `ME_FLAG` to optional generic boolean attributes. Storing this
data as generic attributes can significantly simplify and improve code,
as described in T95965.
The attributes are called `.hide_vert`, `.hide_edge`, and `.hide_poly`,
using the attribute name semantics discussed in T97452. The `.` prefix
means they are "UI attributes", so they still contain original data
edited by users, but they aren't meant to be accessed procedurally by
the user in arbitrary situations. They are also be hidden in the
spreadsheet and the attribute list by default,
Until 4.0, the attributes are still written to and read from the mesh
in the old way, so neither forward nor backward compatibility are
affected. This means memory requirements will be increased by one byte
per element when the hide status is used. When the flags are removed
completely, requirements will decrease when hiding is unused.
Further notes:
* Some code can be further simplified to skip some processing when the
hide attributes don't exist.
* The data is still stored in flags for `BMesh`, necessitating some
complexity in the conversion to and from `Mesh`.
* Access to the "hide" property of mesh elements in RNA is slower.
The separate boolean arrays should be used where possible.
Ref T95965
Differential Revision: https://developer.blender.org/D14685
This is a port of sculpt-dev's `SculptVertRef` refactor
(note that `SculptVertRef was renamed to PBVHVertRef`)
to master. `PBVHVertRef` is a structure that abstracts
the concept of a vertex in the sculpt code; it's simply
an `intptr_t` wrapped in a struct.
For `PBVH_FACES` and `PBVH_GRIDS` this struct stores a
vertex index, but for `BMesh` it stores a direct pointer
to a BMVert. The intptr_t is wrapped in a struct to prevent
the accidental usage of it as an index.
There are many reasons to do this:
* Right now `BMesh` verts are not logical sculpt verts;
to use the sculpt API they must first be converted to indices.
This requires a lot of indirect lookups into tables, leading to performance
loss. It has also led to greater code complexity and duplication.
* Having an abstract vertex type makes it feasible to have one unified
temporary attribute API for all three PBVH modes, which in turn
made it rather trivial to port sculpt brushes to DynTopo in
sculpt-dev (e.g. the layer brush, draw sharp, the smooth brushes,
the paint brushes, etc). This attribute API will be in a future patch.
* We need to do this anyway for the eventual move to C++.
Differential Revision: https://developer.blender.org/D14272
Reviewed By: Brecht Van Lommel
Ref D14272
In some cases it is mandatory to be able to hide parts of the mesh
in order to paint certain areas. The Mask modifier doesn't work in
weight paint, and edit mode hiding requires using selection, which
is not always convenient.
This makes the weight and vertex paint modes always respect edit mode
hiding like sculpt mode. The change in behavior affects drawing and
building paint PBVH. Thus it affects brushes, but not menu operators
like Smooth or Normalize.
In addition, this makes the Alt-H shortcut available even without
any selection enabled, and implements Hide for vertex selection.
Differential Revision: https://developer.blender.org/D14163
This implements transform modes for the transform tool and Elastic
Transform. This mode uses the Kelvinlets from elastic deform to apply
the transformation to the mesh, using the cursor radius to control the
elasticity falloff.
{F9269771}
In order for this to work, the transform tool uses incremental mode when
elastic transform is enabled. This allows to integrate the displacement of
the Kelvinet in multiple steps.
Review By: Sergey Sharbin & Daniel Bystedt & Julian Kaspar & Campbell
Barton
Differential Revision: https://developer.blender.org/D9653
Ref D15041
This makes it much clearer what data is supposed to be modified
and what data is just used to influence the operation. The new
`BKE_paint_brush_for_read` function isn't great design, but it
can be removed or renamed if similar changes are applied to
more places.
Also pass pointers explicitly to `sample_curves_3d_brush` rather
than reusing the `bContext`. This makes it clearer what data the
function actually needs.
Differential Revision: https://developer.blender.org/D14967
This patch adds allows the user to select the initial fill color when
adding a new color attribute layer.
---
{F13035372}
Reviewed By: JulienKaspar, joeedh
Differential Revision: https://developer.blender.org/D14743
- Add missing doxy-section for Apply Parent Inverse Operator
- Use identity for None comparison in Python.
- Remove newline from operator doc-strings.
- Use '*' prefix multi-line C comment blocks.
- Separate filenames from doc-strings.
- Remove break after return.
- Verrtex paint mode has been refactored into C++ templates.
It now works with both byte and float colors and point
& corner attribute domains.
- There is a new API for mixing colors (also based
on C++ templates). Unlike the existing APIs byte
and float colors are interpolated identically.
Interpolation does happen in a squared rgb space,
this may be changed in the future.
- Vertex paint now uses the sculpt undo system.
Reviewed By: Brecht Van Lommel.
Differential Revision: https://developer.blender.org/D14179
Ref D14179
This patch contains an initial pixel extractor for PBVH and an initial paint brush implementation.
PBVH is an accelleration structure blender uses internally to speed up 3d painting operations.
At this moment it is extensively used by sculpt, vertex painting and weight painting.
For the 3d texturing brush we will be using the PBVH for texture painting.
Currently PBVH is organized to work on geometry (vertices, polygons and triangles).
For texture painting this should be extended it to use pixels.
{F12995467}
Screen recording has been done on a Mac Mini with a 6 core 3.3 GHZ Intel processor.
# Scope
This patch only contains an extending uv seams to fix uv seams. This is not actually we want, but was easy to add
to make the brush usable.
Pixels are places in the PBVH_Leaf nodes. We want to introduce a special node for pixels, but that will be done
in a separate patch to keep the code review small. This reduces the painting performance when using
low and medium poly assets.
In workbench textures aren't forced to be shown. For now use Material/Rendered view.
# Rasterization process
The rasterization process will generate the pixel information for a leaf node. In the future those
leaf nodes will be split up into multiple leaf nodes to increase the performance when there
isn't enough geometry. For this patch this was left out of scope.
In order to do so every polygon should be uniquely assigned to a leaf node.
For each leaf node
for each polygon
If polygon not assigned
assign polygon to node.
Polygons are to complicated to be used directly we have to split the polygons into triangles.
For each leaf node
for each polygon
extract triangles from polygon.
The list of triangles can be stored inside the leaf node. The list of polygons aren't needed anymore.
Each triangle has:
poly_index.
vert_indices
delta barycentric coordinate between x steps.
Each triangle is rasterized in rows. Sequential pixels (in uv space) are stored in a single structure.
image position
barycentric coordinate of the first pixel
number of pixels
triangle index inside the leaf node.
During the performed experiments we used a fairly simple rasterization process by
finding the UV bounds of an triangle and calculate the barycentric coordinates per
pixel inside the bounds. Even for complex models and huge images this process is
normally finished within 0.5 second. It could be that we want to change this algorithm
to reduce hickups when nodes are initialized during a stroke.
Reviewed By: brecht
Maniphest Tasks: T96710
Differential Revision: https://developer.blender.org/D14504
This patch adds color attributes to TexPaintSlot. This allows an easier selection
when painting color attributes.
Previously when selecting a paint tool the user had to start a stroke, before the
UI reflected the correct TexPaintSlot. Now when switching the slot the active
tool is checked and immediate the UI is drawn correctly.
In the future the canvas selector will also be used to select an image or image texture node
to paint on. Basic implementation has already been done inside this patch.
A limitation of this patch is that is isn't possible anymore to rename images directly from
the selection panel. This is currently allowed in master. But as CustomDataLayers
aren't ID fields and not owned by the material supporting this wouldn't be easy.
{F12953989}
In the future we should update the create slot operator to also include color attributes.
Sources could also be extended to use other areas of the object that use image textures
(particles, geom nodes, etc... ).
Reviewed By: brecht
Maniphest Tasks: T96709
Differential Revision: https://developer.blender.org/D14455
color attribute system.
This commit removes sculpt colors from experimental
status and unifies it with vertex colors. It
introduces the concept of "color attributes", which
are any attributes that represents colors. Color
attributes can be represented with byte or floating-point
numbers and can be stored in either vertices or
face corners.
Color attributes share a common namespace
(so you can no longer have a floating-point
sculpt color attribute and a byte vertex color
attribute with the same name).
Note: this commit does not include vertex paint mode,
which is a separate patch, see:
https://developer.blender.org/D14179
Differential Revision: https://developer.blender.org/D12587
Ref D12587
This adds the boilerplate code that is necessary to use the tool/brush/paint
systems in the new sculpt curves mode.
Two temporary dummy tools are part of this patch. They do nothing and
only serve to test the boilerplate. When the first actual tool is added,
those dummy tools will be removed.
Differential Revision: https://developer.blender.org/D14117
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
From investigating T95185, it's important the normal returned by
SCULPT_vertex_normal_get always match the PBVH normal array.
Since this is always initialized in the PBVH, there is no advantage
in storing the normal array in two places, it only adds the possibility
that changes in the future causing different meshes normals to be used.
Split out from D13975.
As described in T91186, this commit moves mesh vertex normals into a
contiguous array of float vectors in a custom data layer, how face
normals are currently stored.
The main interface is documented in `BKE_mesh.h`. Vertex and face
normals are now calculated on-demand and cached, retrieved with an
"ensure" function. Since the logical state of a mesh is now "has
normals when necessary", they can be retrieved from a `const` mesh.
The goal is to use on-demand calculation for all derived data, but
leave room for eager calculation for performance purposes (modifier
evaluation is threaded, but viewport data generation is not).
**Benefits**
This moves us closer to a SoA approach rather than the current AoS
paradigm. Accessing a contiguous `float3` is much more efficient than
retrieving data from a larger struct. The memory requirements for
accessing only normals or vertex locations are smaller, and at the
cost of more memory usage for just normals, they now don't have to
be converted between float and short, which also simplifies code
In the future, the remaining items can be removed from `MVert`,
leaving only `float3`, which has similar benefits (see T93602).
Removing the combination of derived and original data makes it
conceptually simpler to only calculate normals when necessary.
This is especially important now that we have more opportunities
for temporary meshes in geometry nodes.
**Performance**
In addition to the theoretical future performance improvements by
making `MVert == float3`, I've done some basic performance testing
on this patch directly. The data is fairly rough, but it gives an idea
about where things stand generally.
- Mesh line primitive 4m Verts: 1.16x faster (36 -> 31 ms),
showing that accessing just `MVert` is now more efficient.
- Spring Splash Screen: 1.03-1.06 -> 1.06-1.11 FPS, a very slight
change that at least shows there is no regression.
- Sprite Fright Snail Smoosh: 3.30-3.40 -> 3.42-3.50 FPS, a small
but observable speedup.
- Set Position Node with Scaled Normal: 1.36x faster (53 -> 39 ms),
shows that using normals in geometry nodes is faster.
- Normal Calculation 1.6m Vert Cube: 1.19x faster (25 -> 21 ms),
shows that calculating normals is slightly faster now.
- File Size of 1.6m Vert Cube: 1.03x smaller (214.7 -> 208.4 MB),
Normals are not saved in files, which can help with large meshes.
As for memory usage, it may be slightly more in some cases, but
I didn't observe any difference in the production files I tested.
**Tests**
Some modifiers and cycles test results need to be updated with this
commit, for two reasons:
- The subdivision surface modifier is not responsible for calculating
normals anymore. In master, the modifier creates different normals
than the result of the `Mesh` normal calculation, so this is a bug
fix.
- There are small differences in the results of some modifiers that
use normals because they are not converted to and from `short`
anymore.
**Future improvements**
- Remove `ModifierTypeInfo::dependsOnNormals`. Code in each modifier
already retrieves normals if they are needed anyway.
- Copy normals as part of a better CoW system for attributes.
- Make more areas use lazy instead of eager normal calculation.
- Remove `BKE_mesh_normals_tag_dirty` in more places since that is
now the default state of a new mesh.
- Possibly apply a similar change to derived face corner normals.
Differential Revision: https://developer.blender.org/D12770
- Added space below non doc-string comments to make it clear
these aren't comments for the symbols directly below them.
- Use doxy sections for some headers.
- Minor improvements to doc-strings.
Ref T92709
Sculpting tools are designed to ignore hidden geometry and behave like
hidden geometry does not exist.
When getting the neighbors of a vertex, now this takes into account
hidden geometry to avoid returing neighbors which connected edge is not
visible. This should make corner cases of a lot of tools work properly,
especially when working in low poly meshes when is common to have a
single face loop hidden.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D11007
Expand is a new operator for Sculpt Mode which is intended to be the main
tool for masking, Face Set editing, interacting with the filters and pattern
creation.
The fundamentals of the tool are similar to the previous sculpt.mask_expand
operator. It shares the same default shortcuts and functionality, making
the previous operator obsolete.
The shortcuts to execute the operator are:
- Shift + A: Expand mask
- Shift + Alt + A: Expand mask by normals
- Shift + W: Expand Face Set
- Shift + Alt + W: Resize current Face Set
The main changes compared to the previous sculpt.mask_expand operator are:
- Modal keymap, all operator options can be changed in real time while the
operator is running.
- Supports creating Mask, Face Sets and Sculpt Vertex Colors.
- Much better code, new features can be easily integrated.
Limitations:
- All Mask operations are supported for Sculpt Vertex colors, but not exposed
by default as their support is still experimental.
- Dyntopo does not support any Face Set or Sculpt Vertex Colors. functionality
(they are not implemented in general for Dyntopo).
- Multires does not support any feature related to geodesic distances.
- Multires does not support vertex colors.
- Multires does not support recursions.
- In Multires, Face Sets snaping does not initialize all current enabled Face
Sets when toggling snapping.
- In Multires, Face Sets are created at base mesh level (works by this by
design, like any other tool).
- Unlike the previous mask_expand operator, this one does not blur the mask
by default after finishing Expand as that does not fit the new design.
The mask can still be blurred by using the mask filter manually.
Reviewed By: JacquesLucke
Differential Revision: https://developer.blender.org/D10455
'Caused'/revealed by rBd29a720c45e5: Operators that fully re-create the
mesh would previously rely on `sculpt_update_object` called from update
code to get required sculpt-specific data layers re-added to the new
mesh.
Now instead put all code adding data to orig mesh for sculpt purpose
into a new util function (`BKE_sculpt_ensure_orig_mesh_data`), and call
that function when entering sculpt mode, and from voxel remesher code.
This is contonuing effort to more clearly separate orig data from evaluated
data handling/usage in sculpt code.
TODO: there are likely other code paths that would need to call that
new function?
Reviewers: @sergey, @pablodp606
Subscribers:
This fixes the main issue there (essentially a followup to
rB90e12e823ff0: Fix T81854: crash when undoing switch between sculpt and
edit mode).
We basically remove more (hopefully all the remaining!) modifications of
orig mesh from `sculpt_update_object`, as those done here will not be
immediately available in the evaluated data (that specific bug happened
because masking data was added to orig mesh there, but not flushed to
depsgraph evaluated one).
This also goes towards a better separation between handling of evaluated
data and orig one.
Note that modification of orig mesh data can still happen, e.g. values
in some cdlayers, but at least all pointers should now be valid in the
evaluated mesh.
There are still some issues, e.g. we now get an assert/crash in
`multires_reshape_assign_final_coords_from_ccg` when undoing out of the
Sculpt mode, presumably because subdiv_ccg data remains unchanged then
(and hence still has the `has_mask` flag set), while actual mesh data do
not have that cdlayer anymore...
This commit also cleans up/simplifies some code,
`ED_object_sculptmode_enter_ex` was (indirectly) calling
`BKE_sculpt_face_sets_ensure_from_base_mesh_visibility` twice e.g.
This adds support for incremental updates in the sculpt transform
code. Now tools can define if they need the displacement applied
for the original coordinates or incrementally.
This is needed for features like elastic transform or cloth deformation
target in the transform tool.
No functional changes.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9547
This introduces a new operator to edit the detail size of constant
detail mode in dyntopo. The way this operator works and the
functionality it provides is similar to the "Voxel size edit" operator
for the voxel remesher.
It also includes a sample mode. When pressing Ctrl, the detail size
will be sampled from the surface under the cursor, updating the
preview in real time. This allows quick resolution changes without
using the operator multiple times.
The operator is set to Shift + D, replacing the old way to change
the constant detail size of dyntopo. Shift + R will remain available to
be enabled when the voxel remesher works with dyntopo. Deciding
if both detail sizes can be unified needs a separate discussion as the
new dyntopo can work with detail sizes in parts of the mesh that can
easily crash the remesher.
The structure of these operators is similar, but the data they control,
ranges, drawing and setup functions are completely different, making it
hard to merge them into one.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9355
This adds an option to orientate the trimming shape using the surface
normal instead of the view when lasso trim is used.
Reviewed By: dbystedt, sergey
Differential Revision: https://developer.blender.org/D9231
Previously, all Face Set visibility logic was using mvert flags directly
to store the visibility state on the vertices while sculpting. As Face
Sets are a poly attribute, it is much simpler to use mpoly flags and let
BKE_mesh_flush_hidden_from_polys handle the vertex visibility, even for
Multires.
Now all operators that update the Face Set visibility state will always
copy the visibility to the mesh (using poly flags) and the grids, all
using the same code.
This should fix a lot of visibility glitches and bugs like the following:
- Sculpt visibility reset when changing multires levels.
- Multires visibility not updating in edit mode.
- Single face visibible when surrounded by visibile face set, even when
the face set was hidden.
Reviewed By: sergey
Differential Revision: https://developer.blender.org/D9175
This adds an operator property to use the paint cursor radius and
position for the depth of the trimming shape created by the trimming
tools.
When enabled, the shape is located in the surface point when the gesture
started and it will have the depth of the cursor radius. When the cursor
is not over the mesh, the shape will be positioned at the center of the
depth of the whole object from the viewport camera.
Reviewed By: dbystedt, sergey
Differential Revision: https://developer.blender.org/D9129
Previously the softbody strength property was controlling the strength
of the constraints that pin all vertices to the original location. This
was causing problems when the forces were trying to deform the vertices
too much, like when using gravity or grab brushes.
Now softbody is implemented with plasticity, which creates constraints to
a separate coordinates array. These coordinates are deformed with the
simulation, and the plasticity parameter controls how much the
simulation moves the coordinates (plasticity 0), or the coordinates move
the simulation back to its previous position (plasticity 1).
This creates much better and predictable results and adding softbody
plasticity to the brushes can increase its control and the stability of
the simulation.
Reviewed By: sergey, zeddb
Differential Revision: https://developer.blender.org/D9187
Those were only shallow wrappers around `BKE_id_copy`, barely used (even
fully unused in some cases), and we want to get rid of those ID-specific
helpers for the common ID management tasks. Also prevents weird custom
behaviors (like `BKE_object_copy`, who was the only basic ID copy
function to reset user count of the new copy to zero).
Part of 71219.
