Flatland — Light Transport

The desktop application makes rendering geometry directly manipulable: move a camera or sensor, change the aperture, inspect material lobes and medium phase functions, and replay the connections that contribute to a sensor bin. The aim is to understand light transport by manipulating its geometry.

The browser concentrates on a smaller, explicitly normalized model: diffuse surfaces, one-sided line emitters and a pinhole angular film. It runs path tracing, path tracing with direct-light MIS, light tracing and surface photon mapping. The photon map is a new density-estimation route with finite-radius bias; it does not claim the exact same convergence target as the three random-path estimators at fixed settings.

The desktop has the broader interface, but its original tracer classes retain known sampling and normalization issues. The corrected browser core also runs directly in Ruby; it has not yet replaced those desktop classes.

The desktop view lays out scene geometry and the sampled path in the same plane. A ray can be followed to its next intersection, through a material interaction and onward to another surface or emitter. Rejected visibility connections are useful evidence too: they explain why a plausible geometric connection contributes nothing.

Space advances one event, R generates a new path and A toggles automatic playback in the desktop application. Speed controls change inspection pace; clearing history separates runs. PT/LT selection and scene presets expose different geometric opportunities. The browser uses its own labeled controls for the smaller demonstration.

Color can represent throughput or a related diagnostic quantity. Its meaning must be read with the selected visualization mode: throughput, probability density and throughput divided by density are different quantities. A vivid path is not automatically a large unbiased contribution.

The original application exposes camera and sensor geometry directly in the scene. Moving the camera or sensor changes the connection geometry, making it possible to inspect how rays map to sensor positions instead of treating image formation as a hidden final step. Aperture changes provide another way to see which paths can reach the camera construction.

The sensor inspector keeps more information than a final brightness strip. Individual bins can be examined alongside the paths that contributed to them, linking a bright region back to specific transport events. Increasing samples makes the displayed estimate less erratic, but that convergence alone cannot establish a correct normalization.

The aperture and pinhole demonstrations show how changing camera geometry changes available connections. Their recorded brightness is not presented as a calibrated thin-lens reference. The browser showcase instead declares an angular sensor whose normalization can be tested directly.

Selecting a surface in the desktop explorer opens a directional view of its response and sampled directions. Diffuse, glossy, specular, dielectric, microfacet and multiple-lobe experiments give distinct pictures of where a path can continue. The phase-function view extends the same inspection idea to scattering inside a medium.

These displays distinguish three ideas that are often conflated: the physical scattering function, the probability density used to sample it, and the resulting Monte Carlo weight. Matching their shapes visually is insufficient; their normalization and measure must agree. A mirror drawn as a widened spike is a useful illustration of concentration, but the physical delta distribution is not an ordinary finite-width lobe.

The desktop inspector is useful for comparing directional constructions. Numerical comparisons in the browser use a smaller diffuse model with tested sampling and weighting. Glass, microfacet and medium workflows remain documented here, with their estimator conventions treated separately from the browser validation.

A camera path may continue through several surfaces before finding a light. Next-event estimation adds an explicit proposal toward an emitter at eligible interactions. Its shadow connection is shown separately from the continuation ray, so an occluder, a back-facing emitter or a missed geometric opportunity can be identified directly.

Light tracing reverses the starting point: paths are launched from emitters and can attempt connections to the sensor along their journey. The desktop recordings compare large and small apertures and explicit camera connections. This makes the measure-zero difficulty of accidentally hitting a pinhole intuitive, while also motivating why connection weights need careful geometric factors.

Desktop presets include multi-light color mixtures, object arrays, focused-light arrangements and Cornell-like enclosures. They expose path families worth inspecting. The source audit also identifies estimator normalization issues, collected in the validation section rather than treating a convincing diagram as numerical evidence.

The original medium experiments introduce scattering events between surface hits, including homogeneous and spatially varying density constructions. A path can change direction inside the medium, and the phase-function inspector makes the chosen angular response visible. This is a useful extension of the event-based interface because an interaction no longer needs a visible surface to explain its location.

The source includes a delta-tracking-style attempt for varying density. Its phase evaluation and angular sampler still need a consistent normalized two-dimensional formulation before entering the matched-estimator comparison. The medium remains part of the desktop application’s exploratory scope.

The desktop also exposes Russian-roulette termination controls, including the minimum bounce before termination and a survival setting. Roulette changes which paths continue and requires compensating weights; it is different from simply discarding all paths beyond a fixed depth. The browser currently uses an explicit finite-depth target instead. Its simpler termination contract makes the three estimator comparisons easier to verify without implying that the desktop's broader controls have been fully ported.

Photon mapping changes what happens after an emitted path finds a surface. Each diffuse hit stores its arriving flux. A camera-visible point then gathers nearby deposits on that same surface, turning discrete hits into an estimated outgoing radiance. In the browser, the stored hits are visible and the selected gather is highlighted along the actual surface.

A radius control makes the central tradeoff tangible. A small support preserves sharper lighting changes but may contain too few photons. A wider support stabilizes the image while smoothing shadow boundaries and illumination detail. Even with many photons, that finite-radius smoothing is biased. The film uses eight fixed camera directions per angular bin, adding a separate quadrature approximation.

The default map launches 4,096 paths and then freezes; larger budgets store more photon samples. PT, MIS and LT can keep accumulating alongside it. Changing the scene, depth or photon settings rebuilds the map. A one-path inspection follows photon emission and storage, then shows a camera-visible gather and the flux-to-radiance conversion.

The simplified showcase runs the real transport engine inside a worker with a pinned, locally vendored ruby.wasm runtime. It needs no Ruby server. The JavaScript message bridge dispatches requests and draws engine-returned geometry, values and events.

The build script copies the authoritative Ruby source into the static artifact. The browser build uses a byte-identical copy of that source. Native tests and headless measurements load the authoritative file directly, which makes their comparison about execution environments rather than independently rewritten estimators.

• Shared engine: scene intersections, random draws, path weights, visibility tests, film statistics, photon storage/gathers and event records.
• Browser presentation: controls, plots and the schematic drawing of returned paths.
• Desktop application: broader material/camera interactions using its existing Raylib renderer classes.