The Grasshopper Canvas

Grasshopper opens as its own window that floats over Rhino. Three regions matter. Across the top sits the ribbon of component tabs - Params, Maths, Sets, Vector, Curve, Surface, Mesh, Transform and more - each a drawer full of components you can drop onto the board. In the middle is the canvas: the large grid where your definition takes shape. And behind it all sits Rhino, whose viewport is where the geometry your definition produces is actually drawn. There is also a thin menu bar (File, Edit, View, Display, Solution, Help) and, at the far edges, a parameter viewer and remote panel you can ignore for now - the three regions above are what you live in daily.

The canvas is infinite and empty by design. You are not meant to draw here; you are meant to place and wire. Double-click anywhere on blank canvas and a small search box appears - type divide, hit enter, and a Divide Curve component lands under your cursor. That double-click search is the fastest way to work, and most experienced users barely touch the tabs once they know component names. But the tabs are how you learn what exists, so keep them in view early on. Panning is a middle-mouse drag (or arrow scroll); zooming is the scroll wheel; and a quick way to find your way back when you get lost is to zoom-extents the canvas so every component fits the view.

A definition you build is saved as a .gh file (the binary format) or the readable .ghx (an XML variant you can inspect in a text editor). Either way it is separate from your Rhino .3dm file. That separation trips up beginners: your parametric logic and your Rhino scene are two documents that talk to each other, not one file. Save both, and keep them side by side - a definition that references Rhino geometry expects to find that geometry when it reopens.

The component palette lives in those top tabs. Click a tab - say Curve - and a panel of icons drops down, grouped into sub-sections (Primitive, Spline, Analysis, Division, Util). Each icon is a component you can drag onto the canvas. Hovering an icon shows its name; that is how you go from 'I need to split a curve into pieces' to finding Divide Curve under Curve > Division. The tabs are organised by what kind of thing a component works on - curves live under Curve, surfaces under Surface, numbers and logic under Maths and Sets - so once you know roughly what family a task belongs to, the right drawer is a good guess.

A lovely detail: the palette is zoomable. Grasshopper ships with well over a thousand components and the default icons are tiny, so if you hold and drag downward on a tab (the zoomable interface) the icons scale up until you can actually read them, then let go to place one. On a dense tab this is the difference between hunting and finding, and new users often miss it and squint instead. Many practitioners also install extra plug-in tabs (Kangaroo, Ladybug, LunchBox) that appear as additional drawers along the same ribbon - the palette is how the whole ecosystem shows up.

There is a second route worth knowing, and it is faster once you know names. Many parameters can be created by double-clicking the canvas and typing a value or expression: type 12 and Grasshopper offers a Number Slider preset already set near that value; type a point like 0,0,0 and it offers a Point parameter; type pi and it recognises the constant. So there are three ways to place things - the tabs (browse when you don't know the name), double-click search (fast recall when you do), and typed shortcuts (fastest for parameters and constants). Use whichever matches how well you already know the component you are reaching for, and expect to migrate from tabs toward search as your vocabulary grows.

Here is the relationship that makes Grasshopper Grasshopper: the canvas computes geometry, and Rhino draws it. When a component produces geometry, Grasshopper previews it in the Rhino viewport in a soft green (selected components preview brighter). Nothing is 'baked' into the actual Rhino document yet - it is a live overlay that vanishes if you delete the component. To make geometry into real, editable Rhino objects you bake it (right-click > Bake), which is a deliberate one-way handoff.

Because a big definition can throw a lot of geometry on screen, every component has a preview toggle. Right-click a component and untick Preview (or select it and press the preview button) and its geometry stops drawing in Rhino while it keeps computing. You will lean on this constantly: preview only the final result, hide the scaffolding of intermediate points and vectors, and the viewport stays legible. There is also a global Preview off for unselected mode that shows only what you have selected - superb for debugging a busy canvas.

One more link: Grasshopper geometry lives in Rhino's coordinate space and units. A slider that reads 4 means 4 of whatever your Rhino file's units are - millimetres, metres, feet. Set your Rhino units before you build, or your circles will be a thousand times too big or small.

Everything above is furniture. This is the engine. A Grasshopper definition is a directed graph that evaluates from its inputs toward its outputs - conceptually left to right. When you drag a slider, Grasshopper does not re-run the whole board blindly; it marks that slider as changed and re-solves everything downstream of it, in order, while leaving everything upstream untouched. The result appears in the viewport in the same instant.

This is why the mental model of 'a live machine' matters. In CAD, changing something means editing an object. Here, changing something means feeding a new input and letting the computation flow forward. There is no 'apply' button and no undo-heavy rework; the graph is always already solved for the current inputs. If the canvas ever seems frozen, it is usually because a heavy component is recomputing, or you have accidentally created a very large amount of data - not because it broke.

Grasshopper enforces one hard rule that keeps this sane: data flows one way and the graph cannot loop back on itself (no wiring an output back into something upstream of it). That acyclic, one-way flow is exactly what lets it re-solve predictably every time. It also means the canvas has a clear reading direction - inputs on the left, results on the right - so a tidy definition physically mirrors the order in which it computes, which is why professionals lay their canvases out left to right on purpose.

There is a practical corollary worth internalising early: because the graph is always solved, you debug by trusting the current state, not by re-running things. If a result looks wrong, the wrong value is already on the canvas - drop a Panel anywhere along the chain and read the real data at that point. Nothing is hidden behind a build step. Internalise 'left to right, always solved' now and the next three lessons - components, wires, your first definition - will feel like variations on a single, calm idea.