Solve endless curves inside curves using boundary surface

[Siemenc]

As discussed in previous issues here and here

I've just quickly tried it out I think and I believe the boundary surface component tends to take more time to calculate than the approach we're using now. I can't remember how much the difference was but it if it is sufficient it might come down to choosing between endless curves in curves or speed, unless we find an even better approach.

[Siemenc]

Just took the time to have a look inside the cutout component to see if I can implement the solution I've used in a different project using boundary surface. It seems to work and the good news is that by implementing this we get rid of another part of the cluster which slows the component down the most:

Interesting how multiplication can cause such time calculations.

For comparison, the current cutout component:

And the new cutout component using the same geometry:

[Siemenc]

I noticed this solution does mess up the order of curves to be cut, so maybe that needs to be fixed first before committing.
It also brings another question worth discussing:
If Bark beetle automatically checks which region is inside the other region for cutting, does it also automatically first cut the most inner curve? Or is that something that the user should be able to decide?
Are there cases when you don't want to cut the most inner part first?

[mikeFandA]

There are maybe a few cases where you would start from the outside and move inwards, but generally from a machining perspective it greatly reduces stress on the tool to ramp into the centre and move outwards when cutting. It allows the contact area between the tool and material to be more consistent throughout, that first cut from the outside would leave the tool bearing the brunt of the force across the front half of the tool geometry instead of a third or quarter. Great to have the option to choose but I would personally go from inner to outer as a default, hope this helps.

Mike

[Siemenc]

Thanks a lot for your input @mikeFandA ! Just for clarification: are you talking about the advantage of pockets being milled from center? Your explanation makes a lot of sense in that case, but my above question was about cutting out pieces that are inside other pieces on multiple levels. Or maybe I misunderstood your reply.

[Siemenc]

Thomas Holth has been doing amazing research on different techniques to sort curves inside curves and made a great comparison between them including advantages and downsides. Here some screenshots of his work:

I think the boundarysrf might be the optimal solution for Bark Beetle, as it's the fastest and doesn't cause huge problems so far. Accidental Non-planar curves or curves not in the same plane can and should be solved in a different way before the sorting (auto project to cplane for instance), if necessary by the end user. Otherwise you might get unexpected results when offsetting for milling bit diameter compensation when creating the toolpaths.
The hierarchical topology of the curve relationships, that Thomas got with curve region containment, might be one thing lacking with the boundarysrf solution. But I don't like the speed of that (50X slower than boundarysrf). Perhaps this is solvable in a different way after the boundarysrf sorting is completed?

[mikeFandA]

Ahhhh yes my mistake I completely misread the image above, yes I was refering to milling pockets from the centre I had read the image as a set of pocket paths rather than as perimeter cut-outs. In that case for some useful advice, the standard in most software is to offer inside, on-line an outside for these types of paths. It is also useful to be able to set cut direction in these cases as its generally better to use a climb milling direction to avoid tool chatter when cutting soft materials (ply/MDF/ali etc) at high speeds.

[mikeFandA]

For the coding issue, It's hard to see without looking inside the cluster and I'm not at a computer with grasshopper right now. I would say on intuition that going with the boundary srf will be the easiest method especially in keeping the processing time down, but one option could be to lookin into testing for points in the curve rather than the curve itself and using those both to set a heirarchy for cutting and also test for containment simultaneously.

[Siemenc]

I committed the last version with multiple level inside cutting solved using boundary region. I started working on implementing this with pockets but it turned out to be a bit more of a challenge than I was expecting. I think I'm onto something now though, but I still need to fix some data tree issues (it now creates multiple duplicates of curves) and sorting.

@mikeFandA Interesting, but how do you know which curve to test against if you don't know which the outer curve is? Or do you mean going over each curve and testing all starting points (for example) against each curve and use that to create some kind of hierarchy?

[mikeFandA]

Yes that was what I was getting at or something alonf those lines. Essentially you would loop through the cruves and test each start point for inclusion and use that result to then assign the curves to a list in order or to different lists to provide offset directions. I would say the boundary srf is the easier method as you would for all intensive purposes be writing a very similar method to boundary srf to create an arbitrary heirarchy. You could still establish a hierarchy afterwards as you say, perhaps again with points on the surface and then sorting the points based on X,Y,Z coordinates which should be relatively light followed by a synchronous sorting of the surfaces to match.

[Siemenc]

Finally had a bit of time to look at this again and I think I managed to solve the duplicate issues I was getting in the pocket cluster. I also did some more curve sorting. There's still room for improvement but I think this is waay better in terms of multiple level curves inside curves. Went from this:
To this:

Tiny bit of speed loss but not too bad.
Will commit soon. The cutout component is next on the list. We noticed by using the latest version at Fellesverkstedet that sorting from inside to outside is more imporant then having control over the order of cutting. Not sure yet on how to approach that yet in a concrete way.

[Siemenc]

Well. Looks like I was a bit too much focused on that example file I made. I get nice results with those shapes but with any other shape I try I get no usable result:



Might need to revert to the previous version, if there's no way to fix this soon.