Go to ThinkParametric

How and when to Automate using Rhino and Grasshopper

What makes sense to automatize/script and what not

I started doing my first attempts implementing parametric modeling techniques into my projects using Rhino and Grasshopper after I got bored and frustrated repeating a certain set of actions over and over. One of the very first scripts I remember writing was a script to generate a simple column grid. The input parameters where the spacing between the x and y-axis and the size of the columns. The reason for this was that every time there is a new project, almost always a structural grid is needed. This grid allows you to model accurately and more efficiently and it serves as a reference element in your project. The hassle of drawing the grid lines, offsetting them, putting the columns on the intersection of the grid lines doesn’t seem that work intensive, but if there was a change of spacing, column size, column shape etc., things tend to add up.

I know, far from the sexy patterns or form-finding algorithms that are also possible using the same parametric tools! Key to understand is that I got driven by finding myself doing mind-numbing repetition and telling myself, there has to be a more efficient way of doing these tasks. Initially I was not driven by wanting to design sexy patterns or forms etc., that came later on. This was when I discovered how much power and most important, how much control you have using parametric modeling techniques.


Like mentioned above and also visualized in this graph from howtogeek, be smart about when to use scripts in your projects. If you find yourself repeating a certain set of actions a lot, maybe it’s worthwhile writing a script for it. This could also be a good incentive to start writing your very first script, as automatization scripts are usually more simple to write, like my column script.

Start simple and small

Always start small when you start writing your first script. Set a clear goal on what you want your script to accomplish and only focus on that. It is very helpful when you’re new to scripting to write the actions you want your script to perform in pseudo code. Remember, complexity is nothing more than stacked layers of simple elements or actions on top of each other.

For example let’s use my column script and write it out in pseudo code:

Goal: to create a grid in the x and y direction with columns at the intersection points.
Action 1: draw axis in x-direction
Action 2: offset a amount of times with spacing b
Action 4: draw axis in y-direction
Action 5: offset c amount of times with spacing d
Action 6: locate the intersection points of the x and y axis lines.
Action 7: draw a rectangle, circle, or whatever shape column at intersection point with dimensions e.

These are more or less the steps you need to take to get the job done. Next you could start adding another dimension by specifying an extrusion length for your columns etc. It is a silly example, but I hope you get the point. Start small and build your script up gradually.

Take baby steps

The way you’re going to learn and succeed is by trial and error, small steps at a time. Taking Grasshopper as an example, I spend months connecting component to component to figure out what worked and what didn’t. The more I tried and failed, the more I learned on how to actually succeed. Like previously mentioned, start small and simple and expand your definition by small steps at a time. The advantages of taking small steps is that it will be easier for you to see what’s going on and if things don’t work out, you can easily fall back on a previous step, without losing track over your definition.

Let the definition achieve one clear goal

This advice goes hand in hand with the start small advice. Don’t create a script that will design your whole facade or the whole building with a press of a button. Break the task up in smaller parts and set clear goals for each individual task. Like: script for form finding facade, script for panelization explorations facade, script for structural explorations facade, script for standardizing panels facade etc. This way of working has many advantages, just to name a few: It is easier to structure and manage your definitions efficiently, working in a team becomes easier as different people can focus on different goals simultaneously, if something breaks in your script it is easier to locate, you’re more likely to have less crashes of grasshopper with smaller scripts and the execution time is faster. This principle is based on the Single responsibility principle and comes from programming.

High rise example

When I was working at an architectural office (Rojkind Arquitectos), we had a high-rise project and I was in the team in charge of the conceptual design. We started doing some quick manual modeling explorations to find some initial forms that matched our concept and related to the program of demands given by the client. As the client wasn’t sure of what he exactly wanted, the numbers in the program of demands were subject to change. To anticipate this, we decided to parameterize the form finding process. This worked out well, as we could quite quickly anticipate changes in the numbers by the client and adjust our form but keeping design intent.


So far so good, but as the project developed from conceptual design, to schematic design, to design development and finally to construction documents, my definition went from a small little form-finding script to a huge unclear monster do-it-all-script. I tried to incorporate everything in it, besides form-finding, a structural solution, floorplan outlines, facade explorations, floorplan layouts, even to the part of exporting 2D floor plans to DWG files, for drafters to prepare the construction documents. You can imagine that this caused me a lot of unnecessary headaches, locating errors in the definition, unnecessary crashes, it was a pain to work with as it took 40-50 seconds before a solution was calculated and it was almost impossible to work in team work, as I was the only one who understood what the hell was going on.

In the end we decided to rewrite the whole thing from scratch and splitting it up into different parts, it took us luckily only a week to do so, but it saved us so much unnecessary troubles and delays that it was worth every minute.

So I can’t stress this enough, after you decide you’re going to write a script, set a clear goal of what you want your script to accomplish, write the steps out in pseudo-code and only focus on achieving that goal, nothing more.

I hope this blog post was informal, learning something new takes time and effort. We’re here to assist you along your learning path and we’re more than happy to help you along the way with any questions you might have.

Happy learning!

-Arie-Willem de Jongh @awdejongh

  • Tim Fuger

    Great article!! The insight is extremely helpful for understanding how to achieve the larger picture goal!!

  • Mario Manzanilla

    Great article! just a question, how does breaking it into smaller pieces actually work? Is it (for example) baking on grasshopper the geometry and then work with a new definition using that geometry?. big fan of your work btw! i just got out of architecture school and always kept an eye on paramteric modeling n, which projects with Rojkind where you involved in?

  • Yes exactly! basically what you want to do is that your definitions generate outputs that can inform the next ones.nnnThe simpler the better, lines, points and clean simple surfaces for example.

  • Samir Dedarally

    Great read

  • Ricardo Chavez

    Great article