My History in Grasshopper Development

[kiteboardshaper]

With the release of DKUI and the documentation of the DGRS stack for Rhino plugin development using Grasshopper, I thought it would be a good time to start documenting my nearly 10-year journey with Grasshopper development.

This is the first post in a retrospective series, sharing early commercial work, workflow experiments, and some insights from real-world parametric modeling projects.

Project Archive: Composite UAV Drone (2016–2017)

---

Project Overview

Client: Purple Turtle
Timeline: Dec 2016 – Feb 2017
Tools Used:

• Rhino 5
• T-Splines 4.0
• Grasshopper 0.9

Deliverable: Mold-ready 3DM files
Grasshopper Components: 255

---

Project Brief

The client provided 2D drawings of a balsa wood and fabric UAV. The task was to convert this into a fully 3D design suitable for carbon/epoxy composite construction.

I modeled the complete UAV form as a single T-spline object, then split it into sub-components using cutting geometry modeled in Rhino (surfaces and polysurfaces). All splitting and Boolean operations were controlled via a Grasshopper definition to allow live updates during design iteration.

---

Workflow Summary

• T-spline base body modeled in Rhino
• Rhino surfaces used to define cut geometry
• All Booleans scripted in Grasshopper for parametric part separation
• Output: precise, fabrication-ready 3DM molds for composite mold production

---

Why It Mattered

This was my first real project using Grasshopper commercially and it formed the basis of my workflow style going forward: using GH as a logic engine to automate real-world design and manufacturing processes.

I’ll be posting more from my archive over the next few weeks, including:

• Custom tooling for manufacturing
• Shapediver and the first steps into sharing my tools with others
• Plugin development using Grasshopper and the Rhino Script Compiler
• Lessons learned from automating real-world design systems

Happy to discuss any of the technical aspects — comments, feedback, or your own similar experiences are welcome!

Single T-Spline Body:

Trimming/Cutting Objects:

Grasshopper Script:

Complete design split into sub-components:

[kiteboardshaper]

KaroroCAD: A Grasshopper Moonshot for Parametric Kite Design

Hi everyone,

I wanted to share a project that started as a personal Grasshopper learning challenge and grew into something much more. This is the second post in a series documenting my long-term journey with Rhino and Grasshopper.

---

Project Summary

Project: Moonshot GH Coding — KaroroCAD (v0)
Client: Internal R&D / Personal Learning
Timeline: April 2017 – Sept 2017 (initial development; still ongoing)
Tools Used: Rhino 6, Grasshopper 1.0
Deliverables:
• 2D DXF outputs suitable for inflatable kite production
• Parametric design engine (KaroroCAD)
• Grasshopper development experience (and a few headaches!)
GH Component Count: 2,595

---

Background

In early 2017, coming off my first commercial Grasshopper project (a composite UAV mold), I decided to challenge myself by building a full parametric engine for designing inflatable kites.

I had:

• ~10 years of 3D modeling experience

• ~5 years working in Rhino

• ~17 years in the kite industry, including time with top-tier designers

That experience gave me a solid understanding of what production-ready kite design involves — and a motivation to see if Grasshopper could carry that entire workflow.

---

Early Days: Crashing and Learning

My first two attempts failed. I coded myself into dead ends and had to start over from scratch. But by the third version, the logic started to hold together.

The turning point came when I realized:

“I just need to write down my Rhino workflow in GH — not invent something totally new.”

This mindset shift made the entire approach clearer. I was no longer abstracting geometry — I was documenting process.

---

April–May 2017: Full Immersion

Once it started clicking, I went all in. Nights and weekends were consumed with GH development.

As the definition grew, the project transitioned from:

“Can this be done?”
to
“How can I prove this actually works?”

To do that, I needed a prototype. And that meant finding a production partner.

---

Enter Dano See and Hyde Kites

I reached out to people I’d worked with in the kite industry.
Dano See and Hyde Kites (Philippines) understood what I was attempting — and they were open to building a kite based on my GH outputs.

