Discuss issue with Intersect Arcs tool here, separate from issue with Intersect Curves tool. Thanks!

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.

Is this the right thing, that the Intersect Curves tool accepts two arcs? Hmmm.

Yes. Thatās my point. There are some inherent design flaws with the existing tools.

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ā¦

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

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.

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?).

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.

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.)

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.

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.

@ 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