Understand the 3 Types of Grasshopper Scripts to Clarify Your Value
One of the biggest issues that I see with computational design is the lack of awareness. As in most people don't know what we can and cannot do. Companies hire us because they see value in the work that we do but they may not know what that actually is.
Unlike most traditional companies, say architecture or engineering, it's clear what an architect or engineer does. Right now, I work for a company of roughly 700 people that has only 10 computational designers (me included) and most people do not know what I can and cannot do.
Even though the industry currently favours computational design, there is still a lot of ambiguity in the value we offer to a company. Computational design is a huge field that intersects and includes many other fields, so it's hard to understand its specifics.
I don't claim to know the answers to all of this but I know that we need to make a start towards breaking down this ambiguity. The best place to start is with the most popular computational designer's tool: Grasshopper.
Based on my experience, there are three types of Grasshopper scripts that computational designers can offer: utility, workflow and once-off scripts.
Utility Scripts
As its name implies, these are scripts that are designed to be reused over and over again to solve a problem or automate an existing function.
The idea is that these scripts help people execute a workflow that they have been doing manually for some time now. It's a lot like building traditional software, it's a way of getting people to consistently act and a way to standardize the quality of the input and the output.
What comes to my mind are scripts like:
- A property visualiser
- A model rotator
- A model carbon calculator
These are common functions that people have to do in their projects or at work. They are like your company's Microsoft Word or Excel template. They are reusable and meant to enforce a certain standard.
But if you have worked with Grasshopper, you know that since it's largely based on geometry, there is always some massaging that people need to do. Unlike traditional software, we can't hide our mess (the components) with a nice user interface. That means to distribute this to people, they at least need to know the basics of Grasshopper. Unlike traditional software, they can't just install something and hit a button.
Because of the inherent drawbacks of Grasshopper, you need to make sure that these utility scripts have your user in mind. As, these scripts need to be readable, clean and most of all easy to use (or as easy to use as Grasshopper is).
Workflow Scripts
These are scripts that are made for a process that does not happen often. Unlike utility scripts, you are most likely trying to solve a problem that might happen a handful of times as opposed to setting a standard way of working.
Normally, these problems come from projects and depending on who should run these scripts, you don't have to make it as user-friendly. Your main focus should be to make a script that integrates well with the nature of the problem and the team.
An example of these types of functions would be:
- Update column positions based on project X's architect model
- Distribute the panels based on project Y's civil engineer
- Check for clashes when project Z's geotech engineer updates the tunnel centerline
They are scripts that solve specific problems that people think may occur several times throughout the project or within a certain time frame.
Once-off Scripts
Similar to workflow scripts, once-off scripts are made bespoke to a problem. The difference is that once-off scripts are made to solve the problem once. Of course, because it's still a script, you can still re-run them. But these are typically complex scripts that rely on specific assumptions and inputs.
Once-off scripts can solve problems like:
- Create a Revit model from a client's IFC model
- Find an optimal route from site A to site B
- Calculate the section properties for all the unique sections in the project
These are scripts that are not about automation, it's about solving a problem that cannot be solved through traditional means. They are the most fun and challenging types of scripts to make but you cannot scale them. Depending on the project, the impact of these scripts can be limited.
Because these problems tend to be exploratory, they are a significant investment of your time and you may not get a result in the end. You will likely learn from the experience but it might mean more cost for little return for the project. For these scripts, it's important to communicate the findings and the progress of the scripts.
Final Thoughts
By categorising our Grasshopper scripts, we can better communicate their value and capability to the people that we work with. As in, when we engage with project teams or other people, we can use these categories to help them understand how we can help them and what kind of solution they are after.
Often, I have found myself on project teams to help create workflow or once-off scripts for them. When it comes to utility scripts, that has to be looked at from a more holistic point of view. Meaning, you need to first identify common patterns amongst everyone and then sit with them to come up with a script that solves that problem.
Unlike other industries, we cannot exist on our own. We need to be able to work with others and communicate our process to them. It's a weird and wonderful dynamic with full of challenges but I think we can find a way to make it work. I have found that clarifying and educating the computational design process to others is the best way to promote our work.
The clearer and better we get at communicating what we do, the closer we will be bringing that gap.