Hello!
I am starting to get myself more into GH, but frequently I have this situation, where when I create a list of geometries, these follow a random order. Is there a way, where I can re order these geometries?
GEOMETRY LIST.gh (8.9 KB)
This doesn’t directly answer your question, however your order changes after you split the surface with all the edges. For this case it seems unnecessary given the isotrim component already gives you the {ordered} subsurfaces you’re obtaining with the split:
Oh okay interesting, so by adding more steps (Unnecessary steps lets say) the order of a list may be affected. Thanks! That helps a lot.
Not necessarily, and I’m not the most qualified to explain - some processes in GH can mess up order when a data tree changes or is flattened.
In your particular case the subsurfaces resulting from Isotrim are already ordered. However, after that you used DeBrep, which explodes the subsurfaces and outputs single edges (that’s 4 edges per subsurface), which you then flattened (most likely the culprit) and fed into the SrfSplit.
As Rene mentioned, the SrfSplit seems redundant, and causes the geometry to be reordered as you have seen. However, if you still feel this approach is necessary, you can reorder the geometry in a number of ways.
Here I have decided to use the original IsoTrim geometries to organize the SrfSplit geometries. I use the center-points of the ordered IsoTrim geo to create a set. This set contains the multiplied coordinates of each square. I then use this ordered set of coordinates and compare against the unordered SrfSplit coordinates, in order to search for index of the corresponding square with matching coordiantes. I then use this list of reordered indexes and a ListItem component to reorder to geometries.
Hopefully this helps you on the correct path!
GEOMETRY LIST.gh (11.7 KB)
2 Likes
Sorting geometry is extremely common in GH and there are many ways. In this case, Isotrim avoids the need for sorting (purple group below). But if SrfSplit is required, you can sort only by X and Z as shown in the white group. The expression on pDecon ‘X’ is x*1000 which, of course, is very specific to this data set.
sort_geo_2024_Jul18a.gh (19.2 KB)
P.S. This demonstrates how Isostrim (SubSrf) still works while sorting by X and Z (white group) gets messed up. It could be fixed by using distance from surface edges but that’s complicated!
sort_geo_2024_Jul18b.gh (20.1 KB)
sorting by X and Z (white group) gets messed up.
1 Like
Thank you very much to all of you! It helped me a lot.
Hello Joseph, how could apply that logic in this definition and how could I order all the sides of the hexagons to correspond each to other, thanks in advance.
ORDER.gh (38.7 KB)
this looks like the hexagons were placed on a surface.
in that case the surface parameters would help to sort the result.
could you upload the surface?
1 Like
Isotrim was the preferred solution to this thread, which doesn’t apply to hexagons. As Jakob suggests, it might help to have the surface underlying these hexagons.
That might be possible without sorting the hexagons but is there any point without sorting?
The color scheme embedded in your GH file might be optimized for your dark screen but is useless to me. I had to copy your code to a new file to see default colors,
This effort is just getting warmed up but I’m burned out on it already: 
order_2025Jun27a.gh (47.9 KB)
Part of this might be useful if we had the actual surface instead of the derived cylinder?
hello guys here you have, I tried with a line but still not correct.
sorting fail.gh (34.2 KB)
I need order the sides of the hexagons to apply a pattern shifting the curves but it is disorder that will not be possible and the order of all the list just help to fabricate it.
realy difficult -
would be a lot easier to create the pattern in order…
How would you know if the hexagon sides are in the same sequence?
Sorting the hexagons worked out fairly well using a rounding expression on the ‘uvP’ output of Srf CP: round(x/30)*30
But sorting hexagon sides didn’t work as well, perhaps due to alignment of the plane and circle created for each one.
order_2025Jun27b.gh (62.0 KB)
1 Like
interesting!
why does reparametrisation of the surface destroy the ordering of the hexagons?
It pays to take walks. This still isn’t perfect at sorting hexagon edges but maybe better? Certainly simpler!
order_2025Jun27c.gh (48.2 KB)
Might be these isocurves?
order_iso_2025Jun27a.gh (37.4 KB)
Wish you had started a new thread.
2 Likes
I’ve tried many tricks but can’t sort the edges consistently. I thought it would be the easy part. 
order_2025Jun27d.gh (59.1 KB)
1 Like
FINALLY 
I got the hexagons sorted. Used a different method from Sort Points with round expression. Haven’t got their edges sorted yet though… 
2 Likes
I really appreciate your help, that just is a smart way to sort the list. I’m going to check if with this edges can apply the pattern at least is in a sequential mode.
What would be interesting is see with a number slider shifting the order in the clock way in the edges of the hexagons but it is not a petition.
thank you very much
All is fair and love and war. The ‘Cull_D’ slider (blue group) is set manually but it’s not a critical value and could be replaced (computed instead). I must be getting rusty, this was hard!
order_2025Jun27f.gh (76.1 KB)
1 Like
I found a way to eliminate the ‘Cull_D’ slider (blue group) but am still not happy with this way of matching hexagon centers with ‘V’ isocurves for sorting AlongCrv.
order_2025Jun28a.gh (73.1 KB)
I didn’t guarantee that hexagons all have the same curve direction (easily done), but all edge numbers appear to be the same so in this case it isn’t needed?