Recognizing same/similar shapes in different orientations?

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?


dome break (83.7 KB)

A cull pattern with equality on length, area, ect. should do it but it seems there should be a better solution.

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:

See some indicative images on dome matters (and notice how the same items correspond to the seed Polyhedron faces):

DomesDemo12A.rar (10.6 MB)

1 Like

Very cool, thanks Peter.

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).

geodesicmath.pdf (651.1 KB)
GD_F4.pdf (4.4 MB)

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). (141.4 KB)

That said there’s various takes on the dome thingy (but in general I don’t like domes).


@PeterFotiadis Thank you for the help (and your posts I’m finding on the old gh forum) still absorbing and putting this to use.