FS#2694 - Modify > Breakout: Fails on no intersections for a near tangent of an ellipse
Follow up of FS#2685
Tested with 3.23.4 trial on Win 7 but probably not related to OS
With the example file attached to the related forum topic p48576
D2 fails for the upper right ellipse in magenta indicating the segments near (13.55, 3.90) or (13.457, 3.83).
ShapeAlgorithms.getIntersectingShapes() locates 6 intersecting shapes ...
... That is not the issue here.
But 2 of those lines return no intersection points with the ellipse.
Then ShapeAlgorithms.autoSplit() for the given positions removes both segments combined as one segment.
Line (13.4954, 3.8817)-(11.7277, 2.8611) should be considered as a tangent line.
Similar as being tangent to the lower left ellipse in magenta
The calculated discriminant of the quadratic equation is -6.927791673660759e-12
Negative and then there are no real roots to solve for a position of intersection.
The line passes only at about 1.0097e-13 units outside the ellipse.
The same occurs when indicating the segments near (13.79, 3.51) or (13.68, 3.44).
Line (13.7454, 3.4487)-(11.9777, 2.4281) is also nearly a tangent line.
Here the discriminant results in -6.927791673660814e-12
Note that in this case the two tangents in question are almost vertical when transformed into the ellipse’s local coordinate system. dx is almost nothing after transforming.
→ Best handled as a special case. Equations may choke.
Also best practice for near horizontal tangents.
But this doesn’t solves the nearly a tangent condition for all cases.
Increasing discEps is not a solution because:
!! We cannot quantify “almost a tangent” by the degree to which the discriminant of the quadratic equation differs from zero !!
That is a fix for accumulated errors in Floating Point.
Where the result should be plus zero and not at the negative side of zero.
Knowing that transforming to localize already introduces minor errors.
Even rotating by zero rads does alter things (FS#2635)
Regards,
CVH