Welded to nothing

A grasshopper definition is welded to rhino the instant you reach for a solid. Everything downstream follows from which primitives you pick up first.

There’s a small design decision that happens in the first five minutes of every parametric definition. You choose a primitive. You reach for a plane, or you reach for a solid. The rest of the definition is downstream of that choice, and it is almost impossible to back out of.

If you reach for the solid, you get convenience. Booleans. Offsets. Fillets. Rhino will happily do all of it. The math underneath is the NURBS kernel and you are borrowing it. When you hand someone else your definition, you also hand them the requirement that they own the same kernel. When you try to port the definition to the web, or to gcode, or to a CNC post-processor, the kernel is not available, and the work does not travel.

If you reach for the plane – really the plane, with a normal and an origin and a frame – you get inconvenience. You have to build your own offsets out of vectors. You have to construct your own fillets out of arcs and tangencies. Rhino will help you less. But the math is yours. You can carry it anywhere that knows how to add numbers.

The discipline

State it as a rule, in order of preference:

prefer planes to solids
prefer curves to surfaces
prefer pure math to either

The rule is not an aesthetic preference. It is a portability claim. A definition built under it is welded to nothing. It can be rewritten in pure javascript, rendered with three.js or raw svg, turned into gcode, animated with matplotlib, compiled into a unity asset. The math is the substrate; everything else is a renderer.

A definition built without the discipline stays trapped inside the closed tool forever. It is still useful – rhino is a fine home – but it is the ceiling on the work. You will never sell a $9 browser configurator built on it, because the browser will not run the kernel. You will never deliver a lightweight handoff to a client’s engineering team, because the handoff is a 2GB install and a seat of commercial software.

What this looks like in practice

A concrete example. A timber connector jig. The naive approach: model the connector as a solid, boolean subtract holes, offset the faces to get the jig body, loft a lid. Seven or eight kernel operations, each one a potential failure point, each one non-portable.

The discipline approach: describe the connector as a set of points on a plane. Compute hole centers as offsets in the plane. Extrude a boundary curve to get a prism. The solid never existed as a first-class object; it was computed at the last step from curves and planes. Port this to javascript and you will not lose any fidelity, because there was nothing to lose.

The cost is real. The first approach takes an afternoon. The second takes three. But the first approach is terminal and the second compounds. The second definition is faster the second time you use it, and free by the tenth.

Why it’s rare

Almost nobody who uses grasshopper operates under this discipline. Not because they don’t know better – most experienced users will, asked directly, agree with the rule. They just don’t operate under it. The closed tool is too generous; it rewards the path of least resistance, and the path of least resistance is the solid.

So the discipline stays rare, which is good news for anyone who chooses to practice it. The market does not know yet that portable parametric definitions are possible. The market is still buying closed solutions from closed vendors. A small studio that ships portable artifacts – browser configurators, lightweight handoffs, datasets that feed geometry from anywhere – has an unusual amount of room to work.

The discipline is the moat. It is also the thing to teach, once there is enough evidence it works. For now it is enough to operate under it, and to let the work travel.

Filed under geometry, rhino, practice. First of several notes on the operating principles behind everything shipped from this studio.