Grasshopper Validation Plugin

2024 · 3 months · Personal project

AI Design Technologist, Computational Designer, Product Designer

Automated testing for Grasshopper definitions: JSON snapshots capture the full model state, viewport screenshots make regressions visible, and nightly batch runs catch broken geometry before it reaches a client.

The problem

Grasshopper definitions had no test layer. A computational designer changes one cluster, and nothing tells them that a different typology now produces broken geometry. The failure surfaces in a client deliverable.

The constraint

Parametric models fail visually, not with a stack trace. Geometry can be topologically valid and still wrong, so an assertion is not enough: a human has to see the failure, and see it fast enough to act on it before delivery.

What I built

Automated regression testing for parametric models. JSON snapshots capture the full model state, viewport screenshots make visual regressions reviewable, and nightly batch runs sweep parameter boundaries and random stress cases. The run log links straight to the exact images for each case, so review is a scroll rather than a reconstruction. A C# plugin on the RhinoCommon API, with warning popups and gate dialogs so people can explore without breaking the definition's logic.

Role

Sole author. Architecture, plugin, component UX, documentation, and the adoption work with the designers who use it.

Outcome

Broken geometry gets caught before a client sees it. The framework became the validation layer for the Timber, Stairs and Roof Top-Up configurators, in daily use by a team of ten, and it changes how people work: catching one bad regression before delivery is what makes refactoring a complex definition stop feeling dangerous.

Lessons learned

Final reflection

Automated testing is standard in software and rare in parametric modeling, yet Grasshopper definitions keep growing in size, teams and rate of change. The risk is just as real; it only shows up as broken geometry instead of runtime errors.

Bringing testing to parametric work is less about perfection than about confident iteration: without guardrails every change feels dangerous. The same backbone that explores parameter sets and compares runs is what optimization needs. Add scoring rules and search, and the workflow shifts from pass-or-fail to discover-or-improve. Optimization is the next frontier, and the foundation is already there.