Overview of Wrengler
What Wrengler is for an architecture or engineering practice: a federated workspace, its four parts, and the status of each.
Wrengler is a federated workspace for architecture and engineering practices, with a Rhino 8 plug-in and a web app.
Federated means each part of a practice's work is kept in its place. Your Rhino model stays on the machine that drew it, and studies run there; your geometry is never uploaded to be analyzed. A project's files, conversations and agreed facts are kept in your organization's private area on the Wrengler platform, under its roles. Between the model and the platform travel requests and their results, such as a measured area or a finding, never the geometry.
Directed means work starts from a person: a question, a goal, a rule an owner turned on, an approval. The assistant quotes numbers as the project stores them and shows the study, file or conversation behind each one. Sun, view and solar studies are the workspace's compute, the first of the four parts below.
Note
Wrengler is in preview. There has been no release yet.
The four parts#
The workspace has four parts, in the order work travels through them. How it works takes each in turn.
- Compute. Sun, view and solar studies run on your own machine: on the GPU on Apple Silicon, and on the CPU everywhere.
- Goals. Long-running, multi-step work. A planner splits your goal into parts, workers read the project's studies, files and conversations as you, and a writer posts a cited answer into the conversation.
- Output. Answers and tables with their sources, result documents written from a study's stored numbers, and images drawn in a genre and labeled as imagined.
- Always on. Your organization's rules check its files on a schedule, findings go to the people who can act on them, and the notification center, the project conversation and the audit log keep everyone in step.
Where each part stands#
| Part | Today |
|---|---|
| Compute | Sunlight: Available, free. View and Radiation: Pro preview. Daylight: Planned. Every study can run on the CPU; the GPU path is Available on Apple Silicon, In progress for NVIDIA and Planned for cloud GPUs. The assistant acting in Rhino: Pro preview. |
| Goals | A Pro preview. See Goals. |
| Output | Answers cite their sources. Result documents are saved from a study on the project page. Images are Pro, within a monthly allowance. |
| Always on | Housekeeping runs on the schedule an owner or admin sets. The notification center is in the dashboard, and the audit log is kept for every organization. |
The studies#
Each study is a question about a building or a site, answered by a solver in Wrengler's compute engine. Today's studies ask about light and sight: does sunlight reach this point, can this observer see that target, how much solar energy lands on this facade? One solver, ray tracing, answers all three, and Wrengler shows you the answer where you work.
Each study runs over a named geometry group or an ad-hoc selection, so you analyze exactly the part of the model you care about.
| Study | Question it answers | State |
|---|---|---|
| Sunlight Hours | How many hours of direct sun does each point receive, over a chosen period? | Available, free |
| View / Visibility | Can these observers see these targets? Returns a visible fraction per observer. | Pro preview; individual sightlines not included yet |
| Solar Radiation | How much solar power reaches each sensor at one instant, in W/m²? | Pro preview |
| Daylight | Planned |
Results live in the viewport#
A Sunlight Hours and Solar Radiation study paint a live heatmap directly onto your geometry, and as you change the massing the result updates. No separate report, no export step. That is what makes Wrengler a design tool rather than an audit tool: you see the consequence of a move as you make it. View / Visibility remains under live Rhino verification.
An account, and what still runs locally#
A Wrengler account is required. Opening the plug-in presents a sign-in / sign-up wall, and no study runs without a session: the gate covers the Rhino command line too, not only the panel. Sign in with email and password, or with GitHub (which opens your real browser and returns on its own).
Your model still never leaves your machine. The compute engine is linked into the plug-in and runs on your own GPU or CPU; Wrengler uploads no geometry to analyze it, and the account is a product boundary rather than a compute one.
Two different things need the network, and they fail differently.
| Needs a connection | What happens without one | |
|---|---|---|
| The interface | Every time it opens | The panel is a web app Rhino loads from rhino.wrengler.dev. If that is unreachable, the plug-in shows a short local page saying an internet connection is required. It does not carry a copy of the interface |
| Your session | To sign in, then in the background while you work | Studies stop until Wrengler can renew it. When the connection comes back you carry on, without signing in again |
| Your plan | Before every study, about every ten minutes while you use it | Studies wait until Wrengler can check your subscription, Free and Pro alike |
There is no offline mode. A machine that has never signed in cannot run a study, and there is no air-gapped mode.
The compute engine underneath#
Every study runs on one compute engine, and the engine is made of solvers: modern methods, each for one kind of question about a building or a site. Ray tracing is the first. It answers four queries (occlusion, visibility, hemisphere gather and irradiance), and every study today is built from them, so no study learns which hardware answered it. More solvers will join it.
The engine is GPU-first. Ray tracing runs on the GPU's own ray-tracing pipeline: on Apple Silicon today, with NVIDIA in progress. Without a supported GPU it runs on the CPU, and the engine falls back gracefully, so a driver problem never blocks a run.
The reference backend is a brute-force CPU implementation whose results are checked against closed-form physics. Every faster backend is then checked against it, so the same study gives the same answer wherever it runs, and a solver that joins the engine is held to the same rule. See Core concepts for the backend list.
Where to next#
- How it works: what stays where, and how the four parts hand work to one another.
- Architecture: the layered stack, the compute engine, and the bridge into Rhino.
- Core concepts: sensors, solvers and their queries, backends, and groups.
- Installation: get the plug-in running in Rhino 8 on Windows or macOS.