This was a huge milestone. Now the pressure was on to deliver usable files.

---

Aligning with Industry Standards

Dano provided a reference DXF export from a leading commercial kite CAD tool. That gave me a baseline for what factories expect — including annotations, layering, seam allowances, and clean geometry.

I designed a fairly middle-of-the-road 3-strut freeride kite and exported all panels from KaroroCAD via Grasshopper.

---

First Build: Almost Perfect

Hyde reviewed the files and agreed to go ahead.

Initial production caught one issue: some leading edge panels near the wingtip had been unrolled out of sequence, causing geometric distortion when inflated.

I went back to the GH code, corrected the panel logic, and delivered a fixed set of files. The factory quickly turned around a corrected prototype.

---

Seeing the Kite in 3D

Seeing the physical kite in the factory, inflated and matching the 3D model, was incredible.

This was real — the GH definition had gone from abstract parametric concept to tangible product.

---

First Flight: Muizenberg, Sept 2017

The kite arrived in Cape Town.

By chance, we had solid SE wind the day it landed. I dropped everything and headed to Muizenberg.

It was nearly too windy for a 9m kite, but I was too excited not to try. I rigged the kite, used the safest bridle configuration, and launched.

It flew cleanly.

I grabbed my board, walked into the water, dove the kite — and I was up and riding.

---

The Moment

Five months after starting this experiment, I was riding a kite designed 100% in my own GH definition — no external CAD, no manual drafting.

A surreal feeling. It worked.

---

What’s Next?

Of course, this wasn’t the end — it was the end of the beginning.

Over the following months I kept refining the bridle model, geometry handling, and output logic. The second prototype followed soon after.

That’s a story for another post.

---

Happy to answer any GH-specific questions or dive deeper into the modeling/logical side if people are interested.

—
David Kay

Code to Geometry

Being tidy is the secret to managing large GH programs

2595 components and growing…

[kiteboardshaper]

Project Archive: iQR Quick Release System (2018–2019)

Hi everyone,

This is the third post in my ongoing retrospective series, sharing long-form Rhino + Grasshopper development projects from the past decade.
Today I’m highlighting a commercial design that pushed both the limits of my workflow and the boundaries of what parametric modeling can achieve in real-world manufacturing.

---

Project Overview

Client: Airush Kiteboarding
Timeline: 2018–2019
Tools Used:

• Rhino 5
• T-Splines 4.0
• Grasshopper 0.9

Deliverables:

• Production-ready STP + DXF files
• Fully parametric mechanical assembly
• Complete BoM and assembly drawings
• ISO 21853-compliant safety hardware

Grasshopper Component Count: ~1,500

---

Project Brief

After 10+ years of running their “Brain” quick release, Airush needed a next-generation system that could meet updated safety expectations and pass the newly developed ISO 21853 certification.

Requirements included:
Compact, modern form
Durable in salt, sand, UV
Easy reset in gloves/water
ISO-compliant under test rig loads
Tooling-ready CAD output

This wasn’t a redesign — it was a ground-up rethink. And I wanted every element — from the mechanical core to the outer shell — to be controllable via Grasshopper.

---

Hybrid Workflow: Grasshopper + T-Splines

The model was split into two tightly integrated parts:

• T-Splines body (ergonomic form)
• Parametric Grasshopper assembly (functional core)

Every tolerance, release pin geometry, wall thickness, and interface was GH-driven. Downstream exports (STEP, DXF, PDF drawings) were fully automated from the core parametric definition — no manual rebuilds.

Rhino handled final detailing, documentation, and surfacing. T-Splines gave me organic shaping control. Grasshopper gave me the power to change geometry with confidence mid-production.

---

Physical Iteration: 3D Printing as a Design Partner

To match the pace of GH-driven modeling, I pushed for in-house FDM printing. This gave us a design loop measured in hours, not weeks:

