Breakout line segment glitch

[Chuckk]

Greetings!
I installed the latest edition (3.32.3.0 (3.32.3)) (Windows 11pro) and now the Breakout line segment is not working properly. In the below example I am trying to draw a cutaway of a part using isometric projections. In the example I am trying to trim the purple circles, but they ether don't trim at all, trim a section I didn't click, or removes the circle entirely. I have literally drawn hundreds of parts using this method using previous editions and now its not working. Any ideas on what is going on?

[andrew]

Please check the options toolbar at the top while using the tool. Make sure that "Remove Segment" is checked and "Line Selection Mode" is not checked.

[Chuckk]

Hi Andrew, I looked and "remove Segment" is checked and "Line Selection Mode" is not checked. Tried it again and still having the same problem.

[CVH]

Hi, and welcome to the QCAD forum BTW

I can replicate the weird functionality with trimming parts of the magenta Ellipse entities at the right.

Probably related to updates to the ellipse resources since QCAD 3.32.0.
Some were moved to the Pro or proprietary realm but it can be some QSharedPointer issues too.
Unable to verify what goes wrong because a least some parts are proprietary code now.

Then I doubt that the isometric projection of a circle resembles an ellipse.
The projection of the circle axes are not orthogonal, major and minor axes of ellipses are always orthogonal.


Tangent lines to ellipses are at least a mathematical problem.
Presumed is that the internal fixed absolute tolerances up to 1e-4 in handling these are coarse enough.
Even for these small shapes.

But a key mathematical resource may fail ... Refer to: REllipse.getVectorTo(p) exceptions
Several other resources rely on that.
And that may be an issue for any intersection, normal or tangent with an ellipse or for points on an ellipse.

Another issue I noticed long time is that full Ellipse entities have:

• Start parameter 0 and End parameter 360
  Start angle 0 and End angle 0.000!

A full Ellipse entity is in fact a 360 degree Ellipse-arc entity.
For angles a 360 degree value may get replaced with zero or not depending the used code, a zero sweep may be regarded as full.
Something similar exists for Arc entities: Odd circle ... Full circular arc


The solution is then straightforward.
Divide (DI) each full Ellipse entity up in 2 Ellipse-arc entities.
It may be required that intersecting lines are really crossing, elongate them a bit.

If you attempt DI at the intersections with the blue line under QCAD 3.32.3 it is cut up at the minor points.
Proving how wrong it can be.
getVectorTo(p) where p is one of the intersection with the blue line returned a minor point as cutting position.

One half selected, I use a two color scheme for selected entities

DividedFullEllipse.png (5.77 KiB) Viewed 6994 times

Another solution is to explode your Ellipse entities into bulging Polyline entities.
Visit the Application Preferences for how many segments per full ellipse.


I don't have these issues with Ellipse entities anymore since I started using the resources also presented in POC_NearestPointOnEllipse.js
The outcome is no longer based on guessing and is always as exact as possible.
The 'far-side' perpendicular points ABC for Ellipse entities is another enhancement among several others.
Seems that nobody is interested in this but me.

But all these things are implemented under my licensed version QCAD 3.27.6.
I had/have more general GUI specific issues with all later versions up to the most recent.

Regards,
CVH

[Chuckk]

HI CVH,

Thank you for your response. Unfortunately I am not familiar with running scrips, or how to use them. I was hoping for a simple setting issue but that doesn't seem to be the case. I work in R&D and sometimes make dozens of drawings a day. Most only require simple 2d drawings, however more complicated parts require 3d or cutaway views, which made QCAD perfect for my application. I need a simple solution that is permanent, or only one or two clicks. Vary frustrating to use a product for many years only to loose a feature I use daily. Sadly, unless QCAD fixes this quickly, I will probably start looking at other software.
Thanks again, I appreciate your detailed response!

[CVH]

Update:
Probably boils down to Ellipse - Line intersections failing in the latest releases.
Filed a bug report with an example file: FS#2685

