Modelling in Rhino

Rhino's interface looks busy but rests on a simple idea: the command line is the boss. Almost everything is a typed command - Line, Loft, Move - and the command line prompts you for each input in turn ('Start of line', 'Next point'), while offering options in angle brackets you can click or type to change. Toolbar buttons and menus are just shortcuts that run those same commands. Once you trust the command line, Rhino becomes fast: you type the first few letters, autocomplete offers the command, and you read the prompt to know what it wants next.

The screen is usually split into four viewports - Top, Front, Right and Perspective - all showing the same single model from different angles. This matters more than it seems: you model in 3D by working across views, drawing a plan in Top and pulling height in Front. The status bar along the bottom carries the switches you will toggle constantly - Osnap, Ortho, Grid Snap, Gumball, and the current CPlane - which the next lesson covers in depth. For now, the habit to build is: watch the command line, always know what Rhino is asking you for, and never click randomly hoping something happens.

Two more workspace habits repay themselves immediately. First, learn to navigate fluently - orbit, pan and zoom (and Zoom Extents / Zoom Selected to snap the view back to your geometry) - because most beginner frustration is really disorientation, not modelling difficulty. Second, notice Rhino's display modes (Wireframe, Shaded, Ghosted, Rendered): switching to Wireframe to see through geometry, or to Shaded to read a surface, is not decoration - it is how you check that what you built is what you think you built. A model you cannot clearly see is a model you cannot trust.

Good surfaces come from good curves, so most modelling starts in 2D. `Line` and `Polyline` give you exact straight segments - the backbone of anything orthogonal. `Curve` (interpolated or control-point) gives you smooth NURBS curves; InterpCrv passes through the points you click, while the control-point Curve command places control points near the shape, which - as the last lesson explained - gives cleaner, lighter curves once you are comfortable.

The discipline here is to draw curves that are as simple as the shape allows and that connect exactly. Use object snaps so endpoints truly coincide rather than 'nearly' meeting - a gap of a hundredth of a millimetre is invisible on screen but will break a Join, a Loft or a Boolean later. Keep profile curves planar when they are meant to be planar (Rhino can tell you with IsPlanar or the properties panel). Think of your curves as the skeleton: a clean, well-connected skeleton makes every surface operation downstream trivial, while a messy one propagates errors into everything you build on top. This is the first place where 'clean geometry' stops being a slogan and becomes a concrete habit.

Four commands turn curves into most surfaces you will ever need. `Extrude` (ExtrudeCrv) pushes a curve straight along a direction - the workhorse for walls, slabs, mullions and anything prismatic. `Loft` skins a surface through a series of section curves in order, like stretching fabric over ribs - ideal for a hull, a tapering tower, a flowing canopy. `Sweep` (Sweep1 / Sweep2) carries a profile curve along one or two rail curves - the tool for handrails, cornices, extruded mouldings and anything with a consistent cross-section following a path. `Revolve` spins a profile around an axis for anything rotational - a column, a vase, a dome.

The craft is in the input curves and the options. A Loft between curves whose seams (their start points) are misaligned will twist; a Sweep with a lumpy rail inherits the lumps. Match the number of control points and the direction of your section curves and the surface comes out fair; feed it inconsistent curves and no option will fully rescue it. Learn to read the preview before committing, and to reach for the simplest command that does the job - an Extrude you can trust beats a clever Sweep you cannot.

Around these four sit a handful of surface-editing companions you will use constantly: Offset and OffsetSrf to give a surface thickness, Trim and Split to cut geometry with other geometry, Join to stitch pieces into a polysurface, Fillet / FilletEdge to round corners, and Cap to close a tube-like polysurface into a solid. None of these is complicated on its own; fluency is simply knowing that most modelling is a sequence of these small moves - draw curves, make a surface, trim it, offset it, join and cap - rather than one heroic command. When you plan a piece of geometry, it helps to think backwards from the result: what surface do I need, what curves make it, and what is the shortest clean path between the two?

Closed polysurfaces are solids, and Rhino's Booleans - `BooleanUnion`, BooleanDifference, BooleanIntersection - combine them: union fuses volumes, difference carves one out of another, intersection keeps only the overlap. Under the hood a Boolean is just an automated intersect, trim and join: Rhino finds where the solids cross, trims each along that intersection, and stitches the survivors into one polysurface.

That mechanism is exactly why Booleans fail, and why the failures teach you about clean geometry. If the input solids are not truly closed (they have naked edges - open boundaries), or if two faces are precisely coincident (a wall face sitting exactly on another), or if the model tolerance is too loose for the size of the features, the intersect-and-trim step cannot resolve and the Boolean either errors or leaves a mess. The fixes are habits, not tricks: check solids are closed (ShowEdges reveals naked edges), nudge coincident faces apart by a hair, and keep a sensible tolerance for your units. When a Boolean fails, resist forcing it - repair the input geometry, because a corrupt polysurface will haunt every operation and every Grasshopper reference that touches it afterwards.

The single biggest difference between a model that is a pleasure to work with and one that is a nightmare is organisation, and it costs almost nothing to get right. Use layers deliberately: a layer per system (structure, envelope, furniture, reference, context), sensibly named and coloured, so you can isolate, hide and select by category. Name the layers before you need them, not after the model is a soup of 'Layer 07'.

This is not tidiness for its own sake - it is the interface to everything that comes next. When you reference geometry into Grasshopper (the last lesson of this module), the cleanest way to grab 'all the facade curves' is to select them by layer; a well-layered model makes a parametric workflow effortless, while a flat one makes it painful. The same discipline covers naming important objects, purging unused blocks and materials, keeping construction curves on a throwaway layer you can delete, and periodically running Audit3dmFile or checking for bad objects (SelBadObjects). None of this is glamorous, and all of it compounds: an hour of organisation habit saves days of untangling later, on every project, forever.

There is a deeper reason this matters in a computational workflow specifically. A Grasshopper definition that pulls its inputs from named layers via a Geometry Pipeline will automatically update when you add or edit geometry on those layers - so a disciplined layer structure turns your Rhino model into a living, structured input feed rather than a pile of objects you must re-pick by hand. In other words, the layer scheme you set up in the first minute of a project is not housekeeping you do instead of the interesting work; it is part of the parametric design itself. Sloppy layers do not just look bad - they actively block the automation that makes computational design worth the effort.