Timber Structures: Parametric Design System

2025 · 6 months · Packhunt

Computational Designer, Technical Lead

Grasshopper backbone for an online configurator of six timber structure typologies. I led the technical overhaul: a three-layer architecture, customer documentation turned into machine checks, and an 80% faster viewport with BOM-ready outputs.

The problem

Packhunt's timber configurator had to cover six structure typologies on a prototype that mixed concerns and worked for one. Every new typology meant editing geometry code, and the customer's specifications changed mid-week.

The constraint

Three people had to work on the same Grasshopper file at once, the viewport had to stay interactive for a sales configurator, and the bill of materials had to stay synchronised with the geometry on every parametric change.

What I built

A three-layer architecture: inputs and validation, mathematical logic, geometry output. Customer-approved documentation turned into machine checks, so a disagreement about a spec became a failing check instead of a meeting. Surface-first workflows and delayed brep creation in place of boolean operations. One mathematical source feeding both the geometry and the BOM, so the two cannot drift apart.

Role

Technical lead on the overhaul. I designed the three layers, owned the mathematical core and the validation rules, and ran the client alignment.

Outcome

Six typologies on one system, an 80% faster viewport, BOM-ready outputs, and warnings instead of silent failures when geometry breaks a rule. Clean interfaces between clusters let three people work in parallel on the same file instead of queuing for it.

Lessons learned

• Mathematics first, geometry later: Rebuilding the logic as mathematical relations before placing geometry made the file predictable. I now approach every large Grasshopper script this way.
• Documentation is an alignment tool: Turning the customer-approved documentation into machine checks avoided subjective debates and kept us aligned when specs changed mid-week.
• Modular scripts enable parallel work: Clean interfaces between clusters let three people work on the same file without rework. It also made onboarding future team members trivial.

Final reflection

This project solidified my approach to large-scale Grasshopper systems: start from data, keep modules independent, and let the documentation drive the rules. And draw the boundary between maths and geometry before the second variant exists, not after: I paid for that refactor mid-project. The GhValidation plugin kept that structure honest as the system evolved.

Documentation mattered as much as architecture: named clusters with typed inputs and outputs meant work passed between people without meetings. And exporting for the AEC industry only works when one mathematical source drives both geometry and BOM, so a parametric change cannot leave the two out of sync.