Adds ray Bezier/NURBS surface intersection routines

[jcs15c]

Summary

• This PR adds various intersection routines between rays and Bezier/NURBS curves/surfaces, along with relevant tests. NURBS intersection routines first decompose patches into Bezier objects, from which intersections are recorded through recursive subdivision. Segments are used as the base case for curves, and bilinear patches are used as the base case for surfaces.
  • intersect(Ray2D, BezierCurve)
  • intersect(Ray2D, NURBSCurve)
  • intersect(Ray3D, BezierPatch)
  • intersect(Ray3D, NURBSPatch)
• Additionally, the following capabilities have been added to facilitate the above functions
  • A primal::Line class analogous to primal::Ray but extends in either direction from the origin. This will reduce redundant calculation in later winding number methods.
  • A primal::BezierPatch::isBilinear() method that returns if a surface is approximately bilinear according to its control points.
  • Many drop in replacements of std::vector with axom::Array.
  • A few extra methods in KnotVector to simplify iterating over knot spans.
  • A fix to intersect(Ray2D, Segment) to catch some additional edge cases
• Additionally fixes an error in a few winding_number calls.

[Arlie-Capps]

Thanks for this, Jacob!

[kennyweiss]

Thanks @jcs15c for this excellent contribution with extensive testing.

Please don't forget to update the RELEASE_NOTES with this new contribution and with the bugfix for the Ray-Segment intersection.

[kennyweiss]

Please improve this comment.

Presumably, in general position, a line will intersect a box along a (possibly empty) line segment.
Should this parameter be a segment?

Alternatively, would the user only be interested in a (single) point of intersection? If so, does this function make any guarantees about which intersection point this is?

[jcs15c]

This method follows the analogous ray-bb intersection routine, which returns the intersection with the minimum t value as the returned point. While doing this in the line case isn't quite as conceptually straightforward, since that parameter will be negative when the origin is interior to the bounding box, it's consistent, and does serve as some kind of guarantee.

At the same time, my own usage of this method doesn't even use the point of intersection at all, so it's sort of a waste to compute it. With this in mind, I'll update the comment to reflect the behavior of this method, but also write a new one that doesn't compute the intersection in physical space.

[kennyweiss]

Minor: Is normalization required for the intended use of Line? Are there cases where we might not want to normalize the direction vector?

[jcs15c]

Not necessarily, but the primal::Ray class does too, and I can come up with a couple reasons why it could be useful. For example, the magntude doesn't have a useful meaning inherently, and making it a unit vector makes the math objects have a consistent parameterization, which is more useful in algortihms.

[kennyweiss]

Minor (preference, not requirement):
The output in this function might read a bit more clearly using fmt instead of stringstream

[kennyweiss]

What intersections would be get with a line that intersects a non-planar patch, e.g.:

  BezierPatchType bilinear_patch(1, 1);
  bilinear_patch(0, 0) = PointType({0, 0, 0});
  bilinear_patch(1, 0) = PointType({0, 1, 0});
  bilinear_patch(1, 1) = PointType({1, 0, 0});
  bilinear_patch(0, 1) = PointType({1, 1, 2});

  RayType ray(PointType({0, .5, 0.}), VectorType({0,1,1}));

i.e., (if I got it right) the intersection is along the entire patch along its isocurve v==.5

(This might be captured below in the "infinitely many" case)

[jcs15c]

Yep! This is explicitly handled in those cases, where the entire intersection is both a v or a u intersection.

[kennyweiss]

Suggestion: Consider adding a note about why this case is difficult for GARP

[jcs15c]

This case has a double root in the quadratic that needs to be solved, so I've actually moved this test and others like it to the dedicated test block.