This might exist on the forums already but I was coming up with a lot of results on selecting duplicated overlapping geometry. This Geodesic Dome is a really good test, it has 160 panels but only 6 unique, 250 struts but only 6 unique. The hubs will be the same when I generate them, 8 out of 92… or so the math tells me. I would like to color coordinate and label the common geometry for construction.
How complex an undertaking is that? Does a plugin exist that already does the heavy lifting?
One line of code: Sample the dome faces (Meshes are commonly used [speed, connectivity Methods for assembly … etc]) into a List and then use GroupBy (LINQ) using some Method accepting face Area as filter. Same for Edges, Face “equality” etc.
Long way home: since any geo dome is derivant from some seed Polyhedron via some Policy (called Class [C]) and via some Level of Subdivision (called Frequency [F]) … component grouping/clustering is also possible the analytical way. For instance (C1, F4, some seed Polyhedron) and for a given Face:
I imported my dome geometry from CADRE Geo 7, a structural geodesic software I’m using a trial of, just trying to recreate some of that functionality. I found a number of Geodesic grasshopper scripts and plugins but they aren’t as symmetrical or have as few unique components as what CADRE delivers. Their rotation has seemingly random as well so I can’t use an YX plane to cut them at the perfect equator. Otherwise I’d love to identify the faces and struts more logically.
Well … as I said domes are childs of some Polyhedron meaning that you can control 100% the enumeration of dome faces (by managing the Polyhedron “orientation”/faces at creation time) if that sort of control means anything to you. In real-life (AEC) we don’t care about things like these.
I do hope that you are familiar with the whole geo dome theory and how the subdivision (Frequency) works. That said I hate Class II domes (pig ugly).
But the big thing is the real-life on-site assembly meaning connectivity matters related to the resulting truss (single layered or W) out of a given dome (plus obviously the envelope). That’s why domes are represented via Meshes where 7 out of the 9 possible connectivity Trees are directly accessible via Rhino Common Methods as exposed in the SDK (the remaining 2 are rather easy to get).
All the above (plus dealing with structural real-life components 100% via nested Instance Definitions) are rather elementary via code. That said the role of R/GH is to prepare things for the big AEC BIM boys like AECOSIm and the likes (this means that you can skip the R/GH combo and cut the mustard via Generative Components etc etc).
Anyway given the opportunity get the attached (that - as I said - does a not nested clustering [by Area] with just one line of code).
