I’ll try my best to explain this but I need help automatically naming my apertures in a specific order while following a set naming convention. I’ve attempted this myself but am unsure how to proceed further.
To determine the order, I used a referenced polyline along with components like control points and closest point.
This approach has worked well, but applying the naming convention has been challenging—particularly when assigning sub-numbers to window surfaces that belong to the same unit.
I was able to group connected and independent surfaces, but I haven’t managed to categorise them by their respective window units, so I left this as is.
To assign the names, I was thinking of using the Human plugin but I am happy to hear other suggestions.
Please feel to explore entirely different methods if you believe it’ll yield better results.
If you wish to see the files I have provided them below. There are two buildings in the Rhino file, the one labelled ‘WINDOW NAMING REFERENCE ONY’ as the name suggests is used only to demonstrate the naming convention and order I desire.
Any insights or recommendations would be greatly appreciated!
Hey @Luke, this is an interesting question. I don’t know if the example below solves you exact issue, but perhaps it is helpful food-for-thought in coming up with a solution?
Real-World Example:
As part of the HBPH plugin, we have a GH component that we use to create 'Window ‘Types’, which can have a size, ID, and a column/row position indicator. These ‘types’ can then be used to create actual window geometry in the Rhino scene. You supply a ‘base’ curve (basically a vector defining the bottom of the window and a ‘direction’) and it will generate the window geometry based on the type information.
We find this to be much more manageable way to model (and keep updated) large projects. So for instance on a project like this:
Define the various ‘types’ with their sizes, IDs, and column/row positions. Each ‘sash’ is its own ‘type’. You can do this in GH, as shown, or have that data someplace else. We generally do this in an outside database and pull it into GH at runtime.
Combine the ‘types’ into a searchable collection
Use the types and the ‘baseline’ curve to generate the actual geometry. Usually we ‘name’ the baseline in Rhino, and pull this in as the ‘key’ to search the collection for. This component will also yield the window names in the right order. At this point you can either use the geometry directly in GH to build your apertures, or bake it out to Rhino with the name, depending on what you need to do with it.
Thanks for sharing, really interesting approach. It doesn’t quite align with what I’m trying to achieve for this specific problem, I can definitely see how it would be useful for another project I’m working on.
I’m implementing a three-step naming process for apertures as part of my workflow for PassivHaus projects. I’ve already tackled two parts:
Assigning a space name to each window based on proximity.
This last step is about sequentially naming apertures while maintaining a structured sub-numbering system for multi-surface windows. The goal is to follow a naming format like:
W1_Bedroom_South
I also want to include the window operation but I’ll think about this later. The current process involves manually writing names in Airtable and then linking them to my model by assigning the same names to both spaces and windows. Ideally, I want Grasshopper to generate these names automatically and write them back to Airtable, though I would still need to manually name the spaces in rhino.
Sorry, this is a bit tricky for me to explain, and I’m sure it’s just as confusing to read haha!
