Hello,
I am starting development of a rule-driven component platform in Rhino / Grasshopper and I am trying to get the computational architecture correct before writing any significant logic.
I am currently developing a modular system project and assembling a small team of Rhino / Grasshopper computational designers, so I would like to establish the correct architecture before development progresses too far.
This is not intended to be a single parametric model. The goal is to build a reusable system composed of repeatable component families with rule-based assembly, persistent IDs, and fabrication-aware outputs.
My concern is not modelling technique but system architecture.
The typical Grasshopper workflow tends to evolve toward a single expanding definition. In small projects this works well, but at larger scales the “God Definition” pattern appears — solve times increase, the canvas becomes difficult to reason about, and collaborative development becomes problematic.
I am therefore trying to structure the system as a set of discrete responsibilities from the outset.
The current approach I am exploring is roughly:
-
A rule engine (C# / Python) reading external rule tables and evaluating topology and assembly constraints.
-
A placement / assembly layer in Grasshopper responsible for generating valid component instances based on those rules.
-
Independent geometry generators for each component family (for example GHUser objects or Hops endpoints) that accept a plane, dimensional parameters, type identifier and instance ID and return geometry.
-
A metadata and fabrication layer using persistent attributes to generate schedules, BOMs and downstream fabrication outputs.
In other words, treating Grasshopper less as a parametric model and more as an orchestration layer sitting between rule logic, component libraries and output definitions.
The architectural questions I would value guidance on are:
• File structure
Is it generally better to orchestrate a system like this from one master definition calling sub-definitions through Hops, or to break the workflow into staged GH files communicating through intermediate data formats?
• Rule logic location
At what point does it make sense to move assembly logic out of scripted components and into a compiled .gha plugin or external library?
• Metadata persistence
For systems where component identity matters, what is the most robust pattern for maintaining persistent IDs across recomputation and rebaking cycles?
• Grasshopper 2
Does the inter-file dependency model planned for GH2 change the recommended architecture for systems like this enough that it should influence decisions today?
If anyone has experience structuring large GH systems used for fabrication, modular assemblies or similar rule-based systems, I would be very interested to hear how you approached the architecture.
My main goal is to avoid building a monolithic definition that later has to be dismantled.
Thanks very much for any guidance.
Regards Lincoln Miles
@davidrutten I would particularly value your thoughts on this.
