Core Concepts
Sensors and rays, the four ray queries, the multi-backend engine, geometry groups, and the live heatmap.
Six ideas carry the rest of these docs.
1. Sensors & Rays
A sensor is a point where you want an answer — a spot on a facade, a node on an analysis grid, an observer's eye — with a normal direction where that matters. From each sensor, Wrengler casts rays into the model and asks what they hit, or what energy arrives along them.
Sunlight, view, and radiation differ only in which rays they cast and how they aggregate the results. Underneath, they are the same thing.
2. The Four Ray Queries
Every study is composed from four queries:
| Query | What it computes | Used by |
|---|---|---|
| Occlusion | Is a ray blocked between two points? | Sunlight, View |
| Visibility | What fraction of targets is visible from a sensor? | View |
| Hemisphere gather | Sample the sky hemisphere over a sensor | Radiation (diffuse sky) |
| Irradiance | How much solar energy reaches a sensor | Radiation |
Because every study speaks in these four queries, changing the hardware that answers them changes nothing about the study.
3. The Multi-Backend Engine
One engine sits behind one seam, and that seam routes to the best backend your machine supports, falling back gracefully so a driver problem never blocks a run.
| Backend | State |
|---|---|
| CPU brute force | The reference — available everywhere, checked against closed-form physics |
| CPU-BVH | Substantially faster, and identical to the reference |
| Apple Metal | GPU backend, verified against the reference on Apple Silicon |
| NVIDIA OptiX / CUDA (Windows) | Planned — no OptiX code exists yet |
The brute-force CPU backend is the oracle: its results are verified against physics you can derive analytically, and every faster backend is checked for parity against it. You get speed where it's available without trusting it blindly.
You never choose a backend by hand. The engine selects one from what your machine supports, and the answer is the same either way.
4. The Studies
- Sunlight Hours — cumulative direct-sun hours over a chosen period. Shipped.
- View / Visibility — visible fraction and sightlines between observers and targets. Engine verified; Rhino adapter next.
- Solar Radiation — per-sensor irradiance in W/m² at one instant, split into direct, diffuse, and total. Never a total collected over a period. Written, not yet verified; not released.
- Daylight — planned.
See Systems for each in detail.
5. Geometry Groups
A group is a named set of Rhino objects — a tower, a row of plots, the surfaces of one facade. Any study can run over a group, and groups reference object ids, so they stay in sync as you edit the model.
A study always runs over either a group or an ad-hoc selection, so you analyze exactly what you mean to.
6. The Live Heatmap
Results live in the viewport, not in a report. Sunlight Hours paints a heatmap onto your geometry that updates as you change the massing — the environmental consequence of a move, while you make it. The other studies are being wired to the same loop.