The finished wall has quite a few layers. Internally the frame in the photo gets a layer of OSB and an optional service cavity (50mm battens and layers of plasterboards). Externally the frame gets and exterior face, battens for ventilation cavity and cladding.
As I understand wall styles can only model homogeneous layers of materials and are not capable of handling framed walls.
If there’s a standard way to model a complex frame wall - please let me know. (In that case please do not waste your time reading the rest…)
Bellow I to explain the approach I ended up using, which is far from ideal.
So I tried to model the JJI joist wall as a curtain wall. Since curtain walls only support a single cell panel, I ended up creating multiple layers of curtain walls: one for the frame, one for the external cladding, one for the internal shells.
I may need to create straight wall segments and create some additional corners by hand…?
Adding openings seems to be a nightmare - I need to add separate openings to each curtain wall layer. When I am trying to move an opening (or door) in on of these curtain walls, it often stops cutting through the curtain wall - this may be because of overlapping walls as far as understand it from some other threads.
Hello,
It would be a really great feature.
Also, you could add some additional elements to a curtain definition. I mean, why is there only option for one cell and one mullion? If there were more of these, we could prepare more complex definitions, like the one from Dora’s post. Then, there could be another option for supports, there is not always need for them at every mullion, one could skip the very n-th of them… And like Dora says, corners should be more real…
Cheers, Jaro
For version 3 we expect to have wall styles from Grasshopper definitions. This will allow to create wall styles like the one in your picture.
Currently there is no easy option to do it. In the case of trying with curtain walls the problem is that their joints are not solved automatically yet.
Another option could be to use a regular wall with three layers and hide the middle one, then model manually or with Grasshopper the inner layer of the structure, this way at least you would have half of the work of the openings done. To hide a wall layer go to its style editor, select the layer and under the Attributes tab change the value of the Visibility value.
I also added to our bugtrack the requests Jaro mentioned.
@dora.varszegi following up with Ramon’s explanation, you could already develop a Grasshopper definition that generates all the studs automatically from referenced walls. Take a look at the definition attached. Referencing walls composed by 3 layers (setting the middle one to Hidden, is recommended), it generates columns with rectangular profiles, that are as thick as the middle layer. You just need to set the separation among them. However they don’t take into account openings… so this is something that could be developed further in this example. Column array inside 3-Layer Wall.gh (18.5 KB)
I have been trying to evolve your script to make it a parametric solution to create stud walls - ideally making it general enough that others can reuse it, too.
I created a new wall style - Parametric stud wall style with. User parameters control the size and the shape of the studs the given wall layer requires.
Shame GH wall styles are not yet supported by VA 2.7. So my script, similarly to yours explodes an existing wall and generates columns layer by layer based on the user parameters defined for the given layer.
The script is WIP, I didn’t manage to make it general to any number of layers yet and it only supports generating to a single wall at the moment due to my lack of understanding of trees in GH. I want to make it so that the script can run on any wall with any number of layers.
However, there are heaps of problems I ran into, that may make it absolutely useless:
the file grows like aggressively, VA crashes when I generate the coloums for all my walls, despite wireframe display mode, file size went from 87M to 150M.
The test file attached grew 25M by generating the columns for a single long wall, despite there are only 2 block definitions created.
the wall bleeds through in hidden view mode
openings and windows are not cutting through, as it is not a proper wall one can forget wall functions like extending or joining.
At the same time if i use a GH scrip to generate the same columns as plain Rhino extrusions, 100 columns will only take 7M (despite no blocks used), no rendering problems…
Hi Dora,
Thanks for reporting this issue. I can see that the file is 24 MB using the baked columns, while it is 13MB if we bake polysurfaces instead. We will see if we can optimize this and get back to you.
Hi @dora.varszegi, analyzing your GH definition and the process to bake these columns, we have realized that what makes the file size increase is actually the wall, not the columns.
VisualARQ performs subtraction booleans between walls and columns in order to avoid two objects to share the same space and therefore calculate properly the volumes. This is the reason why baking the columns takes too long to compute: VisualARQ is doing a 312 boolean subtraction to the wall poly-surface.
If you delete the walls, the file size with the 312 columns becomes 2.8 MB.
In the same GH, if you bake the columns exploded (using the VisualARQ Explode component), the 3dm file will contain 312 poly-surfaces, and the file size will become 12.5 MB.
If you explode the VisualARQ columns using the Rhino “Explode” command (not using Grasshopper), the file will contain 213 extrusions, and the file size becomes 3.6 MB. So VisualARQ columns are very efficient, more than Rhino extrusions. The “problem” is that when columns are inside walls, VisualARQ will take care that no geometry will share space. The resulting wall in that example is a very complex poly-surface, about nearly 20 MB.
On the other hand, If you hide the wall layers that are intersecting with the columns (from the wall styles dialog), you will see a big gain of the performance speed of the model. Also, if you save the model in that moment, the file size will be smaller.
