Surface Split order of results not consistent

After a lot of work, I have finally trimmed these hexagons the way I want them. But you can see when I choose Item 1 (second item) it picks the correct surface 5 times. The 6th time it doesn’t? Any suggestions before I do this by hand? I have to make one more ring of hexagons, so I’d like to learn why its making these choices.
Thanks.



Uploading: Untitled.3dm (37 KB) - Rhino 6 Commercial - [Perspective] 12_11_2021 5_14_26 PM.png…

RESULT IMAGE

please upload your GH file with internalized geometries

I knew I forgot something. THanks for noticing.

See below.

Trim order.gh (11.8 KB)

I have found that its best to sort items after a split, results are sometimes unpredictable. Perhaps you could sort these based on rotation around the origin. To Polar - Grasshopper Vector - Component for Grasshopper | Grasshopper Docs

2 Likes

You could also take the center point of each hexagon and evaluate the surface you were originally splitting at the srf cp, and use the surface parameters to sort.

2 Likes


Trim order_2021Dec12a.gh (19.6 KB)

P.S. I didn’t have to rewrite all of your code, the relevant bit is in the white group below, inserted back into your original code:


Trim order_2021Dec12b.gh (33.6 KB)

Sorting geometry by various means is common. I included three clusters (open source) in the cyan group that I often use. Sorting by edge length instead of area can be useful and is much faster when there are thousands to sort.

P.P.S. I keep the clusters in the cyan group as “User Objects”, always handy, created like this:

user_object_2021Dec12a

2 Likes

in my -little- experience, if all the geometrical inputs are well sorted also the geometrical outputs will be well sorted

for instance, in your starting situation you provide 6 surfaces and 6 lines and let the SplitSurface component do its job with the data he gets… if you jitter the inputs you will get similar results

if, instead, you provide two data trees:
→ surfaces: 6 branches with one surface per branch
→ curves: 6 branches with left and right curve-cutters for each branch
then the very same component will output a well sorted data tree:


Trim order_1.gh (22.1 KB)

it’s not wrong at all to sort the output surfaces, but if doesn’t take a huge effort to create well-organized input data trees, then I’d suggest that as best practice :wink:

Thanks,
This is very helpful.

This is perfect. Being self taught, one thing I always look for, are pockets of best practices which I never learn or think of. Appreciate it.

1 Like