• CAD update by 4pm
• Overnight print
• Fit/ergonomic test in the morning
• Revisions back in GH that same day
• Repeat

Print speed became the bottleneck — not the CAD process.

---

Integrating ISO 21853: Standards as a Design Constraint

Partway through, ISO 21853 was finalized. It set strict criteria for release force, contamination resistance, and reliability under stress.

Rather than reverse-engineer compliance, I joined the standardization process directly — helping define the test rigs and qualification methods used in official certification.

This allowed me to tune design in GH for release performance under load, sand, and water, without guesswork.

---

Tooling + the Power of Parametric Revisions

Initial tooling came back clean — but in sand tests, the mechanism bound slightly.
Issue: a tight internal tolerance that hadn’t shown up in FDM prints.

The Fix: Remove the problem geometry entirely - initially with a hacksaw. It worked better without it — simpler, smoother, more reliable.

Because the model was fully parametric, I updated the design in less than a day.
No rebuilds
No missed deadlines
Clean new files to the factory

---

Visuals and Marketing — From the Same Model

Using the same Rhino base geometry, I created render assets for:

• Product catalogs
• Launch packaging
• Dealer material
• Web/social release

No secondary models. No duplicated effort. Just clean surfacing, lighting, and rendering off the main design file.

---

Takeaways

This project was a turning point for me — showing that parametric workflows can survive (and thrive) in production environments with real-world stakes.

Key learnings:

• Grasshopper can drive full product dev if it’s cleanly structured
• Standards compliance works best when you help write the rules
• Parametric revisions at tooling stage = real business value

---

Happy to answer any Rhino/GH-specific questions — whether it’s parametric handling of injection/casting geometry, managing large GH definitions, or test rig integration for standards like ISO 21853.

—
David Kay
KaroroCAD • KaroroCAM • DKUI • DGRS Stack

Built in Grasshopper

3D model to 3D print

Innovation that clicks

Renders for marketing

Perfection in use

Riders POV

[kiteboardshaper]

Rhino to Cutter: A Vinyl Cutter/Plotter Revival Story

Hi everyone,

This is the fourth post in my ongoing retrospective series, sharing long-form Rhino + Grasshopper development projects from the past decade.

Today, I’m staying within Rhino, but shifting focus to code development using Python —specifically, writing a custom print driver for a long-disused vinyl cutter/plotter.

Project Summary

Project: Rhino-to-Vinyl-Cutter Workflow

Client: Internal R&D / Workshop Automation

Timeline: Oct 2017 – Dec 2017 (initial build; still in use)

Tools Used: Rhino 6, Python (RhinoScriptSyntax, pySerial), Hyper-Terminal

Deliverables:

• Real-time Rhino-to-cutter integration

• Custom HPGL generator

• Serial comms over USB

Lines of Code: ~150 (Python)

---

From Circuits to Cutting: A Long Loop Back

Although I’ve worked in the water sports and kiteboarding industry for over 25 years, my background is in Electronic Engineering. In fact, my final-year university project involved controlling a DOS-based MP3 player via the serial port — a niche challenge at the time (many many years before the first iPod), but one that got me comfortable with direct hardware communication.

I had no idea that 20 years later, that same experience would become the foundation for solving a very different problem.

By 2017, I was working in and around the Airush Development Lab in Cape Town — building prototypes, developing custom tools, and setting up the workshop for lean, digital manufacturing. One of the tools I needed was a vinyl cutter — not just for logos and decals, but for spray masks and full-size pattern plotting.

---

Right Place, Right Time… Right Machine

As luck would have it, Dave Stubbs, the legendary Cape Town surfboard shaper, was working in the space next door. One day, I mentioned I was looking for a cutter and he casually remarked:

“Oh, I’ve got one in storage — just around the corner.”

That offhand comment led me to an old DGI OM-60, long unused, sitting just a few meters away.

I took the cutter home, gave it a deep clean, and powered it on. It passed its self-test flawlessly. But there was one issue:

The software was missing — and long discontinued.

