trace follow - multiple selection weirdness - 4.6.[23]

[pmcclay]

Selecting multiple unconnected edge paths in a trace:follow op seems to try to work, so I assume it's supposed to work.

The attached workspace export includes 9 Trace Follow ops with inside offset showing different behaviors when selecting multiple closed paths. All model edges are distinct simple circles at various Z heights with centers on a single axis. Exported from 4.6.2; confirmed in 4.6.3.

"first", "second", etc refer to cut order in output preview

The first 8 use climb direction.

1. one edge selected - good result
2. two edges selected - no output
3. two edges selected - first is flipped from inside to outside, second is at the Z height of the first (which is wrong for the second edge); the edges were selected in the same first/second order as output
4. same as #3 but edges were selected in opposite order -- so appearance of Z=first selection in #3 is apparently accidental
5. three edges selected - first is good, second is flipped from inside to outside, third is at Z height of the second (close so the difference is a little hard to see)
6. six edges selected - no output
7. four edges selected (i.e. two edges of #6 deselected)- no output for two edges; first output looks good but is wrong because it's flipped inside to outside which is only accidentally "correct" for that edge; second output is good
8. three edges selected (i.e. one edge of #7 deselected) - first is good; second and third same as the two edges output from #7: 2nd looks good accidentally because it's incorrectly flipped

conventional milling direction

9. same three edges as #8 but direction changed to conventional - same paths as #8 (two good, one flipped) and the directions of the two good paths change to conventional but the bad/flipped path (second) remains in climb direction. (from other examples, I think what happened is that conventional makes all paths clockwise regardless of milling direction -- but that's a different issue if true)

Workspace: trace-follow-selection.zip

(GitHub: no escape for #digit since 2014.)

[petravdw]

I am also stuck with a trace follow command. But with multiple edges connecting. For one part it will work if you select each edge individually. For the next part Kiri will ignore some lines.

Is there a way to trace (engrave) other than selecting the edge at the depth needed? For instance bringing in a 2d image and telling it to cut 4mm deep..

[stewartoallen]

to answer the first, when close polylines are nested, they form boolean "areas" with precedence being outside to in. when that happens your instinct about inside and outside has to change. a single circle has an obvious inside and outside. add a circle inside of that and "inside" becomes the space between the two circles.

if you, instead, have open polylines, there is no such thing as inside and outside. it could change to left/right, but then i also have to add arrowheads on every segment so you know which is which. these kinds of things are on the ui roadmap. just time constrained. so for now, if the polyline is open, you have to test each option.

that also means that selecting multiple disjoint polylines that connect a multiple locations can lead to unexpected results, such as your hex situation. as a workaround in the meantime, break the 2d traces into two trace operations that do not intersect. for hexes this is easy as you just leave all the cross connects for second op.

leaving this issue open because i will get around to creating UI treatments and options for all of them. but this is the situation at the moment.