Open gkjohnson opened 3 years ago
One bit of complexity here when assigning a BVH to the geometry is that the same geometry can be used for a Points or a Mesh object leading to a conflict when building a mesh BVH vs a points BVH:
Some possible solutions:
geometry.boundsTree = new MeshBVH( {
mode: POINTS, // TRIANGLES, LINES
} );
The following functions must be changes to consider the stride of the element (1 for points, 2 for line segments, 3 for triangles):
computeTriangleBounds
(could be optimized out completely for points)partition
The MeshBVH functions that assume triangles must also be implemented for points / lines:
MeshBVHBase
that implements stubs for expected functions.Perhaps an abstraction layer around primitives can be made such that no performance is lost -- or a fast path is provided for supported primitives. Another good use case would be to encapsulate arbitrary n-gons in an arbitrary javascript structure for something like CSG.
Note that the item bound ranges only need to be retrieved on build and refit.
~Question: how to dispose? Have "dispose all" argument?~ Dispose shouldn't be needed
Upgrade the logic in point cloud example to be officially supported and adjust the BVH building logic to support points and improve the memory footprint over the example workaround that uses degenerate triangles and a duplicated geometry.
It might be possible to make a minimal change in the BVH building that will consider a "range" of points when sorting indices for the bounds. For "triangles" the range or stride is 3 but maybe it could be made variable so points (1) and lines (2) could be used.