KaroroCAD Plugin: From Grasshopper Script to Rhino Plugin
Hi all — here is the sixth article in this long-form series on projects I’ve built over nearly 10 years with Rhino and Grasshopper.
Today, I’m diving into the process of transforming KaroroCAD from a complex Grasshopper definition into a polished, professional-grade Rhino plugin — a shift that marked the beginning of the DGRS stack.
Project Summary
Project: Evolving KaroroCAD beyond ShapeDiver into a professional-level Rhino plugin
Client: Internal R&D - commercial software development
Timeline: Initial development June 2021 – 2022, still in active use and development
Tools: Rhino 7, Grasshopper 1.0, Python
Grasshopper Component Count: 3,766
The Problem
By mid-2021, KaroroCAD.online had become a widely used parametric kite design tool for hobbyists and professionals alike. But ShapeDiver’s strict limits on computation time and plugin support meant not all features could be exposed in the browser-based version.
I needed an offline solution — one that could run fully inside Rhino, with no compromises on usability, flexibility, or code protection.
The Sunday Night Forum Post That Sparked the Journey
Late one Sunday night, I found myself writing what was essentially an essay on the McNeel forum — outlining my frustrations and hopes:
This wandering post turned out to be more than venting — it became a specification, a blueprint, and eventually, a roadmap.
Research & Early Insights
With that post doubling as my dev checklist, I dove into the Rhino and Grasshopper ecosystem — exploring UI options, packaging methods, and scripting workflows.
HumanUI looked like a solid choice for a user interface framework. But it came with one fatal flaw: if you closed the Grasshopper window, the UI would freeze, and the definition would stop running.
That was a deal-breaker. For secure packaging, the user should never see the Grasshopper canvas — only Rhino, and a clean, standalone UI.
The Lucky Break: Grasshopper Remote Control Panel (RCP)
Then came the breakthrough.
While watching a video about the Grasshopper Remote Control Panel (RCP), I noticed something subtle but critical: the presenter closed the Grasshopper window… and yet the definition and RCP controls kept working.
This raised a question:
If I added just one component to the RCP, would HumanUI also remain active when the GH window was closed?
I tried it. And to my shock — it worked.
Even better: when I ran the same RCP/HumanUI combo through Grasshopper Player — normally a single-pass tool — everything still functioned:
No Grasshopper window
No visible GH definition
Fully functional HumanUI controls
Live updates in the Rhino viewport
Such a small step — but it changed everything.
The Launch Script & Packaging
Of course, the early success hid a nest of interdependencies. Every part — HumanUI, RCP, Player — needed to be launched in exactly the right order.
I drew on experience from a previous Python scripting project (a vinyl cutter automation tool) and wrote a Python launch script to manage the startup sequence and ensure all dependencies were loaded before the UI appeared.
Once the pieces were working together, I turned to the RhinoScript Compiler, which allowed me to package:
-
the Python launcher
-
the Grasshopper definition
-
the HumanUI interface
-
the RCP component
…into a single .rhp plugin.
With drag-and-drop install, and no visible Grasshopper elements, it looked and behaved like a native C# or C++ plugin — secure, integrated, and professional.
Reality Check: From Demo to Full KaroroCAD
But this was still just a tech demo.
The full KaroroCAD definition had over 150 parameters, most of them sliders, and every single one now needed to be rebuilt as a HumanUI input.
I was no longer building a personal tool — I was turning KaroroCAD into a commercial-grade product. That meant tackling the real work:
Replacing all slider inputs with HumanUI controls
Adding robust validation (types, ranges, dependencies)
Creating save/load functionality for design state (not built-in in HumanUI)
Testing for edge cases and real-world usability
This wasn’t just wrapping a script — it was transforming Grasshopper logic into software.
The UI Rebuild: Pulling the Head Off the Beast
The rebuild took months.
I often referred to this phase as “pulling the head off the beast.”
Every one of those 150+ parameters had to be restructured into a properly labeled, grouped, and interactive UI.
To support reliable input handling, I built custom Python components for validation — not just type checks, but unit constraints and interdependencies between parameters.
Next came state saving.
Capturing the current state meant wiring every input into a key-value system. That alone added hundreds of wires. Saving the data as JSON was relatively simple — but reloading it dynamically took some cleverness.
I used Metahopper and Human plugins to push stored values back into the running GH definition — updating sliders, toggles, dropdowns, and more — all without exposing the canvas.
It wasn’t glamorous work. But it laid the foundation for KaroroCAD to become a Rhino-native application, not just a clever GH hack.
Final Polish: From Tool to Product
With the UI rebuilt, inputs validated, and save/load working — KaroroCAD was no longer just a personal project or technical exercise.
It was time to ship.
I created a custom .rui file to add a pull-down launch menu directly inside Rhino — no commands to memorize, no scripting required.
For delivery, I built a Yak package, ensuring a clean install and update experience.
Now, KaroroCAD could be downloaded, installed, and launched just like any other Rhino plugin — fully self-contained and seamlessly integrated.
What started as a late-night forum post had become something real:
A commercial-grade parametric design tool
Built entirely in Grasshopper, Python, and RhinoScript
Delivered as a Rhino plugin — with no exposed source code
With a UI and workflow indistinguishable from native software
The Takeaway
This project marked a major shift in how I approached Grasshopper development — and directly led to the foundations of the DGRS stack.
Three unrelated tools — HumanUI, the Remote Control Panel, and the RhinoScript Compiler — stitched together with Python, became something much greater than the sum of their parts.
KaroroCAD was no longer just a personal R&D playground.
It was becoming a platform.
Thanks for reading. Happy to dive deeper into any part — the launch script, the packaging workflow, or how to use HumanUI in this kind of project.
— David Kay
Kite Designer // Digital Fabricator // Grasshopper Developer
