Grasshopper

algorithmic modeling for Rhino

# 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

Views: 672

### Replies to This Discussion

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:

Thank you very much for the brilliant answer!

Hi

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:

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.

by June Lee

• View All