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.