Radiance & Daylight Simulation

Radiance is a physically-based light simulation system: it computes real, absolute luminance and illuminance values in candela per square metre and lux, not the plausible-looking pixels of an architectural renderer. Two things earn it the field's trust. First, it is validated - decades of studies have compared Radiance predictions against physical measurements in real and scale-model rooms and found them accurate within the uncertainty of the measurements themselves. Second, it is open and free, so its methods are transparent and reproducible; a peer can re-run your study.

The distinction that makes this concrete is radiometry versus photometry with a physical basis: Radiance tracks light in real energy terms and reports it in the photometric units designers care about - lux and cd/m2 - so a result can be checked against a measured meter reading, not just admired. That is the whole game. A number you can hold against a lux meter is a prediction; a pixel tuned to look nice is an illustration.

That combination is why it underpins the metrics of Lesson 5.1. When IES LM-83 or a LEED submission asks for sDA, the accepted way to get there runs Radiance under the hood. Commercial daylighting tools compete on interface, speed and reporting - not on replacing the engine, because Radiance's accuracy is the benchmark they are measured against. Understanding this saves you a common trap: the fanciest render is not the most accurate simulation. Radiance's spartan images can be more trustworthy than a glossy real-time view, because they carry calibrated physical units rather than tuned-for-beauty pixels.

Light in the real world travels from the sun and sky, bounces around a room, and some of it eventually reaches a point or an eye. Simulating that forwards is hopelessly wasteful - the overwhelming majority of emitted rays never reach the point you care about. So Radiance runs the physics backward: it starts at the sensor (a measurement point, or a pixel of a virtual camera) and shoots sample rays outward into the scene, following each as it reflects off surfaces until it finds a light source - here, the sky.

Each ray gathers a contribution: a ray that reaches the bright sky through the window brings a lot of light; one that bounces off a dark wall first brings less. Radiance sums many such sampled rays, including inter-reflections (light bouncing ceiling-to-floor-to-desk), to estimate the total illuminance arriving at the sensor. The number of bounces (-ab, ambient bounces) and sample counts are the key accuracy-versus-speed dials: too few bounces and a deep room reads too dark; too many and the run crawls. This backward, sensor-first strategy is why Radiance can compute an accurate illuminance grid for a whole floor without simulating every photon in the sky. It is the same idea behind physically-based rendering generally, tuned for correctness over beauty.

One subtlety worth carrying: the sun is a tiny, intensely bright source, and a purely random backward ray rarely happens to hit it. So Radiance treats the sun and other bright sources specially - sampling them directly rather than hoping a stray ray lands there - while the diffuse sky and inter-reflections are handled by the general sampling. That split, direct sources plus sampled ambient, is why the engine can be both fast and correct about sharp sun patches and soft fill light at once.

Every daylight run, in any tool, assembles the same inputs - master these and you can drive Honeybee or ClimateStudio without memorising menus.

1. A sky model. The light source. It can be a single CIE overcast sky (for a daylight factor), a clear sky with sun for one moment, or - for climate-based metrics - a full annual sky built from the location's EPW weather file (Lesson 5.3). The sky is the single biggest driver of the result.

2. Geometry. The room, openings, external obstructions and shading, modelled at sensible resolution. Over-detailed geometry slows the run without changing the light; a missing overhang changes everything.

3. Materials. In daylighting, materials mean reflectance and transmittance, not looks. Wall/ceiling/floor reflectances (say 0.8 ceiling, 0.5 walls, 0.2 floor) and glazing visible transmittance (VT) (a clear double-glazed unit might be VT ~0.7, a tinted one ~0.4) drive how much light survives and bounces. Honest material values matter more than most beginners expect - guessing a ceiling at 0.5 instead of 0.8 can swing deep-room sDA noticeably.

4. A sensor grid. Where the answer is measured - usually a 0.5 m grid at ~0.76 m desk height for illuminance metrics, or a camera view for a render. Get the grid, sky, geometry and materials right and the engine does the rest.

Radiance produces two families of result, and it is worth knowing which you need. A point-in-time render (`rpict`) is a luminance image of the scene for one sky condition - a false-colour or realistic picture in cd/m2, ideal for seeing light distribution and, crucially, for glare analysis (Lesson 5.4), where you need the luminance of every bright source in view. An illuminance grid (`rtrace`/`rcontrib`) returns lux at each sensor point - the raw material of sDA, ASE and UDI. For annual metrics, Radiance uses the efficient daylight-coefficient approach (Lesson 5.3) so it can evaluate all 8760 hours without re-tracing the scene each hour.

You will almost always reach Radiance through a front-end. Honeybee (part of the free Ladybug Tools suite, in Rhino/Grasshopper) exposes Radiance visually and is the standard for learning and research. ClimateStudio and its predecessor DIVA, from Solemma, are polished commercial tools prized for speed and clean LM-83 reporting. All three write the same Radiance scene files and call the same engine - so the principles here transfer across every one. Choose the front-end for workflow and budget; the physics underneath is the shared, validated Radiance you now understand.

Radiance's honesty comes with knobs, and knowing the few that matter separates a trustworthy run from a slow or wrong one. The most important is ambient bounces (`-ab`): how many times a ray is allowed to reflect before Radiance stops following it. Direct light needs zero bounces, but real rooms are lit substantially by inter-reflection - ceiling to wall to desk - so too low a setting makes a deep or side-lit room read falsely dark. A shallow, well-glazed room may be fine at -ab 3; a deep room, a light-well or an indirect scheme may need -ab 5 or more. The related ambient accuracy, divisions and resolution (-aa, -ad, -ar) control how finely Radiance samples that indirect light - higher values reduce splotchy noise at the cost of time. Front-ends hide these behind quality presets ('low / medium / high'), but understanding what the preset changes lets you diagnose a result that looks too dark or too noisy.

Two discipline habits keep you out of trouble. First, converge, don't guess: run a small grid at rising quality until the numbers stop moving, then lock those settings for the full study - that is how you know the answer is the physics, not the sampling. Second, validate the inputs, because the engine will faithfully compute nonsense from bad ones: a missing external obstruction, a ceiling guessed at 0.5 instead of 0.8, or an unrepresentative sky will bias every metric downstream. This is the practical meaning of 'garbage in, confident garbage out'. Radiance itself is rarely the source of error; the sky, the materials, the geometry and the bounce count are. Spend your care there, and daylight simulation becomes one of the most reliable predictions in this whole course.