Ellipse - Circle intersections work well for example.
It is not my task to examine all possible combinations.

Vary frustrating to use a product for many years only to loose a feature I use daily.

The issue with D2 seems to be limited to the Ellipse - Line case.
But other methods relying on the same resource like DI may fail too.
Two methods to work around were presented.

Regards,
CVH

[CVH]

Update:

Traced back to RShape.getIntersectionPointsLE(line1, ellipse2, limited); (Where suffix 1-2 are swapped)
Line 771-776 verifies if the line is (almost) a tangent. (current reference)

• ellipse2.getTangentPoint(line1); returns the ellipse center.
  Which is a valid RVector and is therefore wrongly considered the only solution.
  Not quite the center of the ellipse, the returned point is 3.972e-15 away from it what falls within RS.PointTolerance.

I then verified why getTangentPoint comes to that conclusion ...
... Because the blue line is not a tangent at all, it clearly crosses the ellipse twice.

TestCodeJS+data.txt

JS code injected in a custom script.
Numerical values included.

(6.4 KiB) Downloaded 76 times

Mimicking the math in JS the discriminant of the quadratic equation is 0.00021697730054059171
Positive, what means that there are 2 real roots ... 2 intersections with the ellipse ... Thus not a tangent.
But this is considered to be ZERO in line 1200-1209 (current reference)
What would mean that there is but one intersection or one single point of contact if that was true ... A tangent.

Such faults are widespread ... A discriminant equal to zero in the literature means exactly or almost zero.
Here it is compared with zero, given a tolerance of 0.001 units, and +0.0002.. matches within tolerance.

Floating Point math has it limitations and we should indeed allow some minor tolerance.
But in no way we can use a certain deviation from zero to define 'almost' a tangent.
And as said: "Tangent lines to ellipses are at least a mathematical problem." (Because of several other incorrect shortcuts)
Still, in the region between +0.001 to -0.001 is not appropriate.

I have to point out that we don't have a complete quadratic equation.
Parameter B is almost zero (-2.824192708992169e-16) what leaves A²x+0x+C=0.
The reason is that the Y-intercept in double c is almost zero: -3.913536161803677e-15 (Note: y-intersept is a typo)

No line that (almost) crosses an ellipse center can be a tangent.
Or the ellipse has to be so small that it rather looks like a point in any zoom state.

If you test that for hundreds of lines crossing the center ...
... You might discover that for the intersections inside the ellipse evolute a correct intersection point is returned.
If any, typically near both minor points.
The slope of the normalized lines becomes large with its limit at infinity.

A solution would be:

Code: Select all

    // y-intercept:
    double c = lineNeutral.getStartPoint().y - m * lineNeutral.getStartPoint().x;

    double a = getMajorRadius();
    double b = getMinorRadius();
    
    // A line that intersects the minor axis (=Y normalized) strictly in between both minor points can not be a tangent:
    if (abs(c) < 0.99 * b) {    // Exploiting a size relative tolerance
        return RVector::invalid;
    }  
    

I referenced this follow up in the bug report.

Regards,
CVH

[CVH]

Update:

Please refer to the bug report for a closed format 'near tangent' to ellipse solution.

It exploits the condition for an endless line with equation y = mx + c to be a tangent to a standard full ellipse x²/a² + y²/a² = 1
as given by c² == a²m² + b².

It then allows a little play on the y-intercept value c and returns the nearest point on the ellipse.

A fixed or size relative tolerance is not yet defined but I would advice to use the same for a normalized vertical line.
Not aware how this reacts with other (fixed) tolerances concerning ellipses.

Regards,
CVH

[CVH]

Hi,

Should be (kinda) fixed in the upcoming release or snapshot.
See QCAD Changelog and/or FS#2685


Not convinced with the related commits 0428c5e and 9920b6e.

The riddle of how to quantize 'nearly a tangent to an ellipse' was solved in my last comment on the bug report.
Equally tolerant for just outside, barely touching, exactly tangent or just crossing twice but really close together.


