I am seeking advice regarding whether the following algorithm works (and if so, is the fastest) for a 3D line segment intersecting with a 3D cubic bezier curve:

To test for intersections of a 3D line segment with a 3D bezier cubic path segment, project the 3D cubic path segment and the 3D line segment along a plane coincident with the 3D line segment.  The chosen plane orientation should not cause the resultant 2D bezier cubic path segment to be linear unless its 3D counterpart is also linear.  By default, the orientation will be along the Y axis (a vertical plane perpendicular to the X-Z axis).

Then, perform a normal 2D bezier cubic curve/2D line intersection.  For each found T value in the 2D intersection, only keep the T values in the 3D counterpart curve having all three coordinate values that are intersected by the actual 3D line segment.

Thanks!  Good to know that any projected plane will work with this method, and that it is fast - once I create the rest of the 3D counterparts to the 2D system I already have in place, I will implement this method.

So this method does indeed work, with some caveats:

The 3D -> 2D plane projection process can introduce a loss of precision and can cause false negatives in regards to line segments.

Example: If one has a 3D line segment starting at (2.5, 2.5, 0.0) and going to (5.0, 5.0, 0.0) which happens to hit a point along a Cubic bezier path segment that crosses (2.5, 2.5, 0.0) in the exact middle of the cubic path (T value of 0.5), one would expect a an intersection at (2.5, 2.5, 0.0) with a T value of 0.5 and a U value (representing the position along the line segment from the starting point) of 0.  However, the result ends up being something like (2.4999045..., 2.4999045..., 0.0) with a T value of 0.49995.. and U of -0.0001..  This value lies outside of the line segment (and is also beyond the tolerance of my epsilon-based floating point equality checking) and would not be considered an intersection.

A possible solution is to "snap" values close to U values of 0 to 1 within a large multiple of the binary double floating point precision epsilon (from my testing, the multiple that works is 1.0E10 - this like having values like 1.0E-6 equal to 0.0).

However, I cannot simply override the U value to lie within the line segment, as I would need a full solution that contains all valid fields.  In addition, I have to check that a point at this U is indeed on the Bezier curve.  I need the Bezier's T value for a point.

I take this "snapped" U value, find the corresponding point along the line segment (which should be very close to the initial (2.49.., 2.49.., 0.0) value - in this case (2.5, 2.5, 0)) and perform a Bezier closest-T to guessed T and Point Newtonian approximation method with the 0.4999.. T value to get the corresponding Bezier T value, which should now be at or very close to 0.5.  I then confirm equality with both points to ensure a collision within the line segment and bezier curve took place.

It seems like a lot for such a special case and it might be computationally inefficient, but it appears to work.

If anybody has any other ideas in regards to dealing with floating-point precision issues such as these, please let me know.