Core concepts
Sensors, the compute engine and its solvers, ray tracing's four queries, the GPU and CPU hardware it runs on, geometry groups, and the live heatmap.
Seven ideas carry the rest of these docs.
Sensors#
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. A study asks the same question at every sensor, and a solver answers it.
The compute engine and its solvers#
Wrengler's compute engine is made of solvers. A solver is a modern method for one kind of question about a building or a site: it answers a small set of typed queries, it is written for the GPU first, and it is checked against a reference on the CPU. Studies are built from those queries, so a study never deals with hardware, and one solver can serve every study that needs it.
Ray tracing is the first solver. From each sensor it 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. More solvers will join it, each held to the same rule: a reference first, and every faster path checked against it.
Ray tracing's four queries#
Every study today 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.
The hardware, GPU first#
Each study runs on the best hardware your machine supports, GPU first, falling back gracefully so a driver problem never blocks a run. For ray tracing:
| Hardware | State |
|---|---|
| CPU reference | The reference: available everywhere, checked against closed-form physics |
| Fast CPU path | Substantially faster, and matches the reference |
| Apple Silicon GPU | Runs on Apple Metal's own ray-tracing pipeline, verified against the reference |
| NVIDIA GPU | In progress: built and checked without a GPU; not yet run on an NVIDIA GPU, and not shipped |
| Cloud GPU | Planned: today every study runs on your own machine |
The CPU reference is the yardstick: its results are verified against physics you can derive analytically, and every faster path is checked against it for the same answer. You get speed where it's available without trusting it blindly.
Note
You never choose the hardware by hand. The engine picks it from what your machine supports, and the answer is the same either way.
The studies#
- Sunlight Hours: cumulative direct-sun hours over a chosen period. Available.
- View / Visibility: visible fraction per observer, rendered as a heatmap over observer geometry. Pro preview.
- Solar Radiation: per-sensor irradiance in W/m² at one instant, split into direct, diffuse, and total. For energy over a period, see Radiation over a period. Pro preview.
- Radiation over a Period: per-sensor energy in kWh/m² summed over a period of a weather file. Pro preview.
- Daylight: Planned.
See Studies for each in detail.
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.
The live heatmap#
Results live in the viewport, not in a report. Sunlight Hours and Solar Radiation paint heatmaps onto your geometry that update as you change the massing: the environmental consequence of a move, while you make it. View / Visibility works the same way, as a Pro preview.