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.
This commit introduces a number of changes to make PBVH and related
attribute lifecycle more predictable.
A common method, `BKE_sculptsession_free_pbvh` is introduced to manage
freeing related resources that are stored in `SculptSession`
Prior to this commit, the `active_vert_` attribute was only ever
changed when a raycast successfully hit the mesh. This commit changes
the behavior to not store a stale reference in the following cases:
* When dyntopo is enabled or disabled
* When a mesh with the subdivision modifier is subdivided further
* When the sculpt level of a subdiv modifier is changed
* When the subdivision modifier is removed from a mesh
Pull Request: https://projects.blender.org/blender/blender/pulls/126341
Part of #118145.
These days we aren't really benefiting from making PBVH an opaque type.
As we remove its responsibilities to focus it on being a BVH tree and look
to improve performance with data-oriented design, that will only become
more true.
There are some other future developments the current header structure
makes difficult:
- Storing selections of nodes with `IndexMask` for simpler iteration, etc.
- Specialization of node type for each PBVH type
- Reducing overhead of access to node data as nodes get smaller
- General C++ cleanliness and consistency
This PR moves `PBVH` to `blender::bke::pbvh::Tree` and moves `PBVHNode`
to `blender::bke::pbvh::Node`. Both are classes visible to elsewhere in Blender
but with private data fields.
The difficult part about the change is that we're in the middle of a transition
removing data from PBVH. Rather than making some data truly private I
chose to just give it the `_` suffix, since it will ideally be removed later.
Other things should be class methods or implemented as part of friend
classes. But the "fake" private status is much simpler for now and avoids
increasing the scope of this PR too much. Though that's a bit ugly, there's a
straightforward way to resolve these issues-- it just looks like the sort of
inconsistency you'd expect in the middle of a large refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/124919
After recent commits, the .cc file is only used for actual object data
evaluation in the depsgraph, and the header is only used for the old
DerivedMesh data structure that's still being phased out.
Grouping the legacy DerivedMesh code in the same place helps keep
the actively maintained code clearer and clarifies what we are hoping
to remove in the future.
This requires adding a destructor and deleting move and copy assignment
for SculptSession, because (for now at least) we want to keep the PBVH
as an opaque type (though with one exception for including pbvh_intern.hh
in paint.cc for the SculptSession destructor).
Pull Request: https://projects.blender.org/blender/blender/pulls/121227
The main motivation for this is that it's part of a fix for #113377,
where I want to propagate the edit mesh pointers through copied
meshes in modifiers and geometry nodes, instead of just setting the
edit mesh pointer at the end of the modifier stack. That would have
two main benefits:
1. We avoid the need to write to the evaluated mesh, after evaluation
which means it can be shared directly among evaluated objects.
2. When an object's mesh is completely replaced by the mesh from another
object during evaluation (with the object info node), the final edit
mesh pointer will not be "wrong", allowing us to skip index-mapped
GPU data extraction.
Beyond that, using a shared pointer just makes things more automatic.
Handling of edit mesh data is already complicated enough, this way some
of the worry and complexity can be handled by RAII.
One thing to keep in mind is that the edit mesh's BMesh is still freed
manually with `EDBM_mesh_free_data` when leaving edit mode. I figured
that was a more conservative approach for now. Maybe eventually that
could be handled automatically with RAII too.
Pull Request: https://projects.blender.org/blender/blender/pulls/120276
Use the standard "elements_num" naming, and use the "corner" name rather
than the old "loop" name: `verts_num`, `edges_num`, and `corners_num`.
This matches the existing `faces_num` field which was already renamed.
Pull Request: https://projects.blender.org/blender/blender/pulls/116350
The function really just gives an index mask of all the faces in the
provided nodes. The multires usage of the function didn't need that,
since it just passed all nodes. Also pass the SubdivCCG directly rather
than the PBVH. And rename the function to make this clearer.
"mesh" reads much better than "me" since "me" is a different word.
There's no reason to avoid using two more characters here. Replacing
all of these at once is better than encountering it repeatedly and
doing the same change bit by bit.
Automatic memory management and clearer ownership! Requires
removing `MEM_CXX_CLASS_ALLOC_FUNCS` from `MeshRuntime`,
but that's used very inconsistently anyway, and `MeshRuntime` isn't
that large.
These updates are used to recalculate normals and average values between
grid boundaries during multires sculpting. In main the affected faces
are passed as an array of pointers. Using an `IndexMask` instead reduces
memory usage by 4x per affected face (8 byte pointer to 2 byte integer),
simplifies iteration and threading, and can also improve performance.
Finding which faces are affected is now multithreaded, with its runtime
changing from 0.63 ms to 0.12 ms in a simple test sculpting on a portion
of a 1 million face grid.
Also switch to VectorSet instead of GHash for finding affected adjacent
elements. That's a friendlier data structure that probably has better
performance as well.
Inlining the functions is simpler nowadays, since there are utility
functions to copy spans and tag the mesh caches dirty. Also use an
array instead of a raw pointer for multires.
Resolves#103789
Move object runtime data to a separate header and allocate it separately
as `blender::bke::ObjectRuntime`. This is how node, mesh, curves, and
point cloud runtime data is stored.
Benefits:
- Allow using C++ types in object runtime data
- Reduce space required for Object struct in files
- Increase conceptual separation between DNA and runtime data
- Remove the need to add manual padding in runtime data
- Include runtime struct definition only in files that require it
Pull Request: https://projects.blender.org/blender/blender/pulls/113957
Add three cached topology maps to `Mesh`, to avoid computations when
mesh data isn't changed. Choosing the right maps to cache is a bit
arbitrary, but generally we have to start somewhere. The limiting
factor is memory usage (all the new caches combined have a
comparable footprint to a UV map).
For now, the caches added are:
- Vertex to face corner
- Vertex to face
- Face corner to face
These caches are used in quite a few places already;
- Face corner normal calculation
- UV value merging
- Setting sharp edges from face angles
- Data transfer modifier
- Voxel remesh attribute remapping
- Sculpt mode painting
- Sculpt mode normal calculation
- Vertex paint mode
- Split edges geometry node
- Mesh topology geometry nodes
Caching topology maps means they don't have to be rebuilt every time
they're used. Meshes copied but without topology changes can share
the cache, further reducing re-computations. For example, FPS with a
large mesh using the "Corners of Vertex" node went from 1.8 to 2.3.
Entering sculpt mode is slightly faster too.
There is some obvious work for future commits:
- Use caches in attribute domain interpolation
- More multithreading of second phase of map building
- Update/build caches eagerly in some geometry nodes
Pull Request: https://projects.blender.org/blender/blender/pulls/107816
The goal is to move to more data oriented design, reducing memory
usage and simplifying code by clarifying data access, avoiding
unnecessary levels of abstraction, and reusing code.
- Simplify threading with the C++ threading API
- Pass the faces to update with an IndexMask instead of a pointer array
- IndexMask uses less memory and simplifies masking and iteration
- Store the grid to face map with indices instead of pointers
- Now this is exactly the same as `build_loop_to_face_map`
Using ClangBuildAnalyzer on the whole Blender build, it was pointing
out that BLI_math.h is the heaviest "header hub" (i.e. non tiny file
that is included a lot).
However, there's very little (actually zero) source files in Blender
that need "all the math" (base, colors, vectors, matrices,
quaternions, intersection, interpolation, statistics, solvers and
time). A common use case is source files needing just vectors, or
just vectors & matrices, or just colors etc. Actually, 181 files
were including the whole math thing without needing it at all.
This change removes BLI_math.h completely, and instead in all the
places that need it, includes BLI_math_vector.h or BLI_math_color.h
and so on.
Change from that:
- BLI_math_color.h was included 1399 times -> now 408 (took 114.0sec
to parse -> now 36.3sec)
- BLI_simd.h 1403 -> 418 (109.7sec -> 34.9sec).
Full rebuild of Blender (Apple M1, Xcode, RelWithDebInfo) is not
affected much (342sec -> 334sec). Most of benefit would be when
someone's changing BLI_simd.h or BLI_math_color.h or similar files,
that now there's 3x fewer files result in a recompile.
Pull Request #110944
Implements the rest of #101689, after 5e9ea9243b.
- `vdata` -> `vert_data`
- `edata` -> `edge_data`
- `pdata` -> `face_data`
- `ldata` -> `loop_data`
A deeper rename of `loop` to `corner` will be proposed as a next
step, and renaming `totvert` and `totedge` can be done separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/110432
Implements part of #101689.
The "poly" name was chosen to distinguish the `MLoop` + `MPoly`
combination from the `MFace` struct it replaced. Those two structures
persisted together for a long time, but nowadays `MPoly` is gone, and
`MFace` is only used in some legacy code like the particle system.
To avoid unnecessarily using a different term, increase consistency
with the UI and with BMesh, and generally make code a bit easier to
read, this commit replaces the `poly` term with `poly`. Most variables
that use the term are renamed too. `Mesh.totface` and `Mesh.fdata` now
have a `_legacy` suffix to reduce confusion. In a next step, `pdata`
can be renamed to `face_data` as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/109819
Split much of BKE_pbvh.h into BKE_pbvh_api.hh.
BKE_pbvh.h is included by BKE_paint.h, which in
turn is included by large amounts of code including
RNA.
This makes it extremely difficult to change
or clean up the PBVH API, since each modification
of BKE_pbvh.h can take 20-30 minutes to compile,
even on a quad-core system with an SSD. This
commit fixes that by moving most of BKE_pbvh.h
into another file and just having the core,
external-facing interfaces in BKE_pbvh.h.
