Surface split - segment order + culling intermediate points

Hi there! Not sure how to phrase the question, so let me explain what I am trying to achieve and how far I’ve managed to get. Would appreciate any help!

  1. Create a rectangle.

  2. Subdivide rectangle into n-number of rows/columns of equal width

  3. Subdivide the created rows/columns into rectangles of random widths (within a given domain) - I need to develop this a bit further as it’s somewhat clunky when you start changing variables

  4. Split the rectangles into 5 groups, randomly distributed.

  5. Each group of rectangles will be assigned a different geometric design.

I got up to Step 4 by plugging the generated curves into a SrfSplit component, so I end up with a bunch of separate surfaces. These surfaces I can then usually split up into groups quite easily and then assign a different colour to each group. But now I want to add lines inside of these rectangles, and I don’t necessarily want each rectangle in the group to have the same colours - just the same collection of curves. The problem however is that the order of the segments of these surfaces are inconsistent, and it appears to be because of intermediate points throwing off the segment count per rectangle. I’ve tried simplifying the outline in various ways, but I can’t seem to get this right. Image below shows the List Item component isolating one of the segments, and you can see that it does not select the right hand side segment in all of the rectangles.

Image below shows an idea of what the next step is. Would help if the order of the segments and vertices are consistent!

grid division 2022-12-17.gh (23.9 KB)

Hi,

If you want the leftmost edge, you have to tell Grasshopper so, by sorting the edges in some way. Using the X coordinate of the midpoint works fine.

grid division 2022-12-17.gh (28.7 KB)

You don’t have to use Surface Splitin the first place…


grid division 2022-12-17_re.gh (14.4 KB)

3 Likes

Interesting, thank you! Didn’t even consider this as a strategy for ordering lists, however now it seems so painfully obvious!

I suspected that SrfSplit wasn’t the best way to go about it. I appreciate the alternative approach, seems a lot less convoluted and I’m curious to dissect it. Thank you!

Question: In your file, I notice that if I increase the amount of divisions, it also increases the amount of branches (i.e. the number of groups of rectangles). How would one alter your definition to be able to have the number of branches be adjusted separately?