getIntersectionPointsLE(...) does no longer rely on getTangentPoint(line)
It is now the second that relies on the first.


getIntersectionPointsLE(...):
Fully rewritten but basically doing the things the same way expect calling getTangentPoint() upfront.

For a line fully outside an ellipse there will be no roots for the quadratic equation ... Thus no solutions, even when really nearby.
Fails for a line that is almost a tangent without actually touching the ellipse.

In other cases it configures 2 solutions.
These may be almost or exactly the same when sqrtDisc is (nearly) zero ...
... Only zero for a line that is mathematically exactly a tangent ... Something that almost never is true.

A second solution is discarded when nearly the same as the first.
For that it does not compare the final intersections in situ to be within some tolerance.
It compares the relative position along the line where t=zero at the start and t=1.0 at the endpoint.
The tolerance on t is thus also related with the overall length of the line segment.

If there are 2 almost equal solutions the best possible answer is somewhere in between ... The first of two is arbitrary.


getTangentPoint(line) calls getIntersectionPointsLE(...)
That returns an array with none to two solutions at the most.
From the above: More than one solution will not occur for a near tangent that is actually crossing twice.
Then I see no need for verifying more than 1 candidates.

The verification is based on a Scalar product of two vectors what is zero when these are orthogonal.
But it is also related to the product of the magnitudes or lengths of the two vectors.
Simply comparing the Scalar product with zero is not a uniform way to verify if the line is orthogonal to the normal.


Seen that ellipses are involved, any tolerance is really strict in both code snippets: 1e-9 or 1e-6.

Regards,
CVH

[CVH]

Chuckk,

Not convinced with the related commits

The core of getIntersectionPointsLE(...) is revised again.

I still have to evaluate the full impact of this modification.
It seems more like patches on a patch than a revision.

Tangent to an Ellipse should not be that hard but can mathematically not be achieved using floating point in all cases.
'Almost' tangent is not really defined as that is tangent to an offset shape very near an ellipse.
The function of such an offset is an algebraic curve of order eight, a mathematical dragon that fills a page.
It is practically impossible to solve for a tangent of that in floating point.

I see the route that a nearby parallel is a real tangent as the easiest way to quantize 'Almost tangent'.
- A line goes trough a distant point and is nearly a tangent of an ellipse.
- A mathematical tangent to the ellipse with the same angle, one of the 2 parallels, just misses the distant point.
- The minute distance between two parallels is straightforward and must then comply with an allowed tolerance.

Then the close-by mathematical point of tangency can be used as intersection point with the ellipse.
What can be use as splitting or trimming point, all in the sense: 'As good as it gets' in floating point.

Regards,
CVH

[CVH]

Chuckk, Andrew,

Using the latest release (3.23.4), D2 still has problems with breaking out some obvious ellipse segments in your example file.

Found intersections of lines and the ellipse, and thus breaking points, are already much better.

D2 and indicating near segments with the red arrows removes the ellipse shape completely.
Undo (OO) reverts back to the original.

D2 failing QCAD 3_32_4.png (7.12 KiB) Viewed 86 times

This is probably unrelated to intersections with an ellipse because we can snap to all 8-9 obvious intersections points for this case.


At the high side it is suspected to be a case of a tangent line but then not actually crossing, nearly but just outside the ellipse.
No snapping to an intersection occurs for the two tangent lines.

D2 failing QCAD 3_32_4 high.png (6.31 KiB) Viewed 86 times

For the segments indicated with orange this can be fixed with trimming the line to the ellipse (RM).
But trimming (RM) the tangent for red results again in removing the ellipse shape completely with D2.


Evaluating this setup mathematically in terms of the backing code may shed some light when and why this happens.
To my knowledge, nearly a tangent to an ellipse but just outside is still not accounted for.
A true tangent, or nearly but crossing twice extremely close together should not be a problem.
For the latter, the code returns only one of the two positions, arbitrarily, not something in between.


Regards,
CVH

Regards,
CVH