Getting Architecture Done
Efficient Methods for Architecture

The Hard and the Soft Way to Work with Grasshopper References

There is a fun component when working with computational tools in architecture: they are extremely flexible. They simplify a whole algorithmic world, letting us choose what to do with them.

Freedom and flexibility are great, but they can be a double-edged sword; too much flexibility might lead to solve a problem in multiple ways without a real improvement. Standardizing our ways of doing can speed up our work. Setting up workflows and constrains can save time and create space for creativity.

Two Types of References

When working with Grasshopper, the geometry used can be native from Grasshopper or referenced from Rhino. Either way, the operations we can perform with both types of geometry references inside Grasshopper are the same—the only difference resides in the origin of that geometry and the method used to reference it.

I like to differentiate among two ways of referencing Rhino geometry inside Grasshopper: hard references and soft references.

  • Hard references are manual references of Rhino objects from a Grasshopper component (created by right-clicking the Grasshopper component and manually selecting objects in Rhino). This references reference the objects directly by their guid (the identification number that Rhino uses to identify objects).

  • Soft references are references of Rhino objects through a geometry pipeline, where a Grasshopper component defines a set of object types and a layer filter to find objects in the Rhino document. This references use filters to search for objects inside a document.

I strongly recommend you to always work with soft references. When Grasshopper definitions start getting big, hard references can be your enemy; they are difficult maintain and can break a whole definition easily. On the other hand, soft references will make it easier for you to organize your Grasshopper references in a Rhino document. Here is how I do it.

By-Layer Reference Naming Convention

Every time I work with Rhino references in Grasshopper, I create layers using a naming convention to reference them from the geometry pipeline with ease.

I group all layers with soft references inside a layer folder named REF, and every layer under it is named with the prefix REF_ and a short description (using text and underscores to describe what kind of references are to be stored on them).

In Grasshopper, I create a geometry pipeline component for each of those layers, filtering by name, and, if known, by object type (point, curve, surface, mesh, or a combination of those).

After everything has been set up, we have Grasshopper geometry pipelines that “soft reference” the contents inside the reference layers. Changing the contents of those layers will update the reference and re-generate the Grasshopper definition using the new inputs. For instance, if you were to draw a set of curves where you need trees to be created each five meters, you would:

  • Create a layer, named REF_Tree_Curves;
  • Draw your tree curves inside them;
  • Create a Grasshopper pipeline, setting the type to curves and the name to REF_Tree_Curves;
  • Use that Grasshopper component (that contains all your curves) as the input of your tree-generating definition;
  • Add, delete, or update your curves inside the REF_Tree_Curves layer;
  • See the model update with your updated soft references.

Hopefully, this method will simplify your way of working with Grasshopper references, and allow you to create bullet-proof definitions which don’t get broken by hard-references. Thanks for reading.

Grasshopper Workflows

As happens with programming languages, Grasshopper is a really flexible tool. A given problem could be solved in many different ways, and each of those ways would be equally right, as Grasshopper is basically programming through a visual interface (of course, some solutions to that problem will be more efficient and optimized than others).

Through the daily use of Grasshopper, I found myself repeating tasks over and over—common tasks that were part of most of my Grasshopper definitions.

For those common tasks, I started developing generic Grasshopper definitions that contain just that—the workflows—and can be copy-pasted into bigger Grasshopper definitions when needed.

Workflows are ways to structure definitions for those frequently-performed tasks, or simply paths in which problems can be solved, in order to save time and optimize the way we do things.


Recently, I incorporated two of my workflows to the GettingArchitectureDoneKit, an open-source kit with utilities and workflows for common tasks in Grasshopper for Rhino. You can check the repository of the project on Github. Utilities are simplified or improved operations, and workflows are ways to structure your definitions to achieve certain things.


The first workflow I implemented allows to bake elements in different layers. A small group is created per objects' layer with a specific name, and all of them are later included under a group called Output.

I like maintaining the color used in workflow groups, so every time I copy-paste it to my definitions its color can be easily associated to a workflow.

The main functionality of the GADWorkflowBake is the Bake Component, part of the Elefront plugin for Grasshopper (a dependency of this workflow).


The purpose of the second workflow is to work with different parameter-sets inside a Grasshopper definition.

For instance, the file provided inside the kit has a file with various options for the width, height, length, and x variables of the definition. This way, you can work with different options in parallel, and switch among them just by changing a single connector.

I will be adding more workflows to the GADKit in Github as I create them. It is good to become familiar with this dynamic of abstracting the workflows you often use, to save time and optimize different processes.

Create Grasshopper Components with Python

If you are familiar with Grasshopper for Rhino, you may already know that its visual programming interface works with components that get plugged to each other—each of the components being a function that takes and returns parameters as inputs and outputs, respectively.

GhPython is a Grasshopper plugin which brings the flexibility of the python programming language and the rhinoscriptsyntax right into Grasshopper — so you can build custom Grasshopper components by coding scripts in python.

This plugin doesn't come with Grasshopper by default, but you can download it here, and install it by dragging it on top of Grasshopper. The new plugin will appear under the Math components' section the next time you run Grasshopper (or you can run the GrasshopperUnloadPlugin command in Rhino to unload the plugin, then run Grasshopper to open it back again).

Creating a Point with Python in Grasshopper

You can customize the inputs and outputs on the Grasshopper interface. The input names will represent the name of those objects inside the python script. The output will be created setting a variable inside the python script with the same name that you set in the component. Even though they are editable, the inputs in the example are x and y, and the output is a.

Python scripting code to generate a Point in Grasshopper

Create the Grasshopper definition as you see in the screenshot, and then double click the Python component to edit its code. Add the following snippet:

# Load rhinoscriptsyntax library as rs
import rhinoscriptsyntax as rs

# Variables x and y are automatically defined

# We output a point with (x, y, 0) on variable 'a'
a = rs.AddPoint((x, y, 0))

Rhino Visualization of the Point created with Python in Grasshopper

The end result is output a, which is a Grasshopper Point created by our Python component. This point is exactly the same that if it was created with the Grasshopper Construct Point component.