Over the past months, we at DigitalArchi Japan have been developing a web-based computing and memory-management system for running Grasshopper definitions remotely, leveraging Rhino.Compute. I wanted to share a few concepts that may be relevant to others exploring cloud-based Grasshopper workflows.
Rather than treating a Grasshopper definition as a black-box configurator, our approach emphasizes explicit data schemas and persistent model state.
1. Explicit input/output data schemas
Inputs are treated not merely as UI controls, but as structured data objects containing named parameters, metadata, model state, data paths, and values. This makes it possible to:
-
Version and validate inputs
-
Store (learn or forget) and reload (remember) exact model states
-
Integrate Grasshopper logic into broader pipelines such as automation, batch processing, or external applications
In this way, Grasshopper becomes part of a data-driven system, not just a computation endpoint.
2. Persistent model memory
Each computation is associated with an identifiable state (key), enabling:
-
Re-running models without unnecessary recomputation every downstream components
-
Inspecting and reusing concisely previous results
-
Incrementally editing inputs instead of restarting from an initial state
This is particularly valuable for long-running or computationally expensive definitions.
3. Decoupled UI and logic
The user interface is not embedded within the Grasshopper definition itself. Inputs can be extracted, edited, stored, and re-injected, allowing multiple frontends—web interfaces, internal tools, or scripts—to interact with the same definition through a consistent contract.
4. Transparency for advanced users
The system exposes data flow explicitly and allows safe manipulation, re-engineering, and generation of input data. This significantly lowers the barrier to extending and integrating Grasshopper definitions as web-based applications—not only for developers, but also for technically proficient users and teams.
Overall, this represents an alternative way of thinking about cloud Grasshopper workflows: extending Grasshopper as a stateful computational engine with schema awareness, rather than relying solely on UI-driven configurator models.