Please test this build here:
Release Test Point intersect curves issue #317 · FashionFreedom/Seamly2D · GitHub
2 Likes
I just tested it for a particular edge case where the two curves share an endpoint. A3 is the intersection point of Spl_A2_A1 and Spl_A2_A.
Should we improve the definition of ‘intersection’ to exclude the endpoints if a non-endpoint intersection is found?
1 Like
Another edge case where there are multiple points of intersection.
Should we ask the user to choose ‘1st intersection point’, ‘2nd intersection point’, ‘3rd intersection point’,… ‘nth intersection point’?
1 Like
Yay! Looks good with my experiments!
I think that would be ideal, yes.
As opposed to the current “Vertical correction”, “Horizontal correction” Which could conceivably make the created point switch which intersection it applies to under certain, perhaps edge as well, cases? Yes please!
ETA: Actually, we’d have to figure out what would happen if one of the intersections were to wander off.
1 Like
Like this…?
In this case by moving the arcs away the intersection point A2 is no longer an intersection point and the origin is used as the place holder so the pattern doesn’t crash. Since the arcs no longer intersect there are no arc segment lengths in the variables table->curve lengths.
Edit:
One thing I did discover is that the arc segments will become ZERO as the intersection point is removed… and if you were using the curve lengths in a formula as a divisor you’ll get an error.
2 Likes
Just checking - I assume this build was BEFORE you fixed the unicode issue or from the user’s fork?
2 Likes
That too. Actually, I was thinking more of when there would be multiple crossings, & it’s the furthest intersection which is pointed, but then it ends up getting straightened out to fewer intersections. Does it yoink to zero-point, or does it still take the furthest intersection even though it’s num1 instead of num3?
1 Like
The default is to yoink 
to the first intersection even if its an endpoint. Which is actually what it should do. The user should then be able to go into options and select from a list of the 1st, 2nd, …nth intersection points.
Currently this tool’s Options allow selection of Highest, Lowest , Rightmost, and Leftmost intersection which leaves out those pesky middle points.
2 Likes
wait I was looking at Intersect Curves tool. So theres a separate issue with the Intersecting Arc tool when an arc changes and there’s no longer an intersection point? Not sure there’s a fix for this one. It may be the best option to use the origin point. Other tools default to work with the origin point when there’s no longer an intersection or proper result .
2 Likes
Just a reminder… once you start changing the option of which point the tool uses outside those names which are currently provided in the tool - you might get into the issue of fundamentally changing the tool. Which could require more extensive work on the schema, reading / writing the pattern DomDocument, maintaining compatibility with existing patterns that use that tool and/or conversion, tool dialog changes, updates to the property browser (dock), and possible geometry changes.
Currently I believe this tool uses 2 of the possible “point” schema element tags “vCrossPoint” and “hCrossPoint”… just changing those and you could be looking at a can of worms. Trust me, I know what it was like just changing “passmark” to “notch” in the schema. It’s why I’ve come to understand Roman’s skepticism anytime someone with a little bit of C / C++ experience thinks they can just add a new or change a tool.
Food for thought.
2 Likes
Didn’t look at that… was using the point of intersection of curves tool using arcs vs using simple or bezier curves.
But yes… in the example I posted simply moving the arcs away to a point where they didn’t intersect, the point is replaced with the origin… and in one case the arc segments disappeared in the variables table… other times they were there, but the length value was zero.
Need to investigate more.
Edit: Since the point intersection of curves works with arcs as well there can only be 2 points of intersection… there can’t be an n’th point past 2.
1 Like
This is why I said this…
In testing this some more I found another issue with it… There is a discrepancy between the Table of variables Dialog and the Edit Formula dialog. Oops.
.
There’s an even greater discrepancy the more intersect points you create on a given curve…
2 Likes
Hmm, doesn’t look good. TBH I was a little surprised it got merged so quickly. Given I just cut and paste a bunch of code it wouldn’t surprise me if some bits were missed. In particular, I’m not sure how that naming stuff works for arcs and it would seem the point numbers might be being reused.
2 Likes
Unlike splines (curves) - which use the naming scheme of Spl_ [1st point] _ [2nd point] - arcs have no end points. They are described by Arc_ [center point]_ [unique num]. But there’s no issue in the names that I’m seeing… what I’m more interested in is why in some cases only the full arc length and one segment length(the 1st one?) show in the Edit Formula dialog, while all 3 lengths show in the Table of Variables?
What I’m even more baffled at - and this is also an existing problem using the vtoolpointofintersectionarcs tool… if you have an arc of 360 degs (a circle) , and intersect it with another curve or axis there is still only 1 arc segment. So why does the program show 3 segments? And how is it coming up with the 3 segment lengths? In the example below there is an arc of 360 deg intersecting with a curve at A3…
2 Likes
That I think I understand. What it does is first calculate the intersection point of the two curves, and then calls VArc::CutArc() on the circle. As the comment states this will always return two arcs. The circle goes from 0 to 360 so there is a start and end, even if you don’t see it. And the Arcs in the variables list refer to those. Not very useful obviously.
As to how they can appear in one list and not the other. Maybe it’s a time-travel thing? It’s not showing them because it thinks they’re not available at this point?
2 Likes
Got that… but if you look at the example I gave one segment is nearly 2 inches from 0 or 360… you would be able to see that. Where is THAT point coming from?
Also when I say there are no end points I’m referring to the tool and point names… in this tool the end points of the arc are calculated - there is no stored point names that can be used in formulas or referenced by other tools. This tool is not an arc defined by 2 points and a radius. The fact it has no end point names, you can’t construct segment names like you can with splines.
I thought of that… I had the Variables Table open at the same time as the Edit Formula dialog. They should be showing the same thing… in fact I think both dialogs call the same function to get the data from VContainer. On the bright side there does not seem to be this discrepancy with splines.
2 Likes
OK there’s now a separate discussion thread for the Intersect Arcs tool,
1 Like
So I should probably revert this commit (Edit: Didn’t revert the commit, but I squashed all the commits following it), and we’ll look at this problem. This tool has extensive logic flaws.
@rode_kater - would you have another go at this? Maybe start with the refactoring, don’t add any functionality yet. Get that section to be reusable, you might see more about where the logic is failing. That sound ok to you?
2 Likes
Let me see if I understand this correctly:
- Arc_A_3 = circumference of circle around A, starting at 0 degrees, going to 360 degrees (=Arc_A_8 + Arc_A_9)
- Arc_A_8 = distance from 0 degrees counterclockwise on the circle around A to A3
- Arc_A_9 = distance from 360 degrees clockwise on the circle around A to A3
The splines give explicit begin/end points and they look fine. So the example looks fine to me, what am I missing? The points a 0 and 360 degrees on the arc are not named (though the both happen to fall on the line A-A1) but they do exist as far as the geometry is concerned. If you change your Arc_A_3 to start at 10 degrees it would be obvious what’s going on I think.
2 Likes