Use BMesh as default mesh representation for PBVH #89181

New Issue

Pablo Dobarro · 2021-06-15T20:46:06+02:00

Pablo Dobarro commented

2021-06-15 20:46:06 +02:00

Currently Sculpt Mode tools can directly modify data stored as BMesh, Mesh and CD_MDISP displacement. From the user point of view, these three data types look the same (geometry mesh objects). The purpose of this task is to combine all the geometry data types that are going to be used for the Freeform Mode tools into a single PBVH_BMESH type. This has the following advantages:

Having a common representation for geometry will make that all features will work exactly the same regardless of multires levels or dyntopo being active.
Direct editing of the CD_MDISP multires data causes a huge development overhead. There are also some features that rely on topology info not available in Multires that can't be implemented. See more info in #84864.
Memory usage keeps growing as implementing the design of the tools requires allocating more maps to cache the topology information of Mesh. At this point, we are probably near the memory consumption of BMesh, but with a more complex implementation.
Having a mesh representation that is shared by other modes will help to port functionality and tools between modes.
The code will be much easier to optimise and maintain. Right now there are 3 different normal updating code, PBVH iterator and rendering code. Focusing on one will be important when planning more advance features like full attribute and UV rendering in the viewport.
Instead of focusing on maintaining 3 PBVH types for meshes, we can allocate those resources to maintain other more useful PBVH types for manipulating textures, curves or GPencil strokes.

The reason to choose BMesh over other representations is:

BMesh covers all requirements listed in #85296
BMesh is the mesh representation used for dyntopo. So, regardless of the choice, a BMesh based implementation of any freeform tool must always exists.
BMesh is already used by EditMesh. Having FreeForm tools working for BMesh will allow us to have multi modal tools easily. This concept can be further expanded to a BMesh based layout and attribute edit mode.
There is already a working implementation of an optimised PBVH_BMESH available in the temp_bmesh_multires branch, which shows good results regarding performance and functionality.
There is an already tested and easy to develop for API which will make the development and maintenance of more advanced freeform tools easily.

Currently Sculpt Mode tools can directly modify data stored as BMesh, Mesh and CD_MDISP displacement. From the user point of view, these three data types look the same (geometry mesh objects). The purpose of this task is to combine all the geometry data types that are going to be used for the Freeform Mode tools into a single PBVH_BMESH type. This has the following advantages: - Having a common representation for geometry will make that all features will work exactly the same regardless of multires levels or dyntopo being active. - Direct editing of the CD_MDISP multires data causes a huge development overhead. There are also some features that rely on topology info not available in Multires that can't be implemented. See more info in #84864. - Memory usage keeps growing as implementing the design of the tools requires allocating more maps to cache the topology information of Mesh. At this point, we are probably near the memory consumption of BMesh, but with a more complex implementation. - Having a mesh representation that is shared by other modes will help to port functionality and tools between modes. - The code will be much easier to optimise and maintain. Right now there are 3 different normal updating code, PBVH iterator and rendering code. Focusing on one will be important when planning more advance features like full attribute and UV rendering in the viewport. - Instead of focusing on maintaining 3 PBVH types for meshes, we can allocate those resources to maintain other more useful PBVH types for manipulating textures, curves or GPencil strokes. The reason to choose BMesh over other representations is: - BMesh covers all requirements listed in #85296 - BMesh is the mesh representation used for dyntopo. So, regardless of the choice, a BMesh based implementation of any freeform tool must always exists. - BMesh is already used by EditMesh. Having FreeForm tools working for BMesh will allow us to have multi modal tools easily. This concept can be further expanded to a BMesh based layout and attribute edit mode. - There is already a working implementation of an optimised PBVH_BMESH available in the temp_bmesh_multires branch, which shows good results regarding performance and functionality. - There is an already tested and easy to develop for API which will make the development and maintenance of more advanced freeform tools easily.

Julien Kaspar added this to the Sculpt, Paint & Texture project 2023-02-08 10:20:48 +01:00

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Use BMesh as default mesh representation for PBVH #89181