I think curtain walls can only be shown in 3D axonometry, and its sub-elements have orthogonal views.
Well, others might get a heart attack, but to be honest, we don't really use these views in our schedule:
what we tend to do is have the specifications in the schedule as you show, but the drawings are a separate drawing either from the model directly, but mostly a cleaned line drawing in the construction documentation phase from a worksheet - it's a lot faster in my opinion.
Reasons why I prefer modelling windows separately: I try to always mimic real construction sequencing, which means the window structure goes in as a separate element. Curtain walls are more flexible to model detailed (or custom) assemblies, but they have some problems:
- in my country the nominal size is required to be put on the schedule, which is the opening bounding box size, the assembly itself is smaller, the difference is determined by the standard that you are using
- you need to have multiple elements for the "same" construction, documentation is harder to manage (custom properties and the ID manager comes in handy to filter elements)
- it's purpose mainly is to model curtain walls, which means modelling a normal window is more tedious (you will have a hard time to manage panel offsets for a proper model
To summarize:
Modelling doors and windows properly is hard, if you need a detailed graphical output (the level of granularity that you would get from a manual 2D schedule). The generalised strategy that I follow is to create the opening (could be a custom GDL object) and put a separate object (Curtain wall, Morph, Object, a separate Wall with a Window inside...) in it, as Windows/Doors are wall-bound. I attach the properties to the opening itself, as it needs to be one entity (this is why you would need a custom object for funkier shapes), the assembly could be multiple objects as well: for historical renovations I also modelled windows from profiled beams, columns, saved it as a .mod file and populated the model with them. I also think that scripting your opening with a custom 2D symbol + modelling the window in Rhino and importing it as an object could be a usable workflow.
What I'm trying to say: you have dozens of options to do the "same thing", explore and choose according to your needs and project scale. These are the reasons why I said Kristian's solution might be faster for you, it seems to provide (I haven't purchased yet) the flexibility that the GS objects lack while being an integrated, one-step solution.
odv.hu | actively using: AC25-27 INT | Rhino6-8 | macOS @ apple silicon / win10 x64
