Differing branch lengths cause items to be missed in SUnion

Hi All,

First project with Grasshopper so please be kind!

I am currently trying to create interlocking closed Brep bases based on PolyLine curves generated via voronoi points. I need each voronoi “section” to be a singular Closed Brep as I want to be able to 3D print each part individually.

I had this design working with a single hexagon shape, however it got significantly more complex when introducing multiple instances with randomised geometry.

As you can see from the attached file, I am using spherical surfaces to assist with the interlocking of the components, and given the voronoi pattern generates some small lengths, I have added a cull module to my code to ignore these edges when generating the spherical surfaces.

At the end of my code when solid unioning all the parts together, some of the spherical Brep’s are missed. When listing these items I believe it is because I have different branch lengths because if the culling, and thus Grasshopper isn’t running those items in the longer branches.

Am I correct in my assumption, and if so what would be the best way to remedy this? My first thought is to add null objects to the shorter branches to bring them to the same length as the longest branch, however I haven’t been able to find a method to insert null objects into lists

Any help would be greatly appreciated
Base v1.5.gh (34.7 KB)

please internalize the geometry in the gh file

i think a simple right-click on the sunion input and selecting flatten might solve the issue

Apologies for missing that! I have updated the attached file

see the circled input.

flattening the input list creates a single solid (closed brep)

Thank you for the help. I have tried flattening, however I need each voronoi segment to be separate closed Breps to be able to export them individually to 3d print.

this goes against this:

i think you need multiple SU components and a way to differentiate which geometry goes to which SU component, and of course, flatten the input of each

@Lucy1 to illustrate, if the geometry was ordered correctly into their proper list and branch, this would work

or, of course, move them so that each cluster doesn’t touch any part of the other

Sorry yes my “solid unioning all the parts together” statement was too broad. I need to solid union all the relevant spherical objects to their attached voronoi segments.

Also apologies what do you mean by:

if the geometry was ordered correctly into their proper list and branch, this would work

Each branch is segmented based on what parts need unioning to which voronoi segment.

The problem I have with using an explode function is that I could have ~100 voronoi segments in a file, which I would have to manually link in this method

So in the image i posted above, there are two objects not in the right branch - the two little green ones

Once you manage to get all the objects in their correct branches, there are various techniques to re-order the data

The main idea is to create M flat lists, where each list n is all the objects from nth branches

Thank you for spotting that! I think the list lengths I am using to partition the Breps into their separate branches is incorrect. I’ll have a dig into the code to see if I can find the correct list lengths. I think that will fix my issues!

Could be. It seems to me that you might want to use the number of segments in each closed polyline

Thats exactly what I have done! Its a bit of a bodge fix for the moment but I have taken the original polyline and analysed the lengths to cull anything sort. Simply reversing the list put them in the right order (for now).

Thank you so much for the help! I’ll use the explode function for troubleshooting more in the future!

use the merge component when you’ve figure out the list ordering

btw, this is what is messing the list ordering

the problem starts a little bit earlier, when you flatten the list of segments

1 Like