Architecture
The layered stack behind Wrengler, the compute engine and its solvers, the bridge into Rhino, and the rule that keeps the engine portable.
Wrengler is a set of layers whose dependencies point downward only. The interface travels over the web; the engine travels over hardware. Rhino is where they meet, not where either one lives.
The layers#
Web UI: the panel you interact with, plus this site and a shared design system. Rhino docks an embedded web view and loads the deployed app into it, so the interface ships on the web's cadence rather than the plug-in's. It is a web app, not a native dialog.
Rhino plug-in: the only layer that talks to Rhino. Commands, studies, and the heatmaps in the viewport: it reads geometry and selections from Rhino, hands them down, and paints results back.
Compute: the studies themselves. Each turns "analyze this geometry" into queries for a solver, run on the best hardware your machine has, and aggregates the answers.
Core: the portable heart, the solvers. Today that is ray tracing, which runs on the CPU and on the GPU (Apple Silicon, with NVIDIA in progress), next to the solar-position algorithms the studies share. Core has no dependency on Rhino at all.
The stack#
The compute engine#
Compute and Core together are the compute engine: the solvers, the hardware they run on, and the studies built from them.
| Tier | What it is | Today |
|---|---|---|
| Studies | A question asked of a model, over a group or a selection | Sunlight is Available. View and Radiation are Pro preview. Daylight is Planned |
| Solvers | A method that answers a small set of typed queries | Ray tracing: occlusion, visibility, hemisphere gather, irradiance |
| Hardware | Where a solver runs, picked at run time | The GPU on Apple Silicon, and the CPU everywhere. NVIDIA GPUs are In progress; cloud GPUs are Planned |
A faster way of running a solver is used only because it gives the same answer as the solver's reference, and the reference is checked against closed-form physics. A new solver arrives the same way: a reference first, then faster paths checked against it, then the studies that need it.
The bridge#
The panel and the plug-in talk across a request/response and event bridge carried by the web view. It moves selection, geometry groups, and study runs in both directions, over a versioned protocol checked by a handshake when the panel connects.
The portability rule#
Warning
No part of the engine depends on Rhino. That rule is checked automatically, not left to convention.
Two things follow. The studies can be verified in isolation against closed-form physics, with a straightforward CPU reference that every faster path must match. And the engine is a standalone library that could be hosted or benchmarked with no design software anywhere near it: the Rhino plug-in is its first client, not its home. Serving it over a network, so a study too big for one machine can run on cloud GPUs, is planned: today every study runs on your own machine.
Performance goals#
Design goals, not measured guarantees:
- Keep the viewport interactive while a study runs.
- Process large models in batches so Rhino stays responsive.
- Update the live heatmap as massing changes, rather than blocking on a full recompute.