---

The Hidden Treasure: A Real Manual

There were no drivers. No install disks. And no support from the manufacturer.

But being so old had one big upside: it came with a proper manual — thick, printed on paper, and full of command documentation, including HPGL syntax and serial port settings.

That manual became my gateway. It made one thing very clear: if I could speak HPGL, I could control the machine.

So the question became:

Could I drive this cutter directly from Rhino?

---

GitHub and Grasshopper: A Starting Point

A quick search for “Rhino HPGL” turned up a GitHub project doing just that — or at least part of it. The script converted Rhino curves into HPGL commands and saved them to disk.

The code was in Python, a language I had never used before — but it was clean, readable, and I quickly understood the control flow.

I gave it a spin and soon had my first HPGL files saved to my drive.

But I still needed a way to send them to the cutter.

---

🖧 Old Tricks Still Work

This is where things got interesting.

It turns out that Windows 10 still supports old DOS-style commands to pipe files directly to legacy printer ports. I gave one of them a try — aimed it at LPT1, and hit Enter.

To my shock, the machine came to life.

I loaded some paper into the cutter, wrapped masking tape around a felt pen, and jammed it into the empty blade holder. And there it was — the cutter began plotting “Hello World”!

But not perfectly.

The curves came out fragmented — plotted as disconnected line segments instead of smooth paths. Clearly, there was room to improve the HPGL generation.

---

Digging Deeper: RhinoScript + Python

To fix the jagged plotting, I dove into the RhinoScriptSyntax documentation and started refining the conversion process.

Rhino has a deep SDK and excellent curve tools — I just had to tap into them. With a few changes, I was able to smooth the output, preserve closed curve logic, and still generate valid HPGL.

From there, the results improved dramatically.

---

Real-Time Plotting: Let’s Talk Serial

With clean HPGL output sorted, I wondered:

Why not skip the file export entirely?

The cutter had a serial port — could I send commands directly from Python in Rhino, without writing to disk?

To test this, I needed a USB-to-Serial adapter (since no modern PC has a COM port anymore) and, as the manual specified, a null modem cable to properly cross the TX/RX lines.

A quick trip to the electronics store and some soldering later, I had a working cable setup.

---

Terminal Test: The Moment It Talked Back

Just like I had decades earlier, I fired up a terminal emulator and aimed it at the new COM port.

A few HPGL commands type in… the machine replied, returning the current paper dimensions.

That was the moment. We weren’t just sending commands — we were having a conversation.

---

Python Makes It Easy

This is where my real appreciation for Python began.

Using the built-in pyserial library, I was able to set up and control the serial connection with just a few lines of code. The integration felt natural, and it slotted right into my existing HPGL script with minimal effort.

Within an evening, I had live Rhino-to-cutter plotting working — no file exports, no shell commands.

---

Polishing the Tool

Over the following weeks, I began adding more logic:

• Querying the maximum plot size from the cutter
• Ensuring only closed curves were sent
• Adding user prompts and simple error checking

Python made these improvements feel easy, and Rhino’s script interface made integration painless.

---

From Scrap to Shop Floor

What started as a dusty old machine — seen as scrap by most — became a workhorse in my workshop.

This revived cutter has since handled hundreds of jobs for me (and for Dave Stubbs too). From logos to layout templates, it became an everyday part of my #digitalmfg toolkit.

More importantly, this project reminded me how past experience, a bit of curiosity, and a willingness to dive into the unknown can unlock serious value — both in tools and in learning.

---

The First of Many

This project also marked a turning point for me — the first time I wrote code inside Rhino to directly drive a machine.

It laid the foundation for a new kind of workflow: one where design, logic, and fabrication are tightly integrated through custom code.

That same mindset would eventually lead to more ambitious projects like Shapewave WAM and KaroroCAM — but those are stories for another time.

---

Thanks for reading — happy to dive into the Python/Rhino side if anyone’s curious, or share the repo if there’s interest.

