YachtSoft Next-Gen
Research report & build plan

Method: a 104-agent deep-research workflow — 5 search angles, 15 primary sources fetched, every claim attacked by 3 independent refutation votes (≥2/3 kills it) — plus 4 targeted gap-fill research agents (naval-arch computation, competitors, legal, AI landscape) and the YachtSoft module map from the site rebuild. ~6.3M research tokens. Full cited version lives in the vault: wiki/projects/yachtsoft-nextgen.md.

§1 · The dependency, decomposedWhat Rhino actually supplies — and what each layer costs to replace

§2 · Horizon B economicsRhino.Compute: verified numbers

• Compute executes Grasshopper definitions server-side behind a web API — McNeel's official appserver exists for exactly this, and ShapeDiver runs a commercial SaaS on this architecture at scale.
• No managed McNeel cloud: we stand up, secure and scale our own instances. DevOps burden + McNeel-terms dependency are the real price.
• #1 unknown (Phase-0 gate): whether HullZero / GravityOne / BuoyancyTwo components run headless — Grasshopper components that touch the Rhino UI fail under Compute. Audit Phil's actual definitions before committing.

§3 · PrecedentsHow production web CAD is actually built

Server-side geometry + thin client is the dominant architecture. No production browser-side WASM kernel was verified anywhere. The web UI we build is therefore reusable across kernel eras:

• Onshape — licenses Siemens Parasolid + D-Cubed, rebuilds geometry on server-side "geometry servers", ships only tessellated triangles to a custom in-house WebGL renderer.
• Zoo (KittyCAD) — the 3D view "is just a video stream from our hosted geometry engine"; commands over WebSockets; v1 shipped desktop-first. Its client is MIT open source (React/TypeScript/Rust) — a production-grade web-CAD client we can study or fork, paired with our own backend.
• Shapr3D — the cautionary tale, confirmed by Siemens itself: its initial open-source kernel hit robustness walls within a year; it switched to Parasolid and shipped within 12 months.
• Zoo is the from-scratch price tag — new GPU kernel, ~2 years, <30 engineers, ~$10.1M raised. That's the floor for building a kernel. We don't.
• Representation: even AI-native Zoo chose NURBS B-rep and warns against SDF for common CAD shapes. A product promising fair, curvature-continuous hulls stays NURBS.

§4 · Horizon C kernelsThe independence options, ranked

• OCCT + Gordon surfaces (the find of this research): OCCT's own surfacing isn't hull-quality — DLR's peer-reviewed TiGL bypasses it — but TiGL implements the missing piece itself: Gordon curve-network interpolation (stations + longitudinals → one exact B-spline surface), shipping today under Apache-2.0 (occ_gordon), a primitive its authors note is "almost never found in free/open-source software". That is precisely the yacht-hull lofting problem. Caveat: no marine class-A fairing benchmark exists — curvature-comb quality is the go/no-go test.
• Parasolid licence: the Onshape/Shapr3D path — proven for startups, price undisclosed. Phase-0 inquiry.
• openNURBS (MIT): anchors .3dm interop and NURBS data structures free, forever — file IO and data structures only, not modeling ops.
• Rust kernels / from-scratch GPU: no production evidence; Zoo's $10M precedent prices it. No.

§5 · The computation layerWhat we can reuse vs what is Phil's moat

Module read-out: HullZero/Pro physics = textbook mesh-integration math, fully ownable (the prototype implements it). Performance = openplaning drop-in for Savitsky + reimplemented Holtrop/Delft-series regressions from open literature. Pro's value is Phil's material libraries and workflow, not the integrals. What can't be downloaded anywhere: Phil's calibration of these methods against 100+ real designs.

§6 · MarketCompetitive landscape & the cloud whitespace

No commercial browser-based hull-design or hydrostatics product exists. The only browser tool found is a free single-author hobbyist app (BoatCAD). NAPA's web offering is a viewer. Maxsurf's "cloud" is a billing model (min $5,000 prepaid). ShapeDiver is generic infrastructure with no marine product — searching it surfaces yachtsoft.app itself. Every rung of the ladder is open:

Rhino's community is marketed at 1M+ users (~350k in 2016 → ~450k in 2019), with marine a named McNeel vertical — that's Horizon A's ceiling, gated by plugin discovery. Horizon B/C's ceiling is every designer with a browser, including students and small yards priced out of $3,500/yr stability modules. RINA alone counts 10,000+ professional naval architects.

§7 · DifferentiatorThe AI-native layer nobody in marine CAD has

Nobody ships AI-native hull design. Incumbent CAD AI is assistants (Onshape AI Advisor, NX Design Copilot) or narrow features (Fusion Automated Modeling); generative B-rep-from-prompt is roadmap (Autodesk "Neural CAD") or simple-parts-only (Zoo, Adam — useless for hull fairing today). But every enabling piece is proven separately:

• C-ShipGen / ShipGen (MIT DeCoDE): diffusion over 45-parameter hull vectors, conditioned on principal particulars → 99.5%-feasible low-drag hulls. Code public, no licence file — contact authors before commercial use. The closest prior art to an AI-native YachtSoft, unproductized.
• Surrogates work at yacht-scale samples: a Neural Concept partner built a hull hydrodynamics predictor from 150 hulls in under a month (milliseconds per prediction); PhysicsX is the official AI partner of GB1's America's Cup challenge — AI hull/appendage design is real at the top of the sport.
• LLM-over-dataflow copilots ship: Ant AI (food4Rhino, Feb 2026) builds and edits Grasshopper graphs in-canvas — the "LLM mutates parametric definitions" pattern works, and Phil's definitions are already that substrate.

