Cubic bezier curves and straight (horizontal or vertical) bezier curves intersection

[harjis]

Hi!

First of all great work with the library! Has saved me a ton of time.

The issue I have is an intersection with cubic bezier curves and straight horizontal or vertical bezier curve. My code is as follows:

    const r = 150;
    const k = 0.55228;
    const circleArc = [
      { x: r * 2, y: r }, // Intersection point
      { x: r * 2, y: r + k * r },
      { x: r + k * r, y: r * 2 },
      { x: r, y: r * 2 }
    ];
    const straightLine = [
      { x: r, y: r },
      { x: r * 2, y: r }, //Intersection point
      { x: r * 2 + k * r, y: r },
      { x: r * 4, y: r }
    ];
    const circleArcBezier = new Bezier([...circleArc]);
    const straighLineBezier = new Bezier([...straightLine]);

    console.log(circleArcBezier.intersects(straighLineBezier)); // Empty array

To my understanding the lines should intersect each other at point { x: r * 2, y: r }. Also If I change the straight line even 1px the intersection is detected.

Happens in Chrome Version 58.0.3029.110 (64-bit) and Firefox 53.0.3 (64-bit) at least with version 2.2.3

[Pomax]

Using a bezier curve to represent a straight line's a little odd, but that should still work. It might be IEEE floating points causing a problem here, but I'll have to log what t values and segment coordinates the algorithm comes up with the know for sure.

[rogercampos]

Having the same issue. Still, awesome lib! 👍

[Pomax]

I'll have a look to see if I can improve that, but the main reason for this is that it's trying to resolve the intersection as a curve/curve intersection rather than going "this is a degenerate curve, I should just check for line intersection".

[rogercampos]

I understand it doesn't make sense to use bezier curves when you really have straight lines, but i'm creating a tool where the user can control the shape of the grid (built with cubic bezier lines), so it's possible this happens, sometimes:

[Pomax]

I didn't say it doesn't make sense, I said the code needs to know that it's dealing with a degerenate curve, and that it should automatically fall down to line/curve intersection instead of trying to do the iterative curve/curve intersection detection, which is far more sensitive to IEEE floating point rounding errors.