David Kay
KaroroCAD • KaroroCAM • DKUI • DGRS Stack

In the thick of development

Will this work?

Pen Plotter

Everyone LOVES their own stickers

[kiteboardshaper]

KaroroCAD.online — A Web-Based Grasshopper Tool for Parametric Kite Design (via ShapeDiver + JS)

Hi all — here is the fifth article in this long-form series on projects I’ve built over nearly 10 years with Rhino and Grasshopper. This one might be especially relevant here because it focuses on getting a large, production-ready Grasshopper definition online - no Rhino install, no plugin dependencies, no exposed source code.

---

Project Overview

• Project: KaroroCAD.online
• Goal: Make parametric kite design accessible to non-CAD users via browser
• Tech Stack: Rhino 6, Grasshopper 1.0, ShapeDiver, JavaScript
• Component Count: ~2,500 (post-refactor)
• Status: In use by hobbyists and pro kite builders since 2020

---

Background & Motivation

Back in early 2020, I had already used Grasshopper to produce several working kite prototypes. Then South Africa went into lockdown, and like many, I turned to social media to keep sharing progress on my design work.

I started posting screenshots and snippets of the design process — mostly just to stay engaged with the community. But the reaction surprised me. I kept getting the same question:

“How can I try designing my own kite?”

This was the core challenge:

• I couldn’t share the Grasshopper definition (too complex, too much IP)
• Rhino/Grasshopper isn’t really accessible for casual users or hobbyists
• But the demand for hands-on experimentation was clearly there

So I started exploring how to deliver the tool — not the code — via the web.

---

Rebuilding for ShapeDiver

I had tested ShapeDiver about 18 months earlier, but KaroroCAD was too heavy at the time. This time around, I had better GH practices, more time, and a clear constraint:
Fit the design tool into ShapeDiver’s 10-second execution window.

Steps taken:

• Removed all unsupported plugins
• Used the Grasshopper profiler to isolate bottlenecks
• Found key inefficiencies (e.g. Area used for center points = 25% runtime hit)
• Refactored geometry logic for speed and modularity
• Split the definition into two separate GH files:
  • 3D kite geometry
  • 2D panel generation (for cutting/production)

---

Solving Save/Load Without a Backend

At this time ShapeDiver didn’t offer persistent sessions or user accounts — which meant no saving work between sessions. For a design tool, that’s a dealbreaker.

So I dug into the ShapeDiver API and built a lightweight client-side save/load system using JavaScript:

• Captures the current parameter state (via API)
• Trigger download of a .kite file
• Users can later upload that file to restore their design state

This mimics a typical CAD workflow — versionable files, shareable, reloadable — entirely in the browser.

---

Results

• Opened the tool to a wide range of testers — from weekend kite hobbyists to factory partners
• Received feedback on both UX and geometry output
• Users with no Rhino experience at all successfully designed and exported production-ready kites
• .kite files are now being shared between designers — including for real builds

---

From Script to System

What really struck me with this project wasn’t just that KaroroCAD.online worked — it was that I could share my Grasshopper workflows with others:

• Without the mess of a GH script
• Without exposing source code
• Without the user needing Rhino

That changed everything.

It turned what had started as a solo tool into something collaborative, accessible, and repeatable.

A Grasshopper definition had become a system — one that could be versioned, reused, improved, and deployed by people who’d never opened Rhino in their lives.

That shift in thinking — from internal tool to external platform — was the seed that would eventually grow into the DGRS stack:
A structured approach to building full Rhino plugins directly from Grasshopper logic.

KaroroCAD.online was never just about kites.
It was the moment I realized how far a GH workflow could go when you stop thinking of it as a script… and start treating it like software.

Thanks for reading — happy to dive deeper into how to develop for Shapediver if anyone is interested.

— David Kay Kite Designer // Digital Fabricator // Grasshopper Developer

Working from home on new designs

Design to DXF delivery all available online

From a local tool…

To a globally available app

Even on mobile

