Lesson 9.1Lesson 9.1 · Computational Workflow
Parametric to Fabrication
One definition that drives both the design and the machine data that makes it
The same Grasshopper file that renders the design can emit 400 labelled, nested cut files - no one re-draws a thing.
For most of history, the making instructions were re-created by hand from the design: a drafter turned a drawing into a cut list, panel by panel, error by error. A computational workflow deletes that step. One parametric definition produces both the design you present and the fabrication data a machine reads - labelled parts, a nest, a toolpath, a stream of robot code.
This is the bridge between parametric design and physical making. When the definition drives the machine, a late change is a re-solve, not a redraw; a facade of all-different panels costs about what all-identical panels would; and the cut file can never quietly disagree with the model, because they are the same file.
One graph, two branches: the render and the cut file are the same source of truth.
One definition, two outputs
The premise of this whole course is that the file becomes the thing. A computational workflow pushes that idea one step further: a single parametric definition - a Grasshopper graph in Rhino, a Dynamo script, a bit of COMPAS in Python - produces both the design you present and the data a machine needs to make it. The geometry that renders in your view is the same geometry that gets unrolled, labelled and posted into a toolpath. There is no second model for fabrication, drawn by hand from the pretty one.
Picture a perforated screen of 400 panels, each with a slightly different aperture pattern tuned to the sun behind it. In the old way you would design the look, then a drafter would redraw every panel as a cut file - 400 chances to introduce error and weeks of work. In a parametric-to-fabrication pipeline, the same definition that varies the apertures also emits 400 labelled DXF outlines, already nested on sheets, already carrying a part ID. Move one slider - panel depth, say - and the render and the cut list both regenerate together. Design and making are two branches of one tree.
That single source of truth is the point. It is not automation for its own sake; it is the elimination of the drift that creeps in whenever a human re-draws what another human designed.
Design view and cut file are two branches of ONE definition - not two models.
Turning a model into fabrication data
What actually flows down the fabrication branch? For sheet work it is a sequence you can name: unroll or flatten curved surfaces into 2D outlines; generate the cut geometry - outer profile, internal holes, engraving for a part ID; add fabrication features - tabs to hold parts in the sheet, dogbone fillets so a round router bit can cut a square corner, kerf compensation offsetting each line by half the tool width; label each part with a human-readable ID and, often, an assembly mark that says where it goes; and nest the lot onto stock. Grasshopper plug-ins do each step - OpenNest for nesting, native unroll for developable surfaces, and simple offset components for kerf.
For 3D and robotic work the branch ends differently but the logic holds: the definition drives a CAM step (RhinoCAM, Fusion, or a slicer such as Cura or PrusaSlicer for printing) that produces toolpaths, or it drives a robot post-processor - KUKA|prc, HAL Robotics, or COMPAS FAB - that turns a stream of target planes into native robot code (KRL for KUKA, RAPID for ABB). In every case the designer is authoring not just a shape but the instructions to reproduce it. A worked feel for scale: a plywood pavilion of 600 unique ribs might export as a few hundred DXFs across 40 sheets, every rib pre-labelled, in the time it takes to make coffee - because the definition, not a person, wrote them.
The features are not cosmetic; they are what makes a part assemble. Assembly marks encode which edge meets which, so a builder facing a pile of 600 unique ribs can read the sequence off the parts themselves. Tabs (small uncut bridges) keep a piece from dropping and shifting mid-cut on a laser; you snap them after. Dogbone or T-bone fillets add relief at inside corners so a round router bit can still let a square tab seat fully - a joint that looks right on screen will bind in reality without them. A definition that emits all of this is doing the fabricator's drafting, correctly, hundreds of times over.
Nesting and the economics of the sheet
Nesting is where the pipeline meets money. Stock comes in fixed sizes - an 18 mm birch ply sheet at 1220 x 2440 mm, a 3 mm acrylic at 600 x 400 - and every square millimetre you waste is cash and carbon in the offcut bin. A nesting routine packs unlike shapes together to maximise material yield: the fraction of the sheet that becomes parts rather than skeleton. Hand-nesting 400 different panels is miserable and error-prone; a solver does it in seconds and can respect real constraints - grain direction locked for strength or looks, a minimum gap so adjacent kerfs do not merge, common-line cutting where two parts share one cut to halve the path.
Do the arithmetic once and the value is obvious. Say those 400 panels average 0.9 sheets each if nested naively but 0.75 if packed well: on 300 sheets versus 360, at a plausible sheet cost, you have saved the price of the software many times over on one job - before counting the cutter time saved by shorter travel. This is why nesting sits inside the definition and not in a separate manual step: when a panel changes, the nest re-solves, and the yield number stays honest instead of quietly rotting.
Yield % is a real KPI - a good nest can save a fifth of your material bill.
From geometry to machine code - and its risks
The last hand-off is the post-processor: the piece of software that speaks the specific machine's dialect. A generic toolpath becomes G-code with this machine's homing, spindle and feed conventions; a robot target stream becomes KRL or RAPID with this cell's tool, base and external-axis definitions. Always simulate before you run. Robot code especially hides traps a laser file does not: the arm can reach a target in several joint configurations, some of which collide; near a singularity (arm fully stretched, wrist aligned) joint speeds spike toward infinity and the controller faults; and a reachable point on screen may be unreachable once the real end-effector and cabling are on. Simulation in the same environment - KUKA|prc, RobotStudio, Visual Components - catches these before a two-tonne machine finds them for you.
The deeper risk is quieter: a live pipeline can regenerate wrong data just as fast as right data. If a unit slips from millimetres to inches, or a kerf offset flips sign, the machine will faithfully ruin a sheet at full speed. So the workflow needs human checkpoints - a nesting preview a person eyes, a first-part cut before committing the batch, a simulation everyone watches. Automation removes the drudgery, not the judgement. And structural sign-off, load paths and code compliance never live in the definition; those stay with the engineer.
Simulate every robot run. The arm will find the collision you did not.
Keeping the chain live
The prize is a live chain: model, drawings, cut files, nest and machine code all downstream of one definition, so a change at the top ripples cleanly to the bottom. That is powerful and fragile at once. Powerful, because late design changes stop being catastrophic - the client moves a wall, you re-solve, and a corrected cut set falls out. Fragile, because the definition becomes a critical asset that only its author may fully understand, and because 'it regenerated' is not the same as 'it is right'.
The disciplines that keep a live chain trustworthy are unglamorous: version the definition like code so you can see what changed and roll back; internalise and name clusters so a teammate can read the graph; keep a naming convention for parts that survives from screen to sheet to site; and freeze a released cut set - export it, tag it, and cut from that frozen copy, not from a definition someone might nudge overnight. Treated this way, parametric-to-fabrication is not a trick for exotic geometry; it is a reliable production method that happens to make one-off and mass-produced parts cost almost the same. That equivalence is the thread the rest of this module pulls.
Grasshopper / Dynamo
Visual parametric definitions for Rhino / Revit
Where the single definition lives; the same graph drives both the design view and the fabrication branch.
OpenNest / nesting
Packing unlike parts onto stock sheets
Maximises material yield and respects grain and gap constraints; re-solves when a part changes.
Kerf compensation
Offsetting each cut line by half the tool width
Without it, laser or router parts come out undersized; the offset is generated, not eyeballed.
KUKA|prc / COMPAS FAB / HAL
Robot post-processors inside the definition
Turn target planes into native robot code (KRL, RAPID); always simulate for reach, collision and singularities first.
Post-processor / G-code
Machine-specific instruction output
Speaks one machine's dialect; a generic toolpath becomes this machine's homing, feed and spindle conventions.
Workshop — build a one-definition cut set
Take a simple parametric object and drive real fabrication data from it, so design and making are two outputs of one graph. Even without machine access you can produce a genuine, nested, labelled cut set.
Rhino + Grasshopper (or Dynamo/Blender+scripting) with a nesting plug-in such as OpenNest; optionally a supervised laser cutter or CNC router to cut a test part.
Goal: emit labelled, nested cut files from one definition Inputs: Rhino + Grasshopper (or any parametric tool), a nesting plug-in, a sheet size Time: ~90 minutes
- 1Model a simple panelised object parametrically - a slatted screen, a faceted bowl, a set of ribs - with one or two sliders that vary every part (aperture size, twist, height).
- 2Add the fabrication branch: unroll or extract each part to a 2D outline, offset every cut line by half your tool kerf, and bake a part ID as engraved text onto each piece.
- 3Nest all parts onto your chosen stock sheet with a nesting component; read off the material yield and part count, and lock grain direction if the material has any.
- 4Change ONE slider and watch both branches update - confirm the render and the exported DXF set stay in sync. Export a frozen cut set (tag the file/version).
- 5If you have a laser or CNC and supervision, cut one part first to verify kerf and label legibility before committing the batch; otherwise dry-run the nest and note what you would check.
You’ll walk away with
A single parametric definition plus its exported, nested, labelled cut set (DXFs or a screenshot of the nest), a recorded material-yield figure, and a one-line note on what changed downstream when you moved a slider.
Three altitudes on the same idea
Read the band that fits you — or all three.
A live parametric-to-fabrication chain makes ambitious geometry buildable and late changes survivable. Design a non-repetitive facade and the same definition exports every panel labelled, nested and posted for the cutter - so when the client moves a datum, you re-solve rather than re-draw hundreds of sheets. You still hand structure and compliance to your engineer; what you gain is a design that reaches the machine without a fragile manual translation.
This is how bespoke joinery scales past a single piece. A parametric definition for a slatted ceiling, a curved reception desk or a set of made-to-measure wardrobes can emit each unique part with its own ID, nested onto ply sheets ready for the CNC. Change the room dimensions and the cut files follow. You get the control of custom work without hand-drawing every component - and a cut list your fabricator can trust.
Learn to build the fabrication branch, not just the pretty model. Employers prize people who can take a Grasshopper definition all the way to labelled, nested, machine-ready files. Practise unroll, kerf offset, part labelling and nesting on a real laser or CNC job; simulate a simple robot path before you touch the arm. A portfolio that shows the whole chain - definition to made object - reads as production-ready, not just render-ready.
“If the model is parametric, fabrication is automatic - press export and the machine just makes it.”
Do it yourself
No machine needed - reason it through.
- 1Name the two branches a parametric-to-fabrication definition produces from one graph.
- 2List four things that get generated onto a part before it is nested (features, marks, offsets).
- 3What does material yield measure, and why nest inside the definition rather than by hand?
- 4Give two failure modes unique to robot code that simulation catches before a run.
- 5Why is 'it regenerated' not the same as 'it is right', and what checkpoints guard against that?
The one line to carry out
Peer-reviewed journals & authoritative standards
- 01Grasshopper — Algorithmic modeling for Rhino — Robert McNeel & Associates, 2026.
- 02COMPAS — computational framework for research and collaboration in AEC — COMPAS, 2026.
- 03Nesting (process) — Wikipedia, 2026.
- 04Computer-aided manufacturing (CAM) — Wikipedia, 2026.
- 05Gramazio Kohler Research — Digital fabrication in architecture (ETH Zurich) — ETH Zurich, 2026.
If one definition can make the part, the next question is how you know the made part actually matches the model. So next we build a digital twin - comparing as-built to as-designed and closing the loop.
The author
Amogh N P
Architect, interior designer, and creative polymath. Studio Matrx began in his notebooks — his vision of design made honest, useful, and open to everyone. Its Academy is written and taught in his memory, and free, forever.
More about Amogh →