Discuss issue with Intersect Arcs tool here, separate from issue with Intersect Curves tool. Thanks!
1 Like
1 Like
But I WAS using the intersectcurves tool. You can use arcs with the curve tools. And if you note the last example I gave it was an intersect of an Arc and a curve.
1 Like
Is this the right thing, that the Intersect Curves tool accepts two arcs? Hmmm.
1 Like
Yes. That’s my point. There are some inherent design flaws with the existing tools.
2 Likes
It’s actually a really good point about the “intersect curves” tool accepting two arcs. That leads to some interesting corner cases and since there is an “intersect arcs” tool, perhaps it’s worth just not allowing it.
Problem of course is that if people already have pattern using this feature then it then removing it will break their patterns…
2 Likes
What do you think about the following:
Intersect Curve tool:
- Restrict to Splines and SplinePaths as input
- Create curve segments for each side of the intersection
- Intersections with endpoints are allowed
- Allow a maximum of 4 intersection points
- Update Options to select 1st point of intersection, 2nd point of intersection, 3rd point of intersection, 4th point of intersection.
Intersect Arcs tool:
- Same as Intersect Curve tool, except…
- There will be a max of 2 intersection points unless:
- the arcs are exactly the same (infinite intersection points), or
- one is a subset of the other (infinite intersection points)
- Question: Should the intersection defaults to:
- the first & last points of the shared arc, or
- the origin point like our other tools
- There will be a max of 2 intersection points unless:
Intersect Curve and Arc tool:
- Same as Intersect Curve tool
2 Likes
Hate to throw another wrench in the works - Don’t forget that an Elliptical arc can also be selected in using the Point intersection curves & Point intersect curve & axis tools. <sigh>
Note: The Point intersect curve & axis and Point intersect arc & axis use the same tool code. Now by separating the curves & arcs (and ellipses) you’re not talking about doubling or tripling THAT tool.
I need to give it some thought and check a few things, but remember… changing any of the tools by adding or deleting properties will likely result in updating the schema and could result in breaking existing patterns requiring conversion from the old to new. I can only assume users have used these intersect tools so it could be a big headache.
2 Likes
W.r.t. the problem of arcs intersecting multiple times, I’m not sure if this is something we need to worry about. How often is this likely to come up in a real pattern?
Also, the option of letting people choose “1st, 2nd, etc” doesn’t sound like something useful in pattern making. Instead you’d probably want something like “the intersection between points A & B (which are on the curve already)”. Besides, which is the “first” intersection kinda depends on your point of view. Similarly highest/lowest/leftmost/rightmost (like now) seem also to be useful for pattern maker, we’re not making a mathematical geometry program (I think).
You achieve almost the same effect by allowing people to split curves into sub-curves, and then using the sub-curves as input to the tools: same effect, different method.
So I think what is there now is almost good, except I think forbidding selecting two arcs is good (though perhaps you could automatically convert it to the other tool?).
2 Likes
I’m having an issue with this at the moment. If I make 1 arc too short in diameter, it won’t take the shoulder length when I resize the pattern to a smaller sizes, but if I make the arc longer, then I get the arcs intersecting in 2 places on the larger sizes. So the intersection only works on the mid sizes. So yes, it does occur in a real pattern. At the moment, I’ve put in a formula to widen the shoulder dart to get my pattern to work on a smaller arc diameter. Since the dart gets closed up on this particular pattern, it’s possible to use this solution. 
1 Like
counting from the origin point of the first curve selected, probably.
2 would be quite common. 3 or more… yeah, I’m not so sure about that… idea! A wavy coat closure. I don’t have time to pursue that idea further tonight, but a rough “sketch” indicates that I’m probably right. It could call for a dozen! (or perhaps I just don’t understand pattern-making well enough.)
1 Like
One of the problems with discussing this is how hard it is to differentiate “Intersect Arcs” & “Intersect Curves”. As it stands at the moment, I feel like we’d be best off with two buttons for the same tool, but that’s just the feels of the moment.
So here’s my example of multiple intersections. Pardon my obsession with symmetry, it was not worth fighting this day. 
WibblyClosure.val (4.4 KB)
As you can see, there are six intersections in just this one little clip. Although I was envisioning using the intersections along the axis, which it would be possible to point in a couple of different ways, I think the left or right intersections might actually be better.
1 Like
Yes, I think this one is a toughie. I’d suggest keeping things as simple as possible and to revert back to using the intersection of curve & axis tool here to get the intersections. It would mean more nodes.
Is it at all possible to put all of the curve/arc tools into the curve tools (since they are all effectively curves) so that all the tools under the curves will work on arcs & ellipses, as well as the curves? It seems to me that the only difference is how the curve is originally made that is different and that arc/ellipse do not have start and end nodes - so the segment tool won’t work on them.
If it were up to me, I’d even go so far as to put the arc & ellipse into the curve section so that everything is under the curves. Could this reduce the programming down to only 1 tool per type for all three and add some space to the tool section?
I really do like the 1st option, as a program user, however, the 2nd option has made me re-examine shoulder darts to correct my patterns for people with larger bust sizes and narrower shoulders or vice versa 
Anyway, this is my few pennies worth. Thank you very much for all the thought and programming you are all putting into this amazing software. 
1 Like
@ Douglas Understood. Yet the tool we have is not robust. There are 24 intersection permutations, and these map to 18 distinct algorithms. (see intersection combo list below)
We could overload the current intersect function so that based on the parameter combo one of 18 functions with the same name will perform the calculations specifically for that combo. This way the logic can be fine-tuned and it doesn’t break current pattern files. This approach is fast and a lot of people use it in the c++ world. Function overloading in C++
Another approach is to use a case statement in our current function. The case statement tests for the 18 combos then passes control to functions that are named for that specific combo, like “intersectSplArc.” This code might be easier to maintain because of the readability of function names plus the passing of control is obvious. This also doesn’t break current pattern files.
Intersections ( 6 each for Spl, SplPath, Arc, Ellipse, 6 x4 = 24. There are 6 duplicates, 24 - 6 = 18. Including ‘Line’ because we’ve had user requests for this, so now’s the time to add this.):
- Spl + Line
- Spl + Axis
- Spl + Spl
- Spl + SplPath
- Spl + Arc
- Spl + Ellipse
- SplPath + Line
- SplPath + Axis
- SplPath + Spl (same as #4 Spl + SplPath)
- SplPath + SplPath
- SplPath + Arc
- SplPath + Ellipse
- Arc + Line
- Arc + Axis
- Arc + Spl (Same as #5 Spl + Arc)
- Arc + SplPath (Same as #11 SplPath + Arc)
- Arc + Arc
- Arc + Ellipse
- Ellipse + Arc
- Ellipse + Line
- Ellipse + Spl (Same as #6 Spl + Ellipse)
- Ellipse + SplPath (Same as #12 SplPath + Ellipse)
- Ellipse + Arc (Same as #18 Arc + Ellipse)
- Ellipse + Ellipse
2 Likes