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.

Getting Architecture Done by Nono Martínez Alonso