Honeycomb _ experimental housing architecture using Wasp plug-in



Author:

Categories: Tutorials

Tagged with: | | | | | | |


Goal

My goal for this research was to furtherly develop one of my past studies from my design studio, where I was researching the honeycomb as a structure and was looking deeply into it’s potential as an experimental structural housing typology. I chose the honeycomb because our plot of land was at a place of an existing parking lot and one of the conditions was to keep the function of the parking lot in place while being able to build on the site at the same time. This resulted in several different approaches regarding the structural and load bearing concepts of the works. I chose the honeycomb because the dense structure provides excellent structural support suitable for big spans which for me were desired.

This link will lead you to the design study itself:

https://www.fa.cvut.cz/en/gallery/studio-projects/48939-honeycomb

As of for Grasshopper I wanted to create a script which would generate variations of different types of flats that I desired. In the honeycomb structure it meant that one cell of the structure was one type of a room. The rooms that I worked with were a bedroom, study room, bathroom, kitchen with an attached living space serving also as an entry and last but not least an atrium garden which would bring more light into the rooms accompanying the skylights in each room.

This meant that I firstly had to model the different types of rooms that I desired and load them into grasshopper. I later added variations of the rooms with differing places for doors to stimulate the generation of unique flat layouts. The generated flat layouts varying from 1-bedroom to 4-bedroom apartments would then be loaded as parts themselves and generate a greater aggregation which would eventually cover the whole site.

I was using the plug-in called Wasp that specializes on aggregations and generative design.

This is the whole script that it took. The left part is aggregation developing the single layouts of the flats, in the middle, you can see the part that greatly helped me with loading the developed parts back to GH and at the very right is the final aggregation, which generated the layout of the whole site.

Here are 4 examples of each type of a flat layouts, depending on the number of bedrooms and an example of what the whole site would look like, if it was fully covered in the structure.

Process

Firstly, I had to model out the sole rooms that the flats would be composed of. Secondly, I had to load them into grasshopper as Wasp aggregation parts. As said before I didn’t model only one variant of a room but did variations for more unique designs. The aggregation parts of Wasp have some strict rules so I opted for modelling a kind of a cover for each part that would be used for the aggregation and then had a switch that later showed me the more detailed geometry. That is also seen on the picture, where the white geometry is the detailed one and the greenish see-through cover is the one that GH was computing with. Each part was then loaded into GH as a sole part where I set the name of the part, set up it’s connections and types of connections, the detailed geometry for later (attribute column) and also put in adjacency controls (AEC) which provided me with more control over neighbouring cells but also made the aggregations and the generative process a lot harder, because a lot of the times the conditions that I put in made GH think of ways that made sense in the means of the rules but didn’t in the means of housing typology.

After loading all the parts into GH I could start with the aggregation itself. Wasp has a rule generator which helps a lot with the whole process, but one can also type in their own or adjust the generated ones. Because I was trying to generate reasonable flat layouts, I had to specify the number of each cell that composed the flat. I considered how many bedrooms means how many bathrooms and had the condition that both the kitchen and the bedrooms must be connected to the atrium so that also demanded a specific number of each cell. These specific numbers were possible with Wasp’s addition of the parts catalogue which has exactly this function.

After each successful aggregation that met the conditions that I desired, I saved their script into a file and had for later while still being able to continue to generate another one. If it was not working for a while and I wasn’t getting the results I wanted, I could examine the aggregation diagram and work out the problems. Later I could bring back the aggregation using the file.

None of this would be seen well if it wasn’t for this part. This is where I switched the geometry from the base one to the more detailed one so I would not see only hexagonal prisms but would see the rooms that I wanted to. This is where the “attribute” column from the parts that I loaded in comes into play. Later I just found the desired mesh that I wanted to colour, such as the bathroom floor or the tree in the atrium so I would have nicer models. Forgot to say that the whole Wasp works in meshes, so it is best to always convert it before you put it in the aggregation because it will save a ton of computing time for you with more complex aggregations. Sometimes it doesn’t even work with non-mesh geometries.

After having successfully generated enough variations for each flat type. It was time for me to load them into GH again and make the greater aggregation that would actually cover the whole site. Knowing what was in front of me and having the experience from the earlier aggregation I could approach this one smartly. First, I drew a line on top of each flat which then would help me with connections and the cover geometries of the flats. I started with the line at one of the edges of the wall where the flat entry was located, because I knew that that one connection would be different from the other. This line I then exploded into single lines and using their middle point I could easily make the connection for each outer wall of the flat. Having created a part template that I could just copy over and over and using the internalise data I could dodge having to copy the whole script 14 times. There were no specifically hard moments in this part, just a lot of clicking and copying. Could be done solely in GH but I did unfortunately not have the energy.

After having successfully loaded all of the parts into GH again, it was time for the second aggregation. The process was exactly the same as the one before with one difference, which was the site size constraint. I of course did not want the flats to go out of the site. Wasp has this as column in the aggregation command and I did it as a slightly scale extrusion of the site boundary.

Conclusion

Unfortunately, this all did not result in my desired outcome. Even the fact that I had to do it in two separated aggregations was a disappointment. It meant that the whole aggregation would be made only of the parts that I had generated myself and had to check if they make sense in all of the things that it should. With the 14 variations of the flats that I have developed in the end, there were hundreds of unusable ones. The rules work kind of for themselves and are hard to understand and use to one’s desire. It is all too unpredictable and honestly very random. Wasp as a plug-in is absolutely amazing and I had tons of fun with it and would highly recommend downloading it and experimenting, but it is not that much usable for this type of generative design. I think I have greatly exceeded the average time a person spends on a research project as this one and one could argue that more time and deeper research would lead to better outcomes but I can say that for me it was not possible, because the technology, at least the one that an average student can get their hands on, is just not that far yet. This is meant of course as a more of a user-friendly environment, can’t say that I have tried to write the script manually. The closest I could get were either variations of the whole aggregation without stairs or with too many stairs leading to the flats or just other scenarios that did not match what I had envisioned. The aggregation that I showed at the beginning of this research was made with just the cells as themselves and after a close inspection one would realise that it does not make any sense.

Even so I am grateful that I have picked this subject because I had a lot of fun and also had the opportunity to learn a new programme that is absolutely foreign for the majority of people in this field.

Inspiration, sources and other stuff

The research was done using Rhino 7 and Wasp0.5.008 on a Lenovo Legion 5.

Important links:

Wasp download: https://www.food4rhino.com/en/app/wasp

Wasp tutorials from the developer himself: https://www.youtube.com/playlist?list=PLCn3-_9Z4-E5A0EFluiMldlEbDufMiN1g

Some other interesting site with articles concerning this topic:

https://www.academia.edu/16865836/Grammars_of_designs_and_grammars_for_designing_grammar_based_patterns_for_urban_design

https://www.archdaily.com/899674/could-computer-algorithms-design-the-floor-plans-of-the-future

https://journals.sagepub.com/doi/10.1177/0265813516667300

https://hdsr.mitpress.mit.edu/pub/w1gujxim/release/3

https://link.springer.com/chapter/10.1007/978-981-19-1280-1_17

https://arxiv.org/abs/2404.14448

Fun game that works on a similar principle:

https://www.townscapergame.com