At 2500 components computation time was key

[kiteboardshaper]

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:

Offline 'Shapediver' style service/packaging/app

OK, looks like this is a one sided conversation, but I’ll keep it going with my thoughts and musings. So, spent most of this weekend with my head in Rhino7 looking at different ways of delivery of Rhino/Grasshopper solutions to end users. History of my project is, several years ago I got the idea to build a parametric engine to design kitesurfing kites in Grasshopper. I actually started the project firmly thinking it wouldn’t be possible and I’d give up at some point. To my shock it actually w…

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

[kiteboardshaper]

KaroroCAD Goes Cross-Platform with Its Own User Interface Framework

With the release of #DKUI and the documentation of the #DGRS stack for developing Rhino plugins with Grasshopper, I’ve been reflecting on my journey through the Rhino ecosystem. This is the seventh article in my series documenting nearly a decade of work with Grasshopper — sharing key projects, experiments, and insights from the journey. Today, I’m diving into the development of a fully cross-platform UI for KaroroCAD.

---

Project Summary
Project: KaroroCAD cross-platform UI development
Client: Internal R&D — commercial software development
Timeline: July 2023 – September 2023
Tools Used: Rhino 7 (Windows & Mac), Grasshopper, Python, Bengesht plugin, Eto
Goal: Replace HumanUI (Windows-only) with a cross-platform, maintainable user interface

---

Background & Problem Statement

By July 2023, KaroroCAD as a Rhino plugin had been “in the wild” for about a year. Su Kay at Lacuna Kites had been using it for development, but I was keen to get more kite designers trying it out.

At this point, KaroroCAD relied heavily on HumanUI and other Windows-only Grasshopper plugins, making it a Windows-only solution — the same limitation affecting SurfPlan, the industry standard used by all other kite designers.

What I knew for certain: not a single one of the tens of kite designers I knew using SurfPlan ran Windows as their daily driver. All of them used MacBook Pros and ran Windows only via Parallels to access SurfPlan.

The next goal became clear: could KaroroCAD be redeveloped into a cross-platform solution? Could it become the first macOS-native kite design package in the market? That would be quite a crown to take.

---

Setting Up a Test System

Like all good development, the first step was a test environment. A quick call around friends led me to a suitable Mac Mini sitting unused in storage. After updating macOS and installing Rhino 7, we were ready to get started.

From there, it was a matter of auditing the code base and dependency list. Most third-party plugins were either macOS-compatible or could be replaced. But the biggest challenge was HumanUI — pages of user inputs and hundreds of parameters. How could I replace a Windows-only WPF system with something equally maintainable and fully cross-platform?

---

Exploring Grasshopper UI Options

The landscape of Grasshopper user interface platforms in mid-2023 was very different than today. Options boiled down to:

• Rhino native ETO platform

• Synapse (an ETO wrapper for Grasshopper)

• WebUI (a web-based UI solution)

ETO was powerful, but the learning curve was steep, and online examples were scarce. After a week of trial, I discounted it as a viable option.

Synapse borrowed heavily from the HumanUI workflow but inherited ETO’s complexity and steep learning curve. Again, after a week of testing, it was clear it wasn’t suitable.

WebUI initially offered promise, and I did get a basic UI running from its tutorials. But the code was unstable, crashing without warning, and the project hadn’t been updated in two years. It wasn’t trustworthy for a commercial product.

With all existing options off the table, it was time to consider building something myself.

---

Inspiration from the Web
WebUI sparked a thought: the web browser is the most advanced, widely-tested user interface system ever created. Tens of millions of hours of human effort have gone into creating web-based UIs for countless applications.

And then I remembered: Rhino has its own built-in web browser. Could I communicate with it from Grasshopper? There had to be a way.

But how to do it? WebUI had its own internal system for sending pages to the UI window, but I needed something similar — and I had almost no web development experience outside of making KaroroCAD.online work with ShapeDiver.

---

