PBVH_BMESH Notes #87456

New Issue

Joseph Eagar · 2021-04-13T09:33:11+02:00

Joseph Eagar commented

2021-04-13 09:33:11 +02:00

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).

The purpose of this document is to set down some ideas for the future direction of PBVH_BMESH and how we might get there.

Current state of PBVH_BMESH

PBVH_BMESH Changes

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.
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.

  Instead using a new system (see below).

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.

General PBVH Changes

The sculpt API now has a concept of sculpt vertex references (SculptVertRef) which are indices for PBVH_FACES/GRIDS and BMVert pointers for
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.

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.


typedef struct PBVHTri {
  int v[3];       // references into PBVHTriBuf->verts
  intptr_t l[3];  // loops
  int eflag;      // bitmask of which edges in the tri are real edges in the mesh

  float no[3];
  SculptFaceRef f;
} PBVHTri;

typedef struct PBVHTriBuf {
  PBVHTri *tris;
  SculptVertRef *verts;
  int *edges;
  int totvert, totedge, tottri;
  int verts_size, edges_size, tris_size;

  // private fields
  intptr_t *loops;
  int totloop, mat_nr;
  float min[3], max[3];
} PBVHTriBuf;

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:

Future Steps

To make PBVH_BMESH usable outside of DynTopo (and even sculpt), the following needs to happen:

DONE. Remove triangle restriction from PBVH_BMESH. DynTopo should dynamically triangulate any non-triangle faces as it comes across them.
PARTIAL. Refactor DynTopo into it's own API separate from PBVH_BMESH.
DONE. Cache mesh triangulations inside PBVH nodes.
DONE. Use cached triangulations for drawing.
- DONE. 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.

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). The purpose of this document is to set down some ideas for the future direction of PBVH_BMESH and how we might get there. ## Current state of PBVH_BMESH **PBVH_BMESH Changes** - 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. - 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. ``` Instead using a new system (see below). ``` - 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. ### General PBVH Changes The sculpt API now has a concept of sculpt vertex references (SculptVertRef) which are indices for PBVH_FACES/GRIDS and BMVert pointers for 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. **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. ``` typedef struct PBVHTri { int v[3]; // references into PBVHTriBuf->verts intptr_t l[3]; // loops int eflag; // bitmask of which edges in the tri are real edges in the mesh float no[3]; SculptFaceRef f; } PBVHTri; typedef struct PBVHTriBuf { PBVHTri *tris; SculptVertRef *verts; int *edges; int totvert, totedge, tottri; int verts_size, edges_size, tris_size; // private fields intptr_t *loops; int totloop, mat_nr; float min[3], max[3]; } PBVHTriBuf; ``` 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? ## Future Steps To make PBVH_BMESH usable outside of DynTopo (and even sculpt), the following needs to happen: - DONE. Remove triangle restriction from PBVH_BMESH. DynTopo should dynamically triangulate any non-triangle faces as it comes across them. - PARTIAL. Refactor DynTopo into it's own API separate from PBVH_BMESH. - DONE. Cache mesh triangulations inside PBVH nodes. - DONE. Use cached triangulations for drawing. - DONE. 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. ```

Joseph Eagar commented

2021-04-13 09:33:11 +02:00

Added subscriber: @JosephEagar