I have to admit that since 2008, when Grasshopper started to be known in the architectural field, I have felt the attraction of this super powerful software.
Time is limited, and although I have assumed that I will probably never learn how to code properly, I still design most of the time thinking of a system that could be described, and that could be slightly changed its form to adapt to different conditions (or parameters).
This way to think architecture (now so trendily called algorithmic design) is so attractive for several reasons. By following a given logic, designers can test many solutions with almost no effort. That increases the productivity and gives more freedom and control of the results. To obtain that amount of control, the designer needs to understand the logic that he is applying which requires at least some mathematical background; otherwise it can just become a random push of buttons to get a funny shape. Just an unbuildable shape.
In our case, besides exploring more complex geometries, we have been trying to use Grasshopper to upgrade the BIM concept. That means for us, having more control of the geometry and the data generated.
FIRST ATTEMPT ON A LIVE PROJECT.
In the following example, we were appointed to develop the concept design for the flagship store of a beauty brand inside a commercial mall in Manila (Philippines). A small scale design exercise, perfect to do some research.
Right after the design phase and after choosing among other options, the client wanted to move forward very fast and we were asked to give an accurate description of the different components of the main structure.
Because all our projects start and end being BIM, normally we would just come back to the ARCHICAD model, refine few elements and rapidly schedule building components and get the necessary drawings from it.
In this case, due to a slightly more complex geometry, the task was not that easy. We needed to give the contractor length, curvatures, and sections of the components of the main structure, which consisted of a 3D curve. We needed info of the surface to cover with the fabric or ropes, general drawings… data, data, data.
So, keeping in mind that we would be able to control better the curved geometries, and for the sake of testing the workflow, we moved to Rhino/Grasshopper.
THE PROCESS
Having a sketchy model built for the concept phase done in ARCHICAD and Cinema4D, we rebuilt the geometry in Grasshopper in order to refine the option, by addressing the comments from the client –thus making it more interesting, and at the same time gaining control of the data.
Our initial plan was to bring from Archicad a 2D line representing the perimeter of the shop to Grasshopper. Using that reference line, we would construct the whole thing in GH to keep it as most parametric as possible.
We placed a few points inside Rhino, filling the corners and the middle point of the rectangle used as the reference line; and then joined them with a polyline. We created the curvature adding an extra GH node to round the corners.
Then, playing around with the position of the points (to get the entrances and the visuals right), we got the 3D curve that we needed, composed only by straight lines and rounded edges with a constant curvature. Projecting that curve onto the ceiling plant, and lofting them we obtained the surface to cover.
To make the structure rigid, we joined both curves with vertical lines in several points (we decided to do it by the points where the curvature changes).
Once we had the wireframe structure, we proceeded to convert it to ARCHICAD elements. This is when the fun started, and when we encountered the first issues!
AC elements have their own rules. They don’t always match with reality and sometimes you need to use imagination to find the right tool for the job, other than the name that it holds. There is a very interesting series of articles by Jared Banks talking about this topic.
The initial idea was to covert the Grasshopper curves into beams and columns in AC, so that we could easily list them and get the length, section type and curvature of the beams.
Surprisingly, the first problem we found is that you can’t have curved and slanted beams. So you can’t convert the 3D curves coming from Grasshopper into ARCHICAD beams. What you could do is to sweep a section in Grasshopper, and then convert the Rhino pipe into a morph. That will give you morph pieces in AC – or even GDL objects, but those aren’t intelligent. They don’t know their axial dimension, curvature or section. They are just pure geometry, so you can’t get an automatic schedule from it.
I have to admit that this was a bit disappointing.
Knowing the problem, we decided to use MEP elements, but they are still not available as nodes inside GH. We opted to get from it just the wireframe structure, and used it to trace over it with MEP elements (pipes and ducts), knowing from our experience that they can build 3D curves. But then, the problem is that ARCHICAD geometry does not update with the script.
We faced one last setback, which is not strictly related with the topic. Once we got all the structure defined with MEP elements, we discovered that – although these are intelligent and know lengths, curvatures and sections, somehow you can’t extract or schedule all that data automatically; or if you can, is not so obvious.
Still, we found a workaround inside Grasshopper. Breaking the 3D curve in segments and adding something called a “panel”, we listed all the segments that compose the 3D curve getting the length of both the straight and curved lines. The curvature was a global parameter applied to all the curved segments, so knowing the length and the name of the different items, the contractor could understand and accordingly quote the structure easily.
The advantage is that playing around with the position of the original control points, and the other parameters, all the logic behind will be maintained, creating a different result and still knowing all the relevant data needed for construction.
CONCLUSION
This has been so far the first tiny, but real experience where the use of this set of tools has really made a difference in productivity and specially providing control and relevant data.
We have seen some limitations that are probably already being worked out, specially regarding the obtention of data from native objects inside ARCHICAD. Intelligence and retrieval of data from MEP elements need to be revised. We will have a full article related to MEP modelling regarding the experience of a current project in Hong Kong.
Maybe given the whole world of possibilities that this connection with Grasshopper brings, the geometric limitation of objects such beams or slabs could be reframed.
As a final comment for this article (just the first one of a probably long list of Grasshopper related ones) we want to say that in our opinion, geometry is just a small piece of the puzzle. Grasshopper can drive the logic of the projects with measurable data. It is important to be able to get all that data from Grasshopper to ARCHICAD because inside ARCHICAD you can squeeze the most of it. Schedules, use of “find and select”, labels, etc.
Data in AC can be displayed, used in many ways to work, shared and managed. If the information exists inside Grasshopper we should be able to get it back to ARCHICAD as well.
Also we are looking forward to see a MAC version of both Grasshopper and the plugin! It seems unbelievable for an AC user, familiar with the multi-platform concept, to be forced to install Windows and duplicate ARCHICAD!
Hope you find this article interesting and please post if you have some experience that you can share, or any question.
Thanks for reading and see you soon in the next article!