The Breakthrough: Bengesht Plugin
Then I got lucky with the Bengesht plugin for Grasshopper. A ten-year-old project that still worked in modern Rhino — including Rhino for MacOS.

Bengesht brought HTML server components, which allowed serving HTML pages and, crucially, receiving HTML form data directly inside Grasshopper, all from a localhost port.

Quickly, I threw together a proof of concept: a couple of text boxes and a submit button. Two-way UI communication from GH to the Rhino web browser and back again was alive.

---

Building a Full Cross-Platform System
But a proof of concept is not a final solution — there was still work to do.

First, the Rhino Web Browser is not implemented in MacOS Rhino. To get around this, I had to investigate alternatives. It turned out that Eto would still be required, but only to launch an Eto.WebView window pointed at the Bengesht server. This meant the heavy lifting of the UI could remain web-based and cross-platform, while Eto acted merely as a lightweight launcher compatible with both Windows and MacOS.

To follow the familiar workflow of HumanUI, each UI element — number input, slider, button, etc. — needed its own dedicated Grasshopper component. Each of these was hand-crafted in IronPython, taking standard Grasshopper text and numeric data and converting it into valid HTML form data. The components were designed to merge sequentially, building up a full, cohesive user interface that could communicate seamlessly with the web browser window.

This was the point where the extensive online resources for web development became truly invaluable. For virtually every challenge I faced, there was an excellent example or pattern to follow. The task boiled down to writing Python code that could generate the required HTML, CSS, and JavaScript output for each Grasshopper component — effectively bridging the parametric logic of KaroroCAD with the flexibility and universality of a web-based interface.

After three solid weeks of development, fitted around my daily work schedule, I had a full set of UI controls ready. Each component — sliders, number inputs, buttons, and more — had been hand-crafted in IronPython and rigorously tested on both Windows and MacOS. For the first time, it felt like a cross-platform solution for KaroroCAD was within reach — a user interface system flexible enough to replace HumanUI, yet fully compatible with both major operating systems.

---

Pulling the Head Off the Beast — Again
With the full set of controls in place, it was time for the next challenge: pulling the head off the beast — for the second time. Just like the earlier KaroroCAD plugin rebuild, every single input, slider, and toggle needed to be integrated into the new web-based UI system. This meant wiring hundreds of parameters, ensuring correct data flow between Grasshopper and the browser, and building robust validation into every component. It was tedious, intricate work, but necessary to transform the proof-of-concept into a reliable, production-ready platform.

This overhaul also required a complete rebuild of the state-saving logic inside KaroroCAD — a major undertaking in its own right. Every saved design needed to serialize the new web-based UI inputs correctly, preserve all parameter relationships, and reload seamlessly into Grasshopper. Doing this while simultaneously replacing the entire user interface added a layer of complexity that made the project feel almost like building KaroroCAD from scratch a second time.

But finally — after eight weeks of winter programming — it happened. I compiled a YAK file, dropped it into Rhino for MacOS, and launched KaroroCAD natively on MacOS. In that moment, I realized it was the first commercial kite design software available as a true cross-platform solution. I was completely STOKED.

---

Closing Thoughts
The development of a cross-platform KaroroCAD was a huge technical and personal milestone. By leveraging the web as a UI platform, and carefully integrating Grasshopper, Bengesht, and Eto, KaroroCAD moved beyond Windows limitations, opening the door to true cross-platform parametric kite design.

This project reinforced a core principle that has guided my work for years: if the workflow and tools move at the speed of thought, software can empower creativity across platforms, devices, and users.

KaroroCAD is no longer just a Rhino plugin. It’s a fully cross-platform platform for kite designers, and a testament to what’s possible when we rethink the boundaries of tools we’ve taken for granted.

---

— David Kay
Kite Designer // Digital Fabricator // Grasshopper Developer

[markz]

A great story - thank you for sharing your experience. I very much understand the feeling - going from wild idea to a product - and the feeling -”it worked!”

[kiteboardshaper]

