Implement TriBvh in a more simd-efficient way. (#593)

Summary:
Pull Request resolved: #593

The current TriBvh has a few specific limitations that bother me:
1. It's not _really_ simd code, because it does most operations without simd and then only tries to assemble simd triangles with a big gather() operation at the end.  It would be much more efficient if data was actually stored packed in simd primitives.
2. It's annoying to construct a tri_bvh because it takes a very unusual data structures that aren't actually used anywhere in momentum (Eigen::MatrixX3 instead of the std::vector<<Eigen::Vector3f>> that momentum::Mesh uses, which means constructing a TriBvh for a momentum Character requires a bunch of boilerplate code).
3. It lacks an early exit for closest_point functionality based on distance, even though most closest point use cases only care if the query point is actually close (they don't need to distinguish between 1 meter and 10 meters).  This is more important than you'd think because when you're doing a distance query and you use a point which is say 1 meter away from the mesh, it will end up looking at large chunks of the bbox hierarchy since all the bboxes are roughly the same distance away (by vector norm), but if you use a query point which is right next to the mesh it only needs to look at a relatively small number of triangles.

This should be a solveable problem.  I think the original issue here is that we are trying really hard to make TriBvh use the "regular" bvh class.  However IMO in this case we should instead be optimizing for the triangle use case, because there are many more use cases for triangles specifically than for any other kind of thing you'd store in a bounding box hierarchy.  So instead, let's specialize on triangles, and store the actual triangles in the leafs in SIMD-length blocks.  This will let us quickly process the triangles 8 at a time, and gives us a nice ~2x speedup.  Also, since we're repacking the triangles anyway, we no longer need to rely on taking the input arguments as std::move(), and allows us to support multiple possible input types.

Reviewed By: jeongseok-meta, FallenShard

Differential Revision: D82481416

fbshipit-source-id: 7ef210717f457de16c13c759ecaac289b7c33f12

Author: cdtwigg

axel/CMakeLists.txt

@@ -33,6 +33,7 @@ set(headers
   axel/math/BoundingBoxUtils.h
   axel/math/PointTriangleProjection.h
   axel/math/PointTriangleProjectionDefinitions.h
+  axel/math/RayBoxIntersection.h
   axel/math/RayTriangleIntersection.h
   axel/BoundingBox.h
   axel/Bvh.h
@@ -45,6 +46,7 @@ set(headers
 
 set(sources
   axel/math/PointTriangleProjection.cpp
+  axel/math/RayBoxIntersection.cpp
   axel/math/RayTriangleIntersection.cpp
   axel/BoundingBox.cpp
   axel/Bvh.cpp