Strange surface split result

Hello,

In the attached definition i used a list of 10 curves (represents the edges of breps highlighted in green) to split a 4 surfaces so the result will be 11 splitting fragments for each surface ( the total will be 44). when I looked into the order of splitting fragments it showed strange results, instead of having the splitting fragments ordered from 0,1,2,3,4,5...etc it starts with 0,10,1,2,3,.... and for the second group of fragments also a different order 10,1,2,3,4....

I don't know what causes such result because the

what can i do to rearrange it into the correct order 0,1,2,3,4,5,6,7,8,9,10..and make the new index starts from the edge of the original surface?

Question4.gh

Replies to This Discussion

Permalink Reply by peter fotiadis on December 10, 2016 at 6:59am

See attached (and the comments ... especially with regard the "size" of the cutters > that's why the curve pairs are extended AND moved further apart). Strangely the GH native component related with the Brep Join fails (most probably a document tolerance issue).

Attachments:

Split_Question_V1.gh, 46 KB

Permalink Reply by isbahes on December 10, 2016 at 7:26am

Thank you very much for the brilliant answer!

Permalink Reply by Leela Tzaida on December 11, 2016 at 3:01am

Peter asked me to do that as an exercise (at Saturday night !!!).

He was not pleased - at all - mind:

What about any profile for the "tube" (sweep1) ? what about more "Z" control? what if the rail curve is closed? what about curve Lists? why not solids? what happens if the "Z" cutters "conflict" (height) each other ? Why you inverse what to keep splitting (as the "work" brep) and what to store (as "piece") according the alignCutter option?

more soon.

Attachments:

Split_brepWithZCutters_V1.gh, 60 KB

Permalink Reply by isbahes on December 11, 2016 at 11:05am

Thank you Leela for your contribution to this discussion! my only problem was how to overcome the limitations of Boolean operations when using native grasshopper components ( Join, subtract, union...etc) . obviously it doesn't work as in Rhino, even the "Join brep" component for example has only one input which limits how much we can control the result.

RSS