Parametrics Meet Robotics: Shapewave WAM

With the release of #DKUI and the documentation of the #DGRS stack for developing Rhino plugins with Grasshopper, I’ve been reflecting on my journey through the Rhino ecosystem.

This is the eighth article in my retrospective series on nearly a decade of work with Grasshopper — sharing key projects, experiments, and insights along the way.

Today, I’m looking back at late 2022, when I reconnected with a long-time contact from the kite industry and started work on something completely different — a parametric interface for robotically welded inflatables.

---

Project Summary

Project: Shapewave WAM (Webbing Allocation Module)
Client: Shapewave
Timeline: First prototype December 2022 — ongoing
Tools: Rhino 7 & 8, Grasshopper, DKUI, Python
Goal: Develop a robust, parametric design-to-manufacture system for welded-tape inflatable structures — enabling real-time layout and robotic production of complex, pressurizable forms.

---

How It Started

In December 2022, I got a message from Rudo Enserink — a designer I’d first met in the early 2010s when I was product manager at Cabrinha Kites. Rudo, then working with Ocean Rodeo, had led the design of several key products that left a serious mark on the industry.

More than a decade later, he was working on something radically new.

Shapewave was Rudo’s project: a potentially disruptive technology for kites, wings, inflatable SUPs, and other high-performance inflatable structures. Instead of traditional drop-stitch construction or shaped panelling, Shapewave was developing a patented method for welding thousands of individual webbing tapes between membrane panels — creating complex, shaped, high-pressure inflatables with true freeform geometry.

At that point, Rudo was bringing all the pieces of the puzzle together — people, machines, and funding. But one critical piece was missing: a software stack that could take a 3D model and translate it into custom 6-axis G-code for the welding robot.

Rudo had reached out to software development businesses for solutions — but the responses were daunting. Replies like “that will take us 20 man-years of work” dominated his inbox.

Then, in what became a lucky break, one member of Rudo’s team — familiar with my work on KaroroCAD — mentioned that project to him.

This led to Rudo reaching out directly, and what followed was a series of calls and emails, diving into technical challenges, design intent, and the practicalities of turning Shapewave’s vision into a parametric, robot-ready workflow.

---

Project Kickoff

The project revolved around turning complex 3D designs into production-ready instructions for Shapewave’s inflatable technology. While I can’t share exact mechanics, it required a unique, software-driven workflow to manage parametric geometry and prepare it for fabrication.

Working with Rudo and the team, I quickly built a prototype / proof of concept. It was rough and far from complete, but it proved the project was viable — and highlighted that Rhino and Grasshopper are a powerful platform for 3D development.

---

Challenges & Breakthroughs

There were lots of edge cases to handle, though I can’t go into specifics. What I can say is that the project required parametric logic at scale — handling complex geometry, multiple inputs, and iterative design adjustments — all feeding directly into a robot-driven workflow.

With DKUI and the DGRS stack, I was able to deliver a fully functional, professional-level Rhino plugin for Shapewave, complete with a custom user interface, enabling the team to work directly with parametric models in a production-ready workflow.

---

Ongoing Development

Since the first prototype in December 2022, the Shapewave WAM project has continued to evolve over more than two and a half years. The work remains active, with ongoing refinement, iteration, and testing. While I can’t share the inner workings, the project continues to demonstrate the power and flexibility of Grasshopper and Rhino as a platform for parametric, robot-driven workflows.

---

A Culmination of a Decade

With Shapewave, many threads of my Grasshopper development came together — from the composite UAV project, to vinyl cutter Python workflows, to KaroroCAD, and now this parametric, robot-driven software. Each of these experiences contributed to the same underlying skill set: creating a translation layer from 3D design to digital manufacture.

It was around this time that I started to see my niche in Grasshopper development, what I would come to define as “bridging 3D design to digital manufacture” — connecting creative design directly with automated production.

---

Thanks for reading
—
David Kay
Kite Designer // Digital Fabricator // Grasshopper Developer