Radiance remembers how light moves through a room

A physical lighting and shading experiment at Berkeley Lab's FLEXLAB. Measurements from the Philips collaboration were compared with Radiance simulations. Photograph: Berkeley Lab; reproduced from the project case study.[6]

A window can brighten a desk and make its occupant reach for the blind. Predicting that room requires a description of its surfaces, a way to follow light, and a clear idea of what to measure. Radiance, the open-source lighting engine developed at Berkeley Lab, separates those jobs into small programs. Its architecture becomes especially revealing when we ask what each program can reuse after something changes.[1]

Consider an illustrative office with a window, pale walls, and a row of desks. We want both a view from a chair and calculated light levels across the work surfaces. The following account follows Radiance's conventional ray-tracing and ambient calculation; its photon-mapping and annual daylight workflows add other machinery.

Prepare the room

Radiance scene files describe geometry, materials, and light sources. The oconv program assembles scene descriptions into an octree, commonly saved as a .oct file.[2] That spatial index starts with a cube around the scene and repeatedly divides space into eight smaller cubes. A ray can use it to narrow the search for surfaces it might strike.[3]

The octree therefore answers a geometric question: what is in this part of the room? It does not contain a completed calculation of the light on every desk. Preparing the scene and querying its illumination remain separate operations.

There is also a useful packaging choice. Normally, an octree retains references to scene files; oconv -f freezes the scene information into the octree. Moving surface coordinates or adding or removing primitives requires rebuilding. The manual permits changes to non-surface parameters without regenerating an ordinary, non-frozen octree, so “any edit always requires recompilation” would be too broad.[2]

For a reproducible comparison, keeping a frozen octree with its corresponding source files gives each room variant a concrete artifact. It still needs calculation settings and query inputs before it can produce a result.

Ask with a camera or a measuring point

rpict takes the octree and a view specification and produces a Radiance picture.[4] The chair's position and viewing direction define the question we are asking of the room.

rtrace exposes a different interface. It reads ray origins and directions from standard input and returns results on standard output. With uppercase -I, those inputs become measurement points and orientations, and the output represents irradiance: radiant power arriving per unit area.[5]

That makes a row of virtual sensors possible without arranging a camera to see every desktop. Orientation matters: an upward-facing work surface and a vertical surface at someone's eyes receive different light. In this example, they are different queries against the same room description.

A small spelling distinction carries a large meaning. Lowercase -i concerns irradiance at the surface a ray reaches; uppercase -I uses the supplied point and orientation directly. Confusing them changes where the measurement happens.[5] A script can run successfully while answering the wrong question.

Remember the indirect light

Light arriving through the window can bounce from walls and ceilings before reaching a desk. Recomputing that diffuse contribution independently for every image pixel would be expensive. Ward's 1994 system paper describes Radiance's solution: calculate indirect irradiance where needed, retain the results, and interpolate suitable nearby values. The sampling adapts to the scene; direct and specular contributions are handled separately.[3]

The stored values describe illumination at surfaces, which makes them useful across different views. A camera move can reveal new places that need calculation while still benefiting from work already done. This is the architectural reason an image's pixels and the reusable lighting results have different lifetimes.[3]

In the conventional ambient calculation, -ab limits the number of diffuse bounces; zero disables that indirect calculation. It is not a universal count of every reflection handled by the renderer. -aa controls ambient interpolation, with zero disabling interpolation.[4] These settings affect how light is calculated. Increasing the picture's pixel dimensions addresses a separate question: how finely to sample the view.

Know when the memory expires

The -af option writes indirect irradiance values to an ambient file, allowing later invocations to reuse them. The rpict manual describes a smaller image warming that cache before a larger image, while retaining the same calculation parameters.[4]

Now lower the blind in our office. The saved light belongs to a different scene. Radiance's manuals instruct users to discard the old ambient file when the scene or calculation parameters change.[4][5]

That rule suggests a practical arrangement for a small research or design team: keep each scene variant, its settings, and its ambient file together. A shared filename such as room.amb becomes dangerous if successive experiments silently reuse it. This workflow recommendation follows from the documented cache rules; it is not a claim that Radiance automatically tracks every dependency.

The distinction also helps with debugging. A stale geometric index and a stale lighting cache are separate mistakes. Rebuilding the first does not establish that the second is valid.

Give the calculation a physical counterpart

Berkeley Lab's FLEXLAB collaboration with Philips joined automated blinds, lighting controls, sensors, and an occupied office. Its case study reports that researchers compared measured photometric data with Radiance simulations.[6][7] The photograph shows the physical setting behind that comparison: equipment and a room whose behavior could be observed.

This is where the limits of software become concrete. A technically sound calculation still depends on the supplied glazing, surface properties, geometry, and lighting conditions. More computation cannot repair a model of the wrong room. For a team using simulation to support design decisions, the work includes documenting those inputs and checking representative results against measurements.

An independent EPFL account of Greg Ward's 2018 Daylight Award emphasized the continuing contributions of both Ward and Radiance users to daylight research.[8] The architecture helps explain that usefulness: one scene can support different questions, and expensive calculations can survive beyond a single picture. Keeping track of what changed is what makes that reuse trustworthy.

cronfeed.work