Did you see if the clipper2 plugin helps?
Georegion_clipper2.gh (48.8 KB)
Typically when dealing with ‘gazillions’ of elements I give up on splitting, trimming, and ‘region work’ efforts. There’s no point.
1 Like
geo_2025Jun4a.gh (52.5 KB)
As noted yesterday, R8 works and R7 fails. Appears that R8 is more robust about invalid offsets.
P.S. The yellow group in this R7 version removes self-intersecting offset curves. It works in R8 but does nothing because there are no self-intersecting offset curves in R8. There are other differences that (presumably) could be cleaned up as well.
geo_2025Jun4a_R7.gh (55.3 KB) (DEPRECATED)
P.P.S. This version using Clipper2 appears to be the ultimate for R7. Unfortunately, it fails in R8 because it generates six self-intersecting offset curves (in R8). 
But looks great in R7, and SrfSplit is ~15 times faster in R7 
geo_2025Jun4b_R7_Clipper2.gh (52.1 KB)
And Clipper2 Offset.
There are two advantages using Trim with Region and Clipper2 Offset:
-
It works in both R7 and R8.
-
It is substantially faster in R8 than my version ‘Jun4a’, though slightly slower in R7 than my version ‘Jun4b_R7_Clipper2’.
The best solution, for sure 
geo_2025Jun8a.gh (46.9 KB)
1 Like
Looks good what people posted here!
For some more context: I’ve had a vaguely similar problem with intersecting regions on planar surfaces. Here are two of my observations (in RH8):
- Never “auto-derive” regions from surface boundaries, even if it seems convenient and works ‘most of the time’. In my script, gh tended to randomly skip intersections, wich lead to great, but completely obscured chaos in my lists…
- Sometimes curves don’t get intersected right, but explicitly turning them into polylines helped. Of course, your design has to allow for this change from smooth to staggered, plus, I’m not entirely sure if strictly using closed planar curves instead of surface boundaries was the more important culprit that drove me nuts…
2 Likes