Implement ray-polymesh intersections

[hyazinthh]

Introduces methods for intersecting Ray3d with PolyMesh directly, without having to build a k-d tree:

// Filter for hit candidates, returns true for valid intersections and false otherwise
public delegate bool RayHitFilter(in RayHit3d hit);

// Computes all intersections and returns them (arbitrary order)
public List<RayHit3d> GetRayIntersections(Ray3d ray, RayHitFilter filter = null);

// Computes first (i.e. closest to ray origin) intersection
public bool TryGetRayIntersection(Ray3d ray, out RayHit3d hit, RayHitFilter filter = null);

Opted to not follow the Aardvark.Base API as it is a bit convoluted and does not have any methods reporting multiple intersections (which was explicitly requested for this feature). RayHit3d contains all the information anyone would want to query.

Points I'd like to discuss:

1) Are overloads for checking for any intersection required? E.g. Aardvark.Base intersection methods usually have an overload that returns if any intersections were found, returning bool.

2) Is TryGetRayIntersection named appropriately? It returns the first intersection, not any.

3) Do we need overloads that only return V3d (akin to Aardvark.Base)? This is obviously already included in RayHit3d and the benefit of only returning a V3d instead of a 56 byte sized struct does not warrant cluttering the API in my opinion. The intersection tests themselves will dominate the total cost anyway.

4) Intersection methods in Aardvark.Base have an explicit tmin and tmax parameters. Adding them here directly would be superfluous since the same functionality can be achieved by using a filter.

5) For triangulated faces, the intersection test is simple. For faces with more than 3 vertices Face.Polygon3d is used which copies the vertices into a separate array. The intersection with the polygon also allocates memory as the polygon is triangulated internally. Not sure if this can be done more efficiently without implementing a new general ray - polygon intersection method.

[luithefirst]

Opinion on your points:

• (1) I don't think we need an AnyHit method. I also guess naming and overloads might get confusing if we add all these variations (same as with 3.).
• (2) Methods bool return type and out argument are often named TryGetSomthing in .net, but I'm not sure if this a convention that is suggested. In our case, I don't find it very intuitive. I would vote to simply name it Intersects like we also have in Aardvark.Base for e.g. Plane3d.Intersects(Ray3d) and many others. GetRayIntersections is fine I would say since it is for more advanced scenarios.
• (3) I don't think we need overloads with a V3d in addition to RayHit3d.
• (4) tmin/tmax arguments allow for efficient early exits without a callback and would give improved performance in specific uses cases such as with acceleration structures (kd-trees, bb-hierarchies) where typically only specific range needs to be interested. However, I don't see this as a must here.
• (5) The optimization for triangles is nice and I would not go for an optimization at this point for polygons.

Other remarks:

• Please add a comment to GetRayIntersections that the hits are unordered and within a range of +/- infinite.
• The Aardvark.Base Intersects methods a default tmin/tmax ranges of [0, double.MaxValue]. I find it a bit inconvenient if TryGetRayIntersection now would also return hits behind the origin and that the user needs to add a filter to avoid this in the use case I would consider "standard". This would suggest considering adding an overload with a tmin/tmax range and setting the default like with all other methods. (Preferred over limiting to positive hits or other overload possibilities).
• I saw that we have a limitation with identifying the hit coordinate and part index in the case of general polygons. It also looks like the polygon intersect method does not provide you with the triangle index and coordinates, so this even cannot be handled conveniently on the user side? In general mesh intersection use cases I would see getting specific mesh attributes (material, texture, ...) as a requirement. In kd- tree intersection we use the Part as face-triangle index and then there is an additional SetObject.Index for the face index, but this cannot be used here without changing RayHit3d or adding an additional out argument. I don't see an ideal easy solution for this. We should at least add a documentation of this behavior in the comments.
• Please extend the comment of Contains with the requirement that the mesh is expected to "closed" (or I think "manifold" is a more mathematically correct term, please check).

[hyazinthh]

• Renamed TryGetRayIntersection to Intersects
• Added explicit parameters for the ray interval (default is [0, infinity] in both cases)
• Added more descriptive comments
• Fixed Intersects() to consider closest intersection to be the one with smallest absolute t value.

I don't think it's a limitation that the triangle index and barycentric coordinates are not returned for general polygons. If an intersection with a general polygon is found, this information simply is not there. Internally, the polygon gets triangulated to compute the intersection, but conceptionally there are no triangles and therefore the hit information cannot contain a triangle index and barycentric coordinates. If the user is interested in ray - triangle intersections, they must make sure the mesh is triangulated beforehand.