The open lane: principal particulars + service profile → feasible starting hulls; instant surrogate feedback while dragging sliders; a copilot grounded in Phil's design rules. No vendor combines them — and the AI is only as credible as the validation layer under it, which is exactly what Phil owns.

§8 · GuardrailsLegal & commercial: sanctioned, with hard lines

Horizon B is explicitly sanctioned, not a grey zone. McNeel staff frame core-hour billing as a separate product for server scenarios ("Can be considered a completely different product"); the production deploy guide documents commercial setup; ShapeDiver is the at-scale precedent. The rate has held at $0.10/core-hour across 2019→2026 docs — but there's no published rate guarantee or volume tier: get written enterprise terms from McNeel before GA.

• Never redistribute Rhino/Grasshopper binaries ("You may not distribute any portion of the Software"). Running .gh definitions on our billed Compute farm is fine; shipping Grasshopper to users is not.
• Never use desktop licence keys on servers — core-hour billing is the only lawful server path.
• Never put "Rhino" in the product name — Rhino®, Grasshopper®, RhinoCompute® are registered marks. "YachtSoft Cloud", never "YachtSoft Rhino Cloud"; descriptive "for Rhino 8" stays fine.
• OS reality: production Compute = Windows Server 2019+/IIS today; Linux is Rhino 9 beta (official Dockerfiles in progress) — plan the migration, don't architect around it yet.
• rhino3dm is clean SPDX-verified MIT — full .3dm read/write everywhere, free; the prototype's export costs nothing. (The openNURBS repo's own LICENSE file is stale vs McNeel's MIT declaration — counsel item for Horizon C.)
• Cryptolens is rebranding to Devolens (Business €199/mo). The cloud product likely won't need per-seat keys at all — entitlements move into app auth; keep Cryptolens for the desktop line.
• Patents (FTO review before any Horizon-C kernel): Zoo's GPU intersection application US 18/662,056; PTC/Onshape's multi-user cloud-CAD family (US10437938B2 + continuations); Autodesk generative-design patents. None block Horizon B.

§9 · DecisionThree horizons, compared

The horizons are a pipeline, not a fork. A keeps earning while B is built; B's client, computation layer, auth and AI surface all survive into C unchanged (Onshape and Zoo prove the client is kernel-agnostic). C proceeds module-by-module — hull generation first, analysis next (pure math, no kernel), production/CNC last — with Compute as the fallback kernel throughout.

§10 · RoadmapPhase 0 → 1 → 2 → 3

§11 · The buildPrototype spec — 2-week plan

The demo promise: open a URL → drag Beam / LWL / deadrise / chine sliders → a fair planing hull morphs live with curvature combs → hydrostatics (∇, LCB, wetted surface, C_p, C_b, KM_t) and a Savitsky resistance curve update in real time → click Export .3dm → the file opens in Phil's own Rhino 8. Sixty seconds, no install, no Rhino licence — "your workflow, without the workstation."

yachtsoft-nextgen/            (repo: lumanaire/yachtsoft-nextgen, commit as Lumanaire <hello@>)
├── apps/web/                 Next.js 16 demo shell (Phase 2: compute bridge joins here)
├── packages/hull-core/       params → stations/chine/sheer curves → B-spline loft → tessellation
├── packages/hydro/           hydrostatics (waterplane clip + integration), free-trim solver,
│                             Savitsky (own implementation, validated vs openplaning), GZ (stretch)
├── packages/viewport/        three.js: hull mesh, waterline, curvature combs, section overlays
├── packages/rhino-io/        rhino3dm.js (MIT): NurbsSurface build + .3dm write, client-side
└── spikes/compute-hello/     Phase-0: one public .gh solved via Rhino.Compute on a Windows VM

Week 1 — the hull and the numbers. Parameter schema + hard-chine planing family (d1–2) · B-spline loft + three.js viewport with waterline and section/buttock overlays (d3–4) · hydrostatics via mesh integration + free-float sink/trim solver + live panel at 60 fps (d5–7).

Week 2 — the wow and the ship. Curvature combs + Gaussian false-color (d8–9) · Savitsky module + resistance/trim chart (d10) · round-bilge displacement preset (d11) · .3dm export verified opening clean in Rhino 8 (d12) · brand polish, deploy to next.yachtsoft.lumanaire.co.za (noindex), 90-second walkthrough recording for you (d13–14).

Explicit non-goals: no accounts, no Compute dependency, no Grasshopper parity, no kernel ops (booleans/fillets), no class-A claims — the combs show honest curvature; .gh parity belongs to Phase 2 where Phil's definitions do the work.

Open questionsPhase-0 checklist

• Do Phil's actual components run headless under Compute, and what's the per-solve latency/core count (sets scale-to-zero economics)?
• Parasolid's real price and McNeel's written SaaS terms — the two numbers deciding B's long-run margin vs C's timing.
• Can occ_gordon hit the G2+ fairing bar on real yacht curve networks (curvature-comb benchmark vs Rhino/CAESES)?
• Moat map: which computations are commodity vs uniquely Phil's.