head 1.51; access; symbols; locks u-no-hoo:1.51; strict; comment @% @; 1.51 date 2022.05.10.23.31.52; author u-no-hoo; state Exp; branches; next 1.50; 1.50 date 2022.05.10.23.20.27; author u-no-hoo; state Exp; branches; next 1.49; 1.49 date 2022.05.10.22.42.09; author u-no-hoo; state Exp; branches; next 1.48; 1.48 date 2022.05.10.22.18.38; author u-no-hoo; state Exp; branches; next 1.47; 1.47 date 2022.05.05.23.42.45; author u-no-hoo; state Exp; branches; next 1.46; 1.46 date 2022.04.11.18.23.02; author u-no-hoo; state Exp; branches; next 1.45; 1.45 date 2022.03.18.18.35.08; author u-no-hoo; state Exp; branches; next 1.44; 1.44 date 2022.03.17.20.13.18; author u-no-hoo; state Exp; branches; next 1.43; 1.43 date 2021.09.05.21.33.28; author u-no-hoo; state Exp; branches; next 1.42; 1.42 date 2021.09.03.22.30.05; author u-no-hoo; state Exp; branches; next 1.41; 1.41 date 2021.09.02.19.05.18; author u-no-hoo; state Exp; branches; next 1.40; 1.40 date 2021.09.02.19.00.27; author u-no-hoo; state Exp; branches; next 1.39; 1.39 date 2021.09.02.15.23.18; author u-no-hoo; state Exp; branches; next 1.38; 1.38 date 2021.06.08.22.14.16; author u-no-hoo; state Exp; branches; next 1.37; 1.37 date 2021.06.08.21.25.38; author u-no-hoo; state Exp; branches; next 1.36; 1.36 date 2021.04.13.15.30.42; author u-no-hoo; state Exp; branches; next 1.35; 1.35 date 2021.03.23.21.39.44; author u-no-hoo; state Exp; branches; next 1.34; 1.34 date 2021.03.23.21.25.09; author u-no-hoo; state Exp; branches; next 1.33; 1.33 date 2020.08.12.00.45.28; author u-no-hoo; state Exp; branches; next 1.32; 1.32 date 2020.08.07.00.28.02; author u-no-hoo; state Exp; branches; next 1.31; 1.31 date 2019.08.14.18.07.00; author u-no-hoo; state Exp; branches; next 1.30; 1.30 date 2019.01.22.19.46.56; author taschreg; state Exp; branches; next 1.29; 1.29 date 2019.01.11.15.03.51; author taschreg; state Exp; branches; next 1.28; 1.28 date 2019.01.10.19.57.33; author taschreg; state Exp; branches; next 1.27; 1.27 date 2018.12.06.20.39.02; author taschreg; state Exp; branches; next 1.26; 1.26 date 2018.12.06.20.34.21; author taschreg; state Exp; branches; next 1.25; 1.25 date 2018.11.21.19.51.20; author taschreg; state Exp; branches; next 1.24; 1.24 date 2018.03.22.16.48.24; author taschreg; state Exp; branches; next 1.23; 1.23 date 2018.02.06.16.11.20; author taschreg; state Exp; branches; next 1.22; 1.22 date 2018.02.06.16.00.07; author taschreg; state Exp; branches; next 1.21; 1.21 date 2016.05.18.15.11.59; author taschreg; state Exp; branches; next 1.20; 1.20 date 2015.09.24.12.08.41; author taschreg; state Exp; branches; next 1.19; 1.19 date 2015.05.28.10.20.48; author taschreg; state Exp; branches; next 1.18; 1.18 date 2015.05.28.10.16.24; author taschreg; state Exp; branches; next 1.17; 1.17 date 2015.01.29.15.14.34; author taschreg; state Exp; branches; next 1.16; 1.16 date 2015.01.14.11.04.13; author taschreg; state Exp; branches; next 1.15; 1.15 date 2015.01.08.18.36.02; author taschreg; state Exp; branches; next 1.14; 1.14 date 2014.12.04.16.44.02; author taschreg; state Exp; branches; next 1.13; 1.13 date 2014.10.31.12.58.12; author taschreg; state Exp; branches; next 1.12; 1.12 date 2014.10.27.14.39.00; author taschreg; state Exp; branches; next 1.11; 1.11 date 2014.10.21.19.03.46; author taschreg; state Exp; branches; next 1.10; 1.10 date 2014.10.21.18.40.30; author taschreg; state Exp; branches; next 1.9; 1.9 date 2014.10.20.17.40.30; author taschreg; state Exp; branches; next 1.8; 1.8 date 2003.12.01.22.34.31; author u-no-hoo; state Exp; branches; next 1.7; 1.7 date 2003.10.07.13.54.56; author u-no-hoo; state Exp; branches; next 1.6; 1.6 date 2003.03.07.20.40.53; author u-no-hoo; state Exp; branches; next 1.5; 1.5 date 2003.03.07.20.22.05; author u-no-hoo; state Exp; branches; next 1.4; 1.4 date 2003.03.07.20.11.28; author u-no-hoo; state Exp; branches; next 1.3; 1.3 date 2003.02.03.21.11.52; author u-no-hoo; state Exp; branches; next 1.2; 1.2 date 2003.02.03.21.04.55; author u-no-hoo; state Exp; branches; next 1.1; 1.1 date 2003.02.03.20.32.50; author u-no-hoo; state Exp; branches; next ; desc @RADIANCE photon map manual @ 1.51 log @Added smiley; very important! ;^) @ text @\documentclass[a4paper,11pt]{article} \usepackage{color,graphicx,pslatex,rcs,gensymb,footmisc,listings,todonotes, amsmath,geometry } \usepackage[colorlinks,urlcolor=red,bookmarks=false,breaklinks=false] {hyperref} \usepackage[pdftex,outline]{contour} \usepackage[T1]{fontenc} \graphicspath{{figs/}} \renewcommand{\familydefault}{\sfdefault} \newcommand{\radiance}{\textsc{radiance}} \newcommand{\radClassic}{\textsc{radiance classic$^\textsf{\tiny TM}$}} \newcommand{\opt}[1]{\textbf{#1}} \newcommand{\var}[1]{$\mathit{#1}$} \newcommand{\lit}[1]{\textit{#1}\/} \newcommand{\cmd}[1]{\textit{\textbf{#1}}\/} \newcommand{\realLife}{\textsc{RealLife$^\textsf{\tiny TM}$}} \newcommand{\footnoteref}[1]{\textsuperscript{\ref{#1}}} \definecolor{lstbg}{gray}{0.9} \definecolor{lstfg}{rgb}{0,0,0.5} \lstset{frame=single, backgroundcolor=\color{lstbg}, mathescape=true, xleftmargin=5pt, xrightmargin=5pt, %aboveskip=20pt, belowskip=20pt, numbers=none, captionpos=b, basicstyle=\normalsize\color{lstfg}, breaklines, breakatwhitespace, showstringspaces=false, escapeinside={<@@}{@@>}} %\contourlength{0.1pt} %\contournumber{1} \RCS $Revision: 1.50 $ \RCS $Date: 2022/05/10 23:20:27 $ \title{The \radiance{} Photon Map Extension\\User Manual} \author{ Roland Schregle (roland.schregle@@\{hslu.ch, gmail.com\})\\ CC Building Envelopes\\ Lucerne University of Applied Sciences and Arts } \date{ Revision \RCSRevision\\ \RCSDate } \begin{document} \maketitle \tableofcontents \pagebreak \section{What's New?} Development of the \radiance{} photon map has continued within two projects hosted by the Tokyo University of Science and at Hochschule Luzern. In a nutshell, the following features have been added: \begin{itemize} \item ``Lightflow'' photon mapping; an extension to volume photon mapping to evaluate cubic illuminance at arbitrary locations in space, and visualising the lighting distribution (via \cmd{pmapdump}, see below) in the entire scene, as opposed to just on surfaces. \item Precomputed contribution photons; these replace the previous contribution photon map, with the benefit that contributions are now pre-binned and compressed; the binned contributions are then obtained by \cmd{rcontrib} from the single closest photon, similar to the existing precomputed global photons. \item Photon port orientation options; ports may now be reversed to emit from their backfaces, or even from both sides. The default behaviour of (forward) emission towards the interior as defined by the port's normal (per \cmd{mkillum} convention) is retained. \item \cmd{pmapdump} text dump option; photon positions and their flux may now be dumped as plain text for input into interactive point cloud processors and viewers. \item Polyhedral regions of interest (ROIs) specified by material modifiers are considerably more flexible and general than rectangular or spherical ROIs, particularly if the ROI is bounded by complex geometry. \end{itemize} \clearpage \section{Introduction and Motivation} The \radiance{} rendering system \cite{Ward1994} is a very versatile and powerful tool for lighting simulation, and one of the few physically based renderers with available source code. However, developments in light redirecting materials have presented new challenges in their simulation; their specular nature makes them difficult to simulate with \radiance, often resulting in an undersampled specular component and therefore excessive noise. Extreme sampling parameters yield a marginal improvement at the expense of high computational load. Particularly the phenomenon of caustics is undersampled with \radiance. Caustics are bright, iridescent highlights on diffuse surfaces caused by specular reflection or refraction. Figure \ref{fig:caustic} shows an example of a caustic from a retroreflecting lamella, which is a typical redirecting component encountered in daylight simulation. Quoting chapter 13 of ``Rendering with \radiance'', \cite{Ward1998}, \begin{quote} ``Other cases involving curved, specular reflectors pose similar difficulties for \cmd{mkillum}, and the only long-term solution seems to be the creation of a forward raytracing module for computing these kinds of illums.'' \end{quote} The problem is actually more fundamental due to \radiance's backward raytracing methodology, and not restricted to \cmd{mkillum} alone. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.7\linewidth} \includegraphics[width=\linewidth]{IMG_5048b} \parbox{\linewidth}{% \caption{% \label{fig:caustic} Photograph of caustic from retroreflecting lamella (patented by Helmut K\"oster). } } \end{minipage} } \end{figure} \radiance's difficulties with highly directional materials motivated the development of the forward raytracing module mentioned above as a supplementary algorithm. The photon map \cite{Jens1996, Jens1997, Jens2000} was chosen for a number of reasons: \begin{itemize} \item Apart from handling indirect diffuse illumination, it handles caustics efficiently and has become the algorithm of choice for this purpose. \item It is straightforward to integrate into existing ray tracing environments. \item It is decoupled from the scene geometry and thus can handle arbitrarily complex objects. This also enables using the photon map to simulate indirect illumination in volumes such as participating media \cite{Jens1998, Schr2019}. \item It represents a view independent solution to the indirect illumination and can thus be reused for multiperspective renderings with unchanged geometry. \end{itemize} The photon map is based on a (light) particle transport simulation, which lends its name. Each photon interacts with the objects it strikes and is either reflected, transmitted, or absorbed, depending on the characteristics of the material. A Monte Carlo sampling method is used to generate the reflected or transmitted directions of a photon if it survives. Eventually a particle is terminated either by absorption or leakage (if it leaves the scene), and a new photon is emitted. \clearpage \section{Implementation Overview} The photon map algorithm comprises two steps: \begin{description} \item[Photon distribution (forward pass):] as a preprocess, photons are emitted from all light sources and probabilistically reradiated or absorbed upon striking a surface or passing through a volume, depending on its properties. The result is a view independent representation of the indirect illumination (figure \ref{fig:cornell_distrib}). \item[Photon gathering (backward pass):] during the actual rendering, the indirect illumination for a point on a surface or within a volume is determined by finding a number of nearest photons to the point. The irradiance is then proportional to the photon density (figure \ref{fig:nnsearch}), hence the process is known as \emph{ density estimation\/} in the statistics literature. The number of photons gathered defines the area covered by the density estimate, and will be referred to as its \lit{bandwidth} for the rest of this document. \end{description} Note that the combination of a forward and backward pass comprises a bidirectional raytracer, thus all possible light transport paths are accounted for. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \includegraphics[width=0.49\linewidth]{cornell-distrib1} \hfill \includegraphics[width=0.49\linewidth]{cornell-distrib2}\\ \parbox{\linewidth}{% \caption{% \label{fig:cornell_distrib} Global photon distribution in the Cornell box. Left: global and caustic photon paths during forward pass. Dots indicate stored photons, where blue represents global photons, and red represents caustic photons. Right: photon distribution after completion of forward pass (visualised with \cmd{pmapdump}). Note the concentration of caustic photons on the back wall reflected from the glass sphere. } } \end{minipage} } \end{figure} \begin{figure}[t] \centering \fbox{% \begin{minipage}{0.75\linewidth} \resizebox{\linewidth}{!}{\input{figs/nnsearch}} \parbox{\linewidth}{% \caption{% \label{fig:nnsearch} Gathering photons via nearest neighbour search. The number of gathered photons defines the \lit{bandwidth}, or intercepted area, of the density estimate use to evaluate the irradiance. } } \end{minipage} } \end{figure} The distribution step is performed by the \cmd{mkpmap} utility. It is responsible for building the photon map and saving it to a file for subsequent reuse by \cmd{rpict}\footnote{Unless noted otherwise, \cmd{rpict} also implies its siblings \cmd{rtrace} and \cmd{rvu}, which also support photon mapping.} for the actual rendering and photon gathering. The general photon mapping workflow can therefore be summarised as: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} /* Prepare model$\ldots$ */ /* Thinkety-think$\ldots$ (mull over parameters) */ mkpmap [-apg $globalpmap$ $nphotons$] \ [-apc $causticpmap$ $nphotons$] \ [-apv $volumepmap$ $nphotons$] $\ldots$ \ [$options$] $octree$ /* Clickety-click$\ldots$ pokety-poke$\ldots$ */ rpict | rtrace | rvu [-ap $globalpmap$ [$bwidth$]] \ [-ap $causticpmap$ [$bwidth$]] \ [-ap $volumepmap$ [$bwidth$]] $\ldots$ \ [$options$] $octree$ \end{lstlisting} \end{minipage} \end{center} Doan' panic, parameters (highlighted in italics) will be explained in the following sections. Six photon types are available, which are stored in separate photon maps and visualised differently: \begin{description} \item[Global photons] account for all indirect (ambient) illumination incident on surfaces with a diffuse component. \item[Caustic photons] account for all indirect specular to diffuse transfers, i.e. caustics. These transport paths are also accounted for by global photons, but not visualised directly like caustics. \item[Volume photons] account for indirect illumination within participating media using the \lit{mist} primitive. See section \ref{sec:partMedia} for details. \item[Direct photons] account for the direct component from light sources and are intended to serve as a debugging option. These should be rarely used in practice. \item[Precomputed global photons] store irradiance from precomputed density es\-ti\-ma\-tes from a number of nearby photons. This is an optimised variant of global photons and assumes a low indirect irradiance gradient. See section \ref{sec:precomp} for details. \item[Contribution photons] account for contributions from light sources via references to the emitting source, which may also be normalised as coefficients. This is a variant of global photons intended for climate based modelling in conjunction with \cmd{rcontrib}. See section \ref{sec:lsContribs} for details. \end{description} The stock \radiance{} functionality (referred to here as \radClassic) is preserved in \cmd{rpict} when photon mapping mode is disabled. When rendering with the photon map, the ambient calculation is augmented by a photon map density estimate, but the direct and indirect specular components are still delivered by \radClassic. \subsection{Supported Materials} Material types in \radiance{} must provide support for probabilistically generating outgoing directions for incident photons using Monte Carlo methods. The following material primitives support photon mapping: \begin{description} \item[Analytical Gaussian:] \lit{plastic, metal, trans, plastic2, metal2, trans2} \item[Refracting/Reflecting:] \lit{glass, dielectric, interface, mirror} \item[Data-driven] \lit{bsdf} \item[Mixtures:] \lit{mixfunc, mixdata} \item[Patterns:] \lit{colorfunc, brightfunc, colordata, brightdata, colorpict} \item[Textures:] \lit{texfunc, texdata} \item[Volumes:] \lit{mist, antimatter} \end{description} Materials with scattering defined procedurally or through tabulated data are only partially supported. The \lit{plasfunc, metfunc, transfunc, plasdata, metdata}, and \lit{transdata} materials currently only scatter photons diffusely, and will not produce caustics. The \lit{brtdfunc} material only produces caustics via ideal (mirror) specular reflection and transmission. These materials have been largely superseded by the more general \lit{bsdf} material, which uses a highly optimised internal data representation and efficient sampling, and is preferred for realistic scattering behaviour. \subsubsection{Participating Media} \label{sec:partMedia} The \radiance{} photon map supports indirect inscattering in participating media defined with the \lit{mist} primitive. Participating media are somewhat unwieldy in \radiance{}; in order for volume photons to function correctly with materials which modify the coefficient of extinction and scattering albedo (i.e. \lit{dielectric} and \lit{interface}), it is necessary to surround the light source(s) and viewpoint with a \lit{mist} boundary (e.g. \lit{bubble}), unless one intends to restrict volume photons to a small section of the scene. Furthermore, in order to obtain volume caustics from light passing through an object (see \autoref{fig:cornell-volume} for such an example), it must also be surrounded by a mist boundary. Alternatively, the mist parameters can be set globally on the command line, however this requires setting the source and viewpoint boundaries' extinction to zero, otherwise extinction is accumulated. Furthermore, \cmd{rpict} only accounts for inscattering along rays of finite length, i.e. which intersect a local object. The scene therefore requires peripheral geometry to delineate a finite expanse of \lit{mist}, e.g. a boundary of this material for the entire scene. All this just to make life more interesting. That being said, volume photon mapping opens up interesting applications beyond rendering caustics in fog or smoke, for example the simulation of light propagation in architectural spaces \cite{Schr2019}, as shown in \autoref{fig:pmapdump-sunpu}. \subsubsection{Light Sources} Light sources require additional code for photon emission. Currently supported primitives are \lit{light, spotlight, glow}, and \lit{ source.} To ensure accurate distribution, light source geometries are partitioned to a user specified resolution and photons emitted from each partition. The behaviour of a few emitter types differs from \radClassic. In the case of the \lit{source} primitive there is no geometry to partition; instead, the scene cube faces are partitioned and act as emitters, unless photon \emph{ports\/} are used (see section \ref{sec:ports}). Furthermore, the \lit{glow} primitive acts as regular light source within its maximum radius for shadow testing, in which case its contribution is accounted for by the photon map, otherwise it is handled by \radClassic's ambient calculation. Virtual sources are disabled with photon mapping, since caustic photons account for this functionality. As in \radClassic{}, light sources may be modified by function files. Functions may access the following variables (see also \lit{rayinit.cal}) during photon emission, which are defined in terms of the photon origin on the light source: \begin{description} \item[Dx, Dy, Dz]: the photon's direction, pointing towards its origin on the light source \item[Nx, Ny, Nz]: the surface normal on the light source at the photon origin \item[Px, Py, Pz]: the emitted photon's origin on the light source \item[Rdot]: the dot product of the surface normal and the photon's direction at its origin. \end{description} \subsection{Optimisations} A number of optimisations have been incorporated into the implementation to either improve performance or accuracy. The user must be aware of the fact that most of these optimisations incur trade-offs; increasing performance will inevitably compromise accuracy, and vice versa. Such is the harsh reality of Monte Carlo. \subsubsection{Precomputed Global Photons} \label{sec:precomp} Per Christensen's precomputed photon mapping approach \cite{Chri2000} has been integrated into \cmd{mkpmap} and is available via the \opt{-app} option to accelerate the subsequent global photon gathering step in \cmd{rpict}. With this optimisation, global photon irradiance is precomputed for a fraction of the photon positions and stored with the photons, while the rest are discarded. This reduces the overhead of global photon lookups during the gathering phase; only the single closest global photon is retrieved, and its precomputed irradiance can be used directly (figure \ref{fig:precomp}). The disadvantage of this optimisation is potential local bias in scenes with nonuniform indirect illumination. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.6\linewidth} \includegraphics[width=\linewidth]{precomp}\\% \parbox{\linewidth}{% \caption{% \label{fig:precomp} Directly visualised precomputed global photon irradiance. Note the caustic from the glass sphere. } } \end{minipage} } \end{figure} \subsubsection{Bias Compensation} \label{sec:biascomp} The density estimate bandwidth affords the user control over the quality and accuracy of the rendering by trading off between noise and bias. Setting the bandwidth too low may result in excessive noise, while setting it too high may result in excessive blurring and local bias in the solution. To counter this bias/noise tradeoff, a \emph{bias compensation\/} \cite{Schr2003} was developed and incorporated into the density estimate as an option. Its purpose is to adapt the bandwidth within a user specified lower and upper bound. Bias compensation employs a binary search for an optimal bandwidth based on the likelihood that deviations from a running average irradiance are due to noise or bias. This results in substantially improved contours in nonuniform indirect illumination (particularly caustics) with a slight increase in noise in these regions (figure \ref{fig:biascomp}). \sloppy The algorithm also compensates for boundary bias (irradiance falloff at polygon edges) and chromatic bias. However, this sophistication comes at a price, as it does impact performance noticeably. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \includegraphics[angle=-90, width=0.49\linewidth] {spot-bias-50000-false}% \hfill% \includegraphics[angle=-90, width=0.49\linewidth] {spot-biascomp-50000-false}\\% \parbox{\linewidth}{% \caption{% \label{fig:biascomp} Left: falsecolour rendering of severely biased caustic with a bandwidth of 5000 photons. The caustic should have an irradiance of 10 $W/m^2$. Right: falsecolour rendering of the same caustic with bias compensation using a bandwidth of 50--5000 photons. } } \end{minipage} } \end{figure} \subsubsection{Automatic Maximum Search Radius} \label{sec:maxDist} The photon lookup algorithm uses a maximum search radius to identify the nearest neighbours. This radius is progressively reduced during the search until the required number of photons (as defined by the density estimate bandwidth) remain. Photons beyond the maximum search radius are disregarded. An appropriately sized maximum search radius will eliminate many distant photons from the search, thus greatly accelerating the process. Setting it too small, however, will result in a ``short'' lookup, with fewer photons found than requested with the bandwidth. While this does not invalidate the resulting density estimate, a very low number of photons will render it inaccurate due to excessive noise. An optimal maximum search radius is difficult to predict as it changes dynamically with the local photon density. The maximum search radius is therefore estimated from the average photon distance to the centre of gravity of the photon distribution. This adapts the maximum search radius to the average photon density and accounts for non-uniform concentrations of photons, as is often the case with caustics. In situations where the photon distribution is grossly skewed, the user can manually override this automation in \cmd{rpict} by specifying a fixed maximum search radius with the \opt{-am} option. \subsubsection{Photon Ports} \label{sec:ports} Emitting photons from the \lit{source} primitive presents a challenge; there is no local geometry associated with these directional sources. While the default behaviour is to emit photons from the scene cube faces, this can become highly inefficient for sources with large solid angles. These are infact situations for which a forward raytracer is fundamentally inappropriate. \radClassic's backward raytracer fares better here, since sending a ray to a large source is trivial. With the forward raytracer, the majority of emitted photons will be lost and won't contribute to the photon map. To aggravate the situation, directional sources are often used to render interior daylit spaces. With the viewer positioned inside, the few photons that actually strike the geometry must also pass through windows or skylights before they can even contribute visibly to the photon map. Needless to say, this amounts to abysmal performance. A simple workaround to the problem is the concept of \emph{photon ports\/}. The ports are basically apertures through which photons can enter the space containing the viewpoint. These can be windows, skylights, but also invisible polygons acting as boundaries within the scene (figure \ref{fig:port}). The primary drawback to this scheme is that it requires user intervention. The user must define the port geometry and specify the objects by their modifiers using the \opt{-apo} option to \cmd{mkpmap}. Adroit placement of ports can dramatically reduce the photon loss factor, resulting in substantially shorter distribution times with \cmd{mkpmap}. \begin{figure}[!htb] \centering \fbox{% \begin{minipage}{0.85\linewidth} \includegraphics[width=\linewidth]{port5} \parbox{\linewidth}{% \caption{% \label{fig:port} Typical daylighting geometry with window as photon port for directional light sources. Note that external reflections are not accounted for by photons emitted from the port. } } \end{minipage} } \end{figure} All objects in the scene description using the specified port modifiers act as ports during photon distribution. Photons are then emitted directly from the ports rather than from the scene cube faces. The incident flux from directional sources is evaluated at each port and the sources are checked for occlusion. However, no interreflection calculation is made; a port differs from an \lit{illum} in this respect. Photons are scattered by the port upon emission as if they had passed through it. By default, \emph{port objects are defined with their surface normals pointing \underline{inwards}} as per \cmd{mkillum} convention. This behaviour can be overridden with if the port normals happen to point outwards; in this case, the port orientation can be reversed. In addition, ports can also be configured to emit bidirectionally, i.e. from either side. A possible use case is using a \lit{mist} volume boundary as port; per definition, the photon will only scatter if it enters the medium, i.e. if its normal points outwards. In this case, the port needs to be reoriented to face inwards. In some cases ports may not coincide with any scene geometry. These situations call for invisible ports. Photons should be emitted from them, but they should not be affected by scattering through the port, and the port should not be visible during rendering. One simple solution is to define photon ports using the \lit{antimatter} modifier, with \lit{void} as its only string argument. Photon ports are the only optimisation in the implementation which do not compromise accuracy for performance, assuming correct placement on behalf of the user. A more general approach using Markov Chain techniques to automatically find viable photon paths without user intervention may materialise one day. Maybe.\\[1em] \noindent{\scriptsize Or not. Probably not.} \subsubsection{Regions of Interest (ROIs)} \label{sec:roi} The photon map extension supports the specification of one or more regions of interest, or ROIs, in which to exclusively store photons. \cmd{mkpmap} currently accepts ROIs either as 3D coordinates defining bounding boxes (rectangles) or spheres, or as material modifiers specifying polygons that comprise enclosing non-convex polyhedra. ROIs are \emph{accumulated} as they are parsed by \cmd{mkpmap}, consequently a simulation run can contain several ROIs to constrain photons as needed. The primary purpose of defining a ROI is to optimise the photon distribution by concentrating photons where they contribute significantly, and disregarding parts of the geometry which are out of view or insignificant. A typical example is an interior space with a fenestration, with many photons being deposited within the latter, thus reducing the number of useful photons in the interior. The ROI would then correspond to the extent of the interior and exlude the fenestration. An example of this is shown in \autoref{fig:roi}. \begin{figure}[tb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \includegraphics[width=0.49\linewidth] {scene-000-pmapdump-100k}% \hfill% \includegraphics[width=0.49\linewidth] {scene-000-pmapdump-100k-roi}\\% \parbox{\linewidth}{% \caption{% \label{fig:roi} Photon distributions (visualised with \cmd{pmapdump}) within an interior fitted with a redirecting system. Without constraint, the majority of photons are stored in the fenestration due to interreflection (left). By defining a rectangular region of interest corresponding to the room's extent with the \opt{-api} option, \cmd{mkpmap} only deposits photons in the interior, resulting in an improved distribution and rendering quality (right). This example also uses an invisible \lit{antimatter} sensor surface (defined via the \opt{-aps} option) to deposit photons at work plane height. This is noticeably underpopulated without ROI, thus impacting illuminance measurements on it. } } \end{minipage} } \end{figure} A similar situation applies when defining a global mist by specifying \opt{-me} on the command line in conjunction with a volume photon map. Without constraint, volume photons will be stored \emph{everwhere}, which is wasteful. Instead of explicitly defining a \lit{mist} boundary as part of the geometry, it is more convenient to specify the actual polygons enclosing an interior as a polyhedral ROI. An example of this is shown in \autoref{fig:polyroi} for an unusal octahedral structure with sloping roof. \begin{figure}[tb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \centering \includegraphics[width=0.8\linewidth] {kazenooka-polyroi-vpm-crop}\\% \parbox{\linewidth}{% \caption{% \label{fig:polyroi} Clipped plan view of an octagonal interior containing volume photons (visualised with \cmd{pmapdump}) constrained within a polyhedral region of interest (ROI). A global \lit{mist} was defined on the command line to deposit the volume photons. Without a ROI, photons reflected or transmitted through the fenestrations (a low opening at the bottom and a group of skylights which have been clipped here) will also be stored in the exterior. By defining a polyhedral ROI comprised of polygons surrounding the interior (walls, floor, ceiling, fenestrations) using the \opt{-aph} option, \cmd{mkpmap} only deposits volume photons in the enclosed space. This is conveniently done by specifying the corresponding material modifiers of the polyhedron's surfaces. } } \end{minipage} } \end{figure} Individual \textbf{bounding box ROIs} are specified as triplets of minimum and maximum coordinates: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap .. -api $min_x$ $min_y$ $min_z$ $max_x$ $max_y$ $max_z$ .. $octree$ \end{lstlisting} \end{minipage} \end{center} Note that bounding box ROIs must be axis-aligned. Individual \textbf{bounding sphere ROIs} are specified as triplets of sphere origin and radius: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap .. -apI $pos_x$ $pos_y$ $pos_z$ $rad$ .. $octree$ \end{lstlisting} \end{minipage} \end{center} Individual polygons comprising \textbf{polyhedral ROIs} are specified as by their common modifier, or by a set of modifiers read from a file: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap .. -aph $mod$ .. -apH $modfile$ .. $octree$ \end{lstlisting} \end{minipage} \end{center} In realistic scenarios several instances of \opt{-aph} are required to specify the polygons surrounding the ROI, as these will typically use different materials (e.g. walls, ceiling, floor, fenestrations, etc). In this case, it is more convenient to group all modifiers comprising each polyhedral ROI in individual files, and specifying these via the \opt{-apH} option instead. It is important to note that, while the ROIs can be non-convex, no check is made to ensure the defined polyhedra are infact closed nor degenerated (i.e. with overlapping polygons) -- this is the user's responsibility. Once ROIs are defined, photons are only added to the photon map if their hitpoints lie within one of the defined ROIs. The photon path and the resulting contribution to the lighting solution remains unaffected; path segments entering a ROI will deposit photons, while those leaving a ROI will not. Note that the number of stored photons remains approximately the same, but the photon map generation can take considerably longer, depending on the volume and location of the ROIs relative to the photon trajectories. ROIs are an advanced option with inherent pitfalls, as excluding photons represents a \emph{partial} solution of the light transport in the scene. It is therefore assumed that the user is aware of the fact that irradiance will be underestimated by \cmd{rtrace} outside the ROI. For example, estimating glare from the fenestration in \autoref{fig:roi} would clearly lead to underestimation as interreflections within the fenestration are omitted. \clearpage \section{Generating photon maps with \cmd{mkpmap}} \label{sec:mkpmap} The \cmd{mkpmap} utility accepts a \radiance{} octree as input and performs a forward raytracing pass to generate a photon map of each specified type for the scene. The photons are stored in a space subdividing data structure \cite{Bent1975} which facilitates nearest neighbour queries required for the photon lookup step. The data structure is written to a portable binary file for subsequent use by \cmd{rpict}. \subsection{Distribution Algorithm} The parametrisation of the distribution step is primarily intended to be user friendly; the user specifies the required number of photons stored in each map. These are treated as ``targets'' which the photon distribution code tries to attain, since there is no way of knowing the outcome of the distribution a priori. The distribution algorithm makes an educated guess at the number of photons it must emit in order to satisfy the targets. This is based on the results of a distribution prepass in which a small number of photons (a fraction of the minimum specified target) is emitted and distributed. Since the distribution process scales linearly, the remaining number of photons to emit can be predicted and distributed in the main pass. The actual number of photons generated after the distribution is complete will approximate the targets. \subsection{Distribution Failure} The distribution step may bog down and terminate after a user specified number of prepass attempts if any of the specified photon maps are still empty. This is usually an indication of a scene anomaly or an incompatible photon map specification. This is intended as a convenience for the user; without it, \cmd{mkpmap} would end up in an infinite loop. It is nevertheless the user's responsibility to specify photon map types compatible with the materials and to check the validity of the scene. \noindent The following situations can cause \cmd{mkpmap} to fail: \begin{itemize} \item pathological scenes in which none of the light sources see any geometry \item specifying a global photon map for a scene containing no materials with diffuse component \item specifying a caustic photon map for a scene containing no materials with diffuse or specular component \item specifying a volume photon map for a scene lacking the \lit{mist} primitive. \end{itemize} \subsection{Runaway Photons} Photons may become trapped inside \lit{dielectric} or \lit{interface} materials, often due to infinite total reflection. These ``runaway'' photons are terminated after a user defined bounce limit is exceeded, and a warning is issued under the assumption that this is an anomaly of the scene geometry. \subsection{Progress Report} \label{sec:mkpmap.report} If progress reports are enabled, \cmd{mkpmap} will report the following during distribution: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} $N_e$ emitted, $N_g$ global, $N_c$ caustic, $N_v$ volume, $N_d$ direct, $p\ $% after $t$ hours, ETA= $t_r$h \end{lstlisting} \end{minipage} \end{center} where: \begin{itemize} \item \var{N_e} is the total number of emitted photons \item \var{N_g}, \var{N_c}, \var{N_v}, and \var{N_d} is the number of global, caustic, volume, and direct photons stored, respectively \item \var{p} is the percentage completed \item \var{t} is the time elapsed. \item \var{t_r} is the estimated time remaining \end{itemize} When generating a precomputed global photon map, a report will also be issued subsequent to the distribution step, indicating the number of precomputed photons: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} $N_p$ precomputed, $p\,$% after $t$ hours \end{lstlisting} \end{minipage} \end{center} \subsection{Command line arguments for \cmd{mkpmap}} \label{sec:mkpmapArgs} The general synopsis of the \cmd{mkpmap} utility is: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apg|-apc|-apv|-apd|-app|[-apC|-apt|-apT|-apV] \ $pmapfile$ $nphotons$ [$precompbwidth$] $\ldots$ \ [$options$] $octree$ \end{lstlisting} \end{minipage} \end{center} The options are as follows: \begin{description} \item{\opt{-apg} \var{pmapfile} \var{nphotons}}\\ Generate a global photon map containing approximately \var{nphotons} photons, and output to \var{pmapfile}. This accounts for all indirect illumination, from both specular and diffuse scattering, on surfaces with a diffuse component. This is the most general type of photon map and replaces the ambient calculation in \cmd{rpict}. \item{\opt{-apc} \var{pmapfile} \var{nphotons}}\\ Generate a separate caustic photon map containing approximately \var{nphotons} photons, and output to \var{pmapfile}. This is a subset of the global photon map intended for direct visualisation at primary rays. This accounts for all indirect illumination on diffuse surfaces from specular scattering, which usually exhibits a large gradient and requires a higher resolution than the global photon map, typically containing the tenfold number of photons. \item{\opt{-apv} \var{pmapfile} \var{nphotons}}\\ Generate a volume photon map containing approximately \var{nphotons} photons, and output to \var{pmapfile}. These account for indirect inscattering in participating media such as \lit{mist} and complement the direct inscattering computed by \cmd{rpict}. See also the \opt{-me}, \opt{-ma} and \opt{-mg} options below. \item{\opt{-apd} \var{pmapfile} \var{nphotons}}\\ Generate a direct photon map containing approximately \var{nphotons} photons, and output to \var{pmapfile}. This only accounts for direct illumination on diffuse surfaces, and is intended for debugging and validation of photon emission from the light sources, as the quality is too low for actual rendering. Direct photon maps are useful to determine suitable settings for the \opt{-ds} and \opt{-dp} options when using light sources with complex modifiers, as they provide a visual check for the resolution of the probability density function used for photon emission. Furthermore, it can serve as a validation tool for comparison with \radiance's direct component. \item{\opt{-app} \var{pmapfile} \var{nphotons} \var{precompbwidth}}\\ Generate a precomputed global photon map containing a fraction of \var{nphotons} photons (specified with the \opt{-apP} option, see below), and output to \var{pmapfile}. This is a special case of the global photon map where the irradiance is evaluated with a bandwidth of \var{precompbwidth} photons for a fraction of the photon positions, and stored as photon flux; the remaining photons are discarded as their contributions have been accounted for. This obviates the explicit irradiance evaluation by \cmd{rpict}, thus effecting a speedup at the expense of accuracy. The resulting error is tolerable if the indirect illumination has a low gradient, which is usually the case with diffuse illumination. See section \ref{sec:precomp} for details on using precomputed global photons. \item{\opt{-apC} \var{pmapfile} \var{nphotons} \var{precompbwidth} \var{comp} \footnote{Contribution photon mapping is optional and requires out-of-core storage, which is not enabled in the default build. In addition, it is currently not supported on Windows. On platforms that do support it, out-of-core storage must be enabled at compile time with \opt{-DPMAP\_OOC}. To verify if your build supports contribution photon mapping, check if the \opt{-apC} option appears in the output of \cmd{mkpmap -help}. \label{note:contrib} } }\\ Generate a precomputed contribution photon map containing a fraction of \var{nphotons} photons (specified with the \opt{-apP} option, see below), and output to file \var{pmapfile}. Only light sources may contribute, and are specified via their modifier(s) with a subsequent \opt{-m} option (see below). Each precomputed photon accumulates contributions from the \var{precompbwidth} nearest photons into bins (specified with the \opt{-bn} option, see below). If \var{precompbwidth} is less than the number of bins, a warning is issued, since some bins will be zero. Ideally, \var{precompbwidth} should be a multiple of the number of bins. If too many bins (default 50\%) are still zero, a warning about an excessive empty bin ratio is issued, indicating potentially biased contributions, and that the number of photons and/or the bandwidth should be increased further. However, if very small contributions are indeed expected in some bins, this warning should be taken with a grain of salt. Precomputed contribution photon maps can be used by \cmd{rcontrib} to very efficiently evaluate binned light source contributions (e.g. from sky patches) at multiple points by looking up the single nearest precomputed photon. In contribution mode, \cmd{mkpmap} is therefore designed to behave similarly to \cmd{rcontrib}. To ensure the latter obtains binning parameters consistent with those used in the precomputation, \cmd{mkpmap} outputs an option file \var{pmapfile.opt} which must be passed to rcontrib via its \opt{@@} option. The \var{comp} parameter specifies a compression ratio for the binned contributions in the range [0,~1], where 1 corresponds to maximum compression, and 0 implies no compression at all. Compression is recommended as it gives the user control over the size of the binned contributions, which are saved in a separate file for each modifier; depending on the number of photons and bins, these files can become very large. Note however that \cmd{mkpmap} uses a \emph{lossy} wavelet compression, which can introduce artefacts at higher compression ratios if the lighting is complex (e.g. exhibits high gradients). In typical scenarios, a compression ratio of 0.7--0.8 yields an acceptable compromise between accuracy and space savings. With this option, \cmd{mkpmap} uses a modified photon distribution algorithm that increases the odds that all selected light sources contribute approximately the same number of photons. Because of this, \cmd{mkpmap} cannot generate a contribution photon map in combination with others in a single run, and other photon maps specified on the command line will be ignored. See section \ref{sec:lsContribs} for details on using precomputed contribution photon maps with \cmd{rcontrib}. \item{\opt{-apt} \var{pmapfile} \var{nphotons} \var{velocity} \footnote{Transient photon mapping is experimental and requires in-core (kd-tree) storage, which is enabled in the default build. It is currently not supported with optional out-of-core storage (\mbox{\opt{-DPMAP\_OOC}}). To verify if your build supports transient photon mapping, check for the \opt{-apt} option in the output of \cmd{mkpmap -help}. \label{note:transient} } }\\ Generate a transient photon map with the given propagation velocity. This is a variant of the global photon map with the distinction that photons can be located in space and time. When a transient photon interacts with a surface, its time of flight, subject to its velocity, is recorded along with its position (technically, this is internally expressed as the photon path length to simplify the spatio-temporal distance metric used for photon lookups). The velocity is expressed in units 1/sec in relation to the scale of the simulation geometry. For reference, the speed of light in a vacuum is 299792458 metres/sec (or 3e8 if you're not Stephen Hawking). The velocity is currently treated as constant in all media, and is consequently not adapted for the index of refraction in \lit{dielectric} and \lit{interface} materials. Relativistic effects are also not accounted for, since Stephen Hawking doesn't use RADIANCE anyway\footnote{% \url{https://www.youtube.com/watch?v=ITo3EvxWnPg} }. Transient photon maps are particularly useful to study the propagation of light in extreme slow motion. See section \ref{sec:transient} for details on how transient photons can be rendered at specific points in time. \item{\opt{-apT} \var{file} \var{nphotons} \var{velocity} \footnoteref{note:transient} \footnoteref{note:lightflow} }\\ Generate a transient lightflow photon map. This photon map combines the attributes of lightflow and transient photons, i.e. transient rendering at arbitrary locations in a volume (requiring a participating medium). See options \opt{-apt} and \opt{-apV} for details. \item{\opt{-apV} \var{pmapfile} \var{nphotons} \footnote{Lightflow photon mapping is experimental and not enabled in the default build. It must be enabled at compile time with \opt{-DPMAP\_PHOTONFLOW}. To verify if your build supports lightflow photon mapping, check for the \opt{-apV} option in the output of \cmd{mkpmap -help}. \label{note:lightflow} } }\\ Generate a ``lightflow'' photon map containing \var{nphotons} photons. This is a specialised variant of the volume photon map (see the \opt{-apv} option above) designed to evaluate cubic illuminance at arbitrary positions in space. In addition, the photon propagation in space can be visualised with the output of \cmd{pmapdump}. Note however, that illuminance from lightflow is generally less accurate than using a global photon map with a dedicated virtual sensor plane in conjunction with the \opt{-apS} option. As with regular volume photon mapping, lightflow photons require a participating medium in which they are deposited. Unlike regular volume photon mapping however, lightflow photons do not interact with the participating medium, and are neither scattered nor absorbed; consequently, the photon trajectories -- and therefore the light transport as a whole -- is unaffected by the participating medium. Lightflow photon mapping implies an albedo and eccentricity of 1 (corresponding to the options \opt{-ma} and \opt{-mg}, respectively) in participating media. The coefficient of extinction, which can be defined locally for a \lit{mist} primitive, or globally via the \opt{-me} option, is a free parameter that determines the density of the deposited photons. It is generally desirable to keep this parameter low to minimise clustering, at the expense of slower photon distribution. Setting this parameter too high can result in excessive linear clustering of photons along their trajectories, leading to a "ray effect" and local bias in the evaluated illuminance (this is readily apparent on visual inspection with \cmd{pmapdump}). This parameter also depends on the scale of the space in which the photons are deposited. An unwanted side effect of lightflow photon mapping is that photon distribution may overflow, particularly in dense media with high extinction values. In this case, the predistribution factor (see option \opt{-apD}) should be reduced accordingly. Future releases of \cmd{mkpmap} may adjust this parameter automatically. A lightflow photon map can be visualised with \cmd{pmapdump} or evaluated as cubic illuminance with \cmd{rtrace}. See section \ref{sec:lightFlow} for details on using lightflow photon maps with \cmd{rtrace} and \cmd{pmapdump}. \item{\opt{-apD} \var{predistrib}}\\ Photon predistribution factor; this is the fraction of \var{nphotons} which are emitted in a distribution prepass in order to estimate the remaining number of photons to emit in the main pass to approximately yield a photon map of size \var{nphotons}. Setting this too high may yield more than \var{nphotons} in the initial pass with highly reflective geometry. Note that this value may exceed 1, which may be useful if the resulting photon map size greatly deviates from \var{nphotons} with a very low average reflectance. \item{\opt{-aph} \var{mod}}\\ Defines all polygons using the material modifier \var{mod} as part of a polyhedral region of interest (ROI). Photons will only be stored within the volume enclosed by these surfaces. Multiple instances of this option may be specified with cumulative effect to aggregate surfaces into a polyhedron. An error is issued if the identified geometry is not polygonal. However, no check is made to ensure the polyhedron is closed and not degenerated (particularly due to overlapping polygons) -- this is the user's responsibility. This option is useful to constrain photons to only lie in relevant regions of a scene, but may increase the photon distribution time. Beware that this option may lead to biased results. See section \ref{sec:roi} for details and caveats on using ROIs. \item{\opt{-apH} \var{modfile}}\\ Reads modifiers comprising polyhedral regions of interest (ROIs) from \var{modfile}, separated by whitespace. This is convenient to group modifiers per ROI if the geometry is complex and uses multiple materials. See option \opt{-aph} for details and caveats on using polyhedral ROIs. \item{\opt{-api} \var{min_x} \var{min_y} \var{min_z} \var{max_x} \var{max_y} \var{max_z} }\\ Defines an axis-aligned rectangular region of interest (ROI) within which to store photons exclusively; photons will only be stored within the volume bounded by the given minimum and maximum coordinates. Multiple instances of this option may be specified with cumulative effect to define compound ROIs. This option is useful to constrain photons to only lie in relevant regions of a scene, but may increase the photon distribution time. Beware that this option may lead to biased results. See section \ref{sec:roi} for details and caveats on using ROIs. \item{\opt{-apI} \var{pos_x} \var{pos_y} \var{pos_z} \var{rad}}\\ Similar to \opt{-api}, but with a spherical region of interest of given radius, centred at the given coordinates. See caveats there. \item{\opt{-apm} \var{maxbounce}}\\ This option is synonymous with \opt{-lr} for backwards compatibility, and may be removed in future releases. \item{\opt{-apM} \var{maxprepass}}\\ Maximum number of iterations of the distribution prepass before terminating if some photon maps are still empty. This option is rarely needed as an aborted prepass indicates an anomaly in the geometry or an incompatibility with the specified photon map types. \item{\opt{-apo}[\lit{+}$|$\lit{-}$|$\lit{0}] \var{portmod}}\\ Specifies a modifier \var{portmod} to act as a photon port. All objects using this modifier will emit photons directly in lieu of any distant light sources defined with the \lit{source} material. This greatly accelerates photon distribution in scenes where photons have to enter a space which separates them from the emitting light source via an aperture (e.g. fenestration, skylight) acting as a port. In a typical daylight simulation scenario, a fenestration acts as a port to admit photons into an interior after emission from sky and solar sources. See section \ref{sec:ports} for details on using photon ports. Multiple instances of this option may be specified. By default, ports are oriented to emit from their front side, as defined by their surface normal. This can be overridden by specifying a trivalent suffix as follows: \begin{description} \item[\lit{+}\,:] forward emission; this is equivalent to the abovementioned default behaviour, \item[\lit{-}\,:] backward emission; the port is reversed and photons are emitted from the back side. \item[\lit{0}\,:] bidirectional emission; photons are emitted from both sides of the port. \end{description} Typical situations that call for a reversed photon port include, for example: \begin{itemize} \item Using fenestrations as ports that were (for whatever reason) defined with outward facing normals, without having to revise the model, \item Using a \lit{mist} primitive as a port, since this requires outward facing normals in order to register the photons as having entered the volume. \item Reorienting a port associated with a \lit{bsdf} modifier, since inverting its normal would also reorient the BSDF and alter its behaviour. \end{itemize} Other oddball scenarios are conceivable. If in doubt, specify a bidirectional port orientation for a slight performance penalty, as photon emission is attempted from both sides. For well-defined port geometry with inward-facing normals, just use the default; doan' mess with da normalz. Photon port geometry is discretised according to the \opt{-dp} and \opt{-ds} options. These parameters aid in resolving spatially and directionally varying illuminance received by the port from distant light sources, e.g due to partial occlusion or when using climate-based sky models. \item{\opt{-apO}[\lit{+}$|$\lit{-}$|$\lit{0}] \var{portfile}}\\ Read photon port modifiers from the file \var{portfile}, separated by whitespace, as a more convenient alternative to multiple instances of \opt{-apo}. The specified orientation is applied to all modifiers in the file. \item{\opt{-apP} \var{precomp}}\\ Photon precomputation factor; this is the fraction of \var{nphotons} global or contribution photons to precompute, in the range $]0,1]$, when using the \opt{-app} resp. \opt{-apC} options. The remaining photons are discarded. See sections \ref{sec:precomp} and \ref{sec:lsContribs} for details on using precomputed global resp. contribution photons. \item{\opt{-apr} \var{seed}}\\ Seed for the random number generator. This is useful for generating different photon distributions for the same octree and photon map size, notably in progressive applications. \item{\opt{-aps}[\lit{+}$|$\lit{-}$|$\lit{0}] \var{sensmod}}\\ Specifies a modifier \var{sensmod} defined as \lit{antimatter} material to act as a virtual (i.e. invisible) sensor surface. Photons will be deposited on all surfaces using this modifier, just like regular materials, but will then be transferred through the surface without undergoing scattering; the surface therefore does not affect the light transport and simply acts as an invisible photon receiver. Note that \cmd{mkpmap} reports an error if the specified modifier is not an \lit{antimatter} material. This is useful when photon irradiance is to be evaluated at points which do not lie on regular geometry, e.g. at workplane height with \cmd{rtrace}'s \opt{-I} option. Without this workaround, photons would be collected from parallel but distant planes, leading to underestimation. By default, virtual sensors are oriented to deposit photons incident from their front side, as defined by their surface normal. This can be overridden by specifying a trivalent suffix as follows: \begin{description} \item[\lit{+}\,:] Forward orientation; this is equivalent to the abovementioned default behaviour. \item[\lit{-}\,:] Backward orientation; the sensor is reversed and only receives photons incident from the back. \item[\lit{0}\,:] Bidirectional orientation; the sensor receives photons from both sides. \end{description} See \autoref{fig:roi} for an example of a sensor surface in action. \item{\opt{-apS}[\lit{+}$|$\lit{-}$|$\lit{0}] \var{sensfile}}\\ Read virtual sensor surface modifiers from the file \var{sensfile}, separated by whitespace, as a more convenient alternative to multiple instances of \opt{-aps}. The specified orientation is applied to all modifiers in the file. \item{\opt{-ae} \var{excmod}}\\ Add \var{excmod} to the ambient exclude list, so that it will be ignored by the photon map. Objects having \var{excmod} as their modifier will not have photons deposited on them. Multiple modifiers may be given, each as separate instances of this option. \item{\opt{-aE} \var{excfile}}\\ Same as \opt{-ae}, except modifiers to be excluded are read from \var{excfile}, separated by whitespace. \item{\opt{-ai} \var{incmod}}\\ Add \var{incmod} to the ambient include list, so that it will contribute to the photon map. Only objects having \var{incmod} as their modifier will have photons deposited on them. Multiple modifiersmay be given, each as separate instances of this option. Note that the ambient include and exclude options are mutually exclusive. \item{\opt{-aI} \var{incfile}}\\ Same as \opt{-ai}, except modifiers to be included are read from \var{incfile}, separated by whitespace. \item{\opt{-am} \var{maxdist}}\\ Maximum search radius for precomputed photon lookups. in conjunction with the \opt{-app} or \opt{-apC} options. See the discussion of \opt{-am} in section \ref{sec:rpictArgs} for details. \item{\opt{-bn} \var{nbins} \footnoteref{note:contrib}}\\ Set the number of bins for precomputed contribution photons in conjunction with the \opt{apC} option to \var{nbins}. Analogous to \cmd{rcontrib}, the bins discretise the hemisphere of incident directions of contributions in the vicinity of each precomputed photon. Each bin covers a range of incident directions using the Shirley-Chiu disk-to-square mapping \cite{Shir1997}, whose orientation can be defined with the \opt{-e} option. This mapping is hardwired for precomputed contribution photons, and cannot be changed. Effectively, \var{nbins} specifies the mapping resolution. The number of bins \var{nbins} must be an integer squared $\left(\lfloor\sqrt{nbins}\rfloor\right)^2$, otherwise it will be automatically rounded to the nearest such value. If \opt{-bn} isn't specified, the default number of bins is 1, in which case binning is disabled, and each photon carries the integrated contributions from all directions. The binning is effective for the next contribution modifier specified with the \opt{-m} option (q.v.). See also the discussion on binning in \cmd{rcontrib}'s manpage. \item{\opt{-bv}[\lit{+}$|$\lit{-}]}\\ Toggles backface visibility; enabling this causes photons to be stored and possibly scattered if they strike the back of a surface, otherwise they are unconditionally absorbed and discarded. \item{\opt{-dp} \var{sampleres}}\\ Angular resolution for sampling the spatial emission distribution of a modified light source or photon port (e.g. via \lit{brightfunc}), in samples per steradian. This determines the accuracy of the numerical integration of the flux emitted by the source or port, and may need to be increased with complex distributions in combination with caustics. \item{\opt{-ds} \var{partsize}}\\ Light source partition size ratio; this determines the spatial resolution for photon emission from local light sources (or photon ports in case of distant sources). A light source or photon port is spatially partitioned to distribute the photon emission over its surface. This parameter specifies the ratio of the size (per dimension) of each partition to the scene cube extent, and may need to be reduced for modified light sources with high spatial variance, or for partially occluded photon ports. \item{\opt{-e} \var{expr} \footnoteref{note:contrib}}\\ Parse expression \var{expr} to globally initialise binning variables for all contribution modifiers in conjunction with the \opt{-apC} option. For a list of relevant variables, see option \opt{-p} below. \item{\opt{-ef} \var{diagfile}}\\ Redirect diagnostics and progress reports to \var{diagfile} instead of the console. \item{\opt{-fo}[\lit{+}$|$\lit{-}]}\\ Toggles overwriting of output files. By default, \cmd{mkpmap} will not overwrite an already existing photon map file. This is to prevent inadvertently destroying the results of potentially lengthy photon mapping runs. \item{\opt{-ld} \var{maxdist}}\\ Limits cumulative distance travelled by a photon along its path to \var{maxdist}. Photon hits within this distance will be stored, and the photon is terminated once its path length exceeds this limit. This is useful for setting radial regions of interest around emitting/reflecting geometry, but may increase the photon map generation times and yield biased results in regions beyond \var{maxdist}. Discretion is advised. \item{\opt{-lr} \var{maxbounce}}\\ Maximum number of bounces (scattering events) for a photon path before being considered ``runaway'' and terminated. Photons paths are normally terminated via Russian Roulette, depending on their albedo. With unrealistically high albedos, this is not guaranteed, and this option imposes a hard limit to avoid an infinite loop. \item{\opt{-m} \var{mod} \footnoteref{note:contrib}}\\ Include modifier \var{mod} in the precomputed contribution photon map in conjunction with the \opt{-apC} option. This must be a light source modifier, as photons can only carry contributions from their emitting light sources; an error is issued if this is not the case. The most recent binning options \opt{-bn} and \opt{-p} apply to this modifier, and can be individually specified for subsequent modifiers. \item{\opt{-M} \var{modfile} \footnoteref{note:contrib}}\\ Similar to \opt{-m}, but load a list of contribution modifiers from \var{modfile}. The most recent instances of binning parameters \opt{-bn} and \opt{-p} are applied to all modifiers. \item{\opt{-ma} \var{ralb} \var{galb} \var{balb}}\\ Set the global scattering albedo for participating media in conjunction with the \opt{-apv} option. See the \cmd{rpict} documentation for details. \item{\opt{-me} \var{rext} \var{gext} \var{bext}}\\ Set the global extinction coefficient for participating media in conjunction with the \opt{-apv} option. See the \cmd{rpict} documentation for details. \item{\opt{-mg} \var{gecc}}\\ Set the global scattering eccentricity for participating media in conjunction with the \opt{-apv} option. See the \cmd{rpict} documentation for details. \item{\opt{-n} \var{nproc} \footnote{Multiprocessing is currently not available on M\$ Wind0z {\tiny (So tuff luck)}, as it doesn't support \radiance's process-based (as opposed to thread-based) parallelism using the \textit{fork()} syscall. The photon mapping implementation conforms to this convention, although POSIX threads would now clearly be the preferred and portable approach. } }\\ Use \var{nproc} processes for parallel photon distribution. There is no benefit in specifying more than the number of physical CPU cores available (so doan' even try). \item{\opt{-p} \var{var_1=val_1,\ var_2=val_2,\ \ldots} \footnoteref{note:contrib} }\\ Define per-modifier parameters \var{var_1,\ var_2,\ \ldots} for the Shirley-Chiu mapping used to bin precomputed contribution photons in conjunction with the \opt{-apC} option. These parameters apply to the next contribution modifier specified with the \opt{-m} option, and can be individually redefined for subsequent modifiers. The companion option \opt{-e} can be used to set global parameters for all modifiers. The following variables can be set to define the mapping orientation: \begin{itemize} \item{\textit{RHS}}: 1 for right-handed coordinate system (default), -1 for left-handed. \item{\textit{rNx, rNy, rNz}}: surface normal (defines $\theta = 0$, default [0, 0, 1]) \item{\textit{Ux, Uy, Uz}}: up vector (defines $\phi = 0$, default [0, 1, 0]) \end{itemize} See also this option's discussion in \cmd{rcontrib}'s manpage. \item{\opt{-t} \var{sec}}\\ Output a progress report every \var{sec} seconds. See section \ref{sec:mkpmap.report}. \item{\opt{-v}[\lit{+}$|$\lit{-}]}\\ Boolean option to control \cmd{mkpmap}'s console output. If disabled (the default), the output is terse, except for warnings and errors. If enabled, the output is verbose, and includes information on distribution prepasses, photon ports, and light source partitioning. Verbose mode can generate excessive chatter and should only be used for diagnostic purposes, for example if \cmd{mkpmap} seemingly hangs (which can happen if many light source partitions need to be processed). It is a good idea to redirect verbose output with the \opt{-ef} option, since excessive console output will actually slow \cmd{mkpmap} down. \item{\opt{-V}[\lit{+}$|$\lit{-}] \footnoteref{note:contrib}}\\ Boolean option to precompute contributions (enabled) or normalised coefficients (disabled, the default) in conjunction with the \opt{-apC} option. See also this option's discussion in \cmd{rcontrib}'s manpage. \end{description} At least one of the \opt{-apg}, \opt{-apc}, \opt{-apv}, \opt{-apd}, \opt{-app} options (or \opt{-apC}, \opt{-apt}, \opt{-apT}, \opt{-apV}, if available~\footnoteref{note:contrib}~\footnoteref{note:transient}~% \footnoteref{note:lightflow}) must be specified. Most of these can be combined subject to compatibility with the materials used in the scene (an exception is the \opt{-apC} option, since contribution photons use a dedicated distribution algorithm. The \opt{-apC} option, in contrast, uses a different distribution algorithm and cannot be combined with the aforementioned; these will simply be ignored when generating a contribution photon map. \subsection{Examples} The following command generates a global photon map \lit{bonzo.gpm} and a caustic photon map \lit{bonzo.cpm} containing approximately 10000 and 100000 photons, respectively, with a progress report being issued every 5 seconds: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apg bonzo.gpm 10k -apc bonzo.cpm 100k -t 5 \ bonzo.oct \end{lstlisting} \end{minipage} \end{center} Generate a global photon map containing 80000 photons, then precompute the diffuse irradiance for 1/4 of these with a bandwidth of 40 photons: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -app bonzo-precomp.gpm 80k 40 -apP 0.25 bonzo.oct \end{lstlisting} \end{minipage} \end{center} Generate 1 million global photons by emitting them from external light sources of type \lit{source} into a reference room via a fenestration with modifier \lit{glazingMat} acting as photon port, with inward-facing normal: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apg refRoom.gpm 1m -apo glazingMat refRoom.oct \end{lstlisting} \end{minipage} \end{center} Generate 10 million contribution photons from all light sources with modifier \lit{bonzoLite}, precompute 1 million of these by accumulating the contributions from the 2600 nearest photons into 256 bins, and compress them by 75\%. Then accumulate these precomputed contributions for a grid of sensor positions in \cmd{rcontrib}. Note that the relevant binning parameters and modifiers are passed via the option file \lit{bonzo-contrib.Cpm.opt} (see also section \ref{sec:rcontribPmap} for details): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apC bonzo-contrib.Cpm 10m 2600 0.75 -apP 0.1 -bn 256 \ -m bonzoLite -V+ bonzo.oct rcontrib -ap bonzo-contrib.Cpm -o \%s.dat \ @@bonzo-contrib.Cpm.opt bonzo.oct < sensors.pos \end{lstlisting} \end{minipage} \end{center} Generate 10 million transient photons travelling at the approximate speed of light (in m/s, assuming the geometry in \lit{bonzo.oct} is in the same units): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apt bonzo-trans.tpm 10m 3e8 bonzo.oct \end{lstlisting} \end{minipage} \end{center} Generate 25 million "light flow" photons in a global participating medium with extinction 0.001 (note reduced predistribution factor to prevent overflow): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apV bonzo-flo.Vpm 25m -me 0.001 0.001 0.001 \ -apD 0.001 bonzo.oct \end{lstlisting} \end{minipage} \end{center} \clearpage \section{Rendering Photon Maps with \cmd{rpict}} The modified \cmd{rpict} rendering tool takes the photon map generated by \cmd{mkpmap} and performs photon lookups and density estimation. Without photon map functionality enabled, it behaves like \radClassic. \subsection{Caustic Photon Visualisation} \label{sec:causticviz} Caustic photons are visualised at points seen directly by the observer, or via specular reflections. Virtual light sources (normally enabled with the \lit{mirror} material) are disabled with the photon map, as the resulting caustics are already accounted for. Note that irradiance calculations with \cmd{rtrace} using caustic photons are surface bound; irradiance for points which do not lie on surfaces will therefore be biased. As a workaround, \cmd{mkpmap} offers the \opt{-aps} and \opt{-apS} options to specify an invisible receiver surface with \lit{antimatter} material for storing photons in the same plane as the sensor points. See section \ref{sec:mkpmap} for details. \subsection{Global Photon Visualisation} \label{sec:globalviz} Visualisation with a global photon map implies an ambient calculation, thus \cmd{rpict}'s \opt{-ab} option defaults to 1; this differs from the standard \radClassic behaviour, where the ambient calculation must be explicitly enabled. Global photon irradiance is visualised via an intermediate ambient bounce (commonly referred to as \emph{final gather} in the literature \cite{Chri2000}, see figure \ref{fig:visualisation}). This reduces noise in the density estimates from the ambient daughter rays, and the resulting ambient irradiance is cached and interpolated as in \radClassic, unless explicitly disabled with the \opt{-aa 0} option. \begin{figure}[tb] \centering \fbox{% \begin{minipage}{0.75\linewidth} \includegraphics[width=\linewidth]{visualisation} \parbox{\linewidth}{% \caption{% \label{fig:visualisation} Caustic photons are visualised at the primary ray, while an intermediate stratified sampling step is used between the primary ray and the global photon density estimate (\emph{final gather}). } } \end{minipage} } \end{figure} If the global photon irradiance was precomputed by \cmd{mkpmap} with the \opt{-app} option, the ambient daughter rays return the precomputed irradiance from the closest global photons. This improves performance noticeably at the expense of accuracy if the indirect irradiance changes rapidly, which is rarely the case with diffuse illumination. Specifying a negative number of ambient bounces \opt{-ab} enables a debugging mode which does not spawn any ambient rays, but directly visualises the global photon irradiance at the primary ray. This provides a very rough but fast preview of the global illumination solution contained in the photon map. Figure \ref{fig:precomp} is an example of a such a preview for a precomputed photon map. %Ambient values (specified with \opt{-av}) are ignored. ??? \subsection{Progress Report} \label{sec:rpict.report} Bias compensation statistics are provided in the progress report with the standard \opt{-t} option. The statistics for each photon type subject to bias compensation are reported as follows: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} $N_{min}$/$N_{max}$/$N_{avg}$ $ptype$, ($\epsilon_{min}$/$\epsilon_{max}$/$\epsilon_{rms}$ error) \end{lstlisting} \end{minipage} \end{center} where: \begin{itemize} \item \var{N_{min}}, \var{N_{max}} and \var{N_{avg}} is the minimum, maximum, and average number of photons used per density estimate, respectively \item \var{ptype} is one of \lit{global}, \lit{caustic}, \lit{volume}, or \lit{direct}. \item \var{\epsilon_{min}}, \var{\epsilon_{max}}, and \var{\epsilon_{rms}} is the minimum, maximum, and RMS (root mean square) estimated relative errors in the resulting irradiance, respectively. \end{itemize} Since bias cannot be determined without knowing the actual illumination, there is no reliable way of separating it from noise. As such, the error estimates are approximate and serve as a rough guide to judge the quality of the bias compensation. \subsection{Command Line Arguments for \cmd{rpict}} \label{sec:rpictArgs} The photon mapping backward pass is disabled by default and must be explicitly enabled using the \opt{-ap} option. The different photon map types may be renderered independently or in combination. Note that rendering only the global or caustic photon map does not take all light transport paths into consideration at the primary hitpoint. Since modifying the lights or geometry invalidates the photon map, a error is triggered if the octree is newer than the photon map, referring to the latter as ``stale''. In general, a physically valid simulation (assuming specular and diffuse materials) with the photon map is obtained with the following basic set of parameters: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap -apg $globalpmap$ $nphotons$ -apc $causticpmap$ $nphotons$ $octree$ rpict -ap $globalpmap$ $bwidth$ -ap $causticpmap$ $bwidth$ -ab 1 \ -vf $view$ $octree$ \end{lstlisting} \end{minipage} \end{center} As with \radClassic, the \opt{-ad}, \opt{-ar}, and \opt{-aa} parameters may need to be refined in some cases to improve the rendering quality and accuracy. Some parameters are adopted from \radClassic{} due to their assumed familiarity to the user, and have similar semantics in the context of photon mapping. The \cmd{rpict} photon mapping options are as follows: \begin{description} \item{\opt{-ab} \var{nbounces}}\\ This value defaults to 1 in photon mapping mode (see \opt{-ap} below), implying that global photon irradiance is always computed via one ambient bounce; this behaviour applies to any positive number of ambient bounces, regardless of the actual value specified. A negative value enables a preview mode that directly visualises the irradiance from the global photon map without any ambient bounces. This is intended for debugging and checking the irradiance distribution, as the quality of the resulting renderings is generally poor with sparsely distributed photons. If the global photons are precomputed, this produces a Voronoi diagram. As with \radClassic{}, setting this to 0 disables the ambient component, but caustic photon irradiance is still visualised at the primary ray. \item{\opt{-ap} \var{pmapfile} \var{[bwidth_1} \var{[bwidth_2]]} \var{[time]} }\\ Enables photon mapping mode. Loads a photon map generated with \cmd{mkpmap} from \var{file}, and evaluates the indirect irradiance depending on the photon type (automagically detected) using density estimates with a bandwidth of \var{bwidth_1} photons, or the default bandwidth if none is specified (a warning will be issued in this case). Global photon irradiance is evaluated as part of the ambient calculation (see section \ref{sec:globalviz}), caustic photon irradiance is evaluated at primary rays (see section \ref{sec:causticviz}), and indirect inscattering in mist is accounted for by volume photons. Contribution photons are treated as global photons. Additionally specifying \var{bwidth_2} enables bias compensation for the density estimates with a minimum and maximum bandwidth of \var{bwidth_1} and \var{bwidth_2}, respectively. See section \ref{sec:biascomp} for details on how bias compensation works. Global photon irradiance may be optionally precomputed by \cmd{mkpmap} (see section \ref{sec:precomp}, in which case the bandwidth, if specified, is ignored, as the nearest photon is invariably looked up. Using direct photons replaces the direct calculation with density estimates for debugging and validation of photon emission. If \var{pmapfile} contains a transient photon map,\footnoteref{note:transient} the photon density estimate will cover the spatio-temporal domain in the vicinity of the specified time-of-flight \var{time}, expressed in seconds.\footnote{Internally, each photon's time-of-flight is represented by the corresponding path length (distance travelled), consequently the lookup is infact performed in the spatial domain, using a distance metric with consistent units. } The transient photons will be rendered at the given point in time subject to their velocity specified with the \opt{-apt} option when generating the photon map with \cmd{mkpmap}. \item{\opt{-am} \var{maxdist}}\\ Maximum search radius for photon map lookups. Without this option, an initial maximum search radius is estimated for each photon map from the average photon distance to the dis‐ tribution's centre of gravity. It is then adapted to the photon density in subsequent lookups. This option imposes a global fixed maximum search radius for all photon maps, thus defeating the automatic adaptation. It is useful when multiple warnings about short photon lookups are issued. Note that this option does not conflict with the bandwidth specified with the \opt{-ap} option; the number of photons found will not exceed the latter, but may be lower if the maximum search radius contains fewer photons, thus resulting in short lookups. Setting this radius too large, on the other hand, may degrade performance. This setting applies to \emph{all} photon maps specified with \opt{-ap}. \item{\opt{-ac} \var{pagesize} \footnote{Out-of-core photon mapping is not enabled in the default build. In addition, it is currently not supported on Windows. On platforms that do support it, out-of-core storage must be enabled at compile time with \opt{-DPMAP\_OOC}. To verify if your build supports out-of-core photon mapping, check if the caching options \opt{-ac} and \opt{-aC} appear in the output of \cmd{rpict -help}. \label{note:ooc} } }\\ Set the photon cache page size. The photon cache reduces disk I/O incurred by on-demand loading (paging) of photons, and thus increases performance. This is expressed as a (float) multiple of the density estimate bandwidth specified with \opt{-ap} under the assumption that photon lookups are local to a cache page. Cache performance is sensitive to this parameter: larger pagesizes will reduce the paging frequency at the expense of higher latency when paging does occur. Sensible values are in the range 4 (default) to 16. \item{\opt{-aC} \var{cachesize} \footnoteref{note:ooc}}\\ Set the total number of photons cached when using out-of-core photon mapping, taking into account the pagesize specified by \opt{-ac}. Note that this is approximate as the number of cache pages is rounded to the nearest prime. This allows adapting the cache to the available physical memory. In conjunction with the \opt{-n} option, this is the cache size per parallel process. Cache performance is less sensitive to this parameter, and reasonable performance can obtained with as few as 10k photons. The default is 1M. This option recognises multiplier suffixes (k = $10^3$, M = $10^6$), both in upper and lower case. \item{\opt{-aH}[\lit{+}$|$\lit{-}]} \footnoteref{note:lightflow}\\ Boolean switch to enable hemisherical lookups for lightflow photons. See section \ref{sec:altLightFlowIllum} for details. \item{\opt{-aS}[\lit{+}$|$\lit{-}]} \footnoteref{note:lightflow}\\ Boolean switch to calculate mean spherical, instead of cubic, irradiance from lightflow photons. See section \ref{sec:altLightFlowIllum} for details. \end{description} \subsection{Examples} To render ambient illuminance with a global photon map \lit{global.pm} via one ambient bounce, and from a caustic photon map \lit{caustic.pm}, using a bandwidth of 50 photons for each: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} rpict -ab 1 -ap global.pm 50 -ap caustic.pm 50 \ -vf scene.vf scene.oct > scene.hdr \end{lstlisting} \end{minipage} \end{center} To render transient luminance at 60 nanoseconds after photon emission using a transient photon map (see option \opt{-apt} in section \ref{sec:mkpmapArgs}): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} rpict -ap bonzo-trans.tpm 50 6e-8 -ab -1 -vf scene.vf \ scene.oct > scene.hdr \end{lstlisting} \end{minipage} \end{center} Note the use of \opt{-ab -1} in the above example to bypass \radiance{}'s ambient calculation, since the latter can only render the steady-state illumination! See section \ref{sec:transient} for further details on transient rendering. \clearpage \section{% Precomputed Contribution Photon Mapping (Experimental)% \footnoteref{note:contrib} } \label{sec:lsContribs} The \radiance{} photon map supported the computation of light source contributions for annual and climate-based daylight simulation since 2015 \cite{Schr2015}. In this workflow, the scene supplied to \cmd{mkpmap} contains multiple light sources representing either different time-dependent positions (sun positions depending on season and time of day) or sky ``patches'' corresponding to disrete regions in the sky dome modified by seasonal cloud cover (for example from climate-based luminance distributions). All source contributions are aggregated in one efficient simulation. Unlike \cmd{rcontrib}, the photon map only supports contributions from light sources, not arbitrary modifiers, and specifying a non-source modifier results in an error. The \cmd{rcontrib} tool supplied with \radiance{} can determine the irradiance for each sun position or sky patch for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by accumulating the resulting contributions into separate output files for each light source, and optionally into individual ``bins'' that disretise the hemipshere of incident directions at the photons' initial hitpoints immediately after emission (see the \cmd{rcontrib} man page for details on binning fundamentals). The original contribution photon mapping implementation has been revised to precompute contributions and store them in pre-assigned bins, which are stored along with the photons in compressed form by \cmd{mkpmap}. The expense of precomputation is amortised through a caching scheme and multiple evaluations by \cmd{rcontrib} in a (more or less dense) grid of sensor positions. This implies that binning parameters are static and already determined when the photon map is generated with \cmd{mkpmap}. This in turn implies a loss of flexibility over the previous implementation, which binned photons dynamically in \cmd{rcontrib}, although in practice the binning resolution is rarely changed. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.90\linewidth} \centering \includegraphics[width=0.8\linewidth]{shirley-chiu2-crop}\\ \parbox{\linewidth}{% \caption{% \label{fig:shirleyChiu} Shirley-Chiu disk-to-square mapping used to ``bin'' contribution photon directions at their primary hitpoints. This mapping has the desirable (for binning) property of preserving adjacency and fractional area. The disk is obtained by projecting the hemisphere of incident directions on the receiving plane defined by the mapping's normal. } } \end{minipage} } \end{figure} In addition, the binning function used by \cmd{mkpmap} is now ``hardwired'' to the Shirley-Chiu disk-to-square mapping \cite{Shir1997}, which maps the hemisphere of incident directions to a square which is equally subdivided into the specified number of bins in both dimensions (see figure \ref{fig:shirleyChiu}). Thus, the user cannot specify an arbitrary mapping function as with \cmd{rcontrib}. This is justified as the square topology is required for the subsequent compression (see below) as compared to a zonal binning such as Tregenza or Reinhart, where the azimuthal resolution depends on the elevation angle. The mapped disk is obtained by projecting the hemisphere of incident directions on the receiving plane defined by the mapping's normal, while the azimuthal angle $\Phi$ = 0 is defined by the mapping's up vector (see options \opt{-e} and \opt{-p} in section \ref{sec:mkpmapArgs}). With contribution photon mapping, the modifiers and binning parameters are passed to \cmd{mkpmap} instead of \cmd{rcontrib} using the usual options \opt{-m}, \opt{-bn}. In addition, global and per-modifier variables to set the orientation of the binning function may be specified with the usual options \opt{-e} resp. \opt{-p} (see the discussion of these options in section \ref{sec:mkpmapArgs}). In this respect, \cmd{mkpmap} behaves similarly to \cmd{rcontrib}. Likewise, ray coefficients are supported by \cmd{mkpmap} via the usual \opt{-V-} option, which amounts to normalising the emission of each light source. However, this option cannot be reverted in \cmd{rcontrib} when the photon map is loaded, and the option, if specified, will be overridden in this case. The number of bins specified with \opt{-bn} must be an integer square for the Shirley-Chiu mapping, and will be rounded to the nearest such number by \cmd{mkpmap} if necessary. In support of light source contributions, \cmd{mkpmap} uses a modified photon distribution algorithm via the \opt{-apC} option that ensures each light source contributes approximately the same number of photons, irrespective of its emitted flux. To compensate and maintain energy balance, the flux of each photon is adjusted accordingly, which can raise the variance of the resulting contributions. The generated photon map \var{pmapfile} contains a set of child photon maps for each specified modifier \var{mod}. Each child photon map (stored in a subdirectory \lit{.rc/} in turn contains the photons emitted by light sources using this modifier. The photons are stored out-of-core in a file \lit{.rc/.leaf} and paged on demand by \cmd{rcontrib}, as with regular (global, caustic etc.) photons. In addition, the binned and compressed contributions are stored in a separate file \lit{.rc/.wvt}. An overview of this workflow with the inner workings of both \cmd{mkpmap} and \cmd{rcontrib} is shown in figure \ref{fig:contribOverview}. Once the photons are distributed, a fraction of them is precomputed. As with the precomputed global photon map, this precomputation factor is specified with the \opt{-apP} option. A nearest neighbour search using the bandwidth specified with the \opt{-apC} option is performed in the neighbourhood of each precomputed photon, and the contributions from each found photon \emph{emitted from the same light source modifier} is accumulated for the precomputed photon in the specified number of bins. If the bandwidth specified for precomputation is less than the number of bins, a warning is issued, since some bins will be zero. As a rule of thumb the bandwidth should be a multiple of the number of bins, which in practice leads to large bandwidths (though bias is distributed over the bins in this case). \subsection{Wavelet Compression of Contributions} The binned contributions for each precomputed photon can be compressed to manage the size of the out-of-core contribution files, which can easily exceed the terabyte range (assuming the underlying filesystem even supports such sizes). To this end, \cmd{mkpmap}'s \opt{-apC} option expects also a compression ratio \var{comp} in the range [0,1], which specifies the space savings, where 0 implies no compression at all. This compression ratio applies to all photons and all modifiers. The contribution photon map uses a wavelet compression scheme, whereby the binned contributions for each photon map are projected onto biorthogonal basis functions (wavelets) and decomposed into a set of corresponding coefficients. The binned contributions are represented as a 2D matrix (the Shirley-Chiu square) and decomposed into coefficients along both axes. The coefficients consist of a set that act as low pass filters (approximations) and a second set the act as high pass filter (details). The latter set is much larger and therefore subject to compression. The contribution photon map uses a Daubechies DB2 wavelet function\footnote{\url{http://wavelets.pybytes.com/wavelet/db2}} with a support of 4 neighbouring samples (see crazy squiggles in figure \ref{fig:daubechies}). This popular wavelet function offers an acceptable compromise between compression and computational expense (as its support is limited to four neighbouring samples). The wavelet transform is similar to the Fourier transform in that it decorellates the input signal (in this case the 2-dimensional matrix of binned contributions) in both the spatial and frequency domains. This means that detail coefficients will be low in regions where the signal exhibits periodic behaviour, and at various intervals (corresponding to frequency bands). \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.905\linewidth} \centering \includegraphics[width=0.7\linewidth]{Daubechies4-functions}\\ \parbox{\linewidth}{% \caption{% \label{fig:daubechies} Daubechies DB2 biorthogonal wavelet functions with a support of 4 neighbouring samples (or ``taps''). The red wavelet function decomposes the samples into detail (high frequency) coefficients, while the blue scaling function (itself derived from, and orthogonal to, the wavelet) decomposes the samples into approximation (low frequency) coefficients. What this stuff looks like in 2D is left up to the reader's imagination... } } \end{minipage} } \end{figure} \begin{figure}[p] \fbox{% \begin{minipage}{\linewidth} \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{% cpmapTest-64m-bn256-3200-comp0.5% }\\ Compression 0.5 \end{minipage} \hfill \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{% cpmapTest-64m-bn256-3200-comp0.6% }\\ Compression 0.6 \end{minipage}\\[3mm] \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{% cpmapTest-64m-bn256-3200-comp0.7% }\\ Compression 0.7 \end{minipage} \hfill \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{% cpmapTest-64m-bn256-3200-comp0.8% }\\ Compression 0.8 \end{minipage}\\[3mm] \centering \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{% cpmapTest-64m-bn256-3200-comp0.9% }\\ Compression 0.9 \end{minipage}\\[3mm] \parbox{\linewidth}{% \caption{% \label{fig:contribCompression} 3D plots of contributions calculated by \radClassic{} (blue) and photon map (red) from annual sun positions in 256 bins. The contributions are accumulated for an interior floor sensor located in a simple square test room symmetrically lit from fenestrations facing east and west. The contribution photon map was compressed with ratios of 0.5 to 0.9. In this example, compression artefacts appear at the boundaries (corresponding to the horizon) with 80\% compression and above. This is a known limitation of wavelet compression if the input signal exhibits high gradients at the boundary. } } \end{minipage} } \end{figure} However, unlike the Fourier basis functions $\sin$ and $\cos$, wavelets have a finite support (the 4 neighbouring samples in case of DB2), which does not lead to ripple artefacts exbhibited by the Fourier and cosine transforms (the latter used in the JPEG image format, for example). This desirable property, together with the ability to decorellate the signal in discrete frequency bans, enables wavelets to preserve localised peaks in the input signal even at high compression ratios. Like Fourier, the ability to analyse signals at various frequencies makes wavelets suitable for applications in filter banks. Wavelet compression is realised by thresholding the \var{100 \cdot comp}\% smallest detail coefficients (implicitly setting them to zero without actually saving them), under the assumption they are negligible for the reconstructed signal as a whole. \textbf{This means wavelet compression is \underline{lossy} and may introduce artefacts in the high frequency content of the reconstructed contributions}. There is currently no mechanism in place to limit these artefacts, and the choice of an approriate compression ratio is left up the user's judgement (and his/her experience). In general, a compression ratio of 0.6--0.7 can be considered relatively ``safe'', while ratios of 0.8 or above should be used for sky contributions only (exluding solar ones), since these typically exhibit low gradients. Since the compression ratio is fixed, so is the number of resulting compressed coefficients. While an adaptive number of thresholded coefficients would reduce compression artefacts, a fixed number of thresholded coefficients substantially reduces overhead when accessing contribution records in the out-of-core contribution file (which actually contains the thresholded wavelet coefficients). The number of wavelet coefficients (and indirectly, the number of bins) that can be compressed is limited by the wavelet matrix indices that are saved along with the remaining coefficients after thresholding. These indices are compactly encoded with a differential scheme and embedded with the coefficients themselves. This differential encoding can overflow if the remaining coefficients become too sparse, particularly for large numbers of bins and high compression ratios. This overflow cannot be predicted as it depends on the distribution of thresholded coefficients, which in turn depends on the frequency content and energy distribution of the contributions. However, \cmd{mkpmap} will issue a warning before precomputing contributions if the encoding \emph{may} overflow for the given number of bins. \subsection{Evaluating Precomputed Contributions with \cmd{rcontrib}} \label{sec:rcontribPmap} The precomputed contribution photon map is loaded in \cmd{rcontrib} with the usual \opt{-ap} option, and the precomputed contributions from the nearest photon to each specified sensor position are accumulated, in the specified number of bins. If the photon map contains precomputed contributions as opposed to coefficients (toggled via the boolean option \cmd{-V}), this setting will be automatically overriden in \cmd{rcontrib}, accompanied by a corresponding warning. The binning parameters passed to \cmd{rcontrib} must agree with those used to generate the photon map. This is necessary in particular to correctly bin primary and specular rays incident on the sensors, as these are not precomputed by the photon map. Because \cmd{rcontrib} allocates its bins and output streams on-the-fly, i.e. as it parses its command line arguments, they cannot be overriden when the photon map is subsequently loaded (at which point its binning parameters are actually known)\footnote{Well, at least they can't be overridden without disastrous side-effects which would make Don Gregorio very angry... \textbf{;\^{})}}. Consequently, \cmd{mkpmap} dumps its relevant binning parameters and modifiers to an option file, named after the photon map with an \lit{.opt} suffix. This file must be passed to \cmd{rcontrib} via its \cmd{@@} option to ensure its binning is consistent with that of the precomputed contributions in the photon map. \cmd{rcontrib} will report an error if the bin count (defaulting to 1 if omitted) doesn't match the photon map's, and suggest using the option file. When using the option file, it is not necessary to specify the modifiers with the \opt{-m} option, as these are already included in the file. The user may edit the option file to set per-modifier output streams if necessary. \subsection{Examples} \label{sec:contribExamples} A typical invocation of the \radiance{} photon map with light source contributions consists of the following: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap -apC bonzo.Cpm 50m 2500 0.75 -apP 0.1 -bn 256 -m bonzoLite \ -V+ bonzo.oct rcontrib -ap bonzo.Cpm -o %s-contrib.dat @@bonzo.Cpm.opt \ bonzo.oct < sensors.pos \end{lstlisting} \end{minipage} \end{center} where \lit{bonzoLite} is the light source modifier to bin, and \lit{sensors.pos} is a file containing a list of sensor positions as input for the irradiance calculation. The contributions are output to a separate file for each modifer (in this case just \lit{bonzoLite-contrib.dat}). Note that \cmd{mkpmap} also generates the option file \lit{bonzo.Cpm.opt}, which is passed to \cmd{rcontrib} to ensure its binning and modifier options are consistent with those precomputed in the photon map. An example of a visual analysis of a redirecting component for a half year using contribution photons is shown in figure \ref{fig:koester-luxtherm-half}. The performance of the system (consisting of retroreflecting blinds) can be assessed subject to seasonal daylight availability. Redirection towards the ceiling is evident particularly from January to April. Transmission, on the other hand, occurs at low solar angles until March, before transitioning into retroreflection at high solar angles. \begin{figure}[p] %\centering \fbox{% \begin{minipage}{\linewidth} \includegraphics[width=\linewidth]{koester-luxtherm-half} \parbox{\linewidth}{% \caption{% \label{fig:koester-luxtherm-half} Retroreflecting blinds at 26 solar angles for a half year (January to June, in weekly intervals) rendered with contribution photon map and \cmd{rcontrib}. In each instance the time of day is 1:00pm. Redirection and transmission dominate until March, while retroreflection dominates in the following months. } } \end{minipage} } \end{figure} \newgeometry{left = 1cm, right = 1cm, top = 1cm, bottom = 2cm} \begin{figure}[p] \fbox{% \begin{minipage}{\linewidth} \includegraphics[width=\linewidth]{contribpmap-overview2-crop} \parbox{\linewidth}{% \caption{% \label{fig:contribOverview} Overview of contribution photon mapping workflow. Green paths denote inputs (parameters and sensor positions), while red paths denote output. Light source contributions for modifier \var{mod} are binned using an \var{nbins^2} Shirley-Chiu disk-to-square mapping, and wavelet compressed for a fraction \var{precomp} of photons by \cmd{mkpmap}. These contributions are saved along with the corresponding photons in separate files for each modifier, grouped in a subdirectory under the parent photonmap \var{pmapfile}. The photons and their precomputed contributions are subsequently paged on demand, uncompressed, and cached by \cmd{rcontrib}, which passes the contributions to the standard contribution calculation used by \radClassic{}. } } \end{minipage} } \end{figure} \restoregeometry \clearpage \section{% Lightflow Photon Mapping (Experimental)% \footnoteref{note:lightflow} } \label{sec:lightFlow} ``Lightflow'' is an experimental method for architectural lighting design and research to analyse the ``flow'' of light based on volume photon mapping. Unlike surface-bound global or caustic photons, lightflow photons represent the lighting distribution in abritrary space, much like a light field, as it can convey directional illuminance \cite{Schr2021a, Yosh2022}. As a precondition, the space must be enveloped by a participating medium (i.e. global or locally defined \lit{mist}). Lightflow photons are a specialised variant of volume photons which are not scatter in participating media. When a lightflow photon map is generated, participating media implicitly have an albedo $\alpha$ and scattering eccentricity $g$ of 1 (i.e. no absorption and forward scattering, respectively, see figure \ref{fig:lightFlowDistrib}). Consequently, the photons are deposited within the medium, but their paths are not altered. The density of the deposited photons along each path is controlled by the coefficient of extinction $\sigma_t$, and is considered a free parameter here. Because the extinction alters the photon density, it also affects the illuminance obtained from the photons, consequently the photon flux $\Delta\Phi_p$ is automatically scaled by $1 / \sigma_t$ in lightflow mode to compensate. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.9\linewidth} \centering \includegraphics[width=0.8\linewidth]{isoscatter4-crop} \flushright{% \includegraphics[width=0.7565\linewidth]{noscatter2-crop} } \\ \parbox{\linewidth}{% \caption{% \label{fig:lightFlowDistrib} Top: Volume photons (red spheres) interact with particles (white spheres) in participating media, and are scattered with probability $\alpha$ (corresponding to the albedo), and with a directional distribution determined by the eccentricity $g$.\\ Bottom: lightflow photons are neither absorbed nor scattered (or forward scattered) by the medium, and consequently their paths are not altered, corresponding to an albedo and eccentricity of 1.\\ In both cases, the extinction $\sigma_t$ determines the mean free distance $\bar{s}$ of the photon between interactions, and therefore the density with which they are deposited in the medium. } } \end{minipage} } \end{figure} The extinction is a critical parameter in lightflow mode, as it has a strong influence on the photon distribution and the resulting evaluation. Generally, this parameter should be kept as low as possible, but this prolongs photon distribution with \cmd{mkpmap}, as more photon paths need to be generated. On the other hand, if the extinction parameter is too large, the resulting cubic illuminance (see section \ref{sec:cubicIllum}) becomes severely biased. This bias is due to linear clustering of photons along their paths, and is visually evident in the photon distribution (see figure \ref{fig:lightFlowKaze}). This phenomenon is well known with ill-posed mathematical models of participating media and referred to as the \textit{ray effect} \cite{Lath1968}. As a general rule, an extinction of $\sigma_t = 0.001$ would be a reasonable starting value for most scenes. There is an additional caveat with using higher extinction values, namely that the two-pass photon distribution algorithm used by \cmd{mkpmap} to achieve the target number of photons may fail. The default fraction of photons emitted in the 1st pass (prepass) of \cmd{mkpmap} is tuned for well-behaved geometry and materials using global or caustic photons. This predistribution factor (see option \opt{-apD} in section~\ref{sec:mkpmapArgs}) may be too high for volume photons in a dense participating medium, and the photon distribution overflows in the prepass with a ``photon map overflow'' error, meaning that the target photon count was already exceeded. When using lightflow photons, the predistribution factor may consequently need to be reduced from its default if the prepass overflows. \subsection{Cubic Illuminance from Lightflow Photons} \label{sec:cubicIllum} Lightflow photons can be used to analyse how light propagates in space. In a quantitative analysis in particular, \cmd{rtace} can evaluate \textit{cubic illuminance} \cite{Cutt2014} at given sensor positions. This illuminance metric is originally intended to conveniently measure a lightfield using six measurements aligned with the three orthogonal axes passing through the faces of a cube, in positive and negative directions (see figure \ref{fig:cubicIllum}); this approximates the mean spherical illuminance. (The orientation of the cube in world coordinates may be arbitrary). The resulting six illuminance readings $E_i$ can be aggregated into a vector and reduced to scalar values that express both the symmetric and directional (vector) components of the illuminance: \begin{eqnarray} \vec{E} &=& \begin{bmatrix} E_{+u} - E_{-u} \\ E_{+v} - E_{-v} \\ E_{+w} - E_{-w} \end{bmatrix} \label{eq:vectorIllum} \\ \vec{E}^\sim &=& \begin{bmatrix} E_{+u} + E_{-u} \\ E_{+v} + E_{-v} \\ E_{+w} + E_{-w} \end{bmatrix} - \frac{1}{2} \begin{bmatrix} \|E_u\| \\ \|E_v\| \\ \|E_w\| \end{bmatrix} = \begin{bmatrix} \min\left(E_{+u}, E_{-u}\right) \\ \min\left(E_{+v}, E_{-v}\right) \\ \min\left(E_{+w}, E_{-w}\right) \end{bmatrix} \label{eq:symmIllum} \\ E_{sr} &=& \frac{\|\vec{E}\|}{4} \ + \ \frac{\sum_{i \in \left\{u, v, w\right\}} E_i^\sim}{3} \label{eq:scalarIllum} \end{eqnarray} where eq.~\ref{eq:vectorIllum} is the illuminance vector $\vec{E}$ corresponding to the directional component, eq.~\ref{eq:symmIllum} is the symmetric illuminance $\vec{E}^\sim$ corresponding to a "diffuse" term, and eq.~\ref{eq:scalarIllum} is the scalar illuminance $E_{sr}$ which reduces both the aggregate vector and symmetric terms to a convenient scalar term, the latter approximating the mean spherical illuminance. Furthermore, the vector/scalar illuminance ratio $\|\vec{E}\| / E_{sr}$ serves as an index for the directionality of light, ranging from 0 (completely diffuse) to 4 (unilaterally lit). \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.65\linewidth} \centering \includegraphics[width=0.6\linewidth]{cubicillum2-crop} \parbox{\linewidth}{% \caption{% \label{fig:cubicIllum} Cubic illuminance configuration according to Cuttle. } } \end{minipage} } \end{figure} When \cmd{rtrace} loads a lightflow photon map, the normal ambient calculation is disabled, and the \opt{-ab} option automatically defaults to -1, meaning that no ambient rays are traced, and cubic illuminance is directly evaluated at the sensor positions. To evaluate cubic illuminance for a single sensor position, \cmd{rtrace} must be supplied with 6 input records, consisting of a vector $\vec{v} \in \left\{\pm\vec{u}, \pm\vec{v}, \pm\vec{w}\right\}$ corresponding to one of the 6 cube axes, and the sensor position $\vec{x}$, which is identical for all 6 input records\footnote{This parametrisation is obviously redundant, but necessitated by \cmd{rtrace}'s input record format.}: \begin{eqnarray*} \vec{x} & \vec{u} \\ \vec{x} & -\vec{u} \\ \vec{x} & \vec{v} \\ \vec{x} & -\vec{v} \\ \vec{x} & \vec{w} \\ \vec{x} & -\vec{w}, \end{eqnarray*} This input yields the illuminance $E_i$ for each axis as output from \cmd{rtrace}: \begin{eqnarray*} E_{+u,r} & E_{+u,g} & E_{+u,b} \\ E_{-u,r} & E_{-u,g} & E_{-u,b} \\ \ldots \\ E_{+w,r} & E_{+w,g} & E_{+w,b} \\ E_{-w,r} & E_{-w,g} & E_{-w,b}, \end{eqnarray*} where $\left\{r, g, b\right\}$ denote the red, green and blue illuminance components, respectively. The illuminance vector $\vec{E}$, symmetric illuminance $\vec{E}^\sim$ and the scalar illuminance $E_{sr}$ can be calculated from \cmd{rtrace}'s output using a separate script as a postprocess. While it would be convenient for \cmd{rtrace} to calculate $E_{sr}$ directly, this is deemed too inflexible, since the RGB illuminance vector $\vec{E}$ could no longer be derived from this output, making it impossible to assess directionality and colour bleeding, for example. \subsection{Hemispherical and Mean Spherical Illuminance from Lightflow Photons } \label{sec:altLightFlowIllum} This section documents very hush-hush, totally semi-secret options for alternative illuminance evaluation using lightflow photons. These options are not documented in \cmd{rtrace}'s manpage as they are considered too obscure and nobody gives a stuff about them anyway. They are mainly included for testing and comparison and really aren't terribly interesting to anyone. No, really. Per default, the photons for each sensor position are located with a nearest neighbour search in a spherical volume (see upper figure~\ref{fig:lightFlowLookup}), and projected onto the plane defined by the given cube axis (curresponding to the cube face). This differs from the volume density estimate used to calculate instattering from volume photons, which by definition is not referenced to any surface. \begin{figure}[htb] \centering \fbox{% \begin{minipage}{\linewidth} \hfill \includegraphics[width=0.48\linewidth]{sphillum3-crop} \hfill \includegraphics[width=0.48\linewidth]{hemisphillum3-crop} \hfill\\ \parbox{\linewidth}{% \caption{% \label{fig:lightFlowLookup} Lightflow photon lookups in spherical (left) and hemispherical (right) volumes; photons accepted for the density estimate are highlighted in red. In the latter case, photons below the lookup plane are ignored, regardless of whether they are incident from the front of back of the plane. While this is theoretically more accurate, it will lead to a larger search radius (not shown in relative scale here) in order to locate the same number of photons as in a spherical lookup, which may in turn increase bias. } } \end{minipage} } \end{figure} Alternatively, the photons for each sensor position can be located in a hemispherical volume (see lower figure~\ref{fig:lightFlowLookup}); this is theoretically more accurate for asymmetric illuminace, as photons located behind the plane defined by each cube axis are not included in the density estimate. However, this means the search radius is enlarged compared to a spherical lookup for the same number of photons, which may increase bias. The boolean \opt{-aH} option to \cmd{rtrace} enables hemispherical lookups; this option is disabled per default, resulting in spherical lookups. Per default, lightflow photons are evaluated with the abovementioned cubic illuminace. For the purposes of comparison, the photons can also be evaluated in terms of the mean spherical illuminance (which cubic illuminance is designed to approximate). In this case, the vectors passed to \cmd{rtrace} are ignored (since mean spherical illuminace is rotationally invariant), and a single input record per sensor position suffices. The boolean \opt{-aS} option toggles between cubic illuminance (disabled, the default), and mean spherical illuminance (enabled). Note that mean spherical illuminance (\opt{-aS+}) and hemispherical lookups (\opt{-aH+}) are mutually exclusive options. \subsection{Lightflow Photon Visualisation} \label{sec:lightFlowViz} In addition to cubic illuminance, lightflow photons can also be visually analysed in terms of their distribution with \cmd{pmapdump} (see section~\ref{sec:pmapdump}). The \opt{-a} option of \cmd{pmapdump} is particularly useful to generate a point list of lightflow photons which can be interactively visualised in a suitable 3D point cloud viewer, such as the open source CloudCompare software% \footnote{\url{http://www.cloudcompare.org/}}. This facilitates visually identifying concentrations of photons, which can in turn reveal the location of light sources or scattering surfaces that contribute significantly to the illuminance in space (see figure~\ref{fig:lightFlowKaze}). Furthermore, the illuminance vector (eq.~\ref{eq:vectorIllum}) can be evaluated by \cmd{rtrace} in a sensor grid, and interactively visualised (see figure~\ref{fig:lightFlowKazeVec}) for example using a ``cone'' representation. \begin{figure}[p] \fbox{% \begin{minipage}{\linewidth} \centering \includegraphics[width=0.82\linewidth]{lightFlowKaze-0.001}\\[4mm] \includegraphics[width=0.82\linewidth]{lightFlowKaze-0.01} \\[4mm] \includegraphics[width=0.82\linewidth]{lightFlowKaze-0.1} \parbox{\linewidth}{% \caption{% \label{fig:lightFlowKaze} Lightflow photon distributions generated with extinction values of 0.001 (top), 0.01 (middle), and 0.1 (bottom), then extracted with \cmd{pmapdump} and visualised in an interactive 3D modelling tool. In this example, two lightflow photon maps from different fenestrations (skylights in yellow, lower side window in blue) were separately generated and dumped with different colours (using \cmd{pmapdump}'s \opt{-c} option), and output as a point list with the \opt{-a} option. With an extinction of 0.1 (bottom), the ``ray effect'' sets in as photons are linearly clustered along their paths, leading to biased illuminance. An extinction of 0.01 or below is optimal for this scene. Model courtesy of Prof. Nozomu Yoshizawa, Tokyo University of Science. } } \end{minipage} } \end{figure} \begin{figure}[htb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \centering \includegraphics[width=\linewidth]{lightFlowKazeVec} \parbox{\linewidth}{% \caption{% \label{fig:lightFlowKazeVec} Illuminance vectors derived from lightflow photons in figure \ref{fig:lightFlowKaze} represented by cones, where the cone's orientation corresponds to the dominant direction of the light flow at a given sensor position, and the cone's length corresponds to the vector magnitude. } } \end{minipage} } \end{figure} \subsection{Examples} In the following example, \cmd{mkpmap} generates 25 million lightflow photons in a global participating medium with extinction 0.001 (note the use of the \opt{-apD} option to reduce the predistribution factor and prevent an overflow during photon distribution). A subsequent call to \cmd{rtrace} evaluates the illuminance $E_i$ along 6 axes at the origin with a bandwidth of 2000 photons, and passes these to an \cmd{rcalc} invocation. The latter (which would usually be coded in a script or a \lit{.cal} file) calculates the illuminance vector \var{E}, the symmetric illuminance \var{Esym} and the scalar illuminance \var{Esr}. \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} mkpmap -apV bonzo.Vpm 25m -me .001 .001 .001 -apD .001 bonzo.oct echo 0 0 0 1 0 0 0 0 0 -1 0 0 \ 0 0 0 0 1 0 0 0 0 0 -1 0 \ 0 0 0 0 0 1 0 0 0 0 0 -1 | \ rtrace -I -h -ap bonzo.Vpm 2000 | rlam - - - - - - | \ rcalc -f rayinit.cal \ -e 'Exp = grey($\$$1, $\$$2, $\$$3); Exn = grey($\$$4, $\$$5, $\$$6); Eyp = grey($\$$7, $\$$8, $\$$9); Eyn = grey($\$$10, $\$$11, $\$$12); Ezp = grey($\$$13, $\$$14, $\$$15); Ezn = grey($\$$16, $\$$17, $\$$18); Ex = Exp-Exn; Ey = Eyp-Eyn; Ez = Ezp-Ezn; Esymx=min(Exp,Exn); Esymy=min(Eyp,Eyn); Esymz=min(Ezp,Ezn); Esr = sqrt(Ex*Ex + Ey*Ey + Ez*Ez)/4 + (Esymx + Esymy + Esymz)/3; $\$$1=Ex; $\$$2=Ey; $\$$3=Ez; $\$$4=Esymx; $\$$5=Esymy; $\$$6=Esymz; $\$$7=Esr' \end{lstlisting} \end{minipage} \end{center} The coloured lightflow photons in figure \ref{fig:lightFlowKaze} were obtained from separate lightflow photon maps with the following commands: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apV kazenooka-skylight.Vpm -apo skylight 20m -apD 1 \ -me .001 .001 .001 -apH kazenooka-roi.txt kazenooka.oct mkpmap -apV kazenooka-sidelight.Vpm -apo sidelight 20m -apD 1 \ -me .001 .001 .001 -apH kazenooka-roi.txt kazenooka.oct pmapdump -a -n 20k -c 255 255 0 kazenooka-skylight.Vpm \ -a -n 20k -c 0 0 255 kazenooka-sidelight.Vpm > kazenooka.xyz \end{lstlisting} \end{minipage} \end{center} In this example, lightflow photons are separately emitted from a set of skylights and a side fenestration with \cmd{mkpmap} by alternately specifying their respective modifiers as ports with the \opt{-apo} option (see section \ref{sec:ports}. The space in the interior contains a global mist of extinction 0.001 as specified with the \opt{-me} option. The photons are constrained to lie only in the interior using a polyhedral region of interest (ROI) specified with the \opt{-apH} option (see section \ref{sec:roi}); this is more convenient than using a rectangular ROI with \opt{-api} due to the octagonal geometry. The subsequent \cmd{pmapdump} invocation outputs a combined ASCII point list from both photon maps by specifying individual colours (yellow and blue) to distinguish the photons in terms of their emitting ports. Figure \ref{fig:polyroi} was similarly for the same scene, but with a single \cmd{mkpmap} invocation using both ports, and without \cmd{pmapdump}'s \opt{-a} option, which then outputs a \radiance{} scene description instead, \clearpage \section{% Transient Photon Mapping (Experimental)\footnoteref{note:transient} } \label{sec:transient} We perceive, measure and therefore also tend to simulate light in a steady state, because (most of us) can't discern movement at the speed of light. Standard photon mapping techniques locate photons in the spatial neighbourhood of a given point to evaluate illuminance. This, like \radClassic{} and the overwhelming majority of lighting simulation tools, assumes that the lighting distribution is in \emph{steady state}, i.e. illuminance and luminance do not change over time, much as you would expect light to remain constant when you flick a switch as you enter a room (unless the bulb pops or you've dropped acid). \emph{Transient rendering} is a relatively new field in computer graphics on the other hand, adds a temporal dimension to the lighting simulation, resulting in a \emph{spatiotemporal} domain \cite{Jara2014}. This means the lighting distribution is now a function of the time $t$, and no longer steady. Specifically, it enables the simulation of light propagation at specific instances in time. This can offer insight into the light transport process in an architectural interior for example (similarly to the concept of ``light flow'' described in section \ref{sec:lightFlow} from which it is infact derived). In particular, transient rendering can be used to assess directional qualities of light that may be subdued and no longer apparent in the steady state, and to study the influence of individual fenestrations, skylights and scattering surfaces in temporal isolation. Temporal colour bleeding effects, in particular, may be studied before they are neutralised in steady state (see figure \ref{fig:cornellTrans}). In the context of a photon mapping implementation, the photons are then located in a spatiotemporal neighbourhood of a given point \emph{and a given time}. Due to the additional temporal dimension, transient photon maps need to be considerably larger than steady-state ones of comparable quality. \begin{figure}[p] \fbox{% \begin{minipage}{\linewidth} \centering \begin{minipage}{0.35\linewidth} \centering \includegraphics[width=\linewidth]{cornell-tpm1}\\ $t$ = 2.2 nsec \end{minipage} \hspace{4mm} \begin{minipage}{0.35\linewidth} \centering \includegraphics[width=\linewidth]{cornell-tpm2}\\ $t$ = 3.2 nsec \end{minipage}\\[4mm] \begin{minipage}{0.35\linewidth} \centering \includegraphics[width=\linewidth]{cornell-tpm3}\\ $t$ = 3.8 nsec \end{minipage} \hspace{4mm} \begin{minipage}{0.35\linewidth} \centering \includegraphics[width=\linewidth]{cornell-tpm4}\\ $t$ = 4.2 nsec \end{minipage}\\[4mm] \includegraphics[width=0.35\linewidth]{cornell-steady}\\ Steady-state\\ \parbox{\linewidth}{% \caption{% \label{fig:cornellTrans} Four renderings of the cornell box using transient photon mapping at different points in time, illustrating the propagation of light from the ceiling light source. Note the colour bleeding effects from reflections on the blue and red walls after ca. 3 nsec. (Note also the physically implausible specular reflection on the glass sphere). In the steady state (below, rendered with standard global and caustic photons), this colour bleeding effect is mostly neutralised by subsequent interreflections from the white surfaces. A video of this sequence is available online.% \footnoteref{note:cornellTransVid} } } \end{minipage} } \end{figure} For a (remotely) physically based simulation, the user has to specify the photon velocity -- i.e. the speed of light $c$ = 299 792 458 m/s in a vacuum -- in units of the scene geometry with \cmd{mkpmap}'s \opt{-apt} option. Since this is up to the user, and \cmd{mkpmap} makes no assumptions about, nor imposes any checks on, this parameter, there's nothing preventing a physically implausible photon velocity, e.g. $>c$ or in the sonic or even glacial range. The transient photon mapping implemenation is currently experimental and simplistic, and makes a few simplifying assumptions. These include: \begin{itemize} \item Relativistic effects (Lorentz contraction, doppler effect) are not considered; we apologise to Stephen Hawking for the inconvenience. \item The velocity is constant and does not consider the index of refraction of the medium (notably dielectrics) in which the photons propagate. \item Specular reflections are still steady state, as they are calculated using \radClassic's routines. This is obvious in figure \ref{fig:cornellTrans}, for example. \end{itemize} On top of the usual photon attributes such as position and flux, a transient photon also includes the time the photon was deposited, i.e. its \emph{time of flight}. This is internally represented as the photon's cumulative path length (subject to the specified photon velocity) instead of absolute time, as it transforms the temporal domain into a spatial one which is consistent with that used by the existing photon lookup routines; the neighbouring photons are found based on similar positions \emph{and similar path lengths}. This approach limits skewing the lookup volume in either the spatial or temporal dimensions. Nevertheless, transient photon lookups are subject to the same bias effects as those for steady state photons, and this incurs and \emph{additional temporal bias} on top of the already discussed spatial bias. This is why the wavefronts on the wall in in figure \ref{fig:cornellTrans} appear blurred when they should actually be infinitely narrow. Specialised transient renderers can indeed achieve this, but this is beyond the scope and capabilities of \radiance. Transient photon (il)luminance can be rendered with \cmd{rpict} by specifying a photon bandwidth as for steady-state photon maps, and an additional timestamp $t$ for the lookup. Photons will then be located in the neighbourhood of pixel coordinates \emph{and} the time $t$. Note that the simulation spans a definite time interval which can be queried with \cmd{getinfo} (see section \ref{sec:getinfo}). The timespan starts at $t$ = 0, which corresponds to the time of photon emission from either light sources or photon ports; in the temporal context, all photons are emitted simultaneously, consequently the placement of photon ports \emph{does} matter here. The timespan ends when photon distribution has run to completion, i.e. the last photon has been absorbed. While it is an error specify a negative time, a time $t$ beyond the simulation timespan is accepted but will return zero (il)luminance. Typically transient photons will be rendered as a sequence of frames at different times which can be aggregated into a video. A Python script for this purpose, \cmd{transpmap.py}, is available\footnote{Available by request from the author under \href{mailto:roland.schregle@@gmail.com}{roland.schregle@@gmail.com}, at least until it is part of the official \radiance{} distro. } to facilitate the generation of videos for given timespans and time increments. Examples of such videos are available online.% \footnote{Cornell transient sequence available online at:\\ \url{% https://www.researchgate.net/project/3D-Light-Flow/update/61070aff181c2e4f4a7d0f28 } \label{note:cornellTransVid} }% \textsuperscript{,}% \footnote{Villa M\"uller transient sequences are available online at:\\ \url{% https://www.researchgate.net/project/3D-Light-Flow/update/61070620647f3906fc8d475c } and\\ \url{% https://www.researchgate.net/project/3D-Light-Flow/update/61070d452897145fbd65a96e } \label{note:vmuellerTransVid} } Using a sufficiently small time increment per video frame can give the illusion of extreme slow motion, effectively dilating time, which of course makes Stephen Hawking very happy! (Plus it's mindbuggering to look at...) \subsection{Examples} The following example generates 100 million transient photons (note $c$ is scaled to mm/sec since these are the units of \lit{bonzo.oct}), and renders the luminance at $t$=5 nanoseconds using a spatiotemporal bandwidth of 100 photons: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} mkpmap -apt bonzo.tpm 100m 2.99792458e11 $\ldots$ bonzo.oct rpict -ap bonzo.tpm 100 5e-9 $\ldots$ bonzo.oct \end{lstlisting} \end{minipage} \end{center} The following example uses the \cmd{transpmap.py} script to generate a sequence of transient renderings of the Villa M\"uller over a timespan of 100 nanoseconds, and aggregate them into a video (see also figure \ref{fig:vmuellerTrans}). While \cmd{transpmap.py} can generate the photon map and renderings in a single invocation, this particular example generates the photon map separately, then renders the sequence in a subsequent call using the same scene \emph{without sky and solar sources} for a more dramatic and artsy effect, and 'cos we just like it that way: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} transpmap.py -c 2.99792458e11 -p 200m -n 8 -T 0 vmueller.oct -apo Window -apo port transpmap.py -r -E +1 -b 150 -m 50 -x 1000 -y 1000 -n 8 -T 1e-7 -d 2.5e-10 -f 25 xsection-l.vf vmueller-nosrc.oct \end{lstlisting} \end{minipage} \end{center} Parameters here include: \begin{itemize} \item Transient photon velocity $c$ in mm/sec \item 200 million transient photons \item Additional parameters to \cmd{mkpmap} to define photon ports for fenestrations and skylights. \item Parallel execution on 8 cores \item Reuse of existing photon map with option \opt{-r} \item Frame exposure of +1 stops to linearly tonemap each frame with \cmd{pcond} \item Spatiotemporal lookup bandwith of 150 photons \item Maximum lookup radius of 50 mm (reduces banding artefacts at the expense of longer rendering times) \item Maximum frame resolution of 1000$\times$1000 (adjusted to the aspect ratio) \item Time increment of 250 picoseconds per rendered frame \item Video frame rate of 25 fps \item View file \lit{xsection-l.vf} which defines a fore clipping plane to obtain a cross-sectional view of the building \end{itemize} See \cmd{transpmap.py -h} for detailed help on these parameters. \begin{figure}[p] \fbox{% \begin{minipage}{\linewidth} \centering %\begin{minipage}{0.45\linewidth} % \centering % \includegraphics[width=\linewidth]{vmueller-r-7.000e-09}\\ % $t$ = 7 nsec %\end{minipage} %\hfill \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-1.200e-08}\\ $t = 12$ nsec \end{minipage} \hfill \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-2.200e-08}\\ $t = 22$ nsec \end{minipage}\\[4mm] \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-2.625e-08}\\ $t = 26$ nsec \end{minipage} \hfill \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-3.500e-08}\\ $t = 35$ nsec \end{minipage}\\[4mm] \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-4.050e-08}\\ $t = 40$ nsec \end{minipage} \hfill %\begin{minipage}{0.45\linewidth} % \centering % \includegraphics[width=\linewidth]{vmueller-r-4.600e-08}\\ % $t$ = 46 nsec %\end{minipage}\\[2mm] \begin{minipage}{0.49\linewidth} \centering \includegraphics[width=\linewidth]{vmueller-r-5.200e-08}\\ $t = 52$ nsec \end{minipage}\\ \parbox{\linewidth}{% \caption{% \label{fig:vmuellerTrans} A sequence of transient renderings of the Villa M\"uller presented in a cross-sectional view. This scene exhibits complex light propagation due to the combination of skylights, two stairwells, deep halls and large windows. Among the effects observed are: interreflection in the central stairwell ($t=26$ nsec), colour bleeding from the red marble floor ($t=35$ nsec), temporally isolated caustics ($t=40$ nsec), light from the right panorama window reaching the left stairwell ($t=52$ nsec, corresponding to a propagation distance of ca. 16m). Videos of this sequence are available online.% \footnoteref{note:vmuellerTransVid} } } \end{minipage} } \end{figure} \clearpage \section{Utilities} \subsection{Querying the Photon Map with \cmd{getinfo}} \label{sec:getinfo} The \cmd{getinfo} tool supplied with \radiance{} can extract the build parameters and statistics about a photon map from the header of the corresponding file. As with other file types, \cmd{getinfo} can query multiple photon maps in one command line. The output may include the following fields (photon type-specific output is enclosed in parentheses): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} #?RADIANCE $cmdline$ NumPhotons = $N_p$ AvgFlux = [$\phi_r$, $\phi_g$, $\phi_b$] Bbox = [$min_x, min_y, min_z$] [$max_x, max_y, max_z$] CoG = [$CoG_x, CoG_y, CoG_z$] MaxDist^2 = $r_{max}^2$ [ Velocity = $c$ / sec Timespan = [$t_{min}, t_{max}$] sec AvgPathLen = $\bar{s}$ ] [ Photon Map contains precomputed [linear|logarithmic] [contributions|coefficients] Num bins = $scDim \times scDim = nbins$ Num coeffs = $m_d/m_{d,0}$ compressed detail, $m_s$ approx, $m_t$ total Compression = $comp$ % mRGBE config= $mant_r$:$mant_g$:$mant_b$:$exp$:$idx$ ] FORMAT =$fmt$ VERSION =$ver$ \end{lstlisting} \end{minipage} \end{center} where: \begin{itemize} \item \var{cmdline} is the \cmd{mkpmap} command line used to build the photon map, including all arguments, \item \var{N_p} is the total number of photons in the photon map, \item \var{[\phi_r, \phi_g, \phi_b]} is the RGB photon flux averaged over all \var{N_p} photons. \item \var{[min_x, min_y, min_z]} and \var{[max_x, max_y, max_z]} are the minimum resp. maximum photon positions. \item \var{[CoG_x, CoG_y, CoG_z]} is the ``centre of gravity'' of the photon distribution, i.e. the average over all photon positions. \item \var{r_{max}^2} is the square of the average distance of the photons to the CoG. This is used as an estimate for initial photon lookup radius. \item \var{c} is the photon velocity (i.e. simulated speed of light) in (scene units) / sec.\footnote{% Applies to transient photon maps only \label{note:getinfoTrans} } \item \var{[t_{min}, t_{max}]} is the time spanning the photon propagation, in seconds, from photon emission to the last absorbtion.\footnoteref{note:getinfoTrans} \item \var{\bar{s}} is the average cumulative distance travelled by a photon, in scene units. This can be useful for setting \cmd{mkpmap}'s \opt{-ld} option if photon paths should be limited.\footnoteref{note:getinfoTrans} \item \textit{Photon Map contains precomputed [linear|logarithmic] [contributions|coefficients]} reflects the status of the \opt{-V} option passed to \cmd{mkpmap}, and whether the binned contributions/coefficients were encoded linearly (as-is) or logarithmically; the latter is a compile-time option and cannot be overridden by the user at runtime. \item \var{scDim = \sqrt{nbins}} is the number of bins per dimension mapped to the Shirley-Chiu square. \item \var{m_d,\ m_{d,0}} is the number of wavelet detail coefficients remaining after compression, and the original number before compression, respectively. \item \var{m_s,\ m_t} is the number of wavelet approximation coefficients (which are never compressed), and the total size of the (partially populated) wavelet coefficient matrix, respectively. \item \var{comp = 100 (1 - n_d / n_{d,0})} is the compression ratio of wavelet detail coefficients, in percent. \item \var{[mant_r, mant_g, mant_b],\ exp,\ idx} is the number of bits used to encode the RGB mantissa, exponent, and incremental index of wavelet coefficients on disk, within a 32-bit envelope. This configuration is a compile-time option and cannot be overridden by the user at runtime. \item \var{fmt} identifies the photon map type, which is one of \begin{itemize} \item \lit{Radiance\_Global\_Photon\_Map}, \item \lit{Radiance\_PreComp\_Photon\_Map}, \item \lit{Radiance\_Caustic\_Photon\_Map}, \item \lit{Radiance\_Volume\_Photon\_Map}, \item \lit{Radiance\_Direct\_Photon\_Map}, \item \lit{Radiance\_Contrib\_Photon\_Map}, \item \lit{Radiance\_Contrib\_Child\_Photon\_Map}\\ (per-modifier contribution photon map contained in \lit{Radiance\_Contrib\_Photon\_Map}) \item \lit{Radiance\_Transient\_Photon\_Map}, \item \lit{Radiance\_LightFlow\_Photon\_Map}, or \item \lit{Radiance\_TransLightFlow\_Photon\_Map}. \end{itemize} \item \var{ver} is a file format version number to check build options and output file compatibility. \end{itemize} \subsection{Visual Examination of Photon Maps with \cmd{pmapdump}} \label{sec:pmapdump} \subsubsection{Overview} \cmd{Pmapdump} is a minimalist tool to visualise the photon distribution in one or more photon map files. The utility can be used for illustrative purposes to understand the photon map algorithm, but more importantly, it can be used to debug scenes in which the location of photons is unclear. Examples of \cmd{pmapdump} output can be seen in \autoref{fig:cornell_distrib}~(right), \autoref{fig:roi}, \autoref{fig:lightFlowKaze}, \autoref{fig:pmapdump-sunpu} and \autoref{fig:sunpu-cc}. \cmd{Pmapdump} takes one or more photon map files generated with \cmd{mkpmap} as input and, by default, sends a \radiance{} scene description of their photon distributions to the standard output. Photons are represented as spheres of material type \lit{glow}. These can be visualised with e.g. \cmd{objview}, \cmd{rpict}, or \cmd{rvu} to assess the location and local density of photons in relation to the scene geometry. No additional light sources are necessary, as the spheres representing the photons are self-luminous. Alternatively, photons can also be output as an ASCII point list, where each line contains a photon's position and colour. This point list can be imported in a 3D point cloud processor/viewer to interactively explore the photon map. An arbitrary number of photon maps can be specified on the command line and the respective photon type is determined automagically. Per default, the different photon types are visualised as colour coded spheres according to the following default schema: \begin{description} \item[\textcolor{blue}{Blue}:] global photon \item[\textcolor{cyan}{Cyan}:] precomputed global photon \item[\textcolor{red}{Red}:] caustic photon \item[\textcolor{green}{Green}:] volume / lightflow photon \item[\textcolor{magenta}{Magenta}:] direct photon \item[\contour{black}{\textcolor{yellow}{Yellow}}:] contribution photon \item[\contour{black}{\textcolor{white}{White}}:] transient photon \end{description} These colours can be overridden for individual photon maps with the \opt{-c} option (see below). Alternatively, photons can be individually coloured according to their actual RGB flux with the \opt{-f} option (see below); while this makes it difficult to discern photon types, it can be used to quantitatively analyse colour bleeding effects, for example. \begin{figure}[tb] \centering \fbox{% \begin{minipage}{0.95\linewidth} \includegraphics[width=\linewidth]{sunpu-vpm-clip} \parbox{\linewidth}{% \caption{% \label{fig:pmapdump-sunpu} Cutaway view of volume photons entering a modernist church through skylights, rendered with default \cmd{pmapdump} output (yellow spheres) merged with the original scene geometry. Model courtesy of Prof. Nozomu Yoshizawa, Tokyo University of Science. } } \end{minipage} } \end{figure} \subsubsection{Options} \noindent The synopsis for \cmd{pmapdump} is as follows: \begin{center} \begin{minipage}{\linewidth} \begin{lstlisting} pmapdump [-a [-N] [-A]] [-n $num_1$] [-r $radscale_1$] \ [-f [-O $norm_1$]] | [-c $rcol_1$, $gcol_1$, $bcol_1$] $pmap_1$ \ [-a [-N] [-A]] [-n $num_2$] [-r $radscale_2$] \ [-f [-O $norm_2$]] | [-c $rcol_2$, $gcol_2$, $bcol_2$] $pmap_2$ $\ldots$ \end{lstlisting} \end{minipage} \end{center} Options are effective for the photon map file immediately following on the command line, and are reset to their defaults after completion of each dump. As such they must be set individually for each photon map. \cmd{Pmapdump} takes the following options: \begin{description} \item{\opt{-a}[\lit{+}$|$\lit{-}]}\\ Boolean switch to output photons as a point list in ASCII (text) format instead of a \radiance{} scene. Each output line consists of 6 tab-separated floating point values: the X, Y, Z coordinates of the photon's position, and the R, G, B colour channels of its flux. These values. notably the flux, are expressed in scientific notation if necessary to accommodate their high dynamic range. As \cmd{pmapdump} groups its options per photon map, this option must be specified per photon map for consistent output. This prevents erroneously dumping \radiance{} scene descriptions along with point lists, which will fail to load in the 3D point cloud processor/viewer. \item{\opt{-A}[\lit{+}$|$\lit{-}]}\\ Boolean switch to also output type-specific auxiliary data embedded in each photon in conjunction with option \opt{-a}. For most photon types this is the unique path ID. Path IDs consist of a numeric prefix \lit{N} and suffix \lit{M}, and are formatted as \lit{N:M}. \item{\opt{-c} \var{rcol} \var{gcol} \var{bcol}}\\ Specifies a custom sphere/point colour for the next photon map. The colour is specified as an RGB triplet, with each component in the range (0..1]. Without this option, the default colour for the corresponding photon type is used. This option is mutually exclusive with \opt{-f}. \item{\opt{-f}[\lit{+}$|$\lit{-}]}\\ Boolean switch to colour each sphere/point according to the corresponding photon's RGB flux instead of a constant colour. The flux is adjusted for the fraction of dumped photons to maintain the total flux contained in the dumped photon map. Note that no exposure is applied, and as such resulting colours can span several orders of magnitude and may require tone mapping with \cmd{pcond} or normalisation with option \opt{-O} (see below) for visualisation. This option is mutually exclusive with \opt{-c}. \item{\opt{-n} \var{num}}\\ Specifies the number of spheres or points to dump for the next photon map. The dump is performed by random sampling with \var{num} as target count, hence the number actually output will be approximate. \var{Num} may be suffixed by a case-insensitive multiplier for convenience, where \var{k = 10^3} and \var{m = 10^6}, although the latter may lead to problems when processing the output geometry with \cmd{oconv}. The default number is 10k. \item{\opt{-N}[\lit{+}$|$\lit{-}]}\\ Boolean switch to also output photon normals in conjunction with option \opt{-a}. In case of a volume photon map, this option will output the photon's direction. \item{\opt{-O} \var{norm}}\footnote{% Sorry, we ran outta sensible option names here... }\\ Normalise photon flux to the given value. This limits the maximum flux in any colour channel to \var{norm}, which is useful for postprocessing and visualising the photon flux within a predetermined range. This option is only valid in conjuction with the \opt{-f} option. \item{\opt{-P}[\lit{+}$|$\lit{-}]}\\ Boolean option to output photon path IDs in text format. This option is equivalent to \opt{-A} and kept for backwards compatibility only. \item{\opt{-r} \var{radscale}}\\ Specifies a relative scale factor \var{radscale} for the sphere radius. The sphere radius is determined automatically from an estimated average distance between spheres so as to reduce clustering, assuming a uniform distribution. In cases where the distribution is substantially nonuniform (e.g. highly localised caustics) the radius can be manually corrected with this option. The default value is 1.0. This option is ignored for point list output in conjuction with~\opt{-a}. \end{description} \subsubsection{Notes} Note that the \radiance{} scene output may contain many overlapping spheres in areas with high photon density, particularly in caustics. This results in inefficient and slow octree generation with \cmd{oconv}. Generally this can be improved by reducing \var{num} and/or \var{radscale}. \subsubsection{Examples} The following example visualises the distribution of global and caustic photons superimposed on the scene geometry with 5000 pale red and 10000 pale blue spheres, respectively: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} pmapdump -n 5k -c 1 0.4 0.4 global.pm \ -n 10k -c 0.4 0.4 1 caustic.pm | \ oconv - scene.rad > scene_pm.oct rvu scene_pm.oct \end{lstlisting} \end{minipage} \end{center} Note the use of a pipe to directly create \lit{scene\_pmdump.oct} from the \cmd{pmapdump} output. In contrast, this example visualises the caustic photon distribution superimposed on the scene geometry with 10000 spheres coloured according to the photons' respective RGB flux: \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} pmapdump -n 10k -f caustic.pm | \ oconv - scene.rad > scene_pm.oct \end{lstlisting} \end{minipage} \end{center} \radiance{} scene dumps may also be viewed on their own by simply piping the output of \cmd{pmapdump} directly into \cmd{objview} (using the default number of spheres in this example): \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} pmapdump zombo.pm | objview \end{lstlisting} \end{minipage} \end{center} Instead of a \radiance{} scene, the following example dumps photons as a (really long) point list to an ASCII file for import into a 3D point cloud processor/viewer, as shown in \autoref{fig:sunpu-cc}. \begin{center} \begin{minipage}{0.95\linewidth} \begin{lstlisting} pmapdump -a -f -n 100k lotsa.pm > lotsa_pointz.xyz \end{lstlisting} \end{minipage} \end{center} \begin{figure}[h] \centering \fbox{% \begin{minipage}{0.95\linewidth} \includegraphics[width=\linewidth]{sunpu-vpm}\\ \parbox{\linewidth}{% \caption{% \label{fig:sunpu-cc} ASCII point list imported into an interactive point cloud processor/viewer (in this case \cmd{ccViewer}, part of the excellent open-source \lit{CloudCompare} toolsuite \cite{CC2020}). The point list was exported by \cmd{pmapdump} with the \opt{-a} option from the volume map rendered in \autoref{fig:pmapdump-sunpu}. } } \end{minipage} } \end{figure} \clearpage \section{Acknowledgements} The following institutions contributed to the development of the \radiance{} photon map extension: \begin{description} \item[Fraunhofer Institute for Solar Energy Systems (ISE)] supported by the German Research Foundation (DFG LU204/10-2: \textit{Fassadenintegrierte Regelsysteme} (FARESYS)), \item[Lucerne University of Applied Sciences and Arts (HSLU)] supported by the Swiss National Science Foundation (SNSF 147053: \textit{Simulation based assessment of daylight redirecting components for energy savings in office buildings }, SNSF 179067: \textit{Lightfields for spatio-temporal glare assessment }), \item[Tokyo University of Science] supported by the JSPS Grants-in-Aid for Scientific Research Programme (KAKENHI JP19KK0115: \textit{% A new expression of three‐dimensional light flow in architectural spaces and its visual interpretation in the context of human‐centric lighting design }). \end{description} The Developer(s) would also like to thank the following individuals for their invaluable contributions: \begin{description} \item[Greg Ward] for his support in integrating the code, and his tireless efforts in keeping \radiance{} and its community alive, \item[Dr. Peter Apian-Bennewitz, Dr. Karsten Voss and Dr. Volker Wittwer] for initiating and supervising development of the first release of the \radiance{} photon map extension at Fraunhofer ISE as part of the DFG-funded \textit{FARESYS} project. \item[Prof. Stephen Wittkopf and Dr. Lars Grobe] for continuing development of the photon map (notably out-of-core and contributions) within the scope of the SNSF-funded projects \textit{Daylight Redirecting Components (DRC)} and \textit{Lightfields for Glare Assessment (LFG)}. \item[Prof. Nozomu Yoshizawa] and his team for initiating the KAKEN-funded project \textit{Three-dimensional light flow} at the Tokyo University of Science, for supporting the development of the lightflow photon map, and applying it in their experiments, \item[Rob Gugliemetti] for his huge help in getting this thing compiled under W33nd0z and providing nightly builds for that platform, 'cos The Developer(s)$^{TM}$ doan' do W33ndoz, \item[Carsten Bauer (Capt.~B) and Dr. David Geisler-Moroder] for testing the tool with \realLife\ scenes, reporting bugs and providing valuable feedback. \end{description} Finally, a big thanks to \textit{anyone} out there nuts enough to try the extension out! \clearpage \begin{thebibliography}{99} \bibitem[Bent1975]{Bent1975} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. \textit{CACM} 18(9), 1975. \bibitem[CC2020]{CC2020} CloudCompare 3D point cloud and mesh processing software open source project, 2020. Available at \href{http://www.cloudcompare.org}{http://www.cloudcompare.org}. \bibitem[Chri2000]{Chri2000} Per Christensen: ``Faster Photon Map Global Illumination''. \textit{Journal of Graphics Tools} 4(3), April~2000. \bibitem[Cutt2014]{Cutt2014} Christopher Cuttle: ``Research Note: A practical approach to cubic illuminance measurement''. \textit{Lighting Research \& Technology}, 2014; 46(1): 31--34. DOI: 10.1177/1477153513498251 \bibitem[Jara2014]{Jara2014} Adrian Jarabo, Julio Marco, Adolfo Mu\~{n}oz, Raul Buisan, Wojciech Jarosz, Diego Gutierrez: ``A framework for transient rendering''. \textit{ACM Transactions on Graphics} (\textit{Proceedings of SIGGRAPH Asia}), 2014; 33(6). DOI: 10/gfznb8. Available at: \href{% https://cs.dartmouth.edu/~wjarosz/publications/jarabo14framework.html }{% https://cs.dartmouth.edu/~wjarosz/publications/jarabo14framework.html } \bibitem[Jens1996]{Jens1996} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. \textit{Rendering Techniques '96}, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996. \bibitem[Jens1997]{Jens1997} Henrik Wann Jensen: ``Rendering Caustics on Non-Lambertian Surfaces''. \textit{Computer Graphics Forum}, 16(1), March~1997. \bibitem[Jens1998]{Jens1998} Henrik Wann Jensen and Per H.~Christensen: ``Efficient Simulation of Light Transport in Scenes with Participating Media using Photon Maps''. \textit{Proceedings SIGGRAPH~'98}, July~1998. \bibitem[Jens2000]{Jens2000} Henrik Wann Jensen and Niels J{\o}rgen Christensen: ``A Practical Guide to Global Illumination using Photon Maps''. \textit{SIGGRAPH~2000 Course Notes~8}, July~2000. \bibitem[Lath1968]{Lath1968} K.D. Lathrop: ``Ray Effects in Discrete Ordinates Equations''. \textit{Nuclear Science and Engineering}, 1968; 32(3): 357--369. DOI: 10.13182/NSE68-4 \bibitem[Schr2003]{Schr2003} Roland Schregle: ``Bias Compensation for Photon Maps''. \textit{Computer Graphics Forum} 22(4), December~2003. \bibitem[Schr2015]{Schr2015} Roland Schregle, Carsten Bauer, Lars O. Grobe and Stephen Wittkopf: ``EvalDRC: A tool for annual characterisation of daylight redirecting components with photon mapping''. \textit{Proceedings CISBAT 2015}, Lausanne, Switzerland. \bibitem[Schr2016]{Schr2016} Roland Schregle, Lars O. Grobe and Stephen Wittkopf: ``An Out-of-Core Photon Mapping Approach to Daylight Coefficients''. \textit{Journal of Building Performance Simulation}, 9(6), 2016. \bibitem[Schr2019]{Schr2019} Roland Schregle, Nozomu Yoshizawa, Toshihide Okamoto, Ken Komazawa: ``An Ongoing Visual Assessment of Three-dimensional Light Flow Expressed Through Volume Photon Mapping''. Presented at the \textit{18th International RADIANCE Workshop}, New York City, August~2019.\\ Available at: \href{% https://www.radiance-online.org/community/workshops/2019-new-york-ny/presentations/day3/23\_Schregle-Yoshizawa.pdf }{% https://www.radiance-online.org/community/workshops/2019-new-york-ny/presentations/day3/23\_Schregle-Yoshizawa.pdf }. \bibitem[Schr2021a]{Schr2021a} Roland Schregle, Nozomu Yoshizawa, Ken Komazawa and Kaira Otori: ``A Case Study of Three-Dimensional Light Flow Expressed Through Volume Photon Mapping''. Presented at the \textit{19th International Radiance Workshop}, Bilbao, August~2021.\\ Available at: \href{% https://www.radiance-online.org/community/workshops/2021-bilbao-spain-2/presentations/19\_thursday/Radiance2021-3DLightFlowVPMCaseStudy-6.pdf }{% https://www.radiance-online.org/community/workshops/2021-bilbao-spain-2/presentations/19\_thursday/Radiance2021-3DLightFlowVPMCaseStudy-6.pdf }. \bibitem[Schr2021b]{Schr2021b} Roland Schregle and Nozomu Yoshizawa: ``Gone in 60 Nanoseconds: Adventures in Transient Rendering'' Presented at the \textit{19th International Radiance Workshop}, Bilbao, August~2021.\\ Available at: \href{% https://www.radiance-online.org/community/workshops/2021-bilbao-spain-2/presentations/20\_friday/Radiance2021-GoneIn60Nanosec-8.pdf }{% https://www.radiance-online.org/community/workshops/2021-bilbao-spain-2/presentations/20\_friday/Radiance2021-GoneIn60Nanosec-8.pdf }. \bibitem[Shir1997]{Shir1997} Peter Shirley and Kenneth Chiu: ``A Low Distortion Map Between Disk and Square''. \textit{Journal of Graphics Tools}, 2(3), 1997. \bibitem[Ward1994]{Ward1994} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. \textit{Proceedings SIGGRAPH~'94}, July~1994. \bibitem[Ward1998]{Ward1998} Greg Ward Larson and Rob Shakespeare: \textit{Rendering with \radiance}. Morgan Kaufmann, San Francisco, 1998. \bibitem[Yosh2022]{Yosh2022} Nozomu Yoshizawa, Roland Schregle, Ken Komazawa and Kaira Otori: ``Photon Flow: A three-dimensional expression of light flow using Volume Photon Mapping''. TO APPEAR in \textit{Lighting Research \& Technology}. \end{thebibliography} % Manually add bibliography to table of contents % (Why isn't this the default behaviour?!) \addcontentsline{toc}{section}{References} \clearpage \appendix \section*{Appendix} \section{Sample Renderings} \subsection{Caustics} \begin{figure}[h!] %\centering \fbox{% \begin{minipage}{0.98\linewidth} \includegraphics[width=0.49\linewidth] {prismella-xsection-hi-close3}% \hfill \includegraphics[width=0.49\linewidth] {prismella-xsection-lo-close3}\\% \parbox{\linewidth}{% \caption{% \label{fig:prismella} Retroreflecting blinds patented by Helmut K\"oster, rendered with \radiance{} photon map using 600k global and 6M caustic photons with a bandwidth of 100 and 100--2000 (bias compensated), respectively. At 40\degree{} incidence (left), sunlight is retroreflected as evidenced by the caustics on the wall, while skylight is scattered into the interior off the diffuse lamellae undersides. At 20\degree{} incidence (right), the inclination requires adjustment as sunlight is now redirected towards the lamellae undersides rather than being retroreflected. } } \end{minipage} } \end{figure} \begin{figure}[h!] \centering \fbox{% \begin{minipage}{0.98\linewidth} \includegraphics[angle=-90, width=\linewidth] {litepipe-xsection-pmap} \parbox{\linewidth}{% \caption{% \label{fig:litepipe-xsection} Cross-sectional view of a lightpipe rendered with 500k global and 1M caustic photons. The photons are emitted via ports defined for the window, pipe aperture, and external heliostat (not visible). } } \end{minipage} } \end{figure} \begin{figure}[t!] \centering \fbox{% \begin{minipage}{0.98\linewidth} \centering \includegraphics[width=0.5\linewidth]{cornell-flood-50}\\[1mm]% \includegraphics[width=0.5\linewidth]{cornell-flood-500}\\[1mm]% \includegraphics[width=0.5\linewidth]{cornell-flood-50-500}\\% \parbox{\linewidth}{% \caption{% \label{fig:cornell-flood} Flooded Cornell box rendered with caustic photon map using fixed bandwidths of 50 (top) and 500 (centre) photons, and a dynamic bandwidth of \mbox{50--500} photons with bias compensation (bottom). } } \end{minipage} } \end{figure} \clearpage \subsection{Volume Caustics} \begin{figure}[!htb] \centering \fbox{% \begin{minipage}{\linewidth} \centering \includegraphics[width=0.49\linewidth]{cpc-xsection1}% \hfill \includegraphics[width=0.49\linewidth]{cpc-xsection2}\\% \parbox{\linewidth}{% \caption{% \label{fig:cpc-xsection} Compound parabolic concentrator with opaque apertures rendered with volume photon map in a \lit{mist} environment. At normal incidence (left), the incident beam is retroreflected, whereas at 50\degree{} incidence (right) it is transmitted and redirected in a characteristic fan-out. } } \end{minipage} } \end{figure} \begin{figure}[!htb] \centering \fbox{% \begin{minipage}{\linewidth} \centering \includegraphics[width=0.55\linewidth]{cornell-volume}\\% \parbox{\linewidth}{% \caption{% \label{fig:cornell-volume} Funky volume caustics in a \lit{mist} environment from refracted volume photons as they pass through a \lit{dielectric} sphere. Note the blue cast imposed on the refracted photons. } } \end{minipage} } \end{figure} \clearpage \section{Parameter Ranges} The following table lists typical ranges for various parameters used with \cmd{mkpmap} and \cmd{rpict}. It is primarily aimed at novices, who are no doubt bewildered by the plethora of options. The ranges are recommendations based on the developer's experience, and should not be interpreted as fixed constraints. In some situations it is not unlikely to use settings far beyond the typical range. %\todo{Revise table, some of these are too conservative!} \begin{table}[!h] \centering \begin{tabular}{|l|p{0.6\linewidth}|} \hline \cmd{mkpmap} parameter & Typical range \\ \hline \hline \var{nphotons} & 100k--100M (100k--1G with out-of-core option)\\ \opt{-apD} & 0.1--1.0 \\ \opt{-apm} & 1000--5000 \\ \opt{-apP} & 0.25--0.5 \\ \opt{-dp} & 1000--100000 \\ \opt{-ds} & 0.0001--0.01 \\ \hline \hline \cmd{rpict} parameter & Typical range \\ \hline \hline \var{bwidth_1} & 50--100 (50--1000 with out-of-core option)\\ \var{bwidth_2} & 200--500 (200--5000 with out-of-core option)\\ \opt{-ab} & \mbox{1 (default via ambient bounce)}, \mbox{-1 (quick\&dirty direct visualisation)}\\ \opt{-ac} & 4.0--16.0 \\ \opt{-am} & 100-1000 \\ \hline \end{tabular} \end{table} \clearpage \section{Bugz and Weirdness} \label{sec:bugz} \begin{itemize} \item The spotlight focal point is ignored by the photon map; it coincides with the light source surface. This corresponds to specifying a direction vector of infinitesimal length in \radClassic. \item \cmd{mkpmap}'s distribution algorithm can exceed the specified number of photons with scenes having high reflectance or when excessively high settings of \opt{-apD} are used. \item Caustic photon irradiance will be biased when passing \cmd{rtrace} points which do not lie on a surface, unless a virtual receiver surface is defined with \lit{antimatter} and specified with \cmd{mkpmap}'s \opt{-aps} or \opt{-apS} option, as detailed in section \ref{sec:mkpmap}. This also applies when directly visualising global photons with \opt{-ab 1}. Technically this is not a bug, but a fundamental constraint of the photon mapping algorithm itself. \item Arbitrary polygonal light sources and photon ports are not well supported. This is a limitation of RADIANCE's light source sampling code, and \cmd{mkpmap} resorts to a crude rejection sampling technique to improve on this. Because this hack (for want of a better word) discards emitted photons to compensate for bias, it currently has a nasty side effect of generating fewer photons than specified. Triangular and quadrilateral sources are well supported, however, and it is generally recommended to triangulate polygonal geometry prior to importing it into RADIANCE. \end{itemize} \clearpage \section{\cmd{mkpmap} Troubleshooting} \begin{table}[!h] \centering \begin{tabular}{|p{.3\linewidth}|p{.3\linewidth}|p{.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline \cmd{mkpmap} stores too many photons & Too many emitted photons in distribution prepass & Reduce \opt{-apD} \\ \hline Number of photons stored differs substantially from specification & Too few photons emitted in distribution prepass; prediction for main pass inaccurate & Increase \opt{-apD} \\ \hline \cmd{mkpmap} complains about runaway photons & Photons stuck in infinite scattering loop, possibly pathological geometry or materials & Check geometry and materials; increase \opt{-apm} \\ \hline \cmd{mkpmap} is slow with \lit{source} primitive & \lit{source} emits from scene cube faces & Define photon ports \\ \hline \cmd{mkpmap} bogs down in light source flux integration & Excessively high probability density function resolution; too many source partitions & Decrease \opt{-dp}; increase \opt{-ds} \\ \hline \cmd{mkpmap} bails out after too many distribution prepasses & photon ports oriented outward; using caustic photons with non-specular geometry; using volume photons without \lit{mist}; pathological geometry or nonabsorbing materials; light sources see no geometry; wrong lunar phase; bad horoscope, etc. & Check port normal(s) or reverse their orientation(s) with \opt{-apo-}; check scene and specify compatible photon types \\ \hline Excessive noise in photon irradiance & Bandwidth too low & Increase bandwidth \\ \hline Excessive blurring in photon irradiance & Bandwidth too high & Decrease bandwidth or increase size of photon map \\ \hline Excessive noise and blurring in different regions & Bandwidth is fixed & Apply bias compensation for dynamic bandwidth \\ \hline \end{tabular} \end{table} \clearpage \section{\cmd{rpict/rtrace} Troubleshooting} \begin{table}[!h] \centering \begin{tabular}{|p{.3\linewidth}|p{.3\linewidth}|p{.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline Severe irradiance falloff at polygon edges & Boundary bias due to high bandwidth & Reduce bandwidth or apply bias compensation \\ \hline Splotchy ambient illumination from global photons & Excessively noisy density estimates; too few ambient samples; irradiance caching too inaccurate & Check density estimate with \opt{-ab} -1, and increase bandwidth if necessary; increase \opt{-ad} if illumination has high variance or contains caustics; increase \opt{-ar} and/or decrease \opt{-aa} \\ \hline Direct photon irradiance from modified light source deviates significantly & Probability density function cannot adequately resolve emission distribution; too few source partitions & Increase \opt{-dp}; if distribution varies over surface, decrease \opt{-ds} \\ \hline Caustics are underestimated for measurement points passed to \cmd{rtrace} which do not lie on scene geometry & No photons in measurement plane; photons are retrieved from distant co-planar objects, resulting in oversized radius & Define virtual receiver surface with \lit{antimatter} material, and specify its modifier with \cmd{mkpmap}'s \opt{-aps} or \opt{-apS} option when building the photon map \\ \hline \cmd{rpict/rtrace} complains about short photon lookups & Maximum photon search radius too small & Increase \opt{-am} \\ \hline \cmd{mkpmap} generates fewer photons when using polygonal sources/ports & This is a side effect of rejection sampling used to emit photons from arbitrary polygonal geometry. See appendix \ref{sec:bugz} for details. & Increase target photon count or triangulate your polygons \\ \hline Everything is slow & User expects too much & Twiddle thumbs \\ \hline \end{tabular} \end{table} \end{document} @ 1.50 log @Documented warning when overriding -V in rcontrib @ text @d34 2 a35 2 \RCS $Revision: 1.49 $ \RCS $Date: 2022/05/10 22:42:09 $ d2180 1 a2180 1 very angry...}. @ 1.49 log @Wording change in rcontrib section @ text @d34 2 a35 2 \RCS $Revision: 1.48 $ \RCS $Date: 2022/05/10 22:18:38 $ d2168 2 a2169 1 will be automatically overriden in \cmd{rcontrib}. @ 1.48 log @Documented option file passed to rcontrib for consistent binning params. @ text @d34 2 a35 2 \RCS $Revision: 1.47 $ \RCS $Date: 2022/05/05 23:42:45 $ d2170 1 a2170 1 The binning parameters passed to \cmd{rcontrib} must be consistent with d2188 4 a2191 4 When using the option file, it is not necessary to specify the modifiers with the \opt{-m} option, as these are already included. The user may edit the option file to set per-modifier output streams if necessary. @ 1.47 log @Documented empty bin ratio warning. @ text @d34 2 a35 2 \RCS $Revision: 1.46 $ \RCS $Date: 2022/04/11 18:23:02 $ d968 4 d1462 1 a1462 1 if available \footnoteref{note:contrib} \footnoteref{note:transient} d1512 4 a1515 4 for a grid of sensor positions in \cmd{rcontrib} (note that the latter still requires a dummy binning "function" to be defined on the command line, though it is never evaluated, since overridden by the pre-binned photon contributions; see section \ref{sec:rcontribPmap} for details): d1519 2 a1520 1 mkpmap -apC bonzo-contrib.Cpm 10m 2600 0.75 -apP 0.1 -bn 256 -m bonzoLite -V+ bonzo.oct d1522 2 a1523 2 rcontrib -ap bonzo-contrib.Cpm -o \%s.dat -e dummy=0 -b dummy \ -bn 256 -m bonzoLite -ab 1 bonzo.oct < sensors.pos d2166 26 a2191 21 However, because the contributions are already precomputed, the binning parameters passed to \cmd{rcontrib} must agree with those in the photon map, which is the user's responsibility. Due to the way \cmd{rcontrib} allocates its bins and output streams, the binning parameters are not automatically overriden in photon mapping mode\footnote{Yeah, this \emph{is} ugly and will hopefully change in a future release... once we figure out how, without breaking something! } Consequently, the number of bins originally passed to \cmd{mkpmap} must still be specified with the \opt{-bn} option. \cmd{rcontrib} will report an error indicating the expected bin count if it doesn't match the command line (or is omitted, defaulting to~1). Furthermore, \cmd{rcontrib} still requires a dummy binning function, specified with the \opt{-b} option, which can be defined with the \opt{-e} option. In photon mapping mode however, this function is never actually evaluated, since it is overridden by the pre-binned contributions from the photons. The boolean coefficient/contribution option \cmd{-V}, on the other hand, is automatically overriden by the photon map, and need not be specified. d2206 2 a2207 2 rcontrib -ap bonzo.Cpm -o %s-contrib.dat -e dummy=0 -b dummy \ -bn 256 -m bonzoLite bonzo.oct < sensors.pos d2216 3 a2218 4 Note the definition of a dummy binning function and the bin number \opt{-bn} in the \cmd{rcontrib} command; the binning function must be present on the command line, but is not evaluated, and the bin count must agree with that of the photon map. d2236 1 a2236 1 \label{fig:koester-luxtherm-half} d2844 6 a2849 2 for this purpose, \cmd{transpmap.py}, is available\footnote{Where?} to facilitate the generation of videos for given timespans and time @ 1.46 log @Revised to reflect non-overriding of binning parameters to rcontrib in pmap mode after it was clear this had disastrous sideeffects and corrupted output streams. Currently the user must specify -bn *and* a dummy binning function with -b/-e just so the cmdline is parsed, tho it's never evaluated. Hopefully we'll come up with something better. @ text @d34 2 a35 2 \RCS $Revision: 1.45 $ \RCS $Date: 2022/03/18 18:35:08 $ d946 6 a951 3 below), and output to file \var{pmapfile}. Each precomputed photon accumulates contributions from the \var{precompbwidth} nearest photons into bins (specified with the \opt{-bn} option, see below). d953 9 a961 4 is issued, since some bins will be zero. Ideally, \var{precompbwidth} should be a multiple of the number of bins. Only light sources may contribute, and are specified via their modifier(s) with the \opt{-m} option (see below). d3466 1 a3466 1 d3471 1 a3471 1 d3484 1 a3484 1 @ 1.45 log @Clarified examples for precomp contrib pmap, and that -bn is now overridden in rcontrib @ text @d34 2 a35 2 \RCS $Revision: 1.44 $ \RCS $Date: 2022/03/17 20:13:18 $ d1496 1 a1496 1 Generate 10 million contribution photons from all light source with d1500 4 a1503 2 for a grid of sensor positions in \cmd{rcontrib} (note the absence of option \opt{-bn}, which is overridden by the photon map): d1509 2 a1510 2 rcontrib -I -h -ap bonzo-contrib.Cpm -o \%s.dat -m bonzoLite -ab -1 \ bonzo.oct < sensors.pos d1942 1 a1942 1 Similarly, ray coefficients are supported by \cmd{mkpmap} via the d2144 30 d2178 1 d2188 2 a2189 2 rcontrib -I -h -ap bonzo.Cpm -o %s-contrib.dat -m bonzoLite -ab -1 \ bonzo.oct < sensors.pos d2198 4 a2201 3 Note the absence of the binning option \opt{-bn} to \cmd{rcontrib}; this parameter is overridden by the photon map and need not be specified again. @ 1.44 log @Major revisions, added documentation for precomputed contribution pmap, lightflow pmap, and transient pmap. @ text @d34 2 a35 2 \RCS $Revision: 1.43 $ \RCS $Date: 2021/09/05 21:33:28 $ d1496 6 a1501 3 Generate 10 million photons from light source \lit{bonzoLite}, and precompute 1 million of these by accumulating the contributions from the 2600 nearest photons into 256 bins, compressing them by 75\%: d1506 3 a2148 1 d2155 1 a2155 1 rcontrib -I -h -ap bonzo.Cpm -o \%s.dat -m bonzoLite -ab -1 \ d2160 8 a2167 5 where \var{sourcemodfile} is a file containing the list of light source modifiers to bin, and \var{sensorfile} is a file containing a list of sensor positions as input for the irradiance calculation. The contributions are output to separate files \lit{$*$-contrib.dat} prefixed by each light source modifier. @ 1.43 log @Revised polyhedral ROI stuff to only refer to polygonal geometry. @ text @d2 3 a4 1 \usepackage{color,graphicx,pslatex,rcs,gensymb,footmisc,listings,todonotes} d7 2 d19 2 d26 1 a26 2 xleftmargin=5pt, xrightmargin=5pt, %aboveskip=20pt, belowskip=20pt, d28 2 a29 1 breaklines, breakatwhitespace, showstringspaces=false} d31 2 d34 2 a35 2 \RCS $Revision: 1.42 $ \RCS $Date: 2021/09/03 22:30:05 $ d52 1 a52 1 d56 3 a58 3 Development of the \radiance{} photon map continues within a new project hosted by the Tokyo University of Science under the guidance of Prof. Nozomu Yoshizawa. The following features have been added: d60 9 d856 1 d862 1 a862 1 mkpmap -apg|-apc|-apv|-apd|-app|-apC \ d896 1 a896 1 d912 1 a912 25 \item{\opt{-apC} \var{pmapfile} \var{nphotons}}\\ Generate a light source contribution photon map containing approximately \var{nphotons} photons, and output to \var{pmapfile}. This may then be used by \cmd{rcontrib} to compute light source contributions. When used with \cmd{rpict}, contribution photon maps behave as regular global photon maps and yield cumulative contributions from all light sources. With this option, \cmd{mkpmap} uses a modified photon distribution algorithm that ensures all light sources contribute approximately the same number of photons. Each photon indexes a primary hitpoint, incident direction, and emitting light source which can be used to bin contributions per light source and direction. Note \cmd{mkpmap} cannot generate a contribution photon map in combination with others in a single run, as it uses a different distribution algorithm. Other photon maps specified on the command line will be ignored. See section \ref{sec:lsContribs} for details on using photon maps with \cmd{rcontrib}. d914 3 a916 3 Generate a precomputed global photon map containing a fraction of \var{nphotons} photons (specified with the \opt{-apP} option, see below), and output to \var{pmapfile}. d931 146 d1113 2 a1114 3 \item{% \opt{-api} \var{min_x} \var{min_y} \var{min_z} \var{max_x} \var{max_y} \var{max_z} d1128 1 a1128 3 \item{% \opt{-apI} \var{pos_x} \var{pos_y} \var{pos_z} \var{rad} }\\ d1201 5 a1205 5 \var{nphotons} global photons to precompute in the range $]0,1]$ when using the \opt{-app} option. The remaining photons are discarded. See section \ref{sec:precomp} for details on using precomputed global photons. d1272 29 d1324 6 a1329 1 \item{\opt{-e} \var{diagfile}}\\ d1343 1 a1343 1 limit. d1358 14 d1387 11 a1397 1 \item{\opt{-n} \var{nproc}}\\ a1400 7 This option is currently not available on M\$ Wind0z platforms.\footnote{Wind0z doesn't support \radiance's (admittedly legacy) UNIX-style \lit{fork()} parallel programming paradigm. The photon map extension grudgingly conforms to this convention, although POSIX threads are now clearly the preferred, portable approach.}\\ {\scriptsize So there. Tuff luck.} d1402 22 d1427 19 d1449 10 a1458 5 or \opt{-app} options must be specified. These can be combined subject to compatibility with the materials used in the scene. The \opt{-apC} option, in contrast, uses a different distribution algorithm and cannot be combined with the aforementioned; these will simply be ignored when generating a contribution photon map. d1473 2 a1474 1 \end{center} d1483 2 a1484 1 \end{center} d1494 27 a1520 3 \end{center} Generate a contribution photon map containing 10 million photons to bin light source contributions with \cmd{rcontrib}: d1524 2 a1525 1 mkpmap -apC bonzo-contrib.gpm 10m bonzo.oct d1528 1 a1528 2 \end{center} d1581 1 a1581 1 \label{fig:visualisation} d1616 1 d1623 1 a1623 1 \end{center} d1645 1 d1659 1 d1697 3 a1699 1 \item{\opt{-ap} \var{pmapfile} \var{[bwidth_1} \var{[bwidth_2]]}}\\ d1723 1 a1723 1 d1727 14 d1755 4 a1758 4 specified with the \opt{-ap} option; the number of photons found will not exceed the latter, but may be lower if the maximum search radius contains fewer photons, thus resulting in short lookups. Setting this radius too large, on the other hand, d1764 11 a1774 5 \item{\opt{-ac} \var{pagesize}} \footnote{These options are only available with out-of-core photon mapping. Check if they appear in the output of \cmd{rpict} \opt{-help} to verify that your software build supports out-of-core photon mapping, as this is a compile-time option.\label{cacheNote}}\\ d1787 1 a1787 1 \item{\opt{-aC} \var{cachesize}} \footref{cacheNote}\\ d1801 9 d1817 1 d1825 19 a1843 2 \end{center} d1847 4 a1850 1 \section{Photon Mapping with Light Source Contributions} d1853 1 a1853 1 The \radiance{} photon map has been adapted to facilitate the d1855 2 a1856 1 climate-based daylight simulation \cite{Schr2015}. In this workflow, d1858 84 a1941 9 representing different time-dependent positions (e.g. solar elevations depending on season and time of day) of one source, which are handled as aggregate for efficient simulation. The \cmd{rcontrib} tool supplied with \radiance{} can then determine the irradiance for each light source for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by ``binning'' the resulting irradiance into separate output files for each light source. See the \cmd{rcontrib} man page for details. d1948 1 a1948 2 accordingly, which can raise the variance of the resulting density estimates. d1950 59 a2008 9 The generated photon map contains a list of primary hitpoints, incident directions, and emitting light sources, which are indexed by each photon which is spawned along the primary ray's path. This information is used to identify the emitting light source for each photon map, as well as apply an additional binning function to the incident direction via the \opt{-b} option as documented in the \cmd{rcontrib} man page, e.g. to identify contributions from individual sky patches. An example of binned photon contributions is shown in \autoref{fig:tregContribs} for patches from a Tregenza sky. d2010 1 a2010 1 \begin{figure}[tb] d2013 61 a2073 2 \begin{minipage}{0.9\linewidth} \includegraphics[width=\linewidth]{srcbin-skyglow-tregenza} d2076 12 a2087 5 \label{fig:tregContribs} Comparison of photon contributions from 145 Tregenza sky patches (blue) to the indirect irradiance obtained with \radClassic{} (red) on an interior ceiling sensor via a window facing south. d2092 1 a2092 1 \end{figure} d2094 46 a2139 8 Unlike \cmd{rcontrib}, the photon map only supports contributions from light sources, not arbitrary modifiers. Ray coefficients are supported via the \opt{-V-} option, which amounts to normalising the emission of each light source for {\it a posteriori\/} scaling without rebuilding the photon map. Using fewer photons than there are light sources for photon density estimates results in omitted contributions, thus \cmd{rcontrib} clamps the bandwidth accordingly and issues a warning. d2143 1 d2147 2 a2148 1 mkpmap -apC $contribpmap$ $nphotons$ $octree$ d2150 2 a2151 2 rcontrib -ap $causticpmap$ $bwidth$ -I -h -V -fo \ -o %s-contrib.dat -M $sourcemodfile$ $octree$ < $sensorfile$ d2154 1 a2154 1 \end{center} d2190 747 d2942 1 d2945 5 a2949 2 the information about a photon map from the header of the corresponding file. The output has the following format: d2955 20 a2974 3 $N_p$ photons @@ [$\phi_r$, $\phi_g$, $\phi_b$] avg watts FORMAT=$fmt$ VERSION=$ver$ d2977 2 a2978 2 \end{center} where d2982 44 a3025 3 \item \var{N_p} is the number of photons in the photon map, \item \var{[\phi_r, \phi_g, \phi_b]} is the photon flux averaged over the RGB colour channels, d3032 8 a3039 2 \item \lit{Radiance\_Direct\_Photon\_Map} or \item \lit{Radiance\_Contrib\_Photon\_Map} a3043 2 As with other file types, \cmd{getinfo} can query multiple photon maps in one command line. d3048 1 d3057 4 a3060 3 be seen in \autoref{fig:cornell_distrib}~(right), \autoref{fig:roi} and \autoref{fig:pmapdump-sunpu}. d3083 1 a3083 1 \item[\textcolor{green}{Green}:] volume photon d3085 2 a3086 1 \item[\textcolor{yellow}{Yellow} (Yellow):] contribution photon d3101 1 a3101 1 \label{fig:pmapdump-sunpu} d3118 1 a3118 1 \begin{minipage}{0.95\linewidth} d3120 4 a3123 5 pmapdump [-a] [-n $num_1$] [-r $radscale_1$] [-f] \ [-c $rcol_1$, $gcol_1$, $bcol_1$] $pmap_1$ \ [-a] [-n $num_2$] [-r $radscale_2$] [-f] \ [-c $rcol_2$, $gcol_2$, $bcol_2$] $pmap_2$ \ $\ldots$ d3126 1 a3126 1 \end{center} d3146 7 d3167 2 a3168 2 with \cmd{pcond} for visualisation. This option is mutually exclusive with \opt{-c}. d3179 19 d3207 1 a3207 1 for point list output in conjuction with \opt{-a}. d3278 1 a3278 1 \label{fig:sunpu-cc} d3301 1 a3301 1 the German Research Foundation (DFG LU204/10-2, d3304 6 a3309 4 supported by the Swiss National Science Foundation (SNSF 147053, \textit{% Simulation based assessment of daylight redirecting components for energy savings in office buildings% d3312 1 a3312 1 for Scientific Research Programme (KAKENHI JP19KK0115, \textit{% d3315 1 a3315 1 human‐centric lighting design% d3323 13 a3335 8 \item[Dr. Peter Apian-Bennewitz] for initiating development of the photon map at Fraunhofer ISE, \item[Prof. Stephen Wittkopf and Dr. Lars Grobe] for re-igniting development within the scope of the \textit{Daylight redirecting components} project at HSLU, \item[Prof. Nozomu Yoshizawa] and his team for initiating the project \textit{Three-dimensional light flow} at Tokyo University of Science and applying photon mapping in their experiments, d3337 2 a3338 2 under Windoze and providing nightly builds for that platform, 'cos The Developer(s) doan' do Windoze, d3341 1 a3341 1 providing valuable feedback. d3363 19 d3401 5 a3405 8 \bibitem[Ward1994]{Ward1994} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. \textit{Proceedings SIGGRAPH~'94}, July~1994. \bibitem[Ward1998]{Ward1998} Greg Ward Larson and Rob Shakespeare: \textit{Rendering with \radiance}. Morgan Kaufmann, San Francisco, 1998. d3427 50 a3476 1 New York City, New York, USA, August~2019. d3486 1 a3486 1 \section*{Appendix} d3502 1 a3502 1 \label{fig:prismella} d3565 1 a3565 1 \begin{figure}[h!] d3568 2 a3569 1 \begin{minipage}{0.98\linewidth} d3575 1 a3575 1 \label{fig:cpc-xsection} d3587 1 a3587 1 \begin{figure}[h!] d3590 3 a3592 2 \begin{minipage}{0.64\linewidth} \includegraphics[width=\linewidth]{cornell-volume}\\% d3595 1 a3595 1 \label{fig:cornell-volume} d3609 1 a3609 1 \section{Parameter Ranges} @ 1.42 log @Mentioned overlapping surfaces as potential degeneracy of polyhedral ROIs. @ text @d26 2 a27 2 \RCS $Revision: 1.41 $ \RCS $Date: 2021/09/02 19:05:18 $ d587 1 a587 1 (rectangles) or spheres, or as material modifiers specifying surfaces that d636 1 a636 1 of the geometry, it is more convenient to specify the actual geometry d693 1 a693 1 Individual surfaces (polygons) comprising \textbf{polyhedral ROIs} are d704 1 a704 1 specify the geometry surrounding the ROI, as these will typically use d710 1 a710 1 are infact closed nor degenerated (i.e. with overlapping surfaces) -- d951 1 a951 1 Defines all surfaces using the material modifier \var{mod} as part of d955 2 a956 1 surfaces into a polyhedron. Note that no check is made to ensure the d958 1 a958 1 overlapping surfaces) -- this is the user's responsibility. @ 1.41 log @Added polyhedral ROIs to section "what's new". @ text @d26 2 a27 2 \RCS $Revision: 1.40 $ \RCS $Date: 2021/09/02 19:00:27 $ d710 2 a711 2 are infact closed nor degenerated (i.e. overlapping) -- this is the user's responsibility. d956 2 a957 2 polyhedron is closed and not degenerated -- this is the user's responsibility. @ 1.40 log @Minor corrections regarding ROIs @ text @d26 2 a27 2 \RCS $Revision: 1.39 $ \RCS $Date: 2021/09/02 15:23:18 $ d59 4 @ 1.39 log @Added -aph/-apH polyhedral ROIs @ text @d26 2 a27 2 \RCS $Revision: 1.38 $ \RCS $Date: 2021/06/08 22:14:16 $ d647 6 a652 4 Volume photon distribution (visualised with \cmd{pmapdump}) within an octagonal interior. A global \lit{mist} was defined on the command line to deposit the volume photons. Without constraint, photons reflected or transmitted through d655 2 a656 2 stored in the exterior. By defining a polyhedral region of interest comprised of polygons surrounding the interior d659 3 a661 2 interior. This is conviently done by specifying the corresponding material modifiers of the geometry. d947 1 a947 1 Define all surfaces using the material modifier \var{mod} as part of d962 1 a962 1 Read modifiers comprising polyhedral regions of interest (ROIs) from d972 5 a976 5 Defines a rectangular region of interest (ROI) within which to store photons exclusively; photons will only be stored within the volume bounded by the given minimum and maximum coordinates. Multiple instances of this option may be specified with cumulative effect to define compound ROIs. @ 1.38 log @Documented ETA in mkpmap progress reports, Documented issues with polygonal sources/ports. @ text @d26 2 a27 2 \RCS $Revision: 1.37 $ \RCS $Date: 2021/06/08 21:25:38 $ d581 7 a587 14 of interest, or ROIs, in which to exclusively store photons. This is done by supplying appropriate 3D coordinates defining bounding boxes as $(min_x, min_y, min_z, max_x, max_y, max_z)$ to \cmd{mkpmap} via mutiple instances of the \opt{-api} option. Photons are then only stored if their hitpoints lie within one of the defined ROIs, in which case it will be added to the photon map. The photon path and the resulting contribution to the lighting solution remains unaffected; path segments entering a ROI will deposit photons, while those leaving a ROI will not. Note that the number of stored photons remains approximately the same, but the photon map generation can take considerably longer, depending on the volume and location of the ROIs relative to the photon trajectories. d596 1 a596 9 ROIs are an advanced option with inherent pitfalls, as excluding photons from the scene can lead to bias. It is assumed that the user can estimate the bias that results from omitting the indirect illumination contributed by the excluded photons outside the ROI. For example, using a ROI corresponding to the abovementioned interior to estimate glare from the fenestration would clearly lead to underestimation as interreflections within the fenestration are omitted. d613 3 a615 3 region of interest corresponding to the room's extent with the \opt{-api} option, \cmd{mkpmap} only deposits photons in the interior, resulting in an d628 57 d686 39 d942 22 d969 3 a971 3 Defines a rectangular region of interest within which to store photons exclusively; photons will only be stored within the volume bounded by the given minimum and maximum coordinates. Multiple d973 4 a976 4 to define compound regions of interest. This is useful for constraining photons to only the relevant regions of a scene, but d985 1 a985 1 given radius, centred at the given coordinates. @ 1.37 log @Minor corrections/rewording, documented trivalent -aps option for bidirectional virtual sensor surfaces. @ text @d26 2 a27 2 \RCS $Revision: 1.36 $ \RCS $Date: 2021/04/13 15:30:42 $ d722 1 a722 1 $p\ $% after $t$ hours d734 1 d2079 2 a2080 1 \section{Bugs and Weirdness} d2098 10 d2149 2 a2150 1 light sources see no geometry & d2153 13 a2165 1 \hline d2179 2 a2180 14 \hline \hline Excessive noise in photon irradiance & Bandwidth too low & Increase bandwidth \\ \hline Excessive blurring in photon irradiance & Bandwidth too high & Decrease bandwidth or increase size of photon map \\ \hline Excessive noise and blurring in different regions & Bandwidth is fixed & Apply bias compensation for dynamic bandwidth \\ \hline d2184 1 a2184 1 \hline d2192 1 a2192 1 \hline d2199 1 a2199 1 \hline d2207 1 a2207 1 \hline d2211 8 a2218 1 \hline d2222 1 a2222 1 \hline @ 1.36 log @Documented mkpmap's -apI option. @ text @d26 2 a27 2 \RCS $Revision: 1.35 $ \RCS $Date: 2021/03/23 21:39:44 $ d602 1 a602 1 fenestration. An example of this is shown in figure \ref{fig:roi}. d604 1 a604 1 ROIs are an advances option withinherent pitfalls, as excluding photons d623 1 a623 1 \label{fig:roi} d641 1 a641 1 \end{figure} d908 2 a909 2 By default, ports are oriented to emit in the halfspace defined by their associated surface normal. This can be overridden by d915 1 a915 2 photons are emitted into the halfspace facing away from the surface normal, d947 3 a949 2 instances of \opt{-apo}. d963 1 a963 1 \item{\opt{-aps} \var{sensmod}}\\ d970 3 a972 1 as an invisible photon receiver. d981 12 a992 5 Note that photons are only deposited when incident from the front side of the sensor surface, i.e. when entering the \lit{antimatter}, thus the surface normal is relevant. \cmd{mkpmap} reports an error if the specified modifier is not an \lit{antimatter} material. d994 1 a994 4 See figure \ref{sec:roi} for an example of a sensor surface in action. \item{\opt{-apS} \var{sensfile}}\\ d997 3 a999 2 multiple instances of \opt{-aps}. @ 1.35 log @Increased --> reduced for higher res -ds! @ text @d26 2 a27 2 \RCS $Revision: 1.34 $ \RCS $Date: 2021/03/23 21:25:09 $ d137 1 a137 1 \section{Overview of the Implementation} d583 1 a583 1 $(x_{min}, y_{min}, z_{min}, x_{max}, y_{max}, z_{max})$ to d861 5 a865 3 \item{\opt{-api} \var{x_{min}} \var{y_{min}} \var{z_{min}} \var{x_{max}} \var{y_{max}} \var{z_{max}}}\\ Defines a region of interest within which to store photons d877 6 @ 1.34 log @Clarified interplay of photon ports and mkpmap's -dp and -ds opts. @ text @d26 2 a27 2 \RCS $Revision: 1.33 $ \RCS $Date: 2020/08/12 00:45:28 $ d1028 1 a1028 1 extent, and may need to be increased for modified light sources with @ 1.33 log @Revised -apo option documentation for mkpmap, extended example scenarios for photon port reorientation by use case with BSDF. @ text @d26 2 a27 2 \RCS $Revision: 1.32 $ \RCS $Date: 2020/08/07 00:28:02 $ d889 1 a889 1 of any light sources defined with the \lit{source} material. d931 6 d1015 1 a1015 1 distribution of a modified light source (e.g. via d1018 1 a1018 1 by the source, and may need increasing with complex d1023 7 a1029 6 resolution for photon emission from light sources. A light source is spatially partitioned to distribute the photon emission over its surface. This parameter specifies the ratio of the size (per dimension) of each partition to the scene cube extent, and may need increasing for modified light sources with high spatial variation. d1783 2 a1784 2 Development of the \radiance{} photon map was contributed by the following institutions: d1802 1 a1802 1 The developer(s) would also like to thank the following individuals for d1814 7 a1820 2 and applying photon mapping in their experiments. d1822 2 a1823 4 Many thanks also to those who took the time to test the tool with \realLife\ scenes and report bugs and provide valuable feedback, in particular \textbf{Carsten Bauer} (Capt.~B) at Radzilla.org, and \textbf{Dr. David Geisler-Moroder} at Bartenbach GmbH. @ 1.32 log @Major revisions and reorganisation, added frames to figures, set commands and output samples in listings style. Added Sunpu lightflow renderings. Cited ongoing Lightflow project with Tokyo Uni of Science. Documented new -apo photon port orientation options for mkpmap. Added Lightflow presentation at RADIANCE 2019 to references. Etc, etc, etc.... @ text @d26 2 a27 2 \RCS $Revision: 1.31 $ \RCS $Date: 2019/08/14 18:07:00 $ d912 18 a929 8 Situations that call for a reversed photon port include, for example, (a) using fenestrations as ports that were (for whatever reason) defined with outward facing normals, without having to revise the model, or (b) using a \lit{mist} primitive as a port, since this requires outward facing normals in order to register the photons as having entered the volume. Other oddball scenarious are conceivable. If in doubt, just use the default. Doan' mess with da normalz. @ 1.31 log @Documented scaling of photon flux by dump ratio when using pmapdump's -f option. @ text @d2 1 a2 1 \usepackage{color,graphicx,pslatex,rcs,gensymb,footmisc} d17 11 a27 2 \RCS $Revision: 1.30 $ \RCS $Date: 2019/01/22 19:46:56 $ d30 5 a34 3 \author{Roland Schregle (roland.schregle@@\{hslu.ch, gmail.com\})\\ CC Building Envelopes\\ Lucerne University of Applied Sciences and Arts} d48 11 a58 29 Development of the \radiance{} photon map extension has resumed as of november 2013, with the following new features and extended functionality: \begin{itemize} \item Full integration with official \radiance{} distribution \item Support for \lit{bsdf} material \item (Very) basic support for \lit{plasfunc, metfunc, transfunc, plasdata, metdata, transdata}, and \lit{brtdfunc} materials. \item Support for light source contributions via \cmd{rcontrib} \item Support for regions of interest and maximum photon path length \item Selective inclusion/exclusion of modifiers \item Simplified parametrisation with \cmd{rpict} \item Improved maximum search radius for photon lookups \item Improved support for virtual \lit{antimatter} sensor surfaces. \item Renamed some \cmd{mkpmap} options for consistency with \cmd{rpict}; old options kept for interim backwards compatibility. \item Deprecated \cmd{mkpmap}'s \opt{-i} option. \item More output options for \cmd{pmapdump}. \item Optional build using out-of-core data structure for very large photon maps \cite{Schr16}. \item Synced PDF manual and manpages. \item Bugfixes! (Wheeee!) \textbf{:-)} \item \textcolor{red}{ {\bf ATTENTION}: Photon port normals now point \underline{towards the interior} as per \cmd{mkillum} convention! } d62 2 a63 2 \section{Introduction} d65 1 a65 1 The \radiance{} rendering system \cite{Ward94} is a very versatile and d81 1 a81 1 \cite{Ward98}, d88 1 a88 1 The problem is actually far more fundamental due to \radiance's backward d93 12 a104 6 \includegraphics[width=0.7\linewidth]{IMG_5048b} \parbox{0.7\linewidth} {\caption{\small Photograph of caustic from retroreflecting lamella (patented by Helmut K\"oster).} \label{fig:caustic}} d109 2 a110 2 above as a supplementary algorithm. The photon map \cite{Jens96, Jens97, Jens00} was chosen for a number of reasons: d120 1 a120 1 participating media \cite{Jens98}. d136 1 a136 1 d163 20 a182 16 \mbox{}\hfill% \includegraphics[width=0.44\linewidth]{cornell-distrib1}% \hspace{0.02\linewidth}% \includegraphics[width=0.44\linewidth]{cornell-distrib2}% \hfill\mbox{}\\% \parbox{0.9\linewidth} {\caption{\small Global photon distribution in the Cornell box. Left: global and caustic photon paths during forward pass. Dots indicate stored photons, where blue represents global photons, and red represents caustic photons. Right: photon distribution after completion of forward pass (visualised with \cmd{pmapdump}). Note the concentration of caustic photons on the back wall reflected from the glass sphere.} \label{fig:cornell_distrib}} d187 14 a200 8 \resizebox{0.7\linewidth}{!}{\input{figs/nnsearch}} \parbox{0.75\linewidth} {\caption{\small Gathering photons via nearest neighbour search. The number of gathered photons defines the \lit{bandwidth}, or intercepted area, of the density estimate use to evaluate the irradiance.} \label{fig:nnsearch}} d210 25 a234 8 \begin{quote} \cmd{mkpmap} \var{pmap_1} \var{pmap_2\ldots} \var{[options]\ldots}\\ \cmd{rpict}$|$\cmd{rtrace}$|$\cmd{rvu} \var{pmap_1} \var{pmap_2\ldots} \var{[options]\ldots} \end{quote} Four photon types are available, which are stored in separate photon maps d243 2 a244 1 participating media using the \lit{mist} primitive. d246 12 a257 1 and areintended as a debugging option. d302 1 d304 4 a307 1 In order for volume photons to function correctly with materials d310 1 a310 1 surround the light source(s) and viewpoint with a mist boundary (e.g. d314 6 a319 7 Participating media are essentially hacked into \radiance, and this calls for peculiar workarounds. In order to get volume caustics from light passing through an object, it must also be surrounded by a mist boundary. Alternatively, the mist parameters can be set globally on the command line, however this requires setting the source and viewpoint boundaries' extinction to zero, otherwise extinction is accumulated. d324 2 a325 2 of mist, e.g. a mist boundary for the entire scene. All this just to make life more interesting. d327 5 d353 14 a366 15 Light sources may be modified by function files. During photon emission, the predefined variables passed to them (see \lit{ rayinit.cal}) are defined in terms of the photon origin on the light source: \begin{itemize} \item the emitted photon's direction \var{D_x}, \var{D_y}, and \var{D_z} points towards the photon origin \item \var{N_x}, \var{N_y}, and \var{N_z} is the normal on the light source surface at the photon origin \item \var{P_x}, \var{P_y}, and \var{P_z} is the emitted photon's origin \item \var{T} and \var{Ts} are undefined \item \var{Rdot} is the dot product of the surface normal and the photon's direction at its origin. \end{itemize} d383 12 a394 13 Per Christensen's precomputed photon mapping approach \cite{Chri00} has been integrated into the implementation and is available as an option to accelerate the global photon gathering step. Global photon irradiance is precomputed for a fraction of the photon positions and stored with the photons, while the rest are discarded. This reduces the overhead of global photon lookups during the gathering phase; only the single closest global photon is retrieved, and its precomputed irradiance can be used directly (figure \ref{fig:precomp}). This approximation has the disadvantage of introducing bias to the solution for scenes with nonuniform indirect illumination. Precomputation may be combined with bias compensation (see below), albeit to marginal advantage. d398 12 a409 6 \includegraphics[width=0.6\linewidth]{precomp}\\% \parbox{0.6\linewidth} {\caption{\small Directly visualised precomputed global photon irradiance. Note the caustic from the glass sphere.} \label{fig:precomp}} d424 1 a424 1 \cite{Schr03} was developed and incorporated into the density d442 19 a460 15 \mbox{}\hfill% \includegraphics[angle=-90, width=0.44\linewidth] {spot-bias-50000-false}% \hspace{0.02\linewidth}% \includegraphics[angle=-90, width=0.44\linewidth] {spot-biascomp-50000-false}% \hfill\mbox{}\\% \parbox{0.9\linewidth} {\caption{\small Left: falsecolour rendering of severely biased caustic with a bandwidth of 5000 photons. The caustic should have an irradiance of 10 $W/m^2$. Right: falsecolour rendering of the same caustic with bias compensation using a bandwidth of 50--5000 photons.} \label{fig:biascomp}} d490 2 a491 2 can manually override this automation and specify a fixed maximum search radius. d514 1 a514 1 A simple workaround to the problem is the concept of photon \emph{ d517 7 a523 6 skylights, but also invisible polygons within the scene (figure \ref{fig:port}). The primary drawback to this scheme is that it requires user intervention. The user must define the port geometry and specify them according to their modifiers. If the user places the ports intelligently, the photon loss factor will be reduced dramatically, resulting in a substantial increase in performance. d527 14 a540 8 \includegraphics[width=0.75\linewidth]{port4} \parbox{0.8\linewidth} {\caption{\small Typical daylighting geometry with window as photon port for directional light sources. Note that external reflections are not accounted for by photons emitted from the port.} \label{fig:port}} d546 2 a547 4 faces. \emph{Port objects must be defined with their surface normals pointing \underline{inside}} as per \cmd{mkillum} convention. The incident flux from directional sources is evaluated at each port and the sources are checked for occlusion. However, no interreflection d552 10 d571 1 a571 1 parametrisation on behalf of the user. A more general approach using d573 2 a574 2 without user intervention may materialise one day. {\scriptsize (Or not. Probably not.)} d614 26 a639 23 \mbox{}\hfill% \includegraphics[width=0.44\linewidth]{scene-000-pmapdump-100k}% \hspace{0.02\linewidth}% \includegraphics[width=0.44\linewidth]{scene-000-pmapdump-100k-roi}% \hfill\mbox{}\\% \parbox{0.9\linewidth}{ \caption{ \label{fig:roi} \small Photon distributions (visualised with \cmd{pmapdump}) within an interior fitted with a redirecting system. Without constraint, the majority of photons are stored in the fenestration due to interreflection (left). By defining a region of interest corresponding to the room's extent with the \opt{-api} option, \cmd{mkpmap} only deposits photons in the interior, resulting in an improved distribution and rendering quality (right). This example also uses an invisible \lit{antimatter} sensor surface (defined via the \opt{-aps} option) to deposit photons at work plane height. This is noticeably underpopulated without ROI, thus impacting illuminance measurements on it. } d644 1 a644 1 d651 1 a651 1 subdividing data structure \cite{Bent75} which facilitates nearest d674 1 a674 1 d717 9 a725 5 \begin{quote} \var{N_e} emitted, \var{N_g} global, \var{N_c} caustic, \var{N_v} volume, \var{N_d} direct,\\ \var{P}\% after \var{T} hours, \end{quote} d732 2 a733 2 \item \var{P} is the percentage completed \item \var{T} is the time elapsed. d739 7 a745 3 \begin{quote} {\tt \var{N_p} precomputed, \var{P}\% after \var{T} hours}, \end{quote} d752 9 a760 10 \begin{center} \begin{tabular}{l l} \centering \cmd{mkpmap} & \opt{-apg}$|$\opt{-apc}$|$\opt{-apv}$|$ \opt{-apd}$|$\opt{-app}$|$\opt{-apC} \var{file} \var{nphotons} [\var{bwidth}] $\ldots$\\ & [\var{options}] \var{octree}\\ \end{tabular} \end{center} d764 1 a764 1 \item{\opt{-apg} \var{file} \var{nphotons}}\\ d766 1 a766 1 \var{nphotons} photons, and output to \var{file}. This accounts d772 1 a772 1 \item{\opt{-apc} \var{file} \var{nphotons}}\\ d774 1 a774 1 \var{nphotons} photons, and output to \var{file}. d782 1 a782 1 \item{\opt{-apv} \var{file} \var{nphotons}}\\ d784 1 a784 1 \var{nphotons} photons, and output to \var{file}. These account d790 1 a790 1 \item{\opt{-apd} \var{file} \var{nphotons}}\\ d792 1 a792 1 \var{nphotons} photons, and output to \var{file}. This only d806 1 a806 1 \item{\opt{-apC} \var{file} \var{nphotons}}\\ d809 1 a809 1 \var{file}. This may then be used by \cmd{rcontrib} to compute d830 1 a830 1 \item{\opt{-app} \var{file} \var{nphotons} \var{bwidth}}\\ d833 1 a833 1 \opt{-apP} option, see below), and output to \var{file}. d836 1 a836 1 irradiance is evaluated with a bandwidth of \var{bwidth} d886 2 a887 2 \item{\opt{-apo} \var{mod}}\\ Specifies a modifier \var{mod} to act as a photon port. All d892 2 a893 1 emitting light source via an opening, or port. d895 25 a919 6 A typical application is daylight simulation, where a fenestration acts as port to admit photons into an interior after emission from an external light source. See section \ref{sec:ports} for details on using photon ports. Multiple instances of this option may be specified. d921 2 a922 2 \item{\opt{-apO} \var{file}}\\ Read photon port modifiers from the file \var{file}, separated d939 2 a940 2 \item{\opt{-aps} \var{mod}}\\ Specifies a modifier \var{mod} defined as \lit{antimatter} d958 1 a958 1 relevant. \cmd{Mkpmap} reports an error if the specified d964 2 a965 2 \item{\opt{-apS} \var{file}}\\ Read virtual sensor surface modifiers from the file \var{file}, d969 3 a971 3 \item{\opt{-ae} \var{mod}}\\ Add \var{mod} to the ambient exclude list, so that it will be ignored by the photon map. Objects having \var{mod} as their d976 1 a976 1 \item{\opt{-aE} \var{file}}\\ d978 1 a978 1 \var{file}, separated by whitespace. d980 3 a982 3 \item{\opt{-ai} \var{mod}}\\ Add \var{mod} to the ambient include list, so that it will contribute to the photon map. Only objects having \var{mod} as d988 1 a988 1 \item{\opt{-aI} \var{file}}\\ d990 1 a990 1 \var{file}, separated by whitespace. d1014 2 a1015 2 \item{\opt{-e} \var{file}}\\ Redirect diagnostics and progress reports to \var{file} instead of d1059 10 a1068 3 Use \var{nproc} processes for parallel photon distribution. There is no benefit in specifying more than the number of physical CPU cores available. d1081 43 d1126 1 d1165 1 a1165 1 \cite{Chri00}, see figure \ref{fig:visualisation}). This reduces d1169 20 a1188 1 d1204 1 a1204 15 \begin{figure}[!htb] \centering \includegraphics[width=0.6\linewidth]{visualisation} \parbox{0.75\linewidth} {\caption{\small Caustic photons are visualised at the primary ray, while an intermediate stratified sampling step is used between the primary ray and the global photon density estimate (\emph{final gather}).} \label{fig:visualisation}} \end{figure} d1212 7 a1218 4 \begin{quote} \var{N_{min}/N_{max}/N_{avg}} \var{ptype}, (\var{\epsilon_{min}/\epsilon_{max}/\epsilon_{rms}} error), \end{quote} d1221 1 a1221 1 \item \var{N_{min}}, \var{N_{max}}, and \var{N_{avg}} are the minimum, d1224 4 a1227 4 \item \var{ptype} is one of \lit{global}, \lit{caustic}, \lit{volume}, or \lit{direct}. \item \var{\epsilon_{min}}, \var{\epsilon_{max}}, and \var{\epsilon_{rms}} are the minimum, maximum, and RMS (root mean d1253 11 a1263 10 \begin{verse} \cmd{mkpmap} \opt{-apg} \var{globalpmap} \var{nphotons} \opt{-apc} \var{causticpmap} \var{nphotons} \textbackslash\\ \qquad \var{octree} \\ \cmd{rpict} \opt{-ap} \var{globalpmap} \var{bwidth} \opt{-ap} \var{causticpmap} \var{bwidth} \opt{-ab} 1 \opt{-vf} \var{view} \textbackslash\\ \qquad \var{octree} \end{verse} d1265 1 a1265 1 parameters may need modification in some cases to improve the d1267 3 a1269 2 \radClassic{} with extended semantics in conjunction with photon maps. The \cmd{rpict} photon mapping options are as follows: d1290 1 a1290 1 \item{\opt{-ap} \var{file} \var{[bwidth_1} \var{[bwidth_2]]}}\\ d1344 2 a1345 2 software version supports out-of-core photon mapping.\label{cacheNote}}\\ d1373 126 d1502 3 a1504 1 \section{Querying the Photon Map with \cmd{getinfo}} d1509 11 a1519 7 \begin{quote} \#?RADIANCE\\ \var{cmdline}\\ \var{N_p} photons @@ \var{[\phi_r, \phi_g, \phi_b]} avg watts\\ FORMAT=\var{fmt}\\ VERSION=\var{ver} \end{quote} d1536 2 a1537 1 \item \var{ver} is a file format version number to ensure compatibility. d1544 1 a1544 1 \section{Visual Examination with \cmd{pmapdump}} d1546 2 d1553 3 a1555 2 be seen in \autoref{fig:cornell_distrib}(right) and \autoref{fig:roi}. d1588 22 d1611 11 a1621 14 \begin{verse} \cmd{pmapdump} [\opt{-a}] [\opt{-n} \var{num_1}] [\opt{-r} \var{radscale_1}] [\opt{-f} $|$ \opt{-c} \var{rcol_1} \var{gcol_1} \var{ bcol_1}] \textbackslash\\ \qquad\qquad\qquad \var{pmap_1} \textbackslash\\ \qquad\qquad\qquad [\opt{-a}] [\opt{-n} \var{num_2}] [\opt{-r} \var{radscale_2}] [\opt{-f} $|$ \opt{-c} \var{rcol_2} \var{gcol_2} \var{ bcol_2}] \textbackslash\\ \qquad\qquad\qquad \var{pmap_2} \ldots \end{verse} d1639 1 a1639 1 viewer. d1679 3 d1688 3 d1694 11 a1704 9 \begin{verse} \cmd{pmapdump} \opt{-n} \lit{5k} \opt{-c} \lit{1 0.4 0.4} \lit{global.pm} \textbackslash\\ \qquad\qquad\qquad \opt{-n} \lit{10k} \opt{-c} \lit{0.4 0.4 1} \lit{caustic.pm} \textbackslash\\ \qquad\qquad\qquad $|$ \cmd{oconv} - \lit{scene.rad} $>$ \lit{scene\_pm.oct}\\ \cmd{rvu} \lit{scene\_pm.oct} \end{verse} d1711 8 a1718 6 \begin{verse} \cmd{pmapdump} \opt{-n} \lit{10k} \opt{-f} \lit{caustic.pm} \textbackslash\\ \qquad\qquad\qquad $|$ \cmd{oconv} - \lit{scene.rad} $>$ \lit{scene\_pm.oct} \end{verse} d1722 7 a1728 3 \begin{verse} \cmd{pmapdump} \lit{zombo.pm} $|$ \cmd{objview} \end{verse} d1731 8 a1738 9 cloud viewer: \begin{verse} \cmd{pmapdump} \opt{-a} \opt{-f} \opt{-n} \lit{10k} \lit{lotsa.pm} $>$ \lit{lotsa\_pointz} \end{verse} \section{Photon Mapping with Light Source Contributions} \label{sec:lsContribs} d1740 1 a1740 65 The \radiance{} photon map has been adapted to facilitate the computation of light source contributions for annual and climate-based daylight simulation \cite{Schr15}. In this workflow, the scene supplied to \cmd{mkpmap} contains multiple light sources representing different time-dependent positions (e.g. solar elevations depending on season and time of day) of one source, which are handled as aggregate for efficient simulation. The \cmd{rcontrib} tool supplied with \radiance{} can then determine the irradiance for each light source for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by ``binning'' the resulting irradiance into separate output files for each light source. See the \cmd{rcontrib} man page for details. In support of light source contributions, \cmd{mkpmap} uses a modified photon distribution algorithm via the \opt{-apC} option that ensures each light source contributes approximately the same number of photons, irrespective of its emitted flux. To compensate and maintain energy balance, the flux of each photon is adjusted accordingly, which can raise the variance of the resulting density estimates. The generated photon map contains a list of primary hitpoints, incident directions, and emitting light sources, which are indexed by each photon which is spawned along the primary ray's path. This information is used to identify the emitting light source for each photon map, as well as apply an additional binning function to the incident direction via the \opt{-b} option as documented in the \cmd{rcontrib} man page, e.g. to identify contributions from individual sky patches. Unlike \cmd{rcontrib}, the photon map only supports contributions from light sources, not arbitrary modifiers. Ray coefficients are supported via the \opt{-V-} option, which amounts to normalising the emission of each light source for {\it a posteriori\/} scaling without rebuilding the photon map. Using fewer photons than there are light sources for photon density estimates results in omitted contributions, thus \cmd{rcontrib} clamps the bandwidth accordingly and issues a warning. A typical invocation of the \radiance{} photon map with light source contributions consists of the following: \begin{verse} \cmd{mkpmap} \opt{-apC} \var{contribpmap} \var{nphotons} \var{octree}\\ \cmd{rcontrib} \opt{-I -h -V -fo -o \%s}\var{contribfile} \opt{-M} \var{modfile} \textbackslash\\ \qquad\qquad \opt{-ap} \var{contribpmap} \var{bwidth} \var{octree} $<$ \var{sensorpos}, \end{verse} where \var{contribfile} is the suffix for the output bin files per light source, \var{modfile} is a file containing the list of light source modifiers to bin, and \var{sensorpos} is a list of sensor positions as input for the irradiance calculation. An example of a visual analysis of a redirecting component for a half year using contribution photons is shown in figure \ref{fig:koester-luxtherm-half}. The performance of the system (consisting of retroreflecting blinds) can be assessed subject to seasonal daylight availability. Redirection towards the ceiling is evident particularly from January to April. Transmission, on the other hand, occurs at low solar angles until March, before transitioning into retroreflection at high solar angles. \begin{figure}[p] d1742 16 a1757 11 \includegraphics[width=\linewidth]{koester-luxtherm-half} \parbox{\linewidth}{ \caption{ \label{fig:koester-luxtherm-half} Retroreflecting blinds at 26 solar angles for a half year (January to June with weekly intervals) rendered with contribution photon map and \cmd{rcontrib}. In each instance the time of day is 1:00pm. Redirection and transmission dominate until March, while retroreflection dominates in the following months. } a1759 1 a1761 1 \section{Bugs and Weirdness} d1763 2 a1764 1 \begin{itemize} d1766 38 a1803 8 \item The spotlight focal point is ignored by the photon map; it coincides with the light source surface. This corresponds to specifying a direction vector of infinitesimal length in \radClassic. \item \cmd{mkpmap}'s distribution algorithm can exceed the specified number of photons with scenes having high reflectance or when excessively high settings of \opt{-apD} are used. a1804 5 \item Caustic photon irradiance will be biased when passing \cmd{rtrace} points which do not lie on a surface, unless a virtual receiver surface is defined with \lit{antimatter} and specified with \cmd{mkpmap}'s \opt{-aps} or \opt{-apS} option, as detailed in section \ref{sec:mkpmap}. a1805 1 \end{itemize} d1807 14 a1820 17 \section{Acknowledgements} \copyright\ Fraunhofer Institute for Solar Energy Systems, Lucerne University of Applied Sciences and Arts. Development of the \radiance{} photon map was suppoerted by the German Research Foundation (DFG) as part of the FARESYS project, and the Swiss National Science Foundation as part of the project ``Simulation based assessment of daylight redirecting components for energy savings in office buildings'' (DRC, \#147053). Thanks to Dr. Peter Apian-Bennewitz for initiating development of the photon map at Fraunhofer ISE, Greg Ward for his support in integrating the code, and Prof. Stephen Wittkopf and Lars Grobe for initiating the latest phase of development within the scope of the DRC project. d1822 4 a1825 2 Thanks also to those who took the time to test the tool with \realLife\ scenes and report bugs and provide valuable feedback! d1827 1 a1827 13 \begin{thebibliography}{99} \bibitem[Ward94]{Ward94} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. Proceedings SIGGRAPH~'94, July~1994 \bibitem[Ward98]{Ward98} Greg Ward Larson and Rob Shakespeare: ``Rendering with \radiance''. Morgan Kaufmann, San Francisco, 1998 \bibitem[Jens96]{Jens96} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. Rendering Techniques '96, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996 \bibitem[Jens97]{Jens97} d1829 3 a1831 2 Surfaces''. Computer Graphics Forum, vol.~16~(1), March~1997 \bibitem[Jens98]{Jens98} d1834 4 a1837 2 Media using Photon Maps''. Proceedings SIGGRAPH~'98, July~1998 \bibitem[Jens00]{Jens00} d1840 11 a1850 8 SIGGRAPH~2000 Course Notes~8, July~2000 \bibitem[Bent75]{Bent75} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. CACM 18(9), 1975 \bibitem[Chri00]{Chri00} Per Christensen: ``Faster Photon Map Global Illumination''. Journal of Graphics Tools, vol.~4~(3), April~2000 \bibitem[Schr03]{Schr03} d1852 3 a1854 2 Computer Graphics Forum, vol.~22~(4), December~2003 \bibitem[Schr15]{Schr15} d1858 3 a1860 2 Proceedings CISBAT 2015, Lausanne, Switzerland \bibitem[Schr16]{Schr16} d1863 8 a1870 1 Journal of Building Performance Simulation, 2016 (to appear) d1872 4 a1875 1 d1880 1 d1883 27 a1909 20 \begin{figure}[h] \centering \includegraphics[width=0.49\linewidth]{prismella-xsection-hi-close3}% \hfill \includegraphics[width=0.49\linewidth]{prismella-xsection-lo-close3}% \\ \parbox{\linewidth}{ \caption{ \label{fig:prismella} Retroreflecting blinds patented by Helmut K\"oster, rendered with \radiance{} photon map using 600k global and 6M caustic photons with a bandwidth of 100 and 100--2000 (bias compensated), respectively. At 40\degree{} incidence (left), sunlight is retroreflected as evidenced by the caustics on the wall, while skylight is scattered into the interior off the diffuse lamellae undersides. At 20\degree{} incidence (right), the inclination requires adjustment as sunlight is now redirected towards the lamellae undersides rather than being retroreflected. } d1912 19 d1932 1 a1932 1 \begin{figure}[h] d1934 16 a1949 9 \includegraphics[angle=-90, width=\linewidth]{litepipe-xsection-pmap} \parbox{\linewidth}{ \caption{ \label{fig:litepipe-xsection} Cross-sectional view of a lightpipe rendered with 500k global and 1M caustic photons. The photons are emitted via ports defined for the window, pipe aperture, and external heliostat (not visible). } d1951 4 a1954 1 \end{figure} d1956 4 a1959 1 \begin{figure}[h] d1961 16 a1976 12 \includegraphics[width=0.49\linewidth]{cpc-xsection1}% \hfill \includegraphics[width=0.49\linewidth]{cpc-xsection2}\\% \parbox{\linewidth}{ \caption{ \label{fig:cpc-xsection} Compound parabolic concentrator with opaque apertures rendered with volume photon map in a \lit{mist} environment. At normal incidence (left), the incident beam is retroreflected, whereas at 50\degree{} incidence (right) it is transmitted and redirected in a characteristic fan-out. } d1980 1 a1980 1 \begin{figure}[h] d1982 13 a1994 14 \includegraphics[width=0.33\linewidth]{cornell-flood-50}% \hfill \includegraphics[width=0.33\linewidth]{cornell-flood-500}% \hfill \includegraphics[width=0.33\linewidth]{cornell-flood-50-500}% \\ \parbox{\linewidth}{ \caption{ \label{fig:cornell-flood} Flooded Cornell box rendered with caustic photon map using fixed bandwidths of 50 (left) and 500 (centre) photons, and a dynamic bandwidth of \mbox{50--500} photons with bias compensation. } d1996 2 a1997 2 \end{figure} d2008 2 a2009 1 beyond the typical range. d2013 1 a2013 1 \begin{tabular}{|l|l|} d2015 1 a2015 1 \cmd{mkpmap} parameter & typical range \\ d2018 2 a2019 1 \var{nphotons} & 50k--1m \\ d2027 1 a2027 1 \cmd{rpict} parameter & typical range \\ d2030 5 a2034 2 \var{bwidth_1} & 50--100 \\ \var{bwidth_2} & 200--500 \\ a2035 1 \opt{-ac} & 4.0--16.0 \\ d2043 24 a2066 1 \section{\cmd{Mkpmap} Troubleshooting} d2072 1 a2072 1 {\bf Problem} & {\bf Cause} & {\bf Solution} \\ d2075 3 a2077 3 \cmd{mkpmap} stores too many photons & Too many emitted photons in distribution prepass & Reduce \opt{-apD} \\ d2079 4 a2082 4 Number of photons stored differs substantially from specification & Too few photons emitted in distribution prepass; prediction for main pass inaccurate & Increase \opt{-apD} \\ d2084 4 a2087 4 \cmd{mkpmap} complains about runaway photons & Photons stuck in infinite scattering loop, possibly pathological geometry or materials & Check geometry and materials; increase \opt{-apm} \\ d2089 3 a2091 3 \cmd{mkpmap} is slow with \lit{source} primitive & \lit{source} emits from scene cube faces & Define photon ports \\ d2093 4 a2096 4 \cmd{mkpmap} bogs down in light source flux integration & Excessively high probability density function resolution; too many source partitions & Decrease \opt{-dp}; increase \opt{-ds} \\ d2098 7 a2104 5 \cmd{mkpmap} bails out after too many distribution prepasses & Using caustic photons with non-specular geometry; using volume photons without \lit{mist}; pathological geometry or nonabsorbing materials; light sources see no geometry & Check scene and specify compatible photon types \\ d2112 1 a2112 1 \section{\cmd{Rpict/Rtrace} Troubleshooting} d2118 1 a2118 1 {\bf Problem} & {\bf Cause} & {\bf Solution} \\ d2120 8 a2127 15 \hline Excessive noise in photon irradiance & Bandwidth too low & Increase bandwidth \\ \hline Excessive blurring in photon irradiance & Bandwidth too high & Decrease bandwidth or increase size of photon map \\ \hline Excessive noise and blurring in different regions & Bandwidth is fixed & Apply bias compensation for dynamic bandwidth \\ d2129 38 a2166 13 Severe irradiance falloff at polygon edges & Boundary bias due to high bandwidth & Reduce bandwidth or apply bias compensation \\ \hline Splotchy ambient illumination from global photons & Excessively noisy density estimates; too few ambient samples; irradiance caching too inaccurate & Check density estimate with \opt{-ab} -1, and increase bandwidth if necessary; increase \opt{-ad} if illumination has high variance or contains caustics; increase \opt{-ar} and/or decrease \opt{-aa} \\ a2167 28 Direct photon irradiance from modified light source deviates significantly & Probability density function cannot adequately resolve emission distribution; too few source partitions & Increase \opt{-dp}; if distribution varies over surface, decrease \opt{-ds} \\ \hline Caustics are underestimated for measurement points passed to \cmd{rtrace} which do not lie on scene geometry & No photons in measurement plane; photons are retrieved from distant co-planar objects, resulting in oversized radius & Define virtual receiver surface with \lit{antimatter} material, and specify its modifier with \cmd{mkpmap}'s \opt{-aps} or \opt{-apS} option when building the photon map \\ \hline \cmd{rpict/rtrace} complains about short photon lookups & Maximum photon search radius too small & Increase \opt{-am} \\ \hline Everything is slow & User expects too much & Twiddle thumbs \\ \hline @ 1.30 log @Documented pmapdump's -a option for ASCII point list output @ text @d17 2 a18 2 \RCS $Revision: 1.29 $ \RCS $Date: 2019/01/11 15:03:51 $ d1336 2 @ 1.29 log @Fixed typo in sample rcontrib invocation @ text @d17 2 a18 2 \RCS $Revision: 1.28 $ \RCS $Date: 2019/01/10 19:57:33 $ d1261 13 a1273 8 \cmd{mkpmap} as input and sends a RADIANCE scene description of their photon distributions to the standard output. Photons are represented as spheres of material type \lit{glow}. These can be visualised with e.g. \cmd{objview}, \cmd{rpict}, or \cmd{rvu} to assess the location and local density of photons in relation to the scene geometry. No additional light sources are necessary, as the spheres representing the photons are self-luminous. d1294 2 a1295 1 \cmd{pmapdump} [\opt{-n} \var{nspheres_1}] [\opt{-r} \var{radscale_1}] d1301 1 a1301 1 [\opt{-n} \var{nspheres_2}] [\opt{-r} \var{radscale_2}] d1304 1 a1304 2 \qquad\qquad\qquad \var{pmap_2} \textbackslash\\ \qquad\qquad\qquad \ldots d1309 1 a1309 1 of each dump. As such they may be set individually for each photon d1312 38 a1349 9 \item{\opt{-n} \var{nspheres}}\\ Specifies the number of spheres to dump for the next photon map. The dump is performed by random sampling with \var{nspheres} as target count, hence the number actually output will be approximate. \var{Nspheres} may be followed by a multiplier suffix for convenience, where \var{k = 10^3} and \var{m = 10^6}, although the latter may lead to problems when processing the output geometry with \cmd{oconv}. The default number of spheres is 10k. d1358 2 a1359 15 this option. The default value is 1.0. \item{\opt{-c} \var{rcol} \var{gcol} \var{bcol}}\\ Specifies a custom sphere colour for the next photon map. The colour is specified as an RGB triplet, with each component in the range (0..1]. Without this option, the default colour for the corresponding photon type is used. This option is mutually exclusive with \opt{-f}. \item{\opt{-f}[\lit{+}$|$\lit{-}]}\\ Boolean switch to colour each sphere according to the corresponding photon's RGB flux instead of a constant colour. Note that the resulting colours can span several orders of magnitude and may require tone mapping with\cmd{pcond} for visualisation. This option is mutually exclusive with \opt{-c}. d1362 4 a1365 4 Note that the output may contain many overlapping spheres in areas with high photon density, particularly in caustics. This results in inefficient and slow octree generation with \cmd{oconv}. Generally this can be improved by reducing \var{nspheres} and/or d1377 2 a1378 2 \lit{scene\_pmdump.oct}\\ \cmd{rvu} \lit{scene\_pmdump.oct} d1390 1 a1390 1 \lit{scene\_pmdump.oct} d1392 3 a1394 3 Dumps may also be viewed on their own by simply piping the output of \cmd{pmapdump} directly into \cmd{objview} (using the default number of spheres in this example): d1398 7 a1405 1 @ 1.28 log @Updated pmapdump documentation (new -f option), minor formatting changes in figure captions (smalltype, indentation for improved text wrapping). @ text @d17 2 a18 2 \RCS $Revision: 1.27 $ \RCS $Date: 2018/12/06 20:39:02 $ d1429 2 a1430 1 \opt{-M} \var{mods} \opt{-ap} \var{contribpmap} \var{bwidth} d1434 1 a1434 1 light source, \var{lsmod} is a file containing the list of light source @ 1.27 log @Wheee! @ text @d17 2 a18 2 \RCS $Revision: 1.26 $ \RCS $Date: 2018/12/06 20:34:21 $ d56 1 a56 1 \item Simplified and more flexible parametrisation of \cmd{pmapdump}. d101 3 a103 2 \parbox{0.75\linewidth} {\caption{Photograph of caustic from retroreflecting lamella d164 8 a171 5 \includegraphics[width=0.49\linewidth]{cornell-distrib1} \hfill \includegraphics[width=0.49\linewidth]{cornell-distrib2} \parbox{\linewidth} {\caption{Global photon distribution in the Cornell box. Left: d176 2 a177 1 pass. Note the concentration of caustic photons on the d185 3 a187 2 \parbox{0.8\linewidth} {\caption{Gathering photons via nearest neighbour search. The d354 4 a357 3 \includegraphics[width=0.6\linewidth]{precomp} \parbox{0.7\linewidth} {\caption{Directly visualised precomputed global photon d392 10 a401 7 \includegraphics[angle=-90, width=0.49\linewidth] {spot-bias-50000-false} \hfill \includegraphics[angle=-90, width=0.49\linewidth] {spot-biascomp-50000-false} \parbox{\linewidth} {\caption{Left: falsecolour rendering of severely biased caustic d473 3 a475 2 \parbox{0.9\linewidth} {\caption{Typical daylighting geometry with window as photon d545 6 a550 4 \includegraphics[width=0.49\linewidth]{scene-000-pmapdump-100k} \hfill \includegraphics[width=0.49\linewidth]{scene-000-pmapdump-100k-roi} \parbox{\linewidth}{% d553 1 d1039 3 a1041 2 \parbox{0.9\linewidth} {\caption{Caustic photons are visualised at the primary d1257 2 a1258 2 location of photons is unclear. The image on the right in figure \ref{fig:cornell_distrib} is an example of a \cmd{pmapdump} output. d1262 2 a1263 1 photon distributions to the standard output. This can be visualised d1266 2 a1267 1 geometry. d1270 3 a1272 3 line and the respective photon type is determined automagically. The different photon types are visualised as colour coded spheres according to the following default schema: d1282 4 a1285 1 \opt{-c} option (see below). d1290 10 a1299 5 [\opt{-c} \var{rcol_1} \var{gcol_1} \var{ bcol_1}] \var{pmap_1}\\ \qquad [\opt{-n} \var{nspheres_2}] [\opt{-r} \var{radscale_2}] [\opt{-c} \var{rcol_2} \var{gcol_2} \var{ bcol_2}] \var{pmap_2} \\ \qquad \ldots d1330 9 a1338 1 corresponding photon type is used. d1342 1 a1342 1 with high photon density, particularly in caustics. This results in d1347 1 a1347 1 The following is an example to visualise the distribution of global d1351 6 a1356 6 \cmd{pmapdump} \opt{-n} \lit{5k} \opt{-c} \lit{1 0.4 0.4} \lit{global.pm} \textbackslash\\ \qquad \opt{-n} \lit{10k} \opt{-c} \lit{0.4 0.4 1} \lit{caustic.pm} \textbackslash\\ \qquad $|$ \cmd{oconv} - \lit{scene.rad} $>$ \lit{scene\_pmdump.oct}\\ d1361 11 a1371 2 Alternatively, the dump may be viewed on its own by piping the output of d1555 1 a1555 1 \begin{figure}[htb] d1578 1 a1578 1 \begin{figure}[htb] d1592 1 a1592 1 \begin{figure}[htb] d1596 1 a1596 2 \includegraphics[width=0.49\linewidth]{cpc-xsection2}% \\ d1609 1 a1609 1 \begin{figure}[htb] @ 1.26 log @Documented basic support for *data and *func materials. @ text @d17 2 a18 2 \RCS $Revision: 1.25 $ \RCS $Date: 2018/11/21 19:51:20 $ d60 1 @ 1.25 log @Documented -c option for pmapdump @ text @d17 2 a18 2 \RCS $Revision: 1.24 $ \RCS $Date: 2018/03/22 16:48:24 $ d43 3 d243 10 a252 5 Materials defined by tabulated data or functions such as \lit{plasfunc, metfunc, transfunc, brtdfunc, plasdata, metdata,} and \lit{ transdata} are not supported as they have been largely superseded by the more general \lit{bsdf} material, which uses a highly optimised internal data representation and efficient sampling. @ 1.24 log @Documented -ai/-ae modifier include/exclude options. @ text @d17 2 a18 2 \RCS $Revision: 1.23 $ \RCS $Date: 2018/02/06 16:11:20 $ d1246 1 a1246 1 according to the following schema: d1255 2 d1261 5 a1265 3 \var{pmapfile_1}\\ \qquad [\opt{-n} \var{nspheres_2}] [\opt{-r} \var{radscale_2}] \var{pmapfile_2\ldots} d1291 6 d1306 2 a1307 2 and caustic photons superimposed on the scene geometry with 5000 and 10000 spheres, respectively: d1309 6 a1314 3 \cmd{pmapdump} \opt{-n} \lit{5k} \lit{global.pm} \opt{-n} \lit{10k} \lit{caustic.pm} $|$ \textbackslash\\ \qquad\cmd{oconv} - \lit{scene.rad} $>$ \lit{scene\_pmdump.oct}\\ @ 1.23 log @Nu sucky affil @ text @d17 2 a18 2 \RCS $Revision: 1.22 $ \RCS $Date: 2018/02/06 16:00:07 $ d45 1 d523 1 a523 1 \begin{figure}[htb] d761 1 a761 1 Defines a region of interested within which to store photons d799 4 a802 4 \item{\opt{-apO} \var{modfile}}\\ Read photon port modifiers from the file \var{modfile} as a more convenient alternative to multiple instances of \opt{-apo}. d819 1 a819 1 material to act as a dummy (i.e. invisible) sensor surface. d842 27 a868 4 \item{\opt{-apS} \var{modfile}}\\ Read dummy sensor surface modifiers from the file \var{modfile} as a more convenient alternative to multiple instances of \opt{-aps}. d1415 1 a1415 1 dummy receiver surface is defined with \lit{antimatter} and d1701 1 a1701 1 Define dummy receiver surface with \lit{antimatter} material, and @ 1.22 log @Updated with -lr, -ld, -api (now accessible), synced with manpages and reformatted for better (?) legibility @ text @d17 2 a18 2 \RCS $Revision: 1.21 $ \RCS $Date: 2016/05/18 15:11:59 $ d22 1 a22 1 CC Envelopes and Solar Energy\\ @ 1.21 log @Updated with ooC pmap options @ text @d17 2 a18 2 \RCS $Revision: 1.20 $ \RCS $Date: 2015/09/24 12:08:41 $ d44 1 d48 4 d55 1 a55 1 \item Revised documentation and (finally) manpages d320 1 d348 1 d420 1 d485 62 a546 1 d693 3 a695 1 rendering. Direct photon maps are useful to determine suitable d707 5 a711 1 light source contributions. With this option, \cmd{mkpmap} d716 3 a718 1 contributions per light source and direction. Note \cmd{mkpmap} d722 3 a724 1 will be ignored. See section \ref{sec:lsContribs} for details d731 1 d741 3 d750 3 a752 1 \var{nphotons}. Setting this too high may yield more than d758 14 a771 6 \item{\opt{-apP} \var{precomp}}\\ Photon precomputation factor; this is the fraction of \var{nphotons} global photons to precompute in the range $]0,1]$ when using the \opt{-app} option. The remaining photons are discarded. d773 3 a775 7 Maximum number of bounces (scattering events) for a photon path before being considered ``runaway'' and terminated. Photons paths are normally terminated via Russian Roulette, depending on their albedo. With unrealistically high albedos, this is not guaranteed, and this option imposes a hard limit to avoid an infinite loop. d782 1 a782 1 d789 3 a791 1 emitting light source via an opening, or port. A typical d795 3 a797 3 further details. Multiple instances of this option may be specified. d801 9 a809 1 \opt{-apo}. d812 1 a812 1 Seed for the random number generator. This is necessary for d814 1 a814 1 and photon map size. d823 3 a825 1 as an invisible photon receiver. This is useful when photon d830 3 a832 1 underestimation. Note that photons are only deposited when d838 3 d845 1 a845 1 d877 11 d889 7 a895 4 \item{\opt{-i} \var{inc}}\\ Photon heap size increment; the photon heap is enlarged by this amount when storage overflows during photon distribution. No need to fiddle with this under ordinary circumstances. d940 1 d959 1 d1064 9 a1072 9 The number of ambient bounces for the indirect diffuse irradiance; setting this to any positive value will include global photon irradiance via \emph{one} ambient bounce (final gather). The result of this ambient bounce is stored in the ambient cache for interpolation, but the global photon map irradiance is not cached for the ambient daughter rays. Setting this to a negative value will not spawn any ambient rays at all, and instead visualises the global photon irradiance directly at the primary ray. This is intended for debugging and d1074 7 a1080 5 resulting renderings is poor. If the global photons are precomputed, this produces a Voronoi diagram. As with \radClassic, the default value of 0 disables the ambient component, although caustic photon irradiance is still visualised at the primary ray. d1083 27 a1109 15 Loads a photon map from \var{file}, the type of which is automagically identified. The irradiance is then evaluated from the photons depending on their type (global, caustic, volume, direct) using density estimates with a bandwidth of \var{bwidth_1} photons, or the default bandwidth if none is specified (a warning will be issued in this case). Specifying \var{bwidth_2} in addition enables bias compensation for the density estimates with a minimum and maximum bandwidth of \var{bwidth_1} and \var{bwidth_2}, respectively. \var{Bwidth_1} is ignored if specified for precomputed global photons, as the precomputed irradiance from the nearest photon is looked up. \radiance's direct calculation is disabled with direct photons, and only surfaces with diffuse component are accounted for; this is strictly a debugging and validation option, and rarely needed in practice. d1112 20 a1131 13 Sets a fixed maximum search radius for photon lookups, defeating its adaptation to the local photon density (see section \ref{sec:maxDist}). The number of photons found within this radius is still limited by the bandwidth. This option may be necessary when the automatic maximum search radius is underestimated for extremely non-uniform photon distributions. Knowledge on the part of the user of the average photon density is assumed; setting the fixed search radius too low may result in short photon lookups in sparsely populated regions, while setting it too high may degrade performance due to superfluous testing of distant photons. Note that this setting applies to \emph{all} photon maps specified with \opt{-ap}. d1143 3 a1145 1 cache page. Cache performance is sensitive to this parameter: d1157 3 a1159 1 size per parallel process. Cache performance is less @ 1.20 log @Marked contrib pmap as experimental for now, until bugs are resolved. @ text @d2 1 a2 1 \usepackage{color,graphicx,pslatex,rcs,gensymb} d17 2 a18 2 \RCS $Revision: 1.19 $ \RCS $Date: 2015/05/28 10:20:48 $ d43 1 a43 2 \item EXPERIMENTAL support for light source contributions via \cmd{rcontrib} d48 2 d600 1 a600 1 \item{\opt{-apc} \var{file} \var{nphotons} {\bf (EXPERIMENTAL)}}\\ d792 5 d989 28 d1145 1 a1145 1 \section{Photon Mapping with Light Source Contributions \\(EXPERIMENTAL)} d1150 11 a1160 10 climate-based daylight simulation. In this workflow, the scene supplied to \cmd{mkpmap} contains multiple light sources representing different time-dependent positions (e.g. solar elevations depending on season and time of day) of one source, which are handled as aggregate for efficient simulation. The \cmd{rcontrib} tool supplied with \radiance{} can then determine the irradiance for each light source for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by ``binning'' the resulting irradiance into separate output files for each light source. See the \cmd{rcontrib} man page for details. d1303 9 d1427 1 @ 1.19 log @Added acks to testers @ text @d17 2 a18 2 \RCS $Revision: 1.18 $ \RCS $Date: 2015/05/28 10:16:24 $ d43 2 a44 1 \item Support for light source contributions via \cmd{rcontrib} d599 1 a599 1 \item{\opt{-apc} \var{file} \var{nphotons}}\\ d1111 1 a1111 1 \section{Photon Mapping with Light Source Contributions} @ 1.18 log @Revised -am option, removed tacky annual sim plot and replaced it with luxtherm renderings from appendix. Extended acks. @ text @d14 1 d17 2 a18 2 \RCS $Revision: 1.17 $ \RCS $Date: 2015/01/29 15:14:34 $ d1231 3 @ 1.17 log @Updated "What's New" section, added example of renderins of contrib photon map with Köster LuxTherm in appendix. @ text @d16 2 a17 2 \RCS $Revision: 1.16 $ \RCS $Date: 2015/01/14 11:04:13 $ d42 1 a42 2 \item EXPERIMENTAL support for light source contributions via \cmd{rcontrib} d200 1 a200 1 and are only intended as a debugging option. d267 1 a267 1 supported primitives are \lit{light, spotlight, glow,} and \lit{ d272 10 a281 9 The behaviour of a few emitter types deviates from \radClassic. In the case of the \lit{source} primitive there is no geometry to partition; instead, the scene cube faces are partitioned and act as emitters, unless photon \emph{ports\/} are used (see section \ref{sec:ports}). Furthermore, the \lit{glow} primitive acts as regular light source, regardless of its maximum radius for shadow testing, as its ambient contribution is accounted for by the photon map. Virtual sources are disabled with photon mapping, since caustic photons account for this functionality. d359 1 a359 1 The algorithm also compensates for boundary bias (darkening at d400 1 a400 3 centre of gravity of the photon ``cloud'' or distribution. This is scaled by a user-specified coefficient to correct for grossly skewed distributions if necessary. This simple approach adapts the maximum d405 4 a408 1 d441 1 a441 1 \includegraphics[width=0.8\linewidth]{port3} d444 3 a446 1 port for directional light sources.} d629 1 a629 1 \item{\opt{-apC} \var{file} \var{nphotons} {\bf (EXPERIMENTAL)}}\\ d831 8 a838 4 Global photon irradiance is usually visualised via an intermediate ambient bounce (commonly referred to as \emph{final gather} in the literature \cite{Chri00}, see figure \ref{fig:visualisation}) by specifying any positive \opt{-ab} value. This reduces d861 1 a861 1 \includegraphics[width=0.75\linewidth]{visualisation} d967 14 a980 7 \item{\opt{-am} \var{maxdistcoeff}}\\ Sets the coefficient for the maximum search radius for photon map lookups. The search radius is automatically determined based on the average photon distance to the distribution's centre of gravity (see section \ref{sec:maxDist}), and scaled by this coefficient. Increase this value if multiple warnings about short photon lookups are issued. d1109 1 a1109 1 \section{Photon Mapping with Light Source Contributions \\(EXPERIMENTAL)} d1113 11 a1123 11 computation of light source contributions for climate-based daylight simulation. In this workflow, the scene supplied to \cmd{mkpmap} contains multiple light sources representing different time-dependent positions (e.g. solar elevations depending on season and time of day) of one source, which are handled as aggregate for efficient simulation. The \cmd{rcontrib} tool supplied with \radiance{} can then determine the irradiance for each light source for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by ``binning'' the resulting irradiance into separate output files for each light source. See the \cmd{rcontrib} man page for details. d1126 6 a1131 5 modified photon distribution algorithm via the \opt{-apl} option that ensures each light source contributes roughly the same number of photons, irrespective of its emitted flux. To compensate and maintain energy balance, the flux of each photon is adjusted accordingly, which can raise the variance of the resulting density estimates. a1163 20 Figure \ref{fig:annualSuns} is an example of an annual climate based simulation of the irradiance for an interior ceiling sensor, which required binning the contributions of 365 directional light sources representing the daily sun positions at 1:00pm over an entire year. While the irradiance contributions from the photon map are noisier than those obtained with \radClassic, they more accurately account for glare and light redirection from specular surfaces. \begin{figure}[htb] \centering \includegraphics[width=0.75\linewidth]{referenceRoomA-annualSuns-daily} \parbox{0.8\linewidth}{ \caption{ \label{fig:annualSuns} Comparison of annual interior ceiling irradiance over 365 days at 1:00pm simulated with \radClassic{} (red) and photon map (blue). } } \end{figure} d1173 16 d1190 1 a1191 1 d1215 1 a1215 1 \section{Acknowledgement} d1217 13 a1229 4 \copyright Fraunhofer Institute for Solar Energy Systems, Lucerne University of Applied Sciences and Arts. Development of the \radiance{} photon mapping extension was sponsored by the German Research Foundation (DFG) and the Swiss National Science Foundation (SNF). d1231 1 a1231 2 d1345 1 a1345 15 \begin{figure}[p] \centering \includegraphics[width=\linewidth]{koester-luxtherm-half} \parbox{\linewidth}{ \caption{ \label{fig:koester-luxtherm-half} Retroreflecting blinds at 26 solar angles for a half year (January to June with weekly intervals) rendered with contribution photon map and \cmd{rcontrib}. In each instance the time of day is 1:00pm. Redirection and transmission dominate until March, while retroreflection dominates in the following months. } } \end{figure} @ 1.16 log @Documented mkpmap's new -aps and -apS options for specifying dummy antimatter sensor surface, and referenced it in text, notably in troubleshooting table. Documented new -n and -r parameters for pmapdump. @ text @d16 2 a17 2 \RCS $Revision: 1.15 $ \RCS $Date: 2015/01/08 18:36:02 $ d19 1 a19 1 \title{The \radiance{} Photon Map Manual} d34 1 a34 2 \section{What's New in Photon Map 4.3?} d36 3 a38 2 Development of the \radiance{} photon map has resumed as of november 2013, with the following new features and extended functionality: d46 2 d49 5 a53 3 \item \underline{ATTENTION}: Photon port normals now point \underline{towards the interior} as per \cmd{mkillum} convention! d697 3 a699 2 an external light source. Multiple instances of this option may be specified. d1170 10 a1179 1 d1326 15 a1340 1 @ 1.15 log @Revised documentation of pmapdump (now supporting number of spheres on cmdline), removed bit about mkmpap not overwriting files, as this is deprecated with the -fo option. @ text @d16 2 a17 2 \RCS $Revision: 1.14 $ \RCS $Date: 2014/12/04 16:44:02 $ d471 1 d705 18 d724 5 d809 9 a817 3 for. Note that irradiance calculations with \cmd{rtrace} using caustic photons are surface bound; irradiance for points which do not lie on surfaces will therefore be biased. d1004 17 a1020 7 distribution in one or more photon map files. The image on the right in figure \ref{fig:cornell_distrib} is an example of a \cmd{pmapdump} output. The output consists of a \radiance{} scene description which can be included in the octree used to generate the photon maps, or used on its own with \cmd{objview}. The photons themselves are simply modelled as spheres, with their colour denoting the photon type as follows: d1030 42 a1071 15 \noindent The synopsis for \cmd{pmapdump} is very simple: \begin{quote} \cmd{pmapdump} \var{nspheres} \var{pmapfile_1} \var{pmapfile_2\ldots} \end{quote} where \var{nspheres} is the number of spheres to dump as a subset of the photons in the photon map. \cmd{Pmapdump} supports the same multiplier suffixes for this parameter as \cmd{mkpmap}. The sphere radius is determined automatically based on the average photon distance to the distribution's centre of gravity, as well as the number of spheres, to reduce clustering. An arbitrary number of photon maps can be specified on the command line and the respective photon type is determined automagically. A typical application of \cmd{pmapdump} with a global, caustic, and volume photon map would then be: d1073 4 a1076 6 \cmd{oconv} \lit{scene.rad} $>$ \lit{scene.oct}\\ \cmd{mkpmap} \opt{-apg} \lit{global.pm} \opt{-apc} \lit{caustic.pm} \opt{-apv} \lit{volume.pm} \lit{scene.oct} \\ \cmd{pmapdump} \lit{radius} \lit{global.pm} \lit{caustic.pm} \lit{volume.pm} $|$ \textbackslash\\ \qquad\cmd{oconv} - \lit{scene.rad} $>$ \lit{scene\_pmdump.oct} d1081 6 a1086 15 The \cmd{pmapdump} utility can be used for illustrative purposes to understand the photon map algorithm, but more importantly, it can be used to debug scenes in which the location of photons is unclear. Note that \cmd{pmapdump} can generate many overlapping spheres in areas with high photon density, particularly in caustics. This results in inefficient and slow octree generation with \cmd{oconv}, requiring the use of the \opt{-n} or \opt{-r} options for the latter. Generally this can be avoided by reducing the number of spheres. This problem is aggravated with large photon maps, hence it is advisable to limit the size of the dumped photon maps. We found it impractical to visualise more than 10000 photons, which is usually enough to gain an insight into the photon distribution. d1088 1 d1181 4 a1184 1 \cmd{rtrace} points which do not lie on a surface. d1403 1 d1405 1 a1405 1 \hline d1410 1 d1415 1 d1420 1 d1425 8 a1432 6 Splotchy ambient illumination from global photons & Excessively noisy density estimates; too few ambient samples; irradiance caching too inaccurate & Check density estimate with \opt{-ab} -1, and increase bandwidth if necessary; increase \opt{-ad} if illumination has high variance or contains caustics; increase \opt{-ar} and/or decrease \opt{-aa} \\ d1434 1 d1442 10 d1456 1 d1461 1 @ 1.14 log @Update with new contrib pmap parameter -apC, new max search radius coeff -am for rpict/rtrace, Renamed mkpmap's -apf to -apP (global photon precomp factor). Moved sample renderings to appendix. Some rewording. @ text @d16 2 a17 2 \RCS $Revision: 1.13 $ \RCS $Date: 2014/10/31 12:58:12 $ a479 7 If a photon map with the specified file name already exists, \cmd{mkpmap} aborts without overwriting. The need for this protection stems from the frustration of having photon maps from very long previous distribution passes obliterated by the command line history! There is no ``clobber'' option; the files must be renamed or removed by hand. This is an annoyance, but better safe than sorry... d978 3 a980 3 used directly with \cmd{objview}. The photons themselves are simply modelled as spheres of a user defined radius, with their colour denoting the photon type as follows: d992 9 a1000 2 \cmd{pmapdump} \var{radius} \var{pmapfile_1} \var{pmapfile_2\ldots} \end{quote} d1024 1 a1024 1 Generally this can be avoided by reducing the sphere radius. @ 1.13 log @Modified hyperref options @ text @d16 2 a17 2 \RCS $Revision: 1.12 $ \RCS $Date: 2014/10/27 14:39:00 $ d45 1 a45 1 \item Adaptive maximum search radius for photon lookups d116 1 a116 1 absorbtion or leakage (if it leaves the scene), and a new photon is d203 1 a203 1 augmentented by a photon map density estimate, but the direct and d256 1 a256 1 of mist, e.g. a mist boundary for the entire scene. All this ust to d377 2 a378 1 \subsubsection{Adaptive Initial Search Radius} d380 1 a380 1 The photon lookup algorithm uses an maximum search radius to d391 1 a391 1 low number of photons will render it unstable due to excessive noise. d395 7 a401 8 radius is therefore adapted using statistics from previous photon map lookups. This is based on an estimate derived from the ratio of the actual number of photons found and the target bandwidth as specified by the user. If this ratio is less than $\frac{1}{2}$, the photon lookup is considered unreliable, and restarted with a doubled search radius. The maximum search radius is adjusted to accommodate the target bandwidth and is averaged with the previous value using non-uniform weights to prevent excessive fluctuation. d463 1 a463 1 parametrsiation on behalf of the user. A more general approach using d579 1 a579 1 \opt{-apd}$|$\opt{-apl}$|$\opt{-app} d628 1 a628 1 \item{\opt{-apl} \var{file} \var{nphotons} {\bf (EXPERIMENTAL)}}\\ d631 12 a642 9 \var{file}. This is a special case of the global photon map intended for calculating light source contributions with \cmd{rcontrib}. With this option, \cmd{mkpmap} uses a modified photon distribution algorithm that ensures all light sources contribute approximately the same number of photons. Each photon indexes a primary hitpoint, incident direction, and emitting light source which can be used to bin contributions per light source and direction. See section \ref{sec:lsContribs} for details on using photon maps with \cmd{rcontrib}. d647 1 a647 1 \opt{-apf} option, see below), and output to \var{file}. d669 1 a669 1 \item{\opt{-apf} \var{precomp}}\\ d712 1 a712 1 \item{\opt{-bv} [\lit{+}$|$\lit{-}]}\\ d738 6 d769 6 a774 4 At least one of the \opt{-apg}, \opt{-apc}, \opt{-apv}, \opt{-apd}, or \opt{-app} options must be specified. These can be combined subject to compatibility with the materials used in the scene. d876 1 a876 1 warning is issued if the octree is newer than the photon map, d879 1 a879 1 A physically valid simulation (assuming specular and diffuse d892 5 a896 5 As with \radClassic, the \opt{-ad}, \opt{-ar}, and \opt{-aa} parameters may need modification in some cases to improve the rendering quality. Some parameters are adopted from \radClassic{} with extended semantics in conjunction with photon maps. The \cmd{rpict} photon mapping options are as follows: d915 1 a915 1 \item{\opt{-ap} \var{file} \var{bwidth_1} \var{[bwidth_2]}}\\ d920 19 a938 9 \var{bwidth_1} photons. Specifying \var{bwidth_2} in addition enables bias compensation for the density estimates with a minimum and maximum bandwidth of \var{bwidth_1} and \var{bwidth_2}, respectively. \var{Bwidth_1} is ignored for precomputed global photons, as the precomputed irradiance from the nearest photon is looked up. \radiance's direct calculation is disabled with direct photons, and only surfaces with diffuse component are accounted for; this is stricly a debugging and validation option, and rarely needed in practice. d950 4 a953 4 \var{command}\\ \var{N_p} photons\\ \var{[\phi_r, \phi_g, \phi_b]} avg watts / photon\\ FORMAT=\var{format}, d957 1 a957 1 \item \var{command} is the \cmd{mkpmap} command line used to build d961 2 a962 2 the RGB colour channels, and \item \var{format} identifies the photon map type, which is one of d967 3 a969 2 \item \lit{Radiance\_Volume\_Photon\_Map}, or \item \lit{Radiance\_Direct\_Photon\_Map} d971 1 d994 1 d1003 1 a1003 1 typical application of \cmd{pmapdump} with a gobal, caustic, and d1026 4 a1029 4 This problem is aggravated with large photon maps, hence restraint is advised concerning the size of the dumped photon maps. We found it impractical to dump more than 10000 photons, which is usually enough to gain an insight into the photon distribution. d1057 2 a1058 2 incident directions, and emitting light sources, which are indexed by each photon which is spawned along the primary ray's path. This d1060 4 a1063 3 photon map, as well as apply an additional binning function to the incident direction as documented in the \cmd{rcontrib} man page, e.g. to identify contributions from individual sky patches. d1067 6 a1072 5 currently not supported, although the same effect may be obtained by setting the light source radiance to 1. Furthermore, using fewer photons than there are light sources for photon density estimates results in omitted contributions, thus \cmd{rcontrib} clamps the bandwidth accordingly. d1077 1 a1077 1 \cmd{mkpmap} \opt{-apl} \var{contribpmap} \var{nphotons} d1092 2 a1093 2 The irradiance contributions obtained from the photon map noisier than those obtained with \radClassic, but can accurately account for d1138 35 d1174 2 a1175 1 \pagebreak a1252 35 \begin{thebibliography}{99} \bibitem[Ward94]{Ward94} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. Proceedings SIGGRAPH~'94, July~1994 \bibitem[Ward98]{Ward98} Greg Ward Larson and Rob Shakespeare: ``Rendering with \radiance''. Morgan Kaufmann, San Francisco, 1998 \bibitem[Jens96]{Jens96} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. Rendering Techniques '96, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996 \bibitem[Jens97]{Jens97} Henrik Wann Jensen: ``Rendering Caustics on Non-Lambertian Surfaces''. Computer Graphics Forum, vol.~16~(1), March~1997 \bibitem[Jens98]{Jens98} Henrik Wann Jensen and Per H.~Christensen: ``Efficient Simulation of Light Transport in Scenes with Participating Media using Photon Maps''. Proceedings SIGGRAPH~'98, July~1998 \bibitem[Jens00]{Jens00} Henrik Wann Jensen and Niels J{\o}rgen Christensen: ``A Practical Guide to Global Illumination using Photon Maps''. SIGGRAPH~2000 Course Notes~8, July~2000 \bibitem[Bent75]{Bent75} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. CACM 18(9), 1975 \bibitem[Chri00]{Chri00} Per Christensen: ``Faster Photon Map Global Illumination''. Journal of Graphics Tools, vol.~4~(3), April~2000 \bibitem[Schr03]{Schr03} Roland Schregle: ``Bias Compensation for Photon Maps''. Computer Graphics Forum, vol.~22~(4), December~2003 \end{thebibliography} a1254 1 \appendix d1264 1 a1264 1 \begin{table}[!htb] d1272 3 a1274 3 \opt{-apD} & 0.1--10 \\ \opt{-apf} & 0.25--0.5 \\ \opt{-apm} & 5000--10000 \\ d1284 1 a1286 1 \caption{Parameter ranges for \cmd{mkpmap} and \cmd{rpict}.} d1291 2 a1292 1 \section{Troubleshooting} d1294 1 a1294 1 \begin{table}[!htb] d1296 1 a1296 1 \begin{tabular}{|p{0.3\linewidth}|p{0.3\linewidth}|p{0.3\linewidth}|} d1305 1 a1305 1 Number of stored photons differs substantially from specification & d1310 35 d1356 1 a1356 12 \hline \end{tabular} \caption{Troubleshooting chart.} \end{table} \begin{table}[!htb] \centering \begin{tabular}{|p{0.3\linewidth}|p{0.3\linewidth}|p{0.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline a1367 5 \cmd{mkpmap} complains about runaway photons & Photons stuck in infinite scattering loop, possibly pathological geometry or materials & Check geometry and materials; increase \opt{-apm} \\ \hline d1374 4 a1378 15 \cmd{mkpmap} is slow with \lit{source} primitive & \lit{source} emits from scene cube faces & Define photon ports \\ \hline \cmd{mkpmap} bogs down in light source flux integration & Excessively high probability density function resolution; too many source partitions & Decrease \opt{-dp}; increase \opt{-ds} \\ \hline \cmd{mkpmap} bails out after too many distribution prepasses & Using caustic photons with non-specular geometry; using volume photons without \lit{mist}; pathological geometry or nonabsorbing materials; light sources see no geometry & Check scene and specify compatible photon types \\ \hline a1383 1 \caption{Troubleshooting chart (continued).} d1387 1 @ 1.12 log @Fixed typos, moved references before appendix. @ text @d2 3 a4 2 \usepackage{color,graphicx,pslatex,rcs,hyperref,gensymb} d16 2 a17 2 \RCS $Revision: 1.11 $ \RCS $Date: 2014/10/21 19:03:46 $ d47 3 @ 1.11 log @Tagged light source contribs as experimental in heading, extended section on global photon visualisation @ text @d15 2 a16 2 \RCS $Revision: 1.10 $ \RCS $Date: 2014/10/21 18:40:30 $ d62 2 a63 2 Particularly the phenomenon of caustics poses a serious problem for \radiance. Caustics are the bright, iridescent highlights on diffuse d65 1 a65 1 \ref{fig:caustic}) shows an example of a caustic from a retroreflecting d128 8 a135 8 the indirect illumination for a point on a surface or within a volume is determined by finding a number of nearest photons to the point. The irradiance is then proportional to the photon density (figure \ref{fig:nnsearch}), hence the process is known as \emph{ density estimation\/} in the statistics literature. The number of photons gathered defines the area covered by the density estimate, and will be referred to as the \lit{bandwidth} of the density estimate for the rest of this document. d171 4 a174 3 \cmd{rpict} also implies its siblings \cmd{rtrace} and \cmd{rvu}.} for the actual rendering and photon gathering. The general photon mapping workflow can therefore be summarised as: d196 5 a200 6 The stock \radiance{} functionality (referred to here as \radClassic) is preserved in \cmd{rpict} if no command line arguments pertaining to the photon map are given. When rendering with the photon map, the ambient calculation is augmentented by a photon map density estimate, but the direct and indirect specular components are still delivered by \radClassic. d224 5 a228 5 Materials for user defined BRDFs / BTDFs such as \lit{plasfunc, metfunc, transfunc, brtdfunc, plasdata, metdata,} and \lit{ transdata} are not supported as they have been largely superseded by the more general \lit{bsdf} material, which uses a highly optimised internal representation and efficient sampling. d252 2 a253 2 of mist, e.g. a mist boundary for the entire scene. Just to make life more interesting. d269 5 a273 3 \ref{sec:ports}). Furthermore, the \lit{glow} primitive acts as a regular light source, and Virtual sources are disabled with the photon map, since caustic photons already account for these effects. d334 3 a336 3 and bias. Setting this too low may result in excessive noise. Setting this too high may result in excessive blurring and local bias in the solution. d381 1 a381 1 An approriately sized maximum search radius will eliminate many d387 1 d389 9 a397 11 changes dynamically with the local photon density. The maximum search radius is therefore adapted using statistics from previous photon map lookups. This is based on an estimate derived from the ratio of the actual number of photons found and the target bandwidth as specified by the user. If this ratio is less than $\frac{1}{2}$, the photon lookup is considered unreliable, and restarted with a doubled search radius. The maximum search radius is adjusted to accommodate the target bandwidth and is averaged with the previous value using non-uniform weights to prevent excessive fluctuation. d458 5 a462 4 not compromise accuracy for performance, assuming correct parametrsiation on behalf of the user. A forward raytracer using Markov Chain techniques to automatically find viable photon paths without user intervention may materialise one day. {\tiny (Or not. Probably not.)} d469 1 a469 1 performas a forward raytracing pass to generate a photon map of each d472 2 a473 2 neighbour queries required for the gathering step. The data structure is written to a portable binary file for subsequent use by d507 7 a513 7 specified number of distribution prepass attempts if any of the specified photon maps are still empty. This is usually an indication of a scene anomaly or an incompatible photon map specification. This is intended as a convenience for the user; without it, \cmd{mkpmap} would end up in an infinite loop. It is nevertheless the user's responsibility to specify photon map types compatible with the materials and to check the validity of the scene. d576 1 a576 1 \var{pmapFile} \var{nphotons} [\var{bwidth}] d588 1 a588 1 scattering, on sur‐ faces with a diffuse component. This is the d595 2 a596 2 This is a sub‐ set of the global photon map intended for direct visualisation at primary rays, This accounts for all d605 2 a606 2 for indirect inscattering in participating media such as mist and complement the direct inscattering computed by d618 5 a622 5 light sources with modifiers. This can provide a visual check for the resolution of the probability density function used for photon emission in conjunction with complex output distributions. It can also serve as a validation tool for comparison with \radiance's direct component. d629 1 a629 1 \cmd{rcontrib}. With this option, mkpmap uses a modified d632 1 a632 1 photon indexes a primary hit‐ point, incident direction, and d634 2 a635 1 per light source and direction. See section \ref{sec:lsContribs}. d669 1 a669 1 Maximum number of bounces (scattering evens) for a photon path d673 1 a673 1 not guaranteed, and this options imposes a hard limit to avoid d679 1 a679 1 rarely needed as a an aborted prepass indicates an anomaly in d696 1 a696 1 Read photon port modifiers from the file \var{modFile} as a d710 7 a716 9 \item{\opt{-dp sampleres}}\\ Resolution for sampling the spatial emission distribution of a modified light source (e.g. via \lit{brightfunc}), in samples per steradian. This is required for numerically integrating the flux emitted by the light source and for constructing a probability density function for photon emission. The accuracy of photon emission from modified sources therefore depends on this parameter. This parameter may need increasing with complex emission distributions in combination with caustics. d719 7 a725 6 Light source partition size ratio; a light source object is spatially partitioned to distribute the photon emission over its surface. This parameter specifies the ratio of the size (per dimension) of each partition to the scene cube, and may need increasing for modified light sources (e.g. via \lit{brightfunc}) with high spatial variation. d764 4 a767 3 The modified \cmd{rpict} rendering tool takes the photon map generated by \cmd{mkpmap} and perform the photon gathering and density estimation. Without photon map functionality enabled, it behaves like \radClassic. d774 6 a779 5 observer, or via specular reflections. Virtual light sources are disabled with the caustic photon map, since these effects are already accounted for. Note that irradiance calculations with \cmd{rtrace} using caustic photons are surface bound. Irradiance for points which do not lie on surfaces will therefore be biased. d787 5 a791 5 literature \cite{Chri00}, see figure \ref{fig:visualisation}) using the \opt{-ab 1} option. This reduces noise in the density estimates from the ambient daughter rays, and the resulting ambient irradiance is cached and interpolated as in \radClassic, unless explicitly disabled with the \opt{-aa 0} option. d816 2 a817 1 global photon contribution (\emph{final gather}).} d847 1 a847 1 illumination there is no reliable way of separating it from noise. As d849 1 a849 2 to judge the quality of the bias compensation and its parametrisation. d864 3 a866 5 The multitude of options can be daunting for beginners, and it helps to start with a basic set of parameters upon which to refine if necessary. A physically valid simulation (assuming specular and diffuse materials) using the photon map is obtained with the following basic parameters: d869 2 a870 1 \opt{-apc} \var{causticpmap} \var{nphotons} \var{octree}\\ d875 2 a876 1 \end{verse} d880 2 a881 3 in conjunction with photon maps. \noindent The \cmd{rpict} photon mapping options are as follows: d940 1 a940 1 \item \lit{Radiance\_PreComp\_Global\_Photon\_Map}, d958 2 a959 2 used directly with \cmd{objview}. The photons themselves are modeled as simple spheres of a user defined radius, with their colour d979 4 a982 4 \cmd{mkpmap} \opt{-apg} \lit{pmap.gpm} \opt{-apc} \lit{pmap.cpm} \opt{-apv} \lit{pmap.vpm} \lit{scene.oct} \\ \cmd{pmapdump} \lit{radius} \lit{pmap.gpm} \lit{pmap.cpm} \lit{pmap.vpm} $|$ \textbackslash\\ d996 3 a998 2 Similar problems occur if the sphere radius is too small compared to the scene extent. This problem is aggravated with large photon maps, d1000 1 a1000 1 maps. We found it impractical to dump more than 50000 photons, which d1022 1 a1022 1 modified photon distribution algorithm via the \opt{-apl} options d1040 3 a1042 3 photons than there are light sources for density estimation results in omitted contributions from some light sources, thus \cmd{rcontrib} clamps the bandwidth accordingly. d1180 2 a1181 1 a dynamic bandwidth 50--500 of photons with bias compensation. d1185 2 d1188 34 a1221 1 d1253 1 a1253 1 \var{bwidth_2} & 200--400 \\ a1260 1 \clearpage d1291 11 d1305 1 a1305 1 \hline d1312 1 a1312 1 \hline a1324 11 \end{tabular} \caption{Troubleshooting chart.} \end{table} \begin{table}[!htb] \centering \begin{tabular}{|p{0.3\linewidth}|p{0.3\linewidth}|p{0.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline d1333 1 a1333 1 \hline a1346 35 \begin{thebibliography}{99} \bibitem[Ward94]{Ward94} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. Proceedings SIGGRAPH~'94, July~1994 \bibitem[Ward98]{Ward98} Greg Ward Larson and Rob Shakespeare: ``Rendering with \radiance''. Morgan Kaufmann, San Francisco, 1998 \bibitem[Jens96]{Jens96} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. Rendering Techniques '96, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996 \bibitem[Jens97]{Jens97} Henrik Wann Jensen: ``Rendering Caustics on Non-Lambertian Surfaces''. Computer Graphics Forum, vol.~16~(1), March~1997 \bibitem[Jens98]{Jens98} Henrik Wann Jensen and Per H.~Christensen: ``Efficient Simulation of Light Transport in Scenes with Participating Media using Photon Maps''. Proceedings SIGGRAPH~'98, July~1998 \bibitem[Jens00]{Jens00} Henrik Wann Jensen and Niels J{\o}rgen Christensen: ``A Practical Guide to Global Illumination using Photon Maps''. SIGGRAPH~2000 Course Notes~8, July~2000 \bibitem[Bent75]{Bent75} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. CACM 18(9), 1975 \bibitem[Chri00]{Chri00} Per Christensen: ``Faster Photon Map Global Illumination''. Journal of Graphics Tools, vol.~4~(3), April~2000 \bibitem[Schr03]{Schr03} Roland Schregle: ``Bias Compensation for Photon Maps''. Computer Graphics Forum, vol.~22~(4), December~2003 \end{thebibliography} @ 1.10 log @Added sample renderings and documented light source contribs. @ text @d15 2 a16 2 \RCS $Revision: 1.9 $ \RCS $Date: 2014/10/20 17:40:30 $ d36 1 a36 1 Development on the \radiance{} photon map has resumed as of november 2013, d781 23 a803 8 Global photons are visualised via an intermediate ambient bounce (commonly referred to as \emph{final gather} in the literature), which reduces noise (figure \ref{fig:visualisation}). An exception to the rule applies when specifying a negative number of ambient bounces \opt{-ab}, which enables debugging by directly visualising the global photon irradiance. Ambient values (specified with \opt{-av}) are ignored. The global photon irradiance may be optionally precomputed by \cmd{mkpmap} to speed things up at the expense of accuracy. d1001 1 a1001 1 \section{Photon Mapping with Light Source Contributions} d1004 12 a1015 11 The \radiance{} photon map has been adapted to facilitate the computation of light source contributions for climate-based daylight simulation. In this workflow, the scene supplied to \cmd{mkpmap} contains multiple light sources representing different time-dependent positions (e.g. solar elevations depending on season and time of day) of one source, which are handled as aggregate for efficient simulation. The \cmd{rcontrib} tool supplied with \radiance{} can then determine the irradiance for each light source for a given sensor position in the scene, thus efficiently accounting for each source's contribution. In practice, this is done by ``binning'' the resulting irradiance into separate output files for each light source. See the \cmd{rcontrib} man page for details @ 1.9 log @Documented new parameters, added "what's new" section, reformatted with macros for variables, options, and literals. @ text @d2 1 a2 1 \usepackage{color,graphicx,pslatex,rcs} d15 2 a16 2 \RCS $Revision$ \RCS $Date$ d310 1 a310 2 precomputed irradiance can be used directly (figure \ref{fig:finalgather}). d319 1 a319 1 \includegraphics[width=0.6\linewidth]{finalgather1} d323 1 a323 1 \label{fig:finalgather}} d348 1 d351 1 a351 1 at a price, at it does impact performance noticeably. d404 1 a404 1 challenge; there is no local geometry associated with these distant d413 1 a413 1 To aggravate the situation, distant sources are often used to render d427 1 a427 1 dramatically, resulting in a dramatic increase in performance. d431 1 a431 1 \includegraphics[width=0.8\linewidth]{port1} d434 1 a434 1 port for distant sources.} d443 1 a443 1 incident flux from distant sources is evaluated at each port and the d464 1 a464 6 \section{Photon Mapping with Light Source Contributions} \label{sec:lsContribs} \section{Photon Distribution with \cmd{mkpmap}} d467 6 a472 5 generates a photon map of each specified type for the scene. The photons are stored in a space subdividing data structure \cite{Bent75} which facilitates nearest neighbour queries required for the gathering step. The data structure is written to a portable binary file for subsequent use by \cmd{rpict}. d544 2 a545 1 \var{N_v} volume, \var{N_d} direct, \var{P}\% after \var{T} hours, d760 140 d986 72 a1057 1 \section{Photon Gathering with \cmd{rpict}} a1058 3 The modified \cmd{rpict} rendering tool takes the photon map generated by \cmd{mkpmap} and perform the photon gathering and density estimation. Without photon map functionality enabled, it behaves like \radClassic. d1060 1 d1062 1 d1064 8 a1071 1 \subsection{Caustic Photon Visualisation} d1073 2 a1074 6 Caustic photons are visualised at points seen directly by the observer, or via specular reflections. Virtual light sources are disabled with the caustic photon map, since these effects are already accounted for. Note that irradiance calculations with \cmd{rtrace} using caustic photons are surface bound. Irradiance for points which do not lie on surfaces will therefore be biased. d1076 1 a1078 1 \subsection{Global Photon Visualisation} d1080 1 a1080 19 Global photons are visualised via an intermediate ambient bounce (commonly referred to as \emph{final gather} in the literature), which reduces noise (figure \ref{fig:visualisation}). An exception to the rule applies when specifying a negative number of ambient bounces \opt{-ab}, which enables debugging by directly visualising the global photon irradiance. Ambient values (specified with \opt{-av}) are ignored. The global photon irradiance may be optionally precomputed by \cmd{mkpmap} to speed things up at the expense of accuracy. \begin{figure}[!htb] \centering \includegraphics[width=0.75\linewidth]{visualisation} \parbox{0.9\linewidth} {\caption{Caustic photons are visualised at the primary ray, while an intermediate stratified sampling step is used between the primary ray and the global photon contribution (\emph{final gather}).} \label{fig:visualisation}} \end{figure} d1082 4 a1087 2 \subsection{Progress Report} \label{sec:rpict.report} d1089 39 a1127 19 Bias compensation statistics are provided in the progress report with the standard \opt{-t} option. The statistics for each photon type subject to bias compensation are reported as follows: \begin{quote} \var{N_{min}/N_{max}/N_{avg}} \var{ptype}, (\var{\epsilon_{min}/\epsilon_{max}/\epsilon_{rms}} error), \end{quote} where: \begin{itemize} \item \var{N_{min}}, \var{N_{max}}, and \var{N_{avg}} are the minimum, maximum, and average number of photons used per density estimate, respectively \item \var{ptype} is one of \lit{global}, \lit{caustic}, \lit{volume}, or \lit{direct}. \item \var{\epsilon_{min}}, \var{\epsilon_{max}}, and \var{\epsilon_{rms}} are the minimum, maximum, and RMS (root mean square) estimated relative errors in the resulting irradiance, respectively. \end{itemize} d1129 37 a1165 5 Since bias cannot be determined without knowing the actual illumination there is no reliable way of separating it from noise. As such, the error estimates are approximate and serve as a rough guide to judge the quality of the bias compensation and its parametrisation. d1167 10 d1178 24 a1202 1 \subsection{Command Line Arguments for \cmd{rpict}} a1203 8 The photon mapping backward pass is disabled by default and must be explicitly enabled using the \opt{-ap} option. The different photon map types may be renderered independently or in combination. Note that rendering only the global or caustic photon map does not take all light transport paths into consideration at the primary hitpoint. Since modifying the lights or geometry invalidates the photon map, a warning is issued if the octree is newer than the photon map, referring to the latter as ``stale''. d1205 2 a1206 51 The multitude of options can be daunting for beginners, and it helps to start with a basic set of parameters upon which to refine if necessary. A physically valid simulation (assuming specular and diffuse materials) using the photon map is obtained with the following basic parameters: \begin{verse} \cmd{mkpmap} \opt{-apg} \var{globalpmap} \var{nphotons} \opt{-apc} \var{causticpmap} \var{nphotons} \var{octree}\\ \cmd{rpict} \opt{-ap} \var{globalpmap} \var{bwidth} \opt{-ap} \var{causticpmap} \var{bwidth} \opt{-ab} 1 \opt{-vf} \var{view} \textbackslash\\ \qquad \var{octree} \end{verse} As with \radClassic, the \opt{-ad}, \opt{-ar}, and \opt{-aa} parameters may need modification in some cases to improve the rendering quality. Some parameters are adopted from \radClassic{} with extended semantics in conjunction with photon maps. \noindent The \cmd{rpict} photon mapping options are as follows: \begin{description} \item{\opt{-ab} \var{nbounces}}\\ The number of ambient bounces for the indirect diffuse irradiance; setting this to any positive value will include global photon irradiance via \emph{one} ambient bounce (final gather). The result of this ambient bounce is stored in the ambient cache for interpolation, but the global photon map irradiance is not cached for the ambient daughter rays. Setting this to a negative value will not spawn any ambient rays at all, and instead visualises the global photon irradiance directly at the primary ray. This is intended for debugging and checking the irradiance distribution, as the quality of the resulting renderings is poor. If the global photons are precomputed, this produces a Voronoi diagram. As with \radClassic, the default value of 0 disables the ambient component, although caustic photon irradiance is still visualised at the primary ray. \item{\opt{-ap} \var{file} \var{bwidth_1} \var{[bwidth_2]}}\\ Loads a photon map from \var{file}, the type of which is automagically identified. The irradiance is then evaluated from the photons depending on their type (global, caustic, volume, direct) using density estimates with a bandwidth of \var{bwidth_1} photons. Specifying \var{bwidth_2} in addition enables bias compensation for the density estimates with a minimum and maximum bandwidth of \var{bwidth_1} and \var{bwidth_2}, respectively. \var{Bwidth_1} is ignored for precomputed global photons, as the precomputed irradiance from the nearest photon is looked up. \radiance's direct calculation is disabled with direct photons, and only surfaces with diffuse component are accounted for; this is stricly a debugging and validation option, and rarely needed in practice. \end{description} d1208 54 d1263 29 a1292 1 \section{Bugs and Weirdness} a1293 1 \begin{itemize} d1295 32 a1326 188 \item The spotlight focal point is ignored by the photon map; it coincides with the light source surface. This corresponds to specifying a direction vector of infinitesimal length in \radClassic. \item \cmd{mkpmap}'s distribution algorithm can exceed the specified number of photons with scenes having high reflectance or when excessively high settings of \opt{-apD} are used. \item Caustic photon irradiance will be biased when passing \cmd{rtrace} points which do not lie on a surface. \end{itemize} \section{Acknowledgement} \copyright Fraunhofer Institute for Solar Energy Systems, Lucerne University of Applied Sciences and Arts. Development of the \radiance{} photon mapping extension was sponsored by the German Research Foundation (DFG) and the Swiss National Science Foundation (SNF). \pagebreak \section{Sample Renderings} \pagebreak \appendix \section{Parameter Ranges} The following table lists typical ranges for various parameters used with \cmd{mkpmap} and \cmd{rpict}. It is primarily aimed at novices, who are no doubt bewildered by the plethora of options. The ranges are recommendations based on the developer's experience, and should not be interpreted as fixed constraints. In some situations it is not unlikely to use settings far beyond the typical range. \begin{table}[!htb] \centering \begin{tabular}{|l|l|} \hline \cmd{mkpmap} parameter & typical range \\ \hline \hline \var{nphotons} & 50k--1m \\ \opt{-apD} & 0.1--10 \\ \opt{-apf} & 0.25--0.5 \\ \opt{-apm} & 5000--10000 \\ \opt{-dp} & 1000--100000 \\ \opt{-ds} & 0.0001--0.01 \\ \hline \hline \cmd{rpict} parameter & typical range \\ \hline \hline \var{bwidth_1} & 50--100 \\ \var{bwidth_2} & 200--400 \\ \hline \end{tabular} \caption{Parameter ranges for \cmd{mkpmap} and \cmd{rpict}.} \end{table} \clearpage \section{Troubleshooting} \begin{table}[!htb] \centering \begin{tabular}{|p{0.3\linewidth}|p{0.3\linewidth}|p{0.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline \cmd{mkpmap} stores too many photons & Too many emitted photons in distribution prepass & Reduce \opt{-apD} \\ \hline Number of stored photons differs substantially from specification & Too few photons emitted in distribution prepass; prediction for main pass inaccurate & Increase \opt{-apD} \\ \hline Excessive noise in photon irradiance & Bandwidth too low & Increase bandwidth \\ \hline Excessive blurring in photon irradiance & Bandwidth too high & Decrease bandwidth or increase size of photon map \\ \hline Excessive noise and blurring in different regions & Bandwidth is fixed & Apply bias compensation for dynamic bandwidth \\ \hline Severe irradiance falloff at polygon edges & Boundary bias due to high bandwidth & Reduce bandwidth or apply bias compensation \\ \hline Splotchy ambient illumination from global photons & Excessively noisy density estimates; too few ambient samples; irradiance caching too inaccurate & Check density estimate with \opt{-ab} -1, and increase bandwidth if necessary; increase \opt{-ad} if illumination has high variance or contains caustics; increase \opt{-ar} and/or decrease \opt{-aa} \\ \hline \cmd{mkpmap} complains about runaway photons & Photons stuck in infinite scattering loop, possibly pathological geometry or materials & Check geometry and materials; increase \opt{-apm} \\ \hline Direct photon irradiance from modified light source deviates significantly & Probability density function cannot adequately resolve emission distribution; too few source partitions & Increase \opt{-dp}; if distribution varies over surface, decrease \opt{-ds} \\ \hline \end{tabular} \caption{Troubleshooting chart.} \end{table} \begin{table}[!htb] \centering \begin{tabular}{|p{0.3\linewidth}|p{0.3\linewidth}|p{0.3\linewidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline \cmd{mkpmap} is slow with \lit{source} primitive & \lit{source} emits from scene cube faces & Define photon ports \\ \hline \cmd{mkpmap} bogs down in light source flux integration & Excessively high probability density function resolution; too many source partitions & Decrease \opt{-dp}; increase \opt{-ds} \\ \hline \cmd{mkpmap} bails out after too many distribution prepasses & Using caustic photons with non-specular geometry; using volume photons without \lit{mist}; pathological geometry or nonabsorbing materials; light sources see no geometry & Check scene and specify compatible photon types \\ \hline Everything is slow & User expects too much & Twiddle thumbs \\ \hline \end{tabular} \caption{Troubleshooting chart (continued).} \end{table} \begin{thebibliography}{99} \bibitem[Ward94]{Ward94} Gregory J.~Ward: ``The \radiance{} Lighting Simulation and Rendering System''. Proceedings SIGGRAPH~'94, July~1994 \bibitem[Ward98]{Ward98} Greg Ward Larson and Rob Shakespeare: ``Rendering with \radiance''. Morgan Kaufmann, San Francisco, 1998 \bibitem[Jens96]{Jens96} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. Rendering Techniques '96, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996 \bibitem[Jens97]{Jens97} Henrik Wann Jensen: ``Rendering Caustics on Non-Lambertian Surfaces''. Computer Graphics Forum, vol.~16~(1), March~1997 \bibitem[Jens98]{Jens98} Henrik Wann Jensen and Per H.~Christensen: ``Efficient Simulation of Light Transport in Scenes with Participating Media using Photon Maps''. Proceedings SIGGRAPH~'98, July~1998 \bibitem[Jens00]{Jens00} Henrik Wann Jensen and Niels J{\o}rgen Christensen: ``A Practical Guide to Global Illumination using Photon Maps''. SIGGRAPH~2000 Course Notes~8, July~2000 \bibitem[Bent75]{Bent75} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. CACM 18(9), 1975 \bibitem[Chri00]{Chri00} Per Christensen: ``Faster Photon Map Global Illumination''. Journal of Graphics Tools, vol.~4~(3), April~2000 \bibitem[Schr03]{Schr03} Roland Schregle: ``Bias Compensation for Photon Maps''. To appear in Computer Graphics Forum, vol.~22~(4), December~2003 \end{thebibliography} @ 1.8 log @Removed stuff about wavelet representation. @ text @d2 1 a2 1 \usepackage{color,graphicx,pslatex} d4 2 d7 19 a25 8 \author{Roland Schregle (schregle@@ise.fhg.de)\\ Fraunhofer Institute for Solar Energy Systems} \title{The RADIANCE Photon Map Manual} \date{\today\\ $Revision: 1.7 $} d29 2 a30 418 \maketitle \tableofcontents \section{Introduction} The RADIANCE rendering system \cite{Ward94} is a very versatile and powerful tool for lighting simulation, and one of the very few physically based renderers with available source code. However, developments in light redirecting materials have presented new challenges in their simulation; their specular nature makes them difficult to simulate with RADIANCE, often merely resulting in a noisy mess. Some are downright impossible to simulate correctly with RADIANCE or bog the system down with high computational overhead. Particularly the phenomenon of caustics poses a serious problem for RADIANCE. Caustics are the bright, iridescent highlights on diffuse surfaces caused by specular reflection or refraction. A typical example is the cardioid pattern seen inside a cup or metal ring (figure \ref{fig:caustic}). Quoting chapter 13 of {\it Rendering with RADIANCE\/} \cite{Ward98}, \begin{quote} ``Other cases involving curved, specular reflectors pose similar difficulties for {\tt mkillum}, and the only long-term solution seems to be the creation of a forward raytracing module for computing these kinds of illums.'' \end{quote} The problem is actually far more fundamental due to RADIANCE's backward raytracing methodology, and not restricted to {\tt mkillum} alone. \begin{figure}[!htb] \centering \includegraphics[angle=-90, width=0.7\textwidth]{caustic.ps} \parbox{0.75\textwidth} {\caption{Photograph of metal ring caustic.} \label{fig:caustic}} \end{figure} RADIANCE's difficulties with sophisticated light redirecting materials necessitated the development of the forward raytracing module mentioned above as a supplementary algorithm. The photon map \cite{Jens96, Jens97, Jens00} was chosen for a number of reasons: \begin{itemize} \item Apart from handling indirect diffuse illumination, it handles caustics efficiently and has become the algorithm of choice for this purpose. \item It is straightforward to integrate into existing ray tracing environments. \item It is decoupled from the scene geometry and thus can handle arbitrarily complex objects, including procedural and even fractal ones. This also enables using the photon map to simulate indirect illumination in volumes, such as participating media \cite{Jens98}. \item It represents a view independent solution to the indirect illumination and thus opens up the possiblity of interactive walkthroughs as with the Radiosity method. \end{itemize} The photon map is based on a (light) particle transport simulation, which lends its name. Each photon interacts with the objects it strikes and is either reflected, transmitted, or absorbed, depending on the characteristics of the material. A Monte Carlo sampling method is used to generate the reflected or transmitted directions of a photon if it survives. Eventually a particle is terminated either by absorbtion or leakage (if it leaves the scene), and a new photon is emitted. \section{Overview of the Implementation} The photon map algorithm comprises two steps: \begin{description} \item[Photon distribution:] as a preprocess, photons are emitted from all light sources and probabilistically reradiated or absorbed upon striking a surface or passing through a volume, depending on its properties. The result is a view independent representation of the indirect illumination (figure \ref{fig:cornell_distrib}). \item[Photon gathering:] during the actual rendering, the indirect illumination for a point on a surface or within a volume is determined by finding a number of nearest photons to the point. The irradiance is then proportional to the photon density (figure \ref{fig:nnsearch}). \end{description} \begin{figure}[!htb] \centering \includegraphics[width=0.48\textwidth]{cornell-distrib1.eps} \hfill \includegraphics[width=0.48\textwidth]{cornell-distrib2.ps} \parbox{\textwidth} {\caption{Global photon distribution in the Cornell box. Left: global and caustic photon paths during forward pass. Dots indicate stored photons, where blue represents global photons, and red represents caustic photons. Right: photon distribution after completion of forward pass. Note the concentration of caustic photons on the back wall reflected from the glass sphere.} \label{fig:cornell_distrib}} \end{figure} \begin{figure}[!htb] \centering \resizebox{0.7\textwidth}{!}{\input{nnsearch.pstex_t}} \parbox{0.9\textwidth} {\caption{Gathering photons via nearest neighbour search.} \label{fig:nnsearch}} \end{figure} The distribution step is performed by the {\tt mkpmap} utility. It is responsible for building the photon map and saving it to a file for subsequent reuse by {\tt rpict}\footnote{Unless noted otherwise, {\tt rpict} also implies its siblings {\tt rtrace} and {\tt rview}.} for the actual rendering and photon gathering. \noindent Four photon types are available: \begin{description} \item[Global photons] account for all indirect (ambient) illumination incident on surfaces with a diffuse component. \item[Caustic photons] account for all indirect specular to diffuse transfers, i.e. caustics. These transport paths are also accounted for by global photons, but not visualised directly like caustics. \item[Volume photons] account for indirect illumination within participating media using the {\it mist\/} primitive. \item[Direct photons] account for the direct component from light sources and are only intended as a debugging option. \end{description} Each photon type is stored in a separate photon map and visualised differently. The stock RADIANCE functionality (referred to here as RADIANCE Classic$^\mathsf{TM}$) is preserved in {\tt rpict} if no command line arguments pertaining to the photon map are given. When rendering with the photon map, the ambient calculation is augmentented by a photon map density estimate, but the direct and indirect specular components are still delivered by RADIANCE Classic. \subsection{Supported Primitives} Material types in RADIANCE require additional code to probabilistically generate outgoing directions for incident photons using monte carlo methods. This has been done for those materials with fixed BRDFs / BTDFs: \begin{description} \item[Gaussian:] {\it plastic, metal, trans, plastic2, metal2, trans2} \item[Refracting/Reflecting:] {\it glass, dielectric, interface, mirror} \item[Mixtures:] {\it mixfunc, mixdata} \item[Patterns:] {\it colorfunc, brightfunc, colordata, brightdata, colorpict} \item[Textures:] {\it texfunc, texdata} \item[Volumes:] {\it mist, antimatter} \end{description} Materials for user defined BRDFs / BTDFs such as {\it plasfunc, metfunc, transfunc, brtdfunc, plasdata, metdata,\/} and {\it transdata\/} are currently {\bf not} supported due to the high sampling overhead in conjunction with the photon map\footnote{This overhead arises from the fact that the BRDF would have to be evaluated for the entire hemisphere of outgoing directions for \emph{every\/} photon hit during the distribution pass.}. In order for volume photons to function correctly with materials which modify the coefficient of extinction and scattering albedo (i.e. {\it dielectric\/} and {\it interface\/}), it is necessary to surround the light source(s) and viewpoint with a mist boundary (e.g. {\it bubble\/}), unless one intends to restrict volume photons to a small section of the scene. Participating media are essentially hacked into RADIANCE, and this calls for peculiar workarounds. In order to get volume caustics from light passing through an object, it must also be surrounded by a mist boundary. Alternatively, the mist parameters can be set globally on the command line, however this requires setting the source and viewpoint boundaries' extinction to zero, otherwise extinction is accumulated. Furthermore, {\tt rpict} only accounts for inscattering along rays of finite length, i.e. which intersect a local object. The scene therefore requires peripheral geometry to delineate a finite expanse of mist, e.g. a mist boundary for the entire scene. Confusing? Blame Greg! Light sources require additional code for photon emission. Currently supported primitives are {\it light, spotlight, glow,\/} and {\it source.\/} To ensure accurate distribution light source geometries are partitioned to a user specified resolution, and photons emitted from each partition. In the case of the {\it source\/} primitive there is no geometry to partition; instead, the scene cube faces are partitioned and act as emitters, unless photon {\it ports\/} are used (see section \ref{sec:ports}). The {\it glow\/} primitive acts as a regular light source. Virtual sources are disabled with the photon map, since caustic photons already account for these effects. Light sources may be modified by function files. During photon emission, the predefined variables passed to them (see {\tt rayinit.cal}) are defined in terms of the photon origin on the light source: \begin{itemize} \item the emitted photon's direction {\tt Dx}, {\tt Dy}, and {\tt Dz} points towards the photon origin \item {\tt Nx}, {\tt Ny}, and {\tt Nz} is the normal on the light source surface at the photon origin \item {\tt Px}, {\tt Py}, and {\tt Pz} is the emitted photon's origin \item {\tt T} and {\tt Ts} are undefined \item {\tt Rdot} is the dot product of the surface normal and the photon's direction at its origin. \end{itemize} \subsection{Optimisations} A number of optimisations have been incorporated into the implementation to either improve performance or accuracy. The user must be aware of the fact that most of these optimisations incur trade-offs; increasing performance will inevitably compromise accuracy, and vice versa. Such is the harsh reality of Monte Carlo. \subsubsection{Final Gather} Per Christensen's {\it final gather\/} scheme \cite{Chri00} has been integrated into the implementation and is available as an option to accelerate the global photon gathering step. Global photon irradiance is precomputed for a fraction of the photon positions and stored with the photons. This reduces the overhead of global photon lookups during the gathering phase; only the single closest global photon is retrieved, and its precomputed irradiance can be used directly (figure \ref{fig:finalgather}). However, final gather has the disadvantage of introducing bias to the solution for scenes with nonuniform indirect illumination. When accurate simulation is required it's best to forego this option. Final gather may also be combined with the bias compensating operator explained below. \begin{figure}[!htb] \centering \includegraphics[width=0.6\textwidth]{finalgather1.ps} \parbox{0.9\textwidth} {\caption{Radiance derived from precomputed global photon irradiance for final gather. Note the caustic from the glass sphere.} \label{fig:finalgather}} \end{figure} \subsubsection{Bias Compensation} The number of photons used for an irradiance estimate (also referred to as the estimate {\it bandwidth\/}) affords the user control over the quality and accuracy of the rendering by trading off between noise and bias. Setting this too low may result in excessive noise. Setting this too high may result in excessive blurring and local bias in the solution. To counter the bias/noise tradeoff, a {\it bias compensating operator\/} \cite{Schr03} was developed and incorporated into the irradiance estimate as an option. Its purpose is to adapt the bandwidth within a user specified lower and upper bound. The operator employs a binary search for an optimal bandwidth based on the likelihood that deviations from a running average irradiance are due to noise or bias. This results in substantially improved contours in nonuniform indirect illumination (particularly caustics) with a slight increase in noise in these regions (figure \ref{fig:biascomp}). The operator also compensates boundary bias (darkening at polygon edges) and chromatic bias. However, this sophistication comes at a hefty price; performance will suffer severely under this operator. \begin{figure}[!htb] \centering \includegraphics[angle=-90, width=0.6\textwidth] {spot-bias-50000-false.ps} \\[0.05\textwidth] \includegraphics[angle=-90, width=0.6\textwidth] {spot-biascomp-50000-false.ps} \parbox{0.9\textwidth} {\caption{Top: falsecolour rendering of severely biased caustic with a bandwidth of 5000 photons. The caustic should have an irradiance of 10 $W/m^2$. Bottom: falsecolour rendering of the same caustic with bias compensation using a bandwidth of 50--5000 photons.} \label{fig:biascomp}} \end{figure} \subsubsection{Irradiance Thresholds} Performance can be tweaked with the {\it irradiance threshold\/} parameter, which can be specified separately for each photon type. This is assumed to be the minimum visible irradiance contributed by the photon map. A maximum search radius for photon gathering is derived from this threshold based on the photon flux and the number of photons to gather. No photons beyond this radius will be searched, which can speed up the search dramatically. This of course presupposes some knowledge of the lighting levels in the scene on behalf of the user. Unfortunately, setting the threshold too high will result in frequent ``short'' gathers, finding fewer photons than requested. While this isn't tragic, it can introduce noise or banding. However, grossly overestimated thresholds can lead to the complete omission of low indirect illumination, which is unacceptable, except possibly for crude previews. With reasonable settings the artifacts are usually quite subtle while still yielding a performance gain. Caustics benefit most from this parameter, since they are only visible where the photons cluster, while the rest of the scene is sparse and therefore contributes negligible illumination. \subsubsection{Photon Ports} \label{sec:ports} Emitting photons from the {\it source\/} primitive presents a challenge; there is no local geometry associated with these distant sources. While the default behaviour is to emit photons from the scene cube faces, this can become highly inefficient for sources with large solid angles. These are infact situations for which a forward raytracer is fundamentally inappropriate. RADIANCE Classic's backward raytracer fares better here, since sending a ray to a large source is trivial. With the forward raytracer, the majority of emitted photons will be lost and won't contribute to the photon map. To aggravate the situation, distant sources are often used to render interior daylit spaces. With the viewer positioned inside, the few photons that actually strike the geometry must also pass through windows or skylights before they can even contribute visibly to the photon map. Needless to say, this amounts to abysmal performance. A simple workaround to the problem is the concept of photon {\it ports\/}. The ports are basically apertures through which photons can enter the space containing the viewpoint. These can be windows, skylights, but also invisible polygons within the scene (figure \ref{fig:port}). There is a price to pay however, since this scheme requires user intervention. The user must define the port geometry and specify them according to their modifiers. If the user places the ports intelligently, the photon loss factor will be reduced dramatically, resulting in a substantial increase in performance. \begin{figure}[!htb] \centering \includegraphics[width=0.8\textwidth]{port1.eps} \parbox{0.9\textwidth} {\caption{Typical daylighting geometry with window as photon port for distant sources.} \label{fig:port}} \end{figure} All objects using the specified port modifiers act as ports during photon distribution. Photons are emitted directly from the ports rather than from the scene cube faces. The ports must be defined in the scene description such that the surface normals point {\bf outside}. The incident flux from distant sources is evaluated at each port and the sources are checked for occlusion. However, no interreflection calculation is made; ports differ from {\it illums\/} in this respect. Photons are scattered by the port upon emission as if they had passed through it. In some cases ports may not coincide with any scene geometry. These situations call for invisible ports. Photons should be emitted from them, but they should not be affected by scattering through the port, and the port should not be visible during rendering. The simple solution is to define photon ports using the {\it antimatter\/} modifier, with {\it void\/} as its only string argument. Photon ports are the only optimisation in the implementation which do not compromise accuracy for performance, assuming the user knows what he/she/it is doing. It should also be noted that the photon port concept in the current release is a simple hack as an interim to a more sophisticated and flexible distribution method. Future implementations may use importance information for photon paths to yield more intelligent and efficient distribution, possibly even without user intervention. {\tiny (Or not. Probably not.)} \section{Photon Distribution with {\tt mkpmap}} The {\tt mkpmap} utility accepts a RADIANCE octree as input and generates a photon map of each specified type for the scene. The photons are stored in a space subdividing data structure \cite{Bent75} which facilitates nearest neighbour queries required for the gathering step. The data structure is written to a portable binary file for subsequent use by {\tt rpict}. If a photon map with the specified file name already exists, {\tt mkpmap} aborts without overwriting. The need for this protection stems from the frustration of having photon maps from very long previous distribution passes obliterated by the command line history! There is no ``clobber'' option; the files must be renamed or removed by hand. This is an annoyance, but better safe than sorry... \subsection{Distribution Algorithm} The parametrisation of the distribution step is primarily intended to be user friendly; the user specifies the required number of photons stored in each map. These are treated as ``targets'' which the photon distribution code tries to attain, since there is no way of knowing the outcome of the distribution a priori. The distribution algorithm makes an educated guess at the number of photons it must emit in order to satisfy the targets. This is based on the results of a distribution prepass in which a small number of photons (a fraction of the minimum specified target) is emitted and distributed. Since the distribution process scales linearly, the remaining number of photons to emit can be predicted and distributed in the main pass. The actual number of photons generated after the distribution is complete will approximate the targets. \subsection{Distribution Failure} The distribution step may bog down and terminate after a user specified number of distribution prepass attempts if any of the specified photon maps are still empty. This is usually an indication of a scene anomaly or an incompatible photon map specification. This is intended as a convenience for the user; without it, {\tt mkpmap} would end up in an infinite loop. It is nevertheless the user's responsibility to specify compatible photon map types and to check the validity of the scene. \noindent The following situations can cause {\tt mkpmap} to fail: \begin{itemize} \item pathological scenes in which none of the light sources see any geometry \item specifying a global photon map for a scene containing no materials with diffuse component \item specifying a caustic photon map for a scene containing no materials with diffuse or specular component \item specifying a volume photon map for a scene lacking the {\it mist\/} primitive. \end{itemize} a32 1 \subsection{Runaway Photons} d34 749 a782 154 Photons may become trapped inside {\it dielectric\/} or {\it interface\/} materials, often due to infinite total reflection. These ``runaway'' photons are terminated after a user defined bounce limit is exceeded, and a warning is issued under the assumption that this is an anomaly of the scene geometry. \subsection{Progress Report} If progress reports are enabled, {\tt mkpmap} will report the following during distribution: \begin{quote} {\tt $N_e$ emitted, $N_g$ global, $N_c$ caustic, $N_v$ volume, $N_d$ direct, $P$\% after $T$ hours}, \end{quote} where: \begin{itemize} \item $N_e$ is the total number of emitted photons \item $N_g$, $N_c$, $N_v$, and $N_d$ is the number of global, caustic, volume, and direct photons stored, respectively \item $P$ is the percentage completed \item $T$ is the time elapsed. \end{itemize} When precomputing global photon irradiance a report will also be issued with the number of precomputed photons $N_p$: \begin{quote} {\tt $N_p$ precomputed, $P$\% after $T$ hours}, \end{quote} If precomputation is combined with bias compensation, error statistics will also be reported (see section \ref{sec:rpict.report}). \subsection{Command line arguments for {\tt mkpmap}} The general synopsis of the {\tt mkpmap} utility is: \begin{quote} {\tt mkpmap [options] octree} \end{quote} The options are as follows: \begin{description} \item{\tt -apg }\\ The output file name and approximate number of photons for the global photon map. \item{\tt -app }\\ The output file name for the precomputed global photon map, the approximate number of photons (before precomputation), and the number of photons (bandwidth) to use for the precomputed irradiance estimate. \item{\tt -appb }\\ Same as above, but applying bias compensation within the minimum and maximum number of photons on the precomputed irradiance estimate. \item{\tt -appt } \\ Irradiance threshold for precomputed global photon map in $W/m^2$. \item{\tt -apc }\\ The output file name and approximate number of photons for the caustic photon map. \item{\tt -apv }\\ The output file name and approximate number of photons for the volume photon map. Volume photons can only be used with octrees containing the {\it mist\/} primitive. \item{\tt -apd }\\ The output file name and approximate number of photons for the direct photon map. Direct photon maps are useful to determine suitable settings for the {\tt -ds} and {\tt -dp} options when using light sources with modifiers. This can provide a visual check for the resolution of the probability density function used for photon emission in conjunction with complex output distributions. It can also serve as a validation tool for comparison with RADIANCE's direct component. The quality of the direct photon irradiance is poor, and only accounts for surfaces with diffuse component. For these reasons, the direct photon map is strictly a debugging option. It is in no way intended to replace RADIANCE's direct calculation. \item{\tt -apD }\\ Fraction of the minimum number of photons specified which are emitted in the distribution prepass. Increase this if the number of stored photons differs substantially from your specified targets. This parameter may exceed 1. \item{\tt -apf }\\ Fraction of global photons to precompute for final gather, in the range $]0,1]$. The remaining photons are discarded. \item{\tt -apm }\\ Specifies the maximum number of bounces for a photon before termination as runaway photon. \item{\tt -apM }\\ Specifies the maximum number of distribution prepass attempts before terminating if some photon maps are still empty. This should only be increased under very unusual circumstances, as it normally indicates a scene anomaly or photon map specifications which are incompatible with the scene. \item{\tt -apo }\\ Specifies photon port modifier. All objects with this modifier will act as ports for photons emitted from the {\it source\/} primitive. This option can be used in mutliple instances with cumulative effect. \item{\tt -apO }\\ Photon port modifiers are read from the specified file. \item{\tt -bv}\\ Toggles backface visibility. Enabling this switch causes photons to be stored and possibly reradiated if they strike the back of a surface, otherwise they are ignored and immediately absorbed. \item{\tt -dp }\\ Resolution for sampling user defined light source emission distributions, in samples per steradian. This is required for numerically integrating the flux emitted by the light source and for constructing a probability density function (PDF) for photon emission. The accuracy of photon emission with user specified distributions depends on this parameter. Increase it if caustics exhibit spurious artifacts. \item{\tt -ds }\\ Light source partition size ratio; light sources are partitioned to distribute the photon emission over its surface. This parameter specifies the ratio of the size (per dimension) of each partition to the scene cube. \item{\tt -e }\\ Redirect diagnostics and progress reports to specified file. \item{\tt -i }\\ Photon heap size increment; photon heaps are enlarged by this amount when storage overflows. No need to fiddle with this. \item{\tt -ma }\\ Global scattering albedo. See {\tt rpict}. \item{\tt -me }\\ Global extinction coefficient. See {\tt rpict}. \item{\tt -mg }\\ Global scattering eccentricity. See {\tt rpict}. \item{\tt -t }\\ Generate progress report in specified intervals. \end{description} The {\tt -apc}, {\tt -apv}, and {\tt -apd} options can be freely combined with either {\tt -apg}, {\tt -app}, or {\tt -appb}. At least one of these must be specified... or nothing happens! \section{Querying the Photon Map with {\tt pmapinfo}} The {\tt pmapinfo} tool supplies the following information about a photon map: \begin{itemize} \item the photon map type as identified by magic number: d784 5 a788 5 \item {\tt Radiance\_Global\_Photon\_Map}, \item {\tt Radiance\_PreComp\_Global\_Photon\_Map}, \item {\tt Radiance\_Caustic\_Photon\_Map}, \item {\tt Radiance\_Volume\_Photon\_Map}, or \item {\tt Radiance\_Direct\_Photon\_Map} d790 194 a983 22 \item the {\tt mkpmap} command line used to build the photon map \item the number of photons in the photon map \item the photon flux averaged over the RGB colour channels. \end{itemize} \section{Visual Examination with {\tt pmapdump}} The {\tt pmapdump} tool is a no-frills hack to visualise the photon distribution in one or more photon map files. The ``dump'' to standard output consists of a RADIANCE scene description which can be included in the octree used to generate the photon maps. The photons themselves are modeled as simple spheres of a user defined radius, with their colour denoting the photon type as follows: \begin{description} \item[Blue:] global photon \item[Cyan:] precomputed global photon \item[Red:] caustic photon \item[Green:] volume photon \item[Magenta:] direct photon a985 6 \noindent The synopsis for {\tt pmapdump} is very simple: \begin{quote} {\tt pmapdump ...} \end{quote} An arbitrary number of photon maps can be specified on the command line and the respective photon type is determined automagically. a986 9 A typical application of {\tt pmapdump} would go something like: \begin{quote} {\tt oconv scene.rad > scene.oct \\ mkpmap -apg pmap.gpm -apc pmap.cpm -apv pmap.vpm scene.oct \\ pmapdump 0.01 pmap.gpm pmap.cpm pmap.vpm | \\ oconv - scene.rad > scene\_distrib.oct} \end{quote} Note the use of a pipe to directly create {\tt scene\_distrib.oct} from the {\tt pmapdump} output. d988 1 a988 5 The {\tt pmapdump} utility can be used for illustrative purposes to understand the photon map algorithm, but more importantly, it can be used to debug scenes in which you have no clue where your photons are. The image on the right in figure \ref{fig:cornell_distrib} is an example of a {\tt pmapdump} output. d990 1 a990 6 Note that {\tt oconv} may have a hard time with the {\tt pmapdump} output, requiring the use of the {\tt -n} or {\tt -r} options. This appears to result from the sphere overlap in dense photon distributions (such as caustics) or if the sphere radius is too small compared to the scene extent. Large photon maps tend to bog {\tt oconv} down too, and the individual photons are difficult to discern anyway, hence conservatism is advised. d992 6 d999 2 a1001 58 \section{Photon Gathering with {\tt rpict}} The modified {\tt rpict} rendering tool takes the photon map generated by {\tt mkpmap} and perform the photon gathering and density estimation. Without photon map functionality enabled, it behaves like RADIANCE Classic. \subsection{Caustic Photon Visualisation} Caustic photons are visualised at points seen directly by the observer, or via specular reflections. Virtual light sources are disabled with the caustic photon map, since these effects are already accounted for. Note that irradiance calculations with {\tt rtrace} using caustic photons are surface bound. Irradiance for points which do not lie on surfaces will be biased. \subsection{Global Photon Visualisation} Global photons are visualised via an intermediate ambient bounce, which reduces noise (figure \ref{fig:visualisation}). An exception to the rule is a debugging option which directly visualises the global photons. Ambient values (specified with {\tt -av}) are ignored. The global photon irradiance may be optionally precomputed by {\tt mkpmap} to speed things up at the expense of accuracy. \begin{figure}[!htb] \centering \includegraphics[width=0.75\textwidth]{visualisation.eps} \parbox{0.9\textwidth} {\caption{Caustic photons are visualised at the primary ray, while an intermediate stratified sampling step is used between the primary ray and the global photon contribution.} \label{fig:visualisation}} \end{figure} \subsection{Progress Report} \label{sec:rpict.report} Bias compensation statistics are provided in the progress report with the standard {\tt -t} option. The statistics reported for each photon type subject to bias compensation are as follows: \begin{quote} {\tt $N_{min}$/$N_{max}$/$N_{avg}$ $ptype$, ($\epsilon_{min}$/$\epsilon_{max}$/$\epsilon_{rms}$ error)}, \end{quote} where: \begin{itemize} \item $N_{min}$, $N_{max}$, and $N_{avg}$ are the minimum, maximum, and average number of photons used per irradiance estimate, respectively \item $ptype$ is one of {\tt global}, {\tt caustic}, {\tt volume}, or {\tt direct}. \item \sloppy $\epsilon_{min}$, $\epsilon_{max}$, and $\epsilon_{rms}$ are the minimum, maximum, and RMS (root mean square) estimated relative errors in the irradiance estimates, respectively. a1003 100 Since bias cannot be determined without knowing the actual illumination there is no reliable way of separating it from noise. As such, the error estimates are crude and only serve as a guide to judge the quality of the operator and its parametrisation. \subsection{Command Line Arguments for {\tt rpict}} The photon map is disabled by default and must be explicitly enabled using one or more of the {\tt -ap} options. The different photon map types may be renderered independently or in combination. Note that rendering only the global or caustic photon map does not take all light transport paths into consideration, and may omit some indirect illumination. Since modifying the lights or geometry invalidates the photon map, a warning is issued if the octree is newer than the photon map. The multitude of options can be daunting for beginners, and it helps to start with a basic set of parameters upon which to refine if necessary. A physically valid simulation using the photon map is obtained with the following basic parameters: \begin{quote} \sloppy {\tt mkpmap -apg -apc \\ rpict -apg -apc -ab 1 -vf } \end{quote} As with RADIANCE Classic, the {\tt -ad}, {\tt -ar}, and {\tt -aa} parameters must be modified in some cases to improve the rendering quality. Parameters pertaining to caustic photons must be omitted for scenes lacking specular materials. The {\tt rpict} photon map options are as follows: \begin{description} \item{\tt -ab }\\ The number of ambient bounces; setting this to a positive value will include global photon contributions via {\bf one} ambient bounce (regardless of the actual number specified). The irradiance cache may be applied to the top level ambient rays, but photon map lookups are not cached. Setting this to a negative value will visualise the global photons directly. With precomputed global photons this produces a Voronoi diagram. The quality of the resulting renderings is usually abysmal, hence this setting is primarily intended for debugging purposes, e.g. to check the illuminance distribution. Caustic photons are not visualised with this setting, because the directly visualised global photon map already accounts for them in this case. As with RADIANCE Classic, the default value of 0 disables the ambient component; global photons are not visualised, but caustic photons are still visualised directly. \item{\tt -apg }\\ Loads the global photon map from the file and uses the specified number of photons (bandwidth) for a global irradiance estimate. \item{\tt -apgb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the global irradiance estimate. \item{\tt -apgt } \\ Irradiance threshold for global photon map in $W/m^2$. \item{\tt -app }\\ Loads the precomputed global photon map from the file and uses the precomputed irradiance for final gather. \item{\tt -apc }\\ Loads the caustic photon map from the file and uses the specified number of photons (bandwidth) for a caustic irradiance estimate. \item{\tt -apcb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the caustic irradiance estimate. \item{\tt -apct } \\ Irradiance threshold for caustic photon map in $W/m^2$. \item{\tt -apv }\\ Loads the volume photon map from the file and uses the specified number of photons (bandwidth) for a volume irradiance estimate within the {\it mist\/} primitive. \item{\tt -apvb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the volume irradiance estimate. \item{\tt -apvt } \\ Irradiance threshold for volume photon map in $W/m^2$. \item{\tt -apd }\\ Loads the direct photon map from the file and uses the specified number of photons (bandwidth) for a direct irradiance estimate. RADIANCE's direct calculation is disabled, and only surfaces with diffuse component are accounted for. This is stricly a debugging and validation option, and rarely needed in practice. \item{\tt -apdb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the direct irradiance estimate. \item{\tt -apdt } \\ Irradiance threshold for direct photon map in $W/m^2$. \end{description} d1006 1 a1006 3 \section{Bugs and Weirdness} \begin{itemize} d1008 4 a1011 4 \item The spotlight focal point is ignored by the photon map; it coincides with the light source surface. This corresponds to specifying a direction vector of infinitesimal length in RADIANCE Classic. a1012 3 \item {\tt mkpmap}'s distribution algorithm can exceed the specified number of photons with scenes having high reflectance or when excessively high settings of {\tt -apD} are used. a1013 2 \item Caustic photon irradiance will be biased when passing {\tt rtrace} points which do not lie on a surface. d1015 2 a1016 1 \end{itemize} d1020 2 d1025 1 a1025 1 {\tt mkpmap} and {\tt rpict}. It is primarily aimed at novices, who are no d1035 1 a1035 1 {\tt mkpmap} parameter & typical range \\ d1038 6 a1043 6 {\tt } & 50000--1000000 \\ {\tt -apD} & 0.1--10 \\ {\tt -apf} & 0.25--0.5 \\ {\tt -apm} & 5000--10000 \\ {\tt -dp} & 1000--100000 \\ {\tt -ds} & 0.0001--0.01 \\ d1046 1 a1046 1 {\tt rpict} parameter & typical range \\ d1049 2 a1050 2 {\tt } & 50--2000 \\ {\tt } & 0.001--0.1 \\ d1053 1 a1053 1 \caption{Parameter ranges for {\tt mkpmap} and {\tt rpict}.} d1063 1 a1063 1 \begin{tabular}{|p{0.3\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}|} d1068 1 a1068 1 {\tt mkpmap} stores too many photons & d1070 1 a1070 1 Reduce {\tt -apD} \\ d1075 1 a1075 1 Increase {\tt -apD} \\ d1096 3 a1098 7 Check density estimate with {\tt -ab -1}, and increase bandwidth if necessary; increase {\tt -ad} if illumination has high variance or contains caustics; increase {\tt -ar} and/or decrease {\tt -aa} \\ \hline Banding in photon irradiance & Maximum photon search radius too small & Decrease irradiance threshold \\ d1100 1 a1100 1 {\tt mkpmap} complains about runaway photons & d1103 1 a1103 1 Check geometry and materials; increase {\tt -apm} \\ d1109 2 a1110 2 Increase {\tt -dp}; if distribution varies over surface, decrease {\tt -ds} \\ d1118 1 a1118 1 \begin{tabular}{|p{0.3\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}|} d1123 2 a1124 2 {\tt mkpmap} is slow with {\it source\/} primitive & {\it source\/} emits from scene cube faces & d1127 1 a1127 1 {\tt mkpmap} bogs down in light source flux integration & d1130 1 a1130 1 Decrease {\tt -dp}; increase {\tt -ds} \\ d1132 1 a1132 1 {\tt mkpmap} bails out after too many distribution prepasses & d1134 1 a1134 1 without {\it mist\/}; pathological geometry or nonabsorbing materials; d1150 1 a1150 1 Gregory J.~Ward: ``The RADIANCE Lighting Simulation and d1153 2 a1154 2 Greg Ward Larson and Rob Shakespeare: {\it Rendering with RADIANCE\/}. Morgan Kaufmann, San Francisco, 1998 @ 1.7 log @Added reference for bias compensation. @ text @d11 1 a11 1 \date{\today\\ $Revision: 1.6 $} d173 4 a176 2 conjunction with the photon map. A wavelet representation is being developed for these. {\tiny (But don't hold your breath...)} @ 1.6 log @Moved revision into date. @ text @d11 1 a11 1 \date{\today\\ $Revision: 1.5 $} d263 11 a273 11 To counter the bias/noise tradeoff, a {\it bias compensating operator\/} was developed and incorporated into the irradiance estimate as an option. Its purpose is to adapt the bandwidth within a user specified lower and upper bound. The operator employs a binary search for an optimal bandwidth based on the likelihood that deviations from a running average irradiance are due to noise or bias. This results in substantially improved contours in nonuniform indirect illumination (particularly caustics) with a slight increase in noise in these regions (figure \ref{fig:biascomp}). The operator also compensates boundary bias (darkening at polygon edges) and chromatic bias. However, this sophistication comes at a hefty price; performance will suffer severely under this operator. d993 3 @ 1.5 log @Test to get RCS revision in title. @ text @d10 2 a11 2 \title{The RADIANCE Photon Map Manual\\ $Revision$} d279 1 a279 1 \\[0.02\textwidth] d342 1 a342 1 \includegraphics[width=0.65\textwidth]{port1.eps} d681 1 a681 1 \includegraphics[width=0.7\textwidth]{visualisation.eps} @ 1.4 log @Added pmapdump stuff. @ text @d11 1 a11 1 Version 3.19} @ 1.3 log @Changed some wording... @ text @d3 1 d6 2 d11 3 a13 1 Version 3.15} d16 979 a994 1007 \maketitle \tableofcontents \section{Introduction} The RADIANCE rendering system \cite{Ward94} is a very versatile and powerful tool for lighting simulation, and one of the very few physically based renderers with available source code. However, developments in light redirecting materials have presented new challenges in their simulation; their specular nature makes them difficult to simulate with RADIANCE, often merely resulting in a noisy mess. Some are downright impossible to simulate correctly with RADIANCE or bog the system down with high computational overhead. Particularly the phenomenon of caustics poses a serious problem for RADIANCE. Caustics are the bright, iridescent highlights on diffuse surfaces caused by specular reflection or refraction. A typical example is the cardioid pattern seen inside a cup or metal ring (figure \ref{fig:caustic}). To quote chapter 13 of {\it Rendering with RADIANCE\/} \cite{Ward98}, \begin{quote} ``Other cases involving curved, specular reflectors pose similar difficulties for {\tt mkillum}, and the only long-term solution seems to be the creation of a forward raytracing module for computing these kinds of illums.'' \end{quote} The problem is actually far more fundamental due to RADIANCE's backward raytracing methodology, and not restricted to {\tt mkillum} alone. \begin{figure}[!htb] \begin{center} \includegraphics[angle=-90, width=0.75\textwidth]{caustic.ps} \parbox{0.75\textwidth}{\caption{Photograph of metal ring caustic.} \label{fig:caustic}} \end{center} \end{figure} RADIANCE's difficulties with sophisticated light redirecting materials necessitated the development of the forward raytracing module mentioned above as a supplementary algorithm. The photon map \cite{Jens96, Jens97, Jens00} was chosen for a number of reasons: \begin{itemize} \item Apart from handling indirect diffuse illumination, it handles caustics efficiently and has become the algorithm of choice for this purpose. \item It is straightforward to integrate into existing ray tracing environments. \item It is decoupled from the scene geometry and thus can handle arbitrarily complex objects, including procedural and even fractal ones. This also enables using the photon map to simulate indirect illumination in volumes, such as participating media \cite{Jens98}. \item It represents a view independent solution to the indirect illumination and thus opens up the possiblity of interactive walkthroughs as with the Radiosity method. \end{itemize} The photon map is based on a (light) particle transport simulation, which lends its name. Each photon interacts with the objects it strikes and is either reflected, transmitted, or absorbed, depending on the characteristics of the material. A Monte Carlo sampling method is used to generate the reflected or transmitted directions of a photon if it survives. Eventually a particle is terminated either by absorbtion or leakage (if it leaves the scene), and a new photon is emitted. \section{Overview of the Implementation} The photon map algorithm comprises two steps: \begin{description} \item{\bf Photon distribution:} as a preprocess, photons are emitted from all light sources and probabilistically reradiated or absorbed upon striking a surface or passing through a volume, depending on its properties. The result is a view independent representation of the indirect illumination (figure \ref{fig:cornell_distrib}). \item{\bf Photon gathering:} during the actual rendering, the indirect illumination for a point on a surface or within a volume is determined by finding a number of nearest photons to the point. The irradiance is then proportional to the photon density (figure \ref{fig:nnsearch}). \end{description} \begin{figure}[!htb] \begin{center} \includegraphics[width=0.48\textwidth]{cornell_distrib1.eps} \hspace{\stretch{1}} \includegraphics[width=0.48\textwidth]{cornell_distrib2.eps} \parbox{\textwidth}{\caption{Global photon distribution in the diffuse Cornell box. Left: individual photon paths. Dots indicate stored photons. Right: photon distribution after completion of forward pass.} \label{fig:cornell_distrib}} \end{center} \end{figure} \begin{figure}[!htb] \begin{center} \resizebox{0.8\textwidth}{!}{\input{nnsearch.pstex_t}} \parbox{0.8\textwidth}{\caption{Gathering photons via nearest neighbour search.} \label{fig:nnsearch}} \end{center} \end{figure} The distribution step is performed by the {\tt mkpmap} utility. It is responsible for building the photon map and saving it to a file for subsequent reuse by {\tt rpict}\footnote{Unless noted otherwise, {\tt rpict} also implies its siblings {\tt rtrace} and {\tt rview}.} for the actual rendering and photon gathering. \noindent Four photon types are available: \begin{description} \item{\bf Global photons} account for all indirect (ambient) illumination incident on surfaces with a diffuse component. \item{\bf Caustic photons} account for all indirect specular to diffuse transfers, i.e. caustics. These transport paths are also accounted for by global photons, but not visualised directly like caustics. \item{\bf Volume photons} account for indirect illumination within participating media using the {\it mist\/} primitive. \item{\bf Direct photons} account for the direct component from light sources and are only intended as a debugging option. \end{description} Each photon type is stored in a separate photon map and visualised differently. The stock RADIANCE functionality (referred to here as RADIANCE Classic$^\mathsf{TM}$) is preserved in {\tt rpict} if no command line arguments pertaining to the photon map are given. When rendering with the photon map, the ambient calculation is augmentented by a photon map density estimate, but the direct and indirect specular components are still delivered by RADIANCE Classic. \subsection{Supported Primitives} Material types in RADIANCE require additional code to probabilistically generate outgoing directions for incident photons using monte carlo methods. This has been done for those materials with fixed BRDFs / BTDFs: \begin{description} \item{Gaussian:} {\it plastic, metal, trans, plastic2, metal2, trans2} \item{Refracting/Reflecting:} {\it glass, dielectric, interface, mirror} \item{Mixtures:} {\it mixfunc, mixdata} \item{Patterns:} {\it colorfunc, brightfunc, colordata, brightdata, colorpict} \item{Textures:} {\it texfunc, texdata} \item{Volumes:} {\it mist, antimatter} \end{description} Materials for user defined BRDFs / BTDFs such as {\it plasfunc, metfunc, transfunc, brtdfunc, plasdata, metdata,\/} and {\it transdata\/} are currently {\bf not} supported due to the high sampling overhead in conjunction with the photon map. A wavelet representation is being developed for these. {\tiny (But don't hold your breath...)} In order for volume photons to function correctly with materials which modify the coefficient of extinction and scattering albedo (i.e. {\it dielectric\/} and {\it interface\/}), it is necessary to surround the light source(s) and viewpoint with a mist boundary (e.g. {\it bubble\/}), unless one intends to restrict volume photons to a small section of the scene. Participating media are essentially hacked into RADIANCE, and this calls for peculiar workarounds. In order to get volume caustics from light passing through an object, it must also be surrounded by a mist boundary. Alternatively, the mist parameters can be set globally on the command line, however this requires setting the source and viewpoint boundaries' extinction to zero, otherwise extinction is accumulated. Furthermore, {\tt rpict} only accounts for inscattering along rays of finite length, i.e. which intersect a local object. The scene therefore requires peripheral geometry to delineate a finite expanse of mist, e.g. a mist boundary for the entire scene. Confusing? Blame Greg! Light sources require additional code for photon emission. Currently supported primitives are {\it light, spotlight, glow,\/} and {\it source.\/} To ensure accurate distribution light source geometries are partitioned to a user specified resolution, and photons emitted from each partition. In the case of the {\it source\/} primitive there is no geometry to partition; instead, the scene cube faces are partitioned and act as emitters, unless photon {\it ports\/} are used (see section \ref{sec:ports}). The {\it glow\/} primitive acts as a regular light source. Virtual sources are disabled with the photon map, since caustic photons already account for these effects. Light sources may be modified by function files. During photon emission, the predefined variables passed to them (see {\tt rayinit.cal}) are defined in terms of the photon origin on the light source: \begin{itemize} \item the emitted photon's direction {\tt Dx}, {\tt Dy}, and {\tt Dz} points towards the photon origin \item {\tt Nx}, {\tt Ny}, and {\tt Nz} is the normal on the light source surface at the photon origin \item {\tt Px}, {\tt Py}, and {\tt Pz} is the emitted photon's origin \item {\tt T} and {\tt Ts} are undefined \item {\tt Rdot} is the dot product of the surface normal and the photon's direction at its origin. \end{itemize} \subsection{Optimisations} A number of optimisations have been incorporated into the implementation to either improve performance or accuracy. The user must be aware of the fact that most of these optimisations incur trade-offs; increasing performance will inevitably compromise accuracy, and vice versa. Such is the harsh reality of Monte Carlo. \subsubsection{Final Gather} Per Christensen's {\it final gather\/} scheme \cite{Chri00} has been integrated into the implementation and is available as an option to accelerate the global photon gathering step. Global photon irradiance is precomputed for a fraction of the photon positions and stored with the photons. This reduces the overhead of global photon lookups during the gathering phase; only the single closest global photon is retrieved, and its precomputed irradiance can be used directly (figure \ref{fig:finalgather}). However, final gather has the disadvantage of introducing bias to the solution for scenes with nonuniform indirect illumination. When accurate simulation is required it's best to forego this option. Final gather may also be combined with the bias compensating operator explained below. \begin{figure}[!htb] \begin{center} \includegraphics[width=0.6\textwidth]{finalgather1.ps} \parbox{0.9\textwidth}{\caption{Radiance derived from precomputed global photon irradiance for final gather. Note the caustic from the glass sphere.} \label{fig:finalgather}} \end{center} \end{figure} \subsubsection{Bias Compensation} The number of photons used for an irradiance estimate (also referred to as the estimate {\it bandwidth\/}) affords the user control over the quality and accuracy of the rendering by trading off between noise and bias. Setting this too low may result in excessive noise. Setting this too high may result in excessive blurring and local bias in the solution. To counter the bias/noise tradeoff, a {\it bias compensating operator\/} was developed and incorporated into the irradiance estimate as an option. Its purpose is to adapt the bandwidth within a user specified lower and upper bound. The operator employs a binary search for an optimal bandwidth based on the likelihood that deviations from a running average irradiance are due to noise or bias. This results in substantially improved contours in nonuniform indirect illumination (particularly caustics) with a slight increase in noise in these regions (figure \ref{fig:biascomp}). The operator also compensates boundary bias (darkening at polygon edges) and chromatic bias. However, this sophistication comes at a hefty price; performance will suffer severely under this operator. \begin{figure}[!htb] \begin{center} \includegraphics[angle=-90, width=0.6\textwidth] {spot-bias-50000-false.ps}\\[0.5cm] \includegraphics[angle=-90, width=0.6\textwidth] {spot-biascomp-50000-false.ps} \parbox{0.9\textwidth}{\caption{Top: falsecolour rendering of severely biased caustic with a bandwidth of 5000 photons. The caustic should have an irradiance of 10 $W/m^2$. Bottom: falsecolour rendering of the same caustic with bias compensation using a bandwidth of 50--5000 photons.} \label{fig:biascomp}} \end{center} \end{figure} \subsubsection{Irradiance Thresholds} Performance can be tweaked with the {\it irradiance threshold\/} parameter, which can be specified separately for each photon type. This is assumed to be the minimum visible irradiance contributed by the photon map. A maximum search radius for photon gathering is derived from this threshold based on the photon flux and the number of photons to gather. No photons beyond this radius will be searched, which can speed up the search dramatically. This of course presupposes some knowledge of the lighting levels in the scene on behalf of the user. Unfortunately, setting the threshold too high will result in frequent ``short'' gathers, finding fewer photons than requested. While this isn't tragic, it can introduce noise or banding. However, grossly overestimated thresholds can lead to the complete omission of low indirect illumination, which is unacceptable, except possibly for crude previews. With reasonable settings the artifacts are usually quite subtle while still yielding a performance gain. Caustics benefit most from this parameter, since they are only visible where the photons cluster, while the rest of the scene is sparse and therefore contributes negligible illumination. \subsubsection{Photon Ports} \label{sec:ports} Emitting photons from the {\it source\/} primitive presents a challenge; there is no local geometry associated with these distant sources. While the default behaviour is to emit photons from the scene cube faces, this can become highly inefficient for sources with large solid angles. These are infact situations for which a forward raytracer is fundamentally inappropriate. RADIANCE Classic's backward raytracer fares better here, since sending a ray to a large source is trivial. With the forward raytracer, the majority of emitted photons will be lost and won't contribute to the photon map. To aggravate the situation, distant sources are often used to render interior daylit spaces. With the viewer positioned inside, the few photons that actually strike the geometry must also pass through windows or skylights before they can even contribute visibly to the photon map. Needless to say, this amounts to abysmal performance. A simple workaround to the problem is the concept of photon {\it ports\/}. The ports are basically apertures through which photons can enter the space containing the viewpoint. These can be windows, skylights, but also invisible polygons within the scene (figure \ref{fig:port}). There is a price to pay however, since this scheme requires user intervention. The user must define the port geometry and specify them according to their modifiers. If the user places the ports intelligently, the photon loss factor will be reduced dramatically, resulting in a substantial increase in performance. \begin{figure}[!htb] \begin{center} \includegraphics[width=0.85\textwidth]{port1.eps} \parbox{0.9\textwidth}{\caption{Typical daylighting geometry with window as photon port for distant sources.} \label{fig:port}} \end{center} \end{figure} All objects using the specified port modifiers act as ports during photon distribution. Photons are emitted directly from the ports rather than from the scene cube faces. The ports must be defined in the scene description such that the surface normals point {\bf outside}. The incident flux from distant sources is evaluated at each port and the sources are checked for occlusion. However, no interreflection calculation is made; ports differ from {\it illums\/} in this respect. Photons are scattered by the port upon emission as if they had passed through it. In some cases ports may not coincide with any scene geometry. These situations call for invisible ports. Photons should be emitted from them, but they should not be affected by scattering through the port, and the port should not be visible during rendering. The simple solution is to define photon ports using the {\it antimatter\/} modifier, with {\it void\/} as its only string argument. Photon ports are the only optimisation in the implementation which do not compromise accuracy for performance, assuming the user knows what he/she/it is doing. It should also be noted that the photon port concept in the current release is a simple hack as an interim to a more sophisticated and flexible distribution method. Future implementations may use importance information for photon paths to yield more intelligent and efficient distribution, possibly even without user intervention. {\tiny (Or not. Probably not.)} \section{Photon Distribution with {\tt mkpmap}} The {\tt mkpmap} utility accepts a RADIANCE octree as input and generates a photon map of each specified type for the scene. The photons are stored in a space subdividing data structure \cite{Bent75} which facilitates nearest neighbour queries required for the gathering step. The data structure is written to a portable binary file for subsequent use by {\tt rpict}. If a photon map with the specified file name already exists, {\tt mkpmap} aborts without overwriting. The need for this protection stems from the frustration of having photon maps from very long previous distribution passes obliterated by the command line history! There is no ``clobber'' option; the files must be renamed or removed by hand. This is an annoyance, but better safe than sorry... \subsection{Distribution Algorithm} The parametrisation of the distribution step is primarily intended to be user friendly; the user specifies the required number of photons stored in each map. These are treated as ``targets'' which the photon distribution code tries to attain, since there is no way of knowing the outcome of the distribution a priori. The distribution algorithm makes an educated guess at the number of photons it must emit in order to satisfy the targets. This is based on the results of a distribution prepass in which a small number of photons (a fraction of the minimum specified target) is emitted and distributed. Since the distribution process scales linearly, the remaining number of photons to emit can be predicted and distributed in the main pass. The actual number of photons generated after the distribution is complete will approximate the targets. \subsection{Distribution Failure} The distribution step may bog down and terminate after a user specified number of distribution prepass attempts if any of the specified photon maps are still empty. This is usually an indication of a scene anomaly or an incompatible photon map specification. This is intended as a convenience for the user; without it, {\tt mkpmap} would end up in an infinite loop. It is nevertheless the user's responsibility to specify compatible photon map types and to check the validity of the scene. \noindent The following situations can cause {\tt mkpmap} to fail: \begin{itemize} \item pathological scenes in which none of the light sources see any geometry \item specifying a global photon map for a scene containing no materials with diffuse component \item specifying a caustic photon map for a scene containing no materials with diffuse or specular component \item specifying a volume photon map for a scene lacking the {\it mist\/} primitive. \end{itemize} \subsection{Runaway Photons} Photons may become trapped inside {\it dielectric\/} or {\it interface\/} materials, often due to infinite total reflection. These ``runaway'' photons are terminated after a user defined bounce limit is exceeded, and a warning is issued under the assumption that this is an anomaly of the scene geometry. \subsection{Progress Report} If progress reports are enabled, {\tt mkpmap} will report the following during distribution: \begin{quote} {\tt $N_e$ emitted, $N_g$ global, $N_c$ caustic, $N_v$ volume, $N_d$ direct, $P$\% after $T$ hours}, \end{quote} where: \begin{itemize} \item $N_e$ is the total number of emitted photons \item $N_g$, $N_c$, $N_v$, and $N_d$ is the number of global, caustic, volume, and direct photons stored, respectively \item $P$ is the percentage completed \item $T$ is the time elapsed. \end{itemize} When precomputing global photon irradiance a report will also be issued with the number of precomputed photons $N_p$: \begin{quote} {\tt $N_p$ precomputed, $P$\% after $T$ hours}, \end{quote} If precomputation is combined with bias compensation, error statistics will also be reported (see section \ref{sec:rpict.report}). \subsection{Command line arguments for {\tt mkpmap}} The general synopsis of the {\tt mkpmap} utility is: \begin{quote} {\tt mkpmap [options] octree} \end{quote} The options are as follows: \begin{description} \item{\tt -apg }\\ The output file name and approximate number of photons for the global photon map. \item{\tt -app }\\ The output file name for the precomputed global photon map, the approximate number of photons (before precomputation), and the number of photons (bandwidth) to use for the precomputed irradiance estimate. \item{\tt -appb }\\ Same as above, but applying bias compensation within the minimum and maximum number of photons on the precomputed irradiance estimate. \item{\tt -appt } \\ Irradiance threshold for precomputed global photon map in $W/m^2$. \item{\tt -apc }\\ The output file name and approximate number of photons for the caustic photon map. \item{\tt -apv }\\ The output file name and approximate number of photons for the volume photon map. Volume photons can only be used with octrees containing the {\it mist\/} primitive. \item{\tt -apd }\\ The output file name and approximate number of photons for the direct photon map. Direct photon maps are useful to determine suitable settings for the {\tt -ds} and {\tt -dp} options when using light sources with modifiers. This can provide a visual check for the resolution of the probability density function used for photon emission in conjunction with complex output distributions. It can also serve as a validation tool for comparison with RADIANCE's direct component. The quality of the direct photon irradiance is poor, and only accounts for surfaces with diffuse component. For these reasons, the direct photon map is strictly a debugging option. It is in no way intended to replace RADIANCE's direct calculation. \item{\tt -apD }\\ Fraction of the minimum number of photons specified which are emitted in the distribution prepass. Increase this if the number of stored photons differs substantially from your specified targets. This parameter may exceed 1. \item{\tt -apf }\\ Fraction of global photons to precompute for final gather, in the range $]0,1]$. The remaining photons are discarded. \item{\tt -apm }\\ Specifies the maximum number of bounces for a photon before termination as runaway photon. \item{\tt -apM }\\ Specifies the maximum number of distribution prepass attempts before terminating if some photon maps are still empty. This should only be increased under very unusual circumstances, as it normally indicates a scene anomaly or photon map specifications which are incompatible with the scene. \item{\tt -apo }\\ Specifies photon port modifier. All objects with this modifier will act as ports for photons emitted from the {\it source\/} primitive. This option can be used in mutliple instances with cumulative effect. \item{\tt -apO }\\ Photon port modifiers are read from the specified file. \item{\tt -bv}\\ Toggles backface visibility. Enabling this switch causes photons to be stored and possibly reradiated if they strike the back of a surface, otherwise they are ignored and immediately absorbed. \item{\tt -dp }\\ Resolution for sampling user defined light source emission distributions, in samples per steradian. This is required for numerically integrating the flux emitted by the light source and for constructing a probability density function (PDF) for photon emission. The accuracy of photon emission with user specified distributions depends on this parameter. Increase it if caustics exhibit spurious artifacts. \item{\tt -ds }\\ Light source partition size ratio; light sources are partitioned to distribute the photon emission over its surface. This parameter specifies the ratio of the size (per dimension) of each partition to the scene cube. \item{\tt -e }\\ Redirect diagnostics and progress reports to specified file. \item{\tt -i }\\ Photon heap size increment; photon heaps are enlarged by this amount when storage overflows. No need to fiddle with this. \item{\tt -ma }\\ Global scattering albedo. See {\tt rpict}. \item{\tt -me }\\ Global extinction coefficient. See {\tt rpict}. \item{\tt -mg }\\ Global scattering eccentricity. See {\tt rpict}. \item{\tt -t }\\ Generate progress report in specified intervals. \end{description} The {\tt -apc}, {\tt -apv}, and {\tt -apd} options can be freely combined with either {\tt -apg}, {\tt -app}, or {\tt -appb}. At least one of these must be specified... or nothing happens! \section{Querying the Photon Map with {\tt pmapinfo}} The {\tt pmapinfo} tool supplies the following information about a photon map: \begin{itemize} \item the photon map type as identified by magic number: \begin{itemize} \item {\tt Radiance\_Global\_Photon\_Map}, \item {\tt Radiance\_PreComp\_Global\_Photon\_Map}, \item {\tt Radiance\_Caustic\_Photon\_Map}, \item {\tt Radiance\_Volume\_Photon\_Map}, or \item {\tt Radiance\_Direct\_Photon\_Map} \end{itemize} \item the {\tt mkpmap} command line used to build the photon map \item the number of photons in the photon map \item the photon flux averaged over the RGB colour channels. \end{itemize} \section{Photon Gathering with {\tt rpict}} The modified {\tt rpict} rendering tool takes the photon map generated by {\tt mkpmap} and perform the photon gathering and density estimation. Without photon map functionality enabled, it behaves like RADIANCE Classic. \subsection{Caustic Photon Visualisation} Caustic photons are visualised at points seen directly by the observer, or via specular reflections. Virtual light sources are disabled with the caustic photon map, since these effects are already accounted for. Note that irradiance calculations with {\tt rtrace} using caustic photons are surface bound. Irradiance for points which do not lie on surfaces will be biased. \subsection{Global Photon Visualisation} Global photons are visualised via an intermediate ambient bounce, which reduces noise (figure \ref{fig:visualisation}). An exception to the rule is a debugging option which directly visualises the global photons. Ambient values (specified with {\tt -av}) are ignored. The global photon irradiance may be optionally precomputed by {\tt mkpmap} to speed things up at the expense of accuracy. \begin{figure}[!htb] \begin{center} \includegraphics[width=0.75\textwidth]{visualisation.eps} \parbox{0.9\textwidth}{\caption{Caustic photons are visualised at the primary ray, while an intermediate stratified sampling step is used between the primary ray and the global photon contribution.} \label{fig:visualisation}} \end{center} \end{figure} \subsection{Progress Report} \label{sec:rpict.report} Bias compensation statistics are provided in the progress report with the standard {\tt -t} option. The statistics reported for each photon type subject to bias compensation are as follows: \begin{quote} {\tt $N_{min}$/$N_{max}$/$N_{avg}$ $ptype$, ($\epsilon_{min}$/$\epsilon_{max}$/$\epsilon_{rms}$ error)}, \end{quote} where: \begin{itemize} \item $N_{min}$, $N_{max}$, and $N_{avg}$ are the minimum, maximum, and average number of photons used per irradiance estimate, respectively \item $ptype$ is one of {\tt global}, {\tt caustic}, {\tt volume}, or {\tt direct}. \item \sloppy $\epsilon_{min}$, $\epsilon_{max}$, and $\epsilon_{rms}$ are the minimum, maximum, and RMS (root mean square) estimated relative errors in the irradiance estimates, respectively. \end{itemize} Since bias cannot be determined without knowing the actual illumination there is no reliable way of separating it from noise. As such, the error estimates are crude and only serve as a guide to judge the quality of the operator and its parametrisation. \subsection{Command Line Arguments for {\tt rpict}} The photon map is disabled by default and must be explicitly enabled using one or more of the {\tt -ap} options. The different photon map types may be renderered independently or in combination. Note that rendering only the global or caustic photon map does not take all light transport paths into consideration, and may omit some indirect illumination. Since modifying the lights or geometry invalidates the photon map, a warning is issued if the octree is newer than the photon map. The multitude of options can be daunting for beginners, and it helps to start with a basic set of parameters upon which to refine if necessary. A physically valid simulation using the photon map is obtained with the following basic parameters: \begin{quote} \sloppy {\tt mkpmap -apg -apc \\ rpict -apg -apc -ab 1 -vf } \end{quote} As with RADIANCE Classic, the {\tt -ad}, {\tt -ar}, and {\tt -aa} parameters must be modified in some cases to improve the rendering quality. Parameters pertaining to caustic photons must be omitted for scenes lacking specular materials. The {\tt rpict} photon map options are as follows: \begin{description} \item{\tt -ab }\\ The number of ambient bounces; setting this to a positive value will include global photon contributions via {\bf one} ambient bounce (regardless of the actual number specified). The irradiance cache may be applied to the top level ambient rays, but photon map lookups are not cached. Setting this to a negative value will visualise the global photons directly. With precomputed global photons this produces a Voronoi diagram. The quality of the resulting renderings is usually abysmal, hence this setting is primarily intended for debugging purposes, e.g. to check the illuminance distribution. Caustic photons are not visualised with this setting, because the directly visualised global photon map already accounts for them in this case. As with RADIANCE Classic, the default value of 0 disables the ambient component; global photons are not visualised, but caustic photons are still visualised directly. \item{\tt -apg }\\ Loads the global photon map from the file and uses the specified number of photons (bandwidth) for a global irradiance estimate. \item{\tt -apgb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the global irradiance estimate. \item{\tt -apgt } \\ Irradiance threshold for global photon map in $W/m^2$. \item{\tt -app }\\ Loads the precomputed global photon map from the file and uses the precomputed irradiance for final gather. \item{\tt -apc }\\ Loads the caustic photon map from the file and uses the specified number of photons (bandwidth) for a caustic irradiance estimate. \item{\tt -apcb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the caustic irradiance estimate. \item{\tt -apct } \\ Irradiance threshold for caustic photon map in $W/m^2$. \item{\tt -apv }\\ Loads the volume photon map from the file and uses the specified number of photons (bandwidth) for a volume irradiance estimate within the {\it mist\/} primitive. \item{\tt -apvb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the volume irradiance estimate. \item{\tt -apvt } \\ Irradiance threshold for volume photon map in $W/m^2$. \item{\tt -apd }\\ Loads the direct photon map from the file and uses the specified number of photons (bandwidth) for a direct irradiance estimate. RADIANCE's direct calculation is disabled, and only surfaces with diffuse component are accounted for. This is stricly a debugging and validation option, and rarely needed in practice. \item{\tt -apdb }\\ Same as above, but applying bias compensation within the minimum and maximum bandwidth to the direct irradiance estimate. \item{\tt -apdt } \\ Irradiance threshold for direct photon map in $W/m^2$. \end{description} \section{Bugs and Weirdness} \begin{itemize} % \item Although analytical validation has shown the photon map can % achieve an accuracy within $\pm 0.5\%$ for very simple scenes, % the simulated lighting levels can deviate very slightly % seriously from Real\-Life$^\mathsf{TM}$ when complex geometry is % involved or inappropriate parameters are used. An experimental % validation based on measurements under more realistic conditions % is still being evaluated. \item The spotlight focal point is ignored by the photon map; it coincides with the light source surface. This corresponds to specifying a direction vector of infinitesimal length in RADIANCE Classic. \item {\tt mkpmap}'s distribution algorithm can exceed the specified number of photons with scenes having high reflectance or when excessively high settings of {\tt -apD} are used. \item Caustic photon irradiance will be biased when passing {\tt rtrace} points which do not lie on a surface. \end{itemize} \section{Parameter Ranges} The following table lists typical ranges for various parameters used with {\tt mkpmap} and {\tt rpict}. It is primarily aimed at novices, who are no doubt bewildered by the plethora of options. The ranges are recommendations based on the developer's experience, and should not be interpreted as fixed constraints. In some situations it is not unlikely to use settings far beyond the typical range. \begin{table}[!htb] \begin{center} \begin{tabular}{|l|l|} \hline {\tt mkpmap} parameter & typical range \\ \hline \hline {\tt } & 50000--1000000 \\ {\tt -apD} & 0.1--10 \\ {\tt -apf} & 0.25--0.5 \\ {\tt -apm} & 5000--10000 \\ {\tt -dp} & 1000--100000 \\ {\tt -ds} & 0.0001--0.01 \\ \hline \hline {\tt rpict} parameter & typical range \\ \hline \hline {\tt } & 50--2000 \\ {\tt } & 0.001--0.1 \\ \hline \end{tabular} \caption{Parameter ranges for {\tt mkpmap} and {\tt rpict}.} \end{center} \end{table} \clearpage \section{Troubleshooting} \begin{table}[!htb] \begin{center} \begin{tabular} {|p{0.3\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline {\tt mkpmap} stores too many photons & Too many emitted photons in distribution prepass & Reduce {\tt -apD} \\ \hline Number of stored photons differs substantially from specification & Too few photons emitted in distribution prepass; prediction for main pass inaccurate & Increase {\tt -apD} \\ \hline Excessive noise in photon irradiance & Bandwidth too low & Increase bandwidth \\ \hline Excessive blurring in photon irradiance & Bandwidth too high & Decrease bandwidth or increase size of photon map \\ \hline Excessive noise and blurring in different regions & Bandwidth is fixed & Apply bias compensation for dynamic bandwidth \\ \hline Severe irradiance falloff at polygon edges & Boundary bias due to high bandwidth & Reduce bandwidth or apply bias compensation \\ \hline Splotchy ambient illumination from global photons & Excessively noisy density estimates; too few ambient samples; irradiance caching too inaccurate & Check density estimate with {\tt -ab -1}, and increase bandwidth if necessary; increase {\tt -ad} if illumination has high variance or contains caustics; increase {\tt -ar} and/or decrease {\tt -aa} \\ \hline Banding in photon irradiance & Maximum photon search radius too small & Decrease irradiance threshold \\ \hline {\tt mkpmap} complains about runaway photons & Photons stuck in infinite scattering loop, possibly pathological geometry or materials & Check geometry and materials; increase {\tt -apm} \\ \hline Direct photon irradiance from modified light source deviates significantly & Probability density function cannot adequately resolve emission distribution; too few source partitions & Increase {\tt -dp}; if distribution varies over surface, decrease {\tt -ds} \\ \hline \end{tabular} \caption{Troubleshooting chart.} \end{center} \end{table} \begin{table}[!htb] \begin{center} \begin{tabular} {|p{0.3\textwidth}|p{0.3\textwidth}|p{0.3\textwidth}|} \hline {\bf Problem} & {\bf Cause} & {\bf Solution} \\ \hline \hline {\tt mkpmap} is slow with {\it source\/} primitive & {\it source\/} emits from scene cube faces & Define photon ports \\ \hline {\tt mkpmap} bogs down in light source flux integration & Excessively high probability density function resolution; too many source partitions & Decrease {\tt -dp}; increase {\tt -ds} \\ \hline {\tt mkpmap} bails out after too many distribution prepasses & Using caustic photons with non-specular geometry; using volume photons without {\it mist\/}; pathological geometry or nonabsorbing materials; light sources see no geometry & Check scene and specify compatible photon types \\ \hline Everything is slow & User expects too much & Twiddle thumbs \\ \hline \end{tabular} \caption{Troubleshooting chart (continued).} \end{center} \end{table} \begin{thebibliography}{99} \bibitem[Ward94]{Ward94} Gregory J.~Ward: ``The RADIANCE Lighting Simulation and Rendering System''. Proceedings SIGGRAPH~'94, July~1994 \bibitem[Ward98]{Ward98} Greg Ward Larson and Rob Shakespeare: {\it Rendering with RADIANCE\/}. Morgan Kaufmann, San Francisco, 1998 \bibitem[Jens96]{Jens96} Henrik Wann Jensen: ``Global Illumination using Photon Maps''. Rendering Techniques '96, Eds. X.~Pueyo and P.~Schr\"oder, Springer-Verlag, 1996 \bibitem[Jens97]{Jens97} Henrik Wann Jensen: ``Rendering Caustics on Non-Lambertian Surfaces''. Computer Graphics Forum, vol.~16~(1), March~1997 \bibitem[Jens98]{Jens98} Henrik Wann Jensen and Per H.~Christensen: ``Efficient Simulation of Light Transport in Scenes with Participating Media using Photon Maps''. Proceedings SIGGRAPH~'98, July~1998 \bibitem[Jens00]{Jens00} Henrik Wann Jensen and Niels J{\o}rgen Christensen: ``A Practical Guide to Global Illumination using Photon Maps''. SIGGRAPH~2000 Course Notes~8, July~2000 \bibitem[Bent75]{Bent75} Jon Louis Bentley: ``Multidimensional Binary Search Trees Used for Associative Searching''. CACM 18(9), 1975 \bibitem[Chri00]{Chri00} Per Christensen: ``Faster Photon Map Global Illumination''. Journal of Graphics Tools, vol.~4~(3), April~2000 \end{thebibliography} @ 1.2 log @Documented -apM and distrib prepass termination @ text @d438 7 a444 7 number of distribution prepasses if any of the specified photon maps are still empty. This is usually an indication of a scene anomaly or an incompatible photon map specification. This is intended as a convenience for the user; without it, {\tt mkpmap} would end up in an infinite loop. It is nevertheless the user's responsibility to specify compatible photon map types and to check the validity of the scene. d564 6 a569 6 Specifies the maximum number of distribution prepasses before terminating if some photon maps are still empty. This should only be increased under very unusual circumstances, as it normally indicates a scene anomaly or photon map specifications which are incompatible with the scene. @ 1.1 log @Initial revision @ text @d8 1 a8 1 Version 3.12} d128 1 a128 1 Four photon types are available: d435 29 a474 1 d563 7 d821 1 a821 1 \section{Bugs} d825 7 a831 7 \item Although analytical validation has shown the photon map can achieve an accuracy within $\pm 0.5\%$ for very simple scenes, the simulated lighting levels can deviate very slightly seriously from Real\-Life$^\mathsf{TM}$ when complex geometry is involved or inappropriate parameters are used. An experimental validation based on measurements under more realistic conditions is still being evaluated. a843 16 \item \sloppy Pathological scenes containing light sources which see no geometry will leave {\tt mkpmap} in an infinite loop. \item {\tt mkpmap} may wind up in an infinite loops in the following situations: \begin{itemize} \item specifying a global photon map for a scene containing no materials with diffuse component \item specifying a caustic photon map for a scene containing no materials with diffuse or specular component \item specifying a volume photon map for a scene lacking the {\it mist\/} primitive. \end{itemize} It is the user's responsibility to specify compatible photon map types for the scene. d971 1 a971 1 {\tt mkpmap} stuck in infinite loop & @