Add a built in "PointsBVH", "LineBVH" class

[gkjohnson]

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.

[gkjohnson]

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:

• Both BVHs will modify the index buffer which will break the other BVH
• BufferGeometry.boundsTree is expected to be a MeshBVH
• computeBoundsTree generate a MeshBVH

Some possible solutions:

• A flag could be added to computeBoundsTree to indicate which type of bounds tree to generate (points or triangles).
• Overridden raycast functions could check the BVH stride to determine whether it can be used for raycasting of the object type.
• A single BVH could be allowed per BufferGeometry and possibly log a warning if the correct BVH is not generated when raycasting (that can be disabled). It seems unlikely that the same geometry object would be used for triangles / points / lines.
• A flag could be added to computeBoundsTree to create a bounds tree with a cloned index buffer to avoid conflict.
• An extra function could be added that generate a PointsBVH rather than a MeshBVH on the geometry.

geometry.boundsTree = new MeshBVH( {
  mode: POINTS, // TRIANGLES, LINES
} );

[gkjohnson]

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
• Raycast functions must account for render object type

The MeshBVH functions that assume triangles must also be implemented for points / lines:

• Make a MeshBVHBase that implements stubs for expected functions.
• Raycast / raycast first can be implemented (though maybe not as optimally) with shapecast.

[gkjohnson]

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.

[gkjohnson]

• Add a TriangleBVH base class
• Inherit with PointsBVH, LineBVH, MeshBVH
• Points and line bvhs are based on triangles under the hood
• only support raycast initially
• support both screen and world intersection
• rearrange the og index buffer based on bvh adjust
• add field to compute options to which bvh to construct
• webworker can implicitly use the right approach based on same options
• continuous lines must be converted to segments (or does it? Can we have a "virtual" index that is resolved to the appropriate item by another function? This would be the "indirect" buffer)
• Maybe "indirect" can "just work" without making a new index buffer?

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