Bug: issue with Intersect Arcs tool

[Douglas]

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

Make "point intersection curves" tools define lengths

Like this…? [arc1] [arc2] 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…

[Douglas]

Make "point intersection curves" tools define lengths

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. [arcstest]. There’s an even greater discrepancy the more intersect points you create on a given curve… [arctest3]

[Douglas]

Make "point intersection curves" tools define lengths

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…

[Douglas]

@slspencer

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.

[slspencer]

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

[Douglas]

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

[rode_kater]

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…

[slspencer]

@rode_kater & @Douglas

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

Intersect Curve and Arc tool:

• Same as Intersect Curve tool

[Douglas]

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.

[rode_kater]

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

[Grace]

@rode_kater

How often is this likely to come up in a real pattern?

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.

[Pneumarian]

@rode_kater

Besides, which is the “first” intersection kinda depends on your point of view.

counting from the origin point of the first curve selected, probably.

@rode_kater

How often is this likely to come up in a real pattern?

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

[Pneumarian]

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.

[Grace]

@Pneumarian

As you can see, there are six intersections in just this one little clip.

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.

@Douglas

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.

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?

@slspencer

Question: Should the intersection defaults to:

• the first & last points of the shared arc, or
• the origin point like our other tools

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.

[slspencer]

@Douglas

Don’t forget that an Elliptical arc can also be selected in using the Point intersection curves & Point intersect curve & axis tools.

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.

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

1. Spl + Line
2. Spl + Axis
3. Spl + Spl
4. Spl + SplPath
5. Spl + Arc
6. Spl + Ellipse
7. SplPath + Line
8. SplPath + Axis
9. SplPath + Spl (same as #4 Spl + SplPath)
10. SplPath + SplPath
11. SplPath + Arc
12. SplPath + Ellipse
13. Arc + Line
14. Arc + Axis
15. Arc + Spl (Same as #5 Spl + Arc)
16. Arc + SplPath (Same as #11 SplPath + Arc)
17. Arc + Arc
18. Arc + Ellipse
19. Ellipse + Arc
20. Ellipse + Line
21. Ellipse + Spl (Same as #6 Spl + Ellipse)
22. Ellipse + SplPath (Same as #12 SplPath + Ellipse)
23. Ellipse + Arc (Same as #18 Arc + Ellipse)
24. Ellipse + Ellipse