Architecture

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 WebView and points it at the deployed app, 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, study runners, and viewport visualizers: it reads geometry and selections from Rhino, hands them down, and paints results back.

Compute — the studies themselves, expressed over a capability-routed backend selector. Turns "analyze this geometry" into ray queries and aggregates the answers.

Core — the portable heart: the ray-engine seam, the CPU backends, and the ray queries, with a separate Apple-GPU backend beside it. Core has no dependency on Rhino at all.

The Stack

graph TD
    UI["Web UI — the panel, docked in Rhino"]
    Plugin["Rhino plug-in — commands · runners · visualizers"]
    Compute["Compute — Sunlight · View · Radiation studies"]
    Metal["Apple-GPU backend"]
    Core["Core — ray-engine seam · CPU backends · ray queries"]

    UI -->|"JSON bridge over the embedded WebView"| Plugin
    Plugin --> Compute
    Compute --> Core
    Compute --> Metal
    Metal --> Core

    Core -.->|routes to| MetalGPU["Apple Metal (GPU)"]
    Core -.->|falls back to| BVH["CPU-BVH"]
    Core -.->|falls back to| CPU["CPU brute force — the reference"]
    Core -.->|"planned (Windows)"| OptiX["NVIDIA OptiX / CUDA"]

The Bridge

The panel and the plug-in talk across a JSON request/response and event bridge carried by the WebView. It moves selection, geometry groups, and study runs in both directions, over a versioned protocol checked by a handshake when the panel connects.

Because the panel is only pointed at a URL, you can point it at localhost and develop the interface against a live Rhino document.

The Portability Invariant

Two things follow. The studies can be verified in isolation against closed-form physics, with the brute-force CPU backend acting as the reference for every faster one. And the engine is a standalone library that could be hosted or benchmarked with no CAD host anywhere near it — the Rhino plug-in is its first client, not its home. Serving it over a network is sanctioned but deferred.

Performance Goals

Design goals, not measured guarantees:

• Keep the viewport interactive while a study runs.
• Process large models in batches so the UI thread stays free.
• Update the live heatmap as massing changes, rather than blocking on a full recompute.