Lately there's been interest in users (and some developers) in adding more topological workflows to sculptmode and/or refactoring editmode to use PBVH_BMESH. This will require much refactoring of the code, some of which has already happened as part of the DynTopo cleanup project but not everything.
## Current state of PBVH_BMESH
Currently I've made the following modifications to PBVH_BMESH in the temp_bmesh_multires branch:
# Customdata interpolation is now supported for DynTopo.
# PBVH drawing now sets GPU attributes (mostly) correctly (still need to support multiple UV layers properly).
# Vertices now have a special MDynTopoVert customdata structure for storing original data.
# PBVHNode->bm_unique_verts/bm_other_verts/bm_faces now use a special GSET wrapper that caches entries in a flat array for fast iteration.
# The sculpt API now has a concept of sculpt vertex references (SculptVertRef) which are indices for (PBVH_FACES/GRIDS) or BMVert* pointers
(PBVH_BMESH). You can convert between sculpt vert refs and mesh indices with BKE_vertex_index_to_table and BKE_table_index_to_vertex.
To prevent implicit casts to/from 32-bit ints, SculptVertRef is a structure:
```
struct SculptVertRef { intptr_t i}
```
# The same idea is used for face references too with a similar SculptFaceRef structure.
# Original data is no longer tied to the undo system (at all) for PBVH_BMESH.
# Triangles are no longer cached in an ad-hoc way in node->bm_ortri and bm_orco.
# Face sets are supported.
# The PBVH tree is now split during strokes, except for a few tools like draw sharp.
# PBVH nodes are now joined together at the end of a stroke if they lose too much topology during dyntopo. This
keeps the tree from entering a pathological state of lots of little nodes with few if any triangles.
# There is an option to draw sculpt colors in flat cells instead of the usual vcol interpolation.
## Storing Triangulations In Nodes
We should cache triangles in PBVH nodes. I've roughed out a simple api for this in temp_multires_bmesh already (there were a few truly evil bugs that necessitated it). The new data structures are below.
```
struct PBVHTriBuf {
struct PBVHTri *tris;
SculptVertRef *verts;
int tottri, totvert;
}
struct PBVHTri {
int v[3];
SculptFaceRef f;
float no[3];
}
```
I've kept things as simple as possible (I was planning on doing this a lot later). Triangulations are generated lazily as with the old bm_ortri code, only instead
of flagging nodes as dirty by freeing the triangulation a new PBVH_UpdateTris flag is set in node->flag.
Some open questions are:
# Should we use this for all PBVH types? If so, what should the related SCULPT_XXX api look like?
# How much data should we cache in BVHTri? For example if we want to support splitting by UV island we'll need to store face corner loops.
## Future Steps
To make PBVH_BMESH usable outside of DynTopo (and even sculpt), the following needs to happen:
# Remove triangle restriction from PBVH_BMESH. DynTopo should dynamically triangulate any non-triangle faces as it comes across them.
# Refactor DynTopo into it's own API separate from PBVH_BMESH.
# Cache mesh triangulations inside PBVH nodes. This is partly completed.
# Use cached triangulations for drawing.
## Support indexed drawing in PBVH draw code to save GPU bandwidth
## Generate triangulations that are split by UV islands.
## Add support for fragment shader based flat face shading to the draw system.
This will help save GPU bandwidth for flat shaded meshes by not having to duplicate the vertex data for every single triangle.