From Rhino to Grasshopper

Grasshopper is a visual programming environment that ships inside Rhino - open it by typing Grasshopper at the command line. Instead of writing code, you drag components onto a canvas and wire them together; data flows left to right, from inputs through operations to output geometry. Crucially, Grasshopper does not run in a separate world: its output is previewed live in the Rhino viewport, overlaid on your model in a lighter shade. The definition on the canvas and the geometry in Rhino are two views of one live system.

The rest of this course lives on that canvas. But before you can compute anything interesting, the definition needs something to work on - and very often that something is geometry you have already drawn in Rhino. So the first, foundational Grasshopper skill is not a fancy component; it is simply getting your Rhino geometry into the definition cleanly, and getting results back out when you are done. Master this bridge and Grasshopper stops feeling like a separate program and starts feeling like Rhino with a brain.

One clarification saves a lot of early confusion: Grasshopper does not generate its geometry in the definition file the way you might expect. The .gh definition stores the logic - the components, their wiring, the slider values - while the geometry it produces is computed on the fly and shown as a preview over your Rhino model. That separation is exactly what makes a definition reusable: the same logic can be pointed at different Rhino inputs and produce different results, because the logic and the geometry are deliberately kept apart. The bridge in this lesson is how you connect the two.

To feed a Rhino object into Grasshopper you use a parameter component - a container like Curve, Point, Surface, Brep or Geometry dropped on the canvas. Right-click it and choose Set one Curve (or Set Multiple Curves) and Grasshopper sends you to the Rhino viewport to pick the object(s). Now that parameter holds a reference to those Rhino objects - not a copy, a pointer. This is the everyday way a definition grabs 'this site boundary', 'these facade rails', 'that surface to panelise'.

Because it is a reference, the link is live: edit the original curve in Rhino - drag a control point, move it - and the parameter updates, so everything downstream re-solves automatically. That is the magic and, occasionally, the trap: if you delete the referenced Rhino object, the parameter goes empty and the definition breaks. When you want a definition to be self-contained - to travel to another file or stop depending on the Rhino objects - you internalise the data (right-click the parameter > Internalise), which bakes the geometry into the component and cuts the live cord. A useful habit: reference while you are actively designing and want the link; internalise when you want to hand the definition over or lock its inputs. Selecting by layer (or using a Geometry Pipeline component that grabs everything on named layers automatically) is where the clean-layer discipline from the last two lessons pays off directly.

Once geometry is referenced, you live in a two-window rhythm: the canvas where you build logic and the Rhino viewport where the result previews. Grasshopper geometry shown in the viewport is preview only - it is not real Rhino geometry yet, cannot be selected in Rhino, and vanishes if you close the definition. You can toggle a component's preview on and off (spacebar, or right-click) to keep the viewport readable, and a component shows its state by colour: grey is happy, orange means a warning (something is off but it ran), red means an error (it could not compute). Reading those states is a core debugging skill you will lean on for the rest of the course.

The live link is directional and worth understanding honestly. Changes to the referenced Rhino geometry flow into Grasshopper and re-solve the definition. But changes you make inside Grasshopper (moving a slider, rewiring components) do not alter your original Rhino objects - the definition only ever reads them. Your parametric output stays in Grasshopper's preview until you deliberately push it back across the bridge. This one-way-read, explicit-write-back model is what keeps the workflow safe: you can experiment freely in the definition without ever corrupting the hand-built Rhino geometry underneath.

This is also why the preview is such a gift while you design. Because the result updates the instant you drag a slider or edit the source curve, you get immediate visual feedback on every change - a tight, fast loop of 'adjust, look, adjust' that is the real pleasure of working parametrically. Keep previews on for the components you are actively judging and off for the intermediate plumbing, and the viewport stays a clear readout of the design rather than a tangle. Learning to curate what you preview is a small habit that keeps big definitions legible.

When the definition produces something you want to keep - a panelised facade, an array of louvres, a set of fabrication curves - you bake it: right-click the output component and choose Bake, and Grasshopper writes the previewed geometry into the Rhino document as real, editable objects, on a layer you choose. Baking is the export step from the parametric world back to the ordinary Rhino world; only baked geometry can be dimensioned, detailed, exported to a fabricator, or handed to a consultant.

A few honest habits make baking painless. Bake onto a deliberate layer (respect the discipline from Lesson 1.2) so the results are organised, not dumped on the current layer. Understand that a baked object is a snapshot - it is now static Rhino geometry with no memory of the definition, so if you change a slider afterwards you must bake again to get the updated version (and delete or manage the old bake). For this reason many workflows keep the definition as the living source of truth and bake only at milestones - a design freeze, a drawing set, a fabrication release. Some newer workflows (Rhino's Grasshopper Player, or data-driven documentation) reduce manual baking, but the mental model is unchanged: the definition computes, and baking commits a chosen result into the Rhino file you actually deliver from.

Not everything should be parametric, and a mature computational designer is as good at knowing when not to open Grasshopper as at using it. The honest heuristic is about repetition, variation and change. If a piece of geometry is a one-off - a sculptural stair, a specific context massing, a single feature - modelling it by hand in Rhino is faster and clearer. If it repeats (a facade of a thousand panels), varies by rule (openings that grow toward the sun), or will be swept and re-run (fifty layout options, an optimisation), a definition earns its keep many times over. The cost of a definition is the up-front effort of building and debugging the logic; the payoff is effortless change, reuse and scale. Below a certain complexity or repetition, that trade is not worth it - and forcing everything through Grasshopper is a classic beginner over-reach.

In practice, real projects mix both fluidly. You hand-model the site and the one-off moments, and build definitions for the systems: the panelised skin, the structural grid, the repeating detail. The two stay connected by exactly the bridge in this lesson - reference the hand-built context in, bake the parametric systems back onto their layers. That interplay, not a purist all-parametric model, is what actual computational practice looks like. With the bridge understood, you are ready to step fully onto the canvas: the next module opens Grasshopper itself and teaches the visual language you will speak for the rest of the course.