Homec4science
Diffusion RADIANCE Photon Map Documentation (master) Browse

RadiancePmapDoc/pdf/pmap-manual.tex,v
50693181f1bfmaster

Last Change
Raw File

pmap-manual.tex,v
View Options

This file is larger than 256 KB, so syntax highlighting was skipped.
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{<pmapfile>.rc/} in turn contains the
photons emitted by light sources using this modifier. The photons are
stored out-of-core in a file \lit{<pmapfile>.rc/<mod>.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{<pmapfile>.rc/<mod>.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 <file> <nphotons>}\\ The output file name and approximate
number of photons for the global photon map.
\item{\tt -app <file> <nphotons> <bandwidth>}\\ 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 <file> <nphotons> <nestimate\_min> <nestimate\_max>}\\
Same as above, but applying bias compensation within the minimum and
maximum number of photons on the precomputed irradiance estimate.
\item{\tt -appt <thresh>} \\ Irradiance threshold for precomputed global
photon map in $W/m^2$.
\item{\tt -apc <file> <nphotons>}\\ The output file name and approximate
number of photons for the caustic photon map.
\item{\tt -apv <file> <nphotons>}\\ 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 <file> <nphotons>}\\ 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 <frac>}\\ 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 <frac>}\\ Fraction of global photons to precompute for
final gather, in the range $]0,1]$. The remaining photons are
discarded.
\item{\tt -apm <max>}\\ Specifies the maximum number of bounces for a
photon before termination as runaway photon.
\item{\tt -apM <max>}\\ 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 <mod>}\\ 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 <file>}\\ 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 <res>}\\ 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 <frac>}\\ 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 <file>}\\ Redirect diagnostics and progress reports to
specified file.
\item{\tt -i <inc>}\\ Photon heap size increment; photon heaps are
enlarged by this amount when storage overflows. No need to fiddle with
this.
\item{\tt -ma <ralb> <galb> <balb>}\\ Global scattering albedo. See {\tt
rpict}.
\item{\tt -me <rext> <gext> <bext>}\\ Global extinction coefficient. See
{\tt rpict}.
\item{\tt -mg <gecc>}\\ Global scattering eccentricity. See {\tt rpict}.
\item{\tt -t <sec>}\\ 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 <radius> <pmap1> <pmap2> ...}
\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 <pmap> <nphotons> -apc <pmap> <nphotons> <octree>\\
rpict -apg <pmap> <bwidth> -apc <pmap> <bwidth> -ab 1 -vf <view>
<octree>}
\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 <nbounces>}\\ 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 <file> <bwidth>}\\ Loads the global photon map from the
file and uses the specified number of photons (bandwidth) for a global
irradiance estimate.
\item{\tt -apgb <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth to
the global irradiance estimate.
\item{\tt -apgt <thresh>} \\ Irradiance threshold for global photon map
in $W/m^2$.
\item{\tt -app <file>}\\ Loads the precomputed global photon map from the
file and uses the precomputed irradiance for final gather.
\item{\tt -apc <file> <bwidth>}\\ Loads the caustic photon map from the
file and uses the specified number of photons (bandwidth) for a
caustic irradiance estimate.
\item{\tt -apcb <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth to
the caustic irradiance estimate.
\item{\tt -apct <thresh>} \\ Irradiance threshold for caustic photon map
in $W/m^2$.
\item{\tt -apv <file> <bwidth>}\\ 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 <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth to
the volume irradiance estimate.
\item{\tt -apvt <thresh>} \\ Irradiance threshold for volume photon map
in $W/m^2$.
\item{\tt -apd <file> <bwidth>}\\ 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 <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth to
the direct irradiance estimate.
\item{\tt -apdt <thresh>} \\ 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 <nphotons>} & 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 <bwidth>} & 50--2000 \\
{\tt <thresh>} & 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 <file> <nphotons>}\\ The output file name and
approximate number of photons for the global photon map.
\item{\tt -app <file> <nphotons> <bandwidth>}\\ 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 <file> <nphotons> <nestimate\_min> <nestimate\_max>}\\
Same as above, but applying bias compensation within the minimum
and maximum number of photons on the precomputed irradiance
estimate.
\item{\tt -appt <thresh>} \\ Irradiance threshold for precomputed
global photon map in $W/m^2$.
\item{\tt -apc <file> <nphotons>}\\ The output file name and
approximate number of photons for the caustic photon map.
\item{\tt -apv <file> <nphotons>}\\ 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 <file> <nphotons>}\\ 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 <frac>}\\ 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 <frac>}\\ Fraction of global photons to precompute for
final gather, in the range $]0,1]$. The remaining photons are
discarded.
\item{\tt -apm <max>}\\
Specifies the maximum number of bounces for a photon before
termination as runaway photon.
\item{\tt -apM <max>}\\
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 <mod>}\\
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 <file>}\\
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 <res>}\\ 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 <frac>}\\ 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 <file>}\\
Redirect diagnostics and progress reports to specified file.
\item{\tt -i <inc>}\\
Photon heap size increment; photon heaps are enlarged by this
amount when storage overflows. No need to fiddle with this.
\item{\tt -ma <ralb> <galb> <balb>}\\
Global scattering albedo. See {\tt rpict}.
\item{\tt -me <rext> <gext> <bext>}\\
Global extinction coefficient. See {\tt rpict}.
\item{\tt -mg <gecc>}\\
Global scattering eccentricity. See {\tt rpict}.
\item{\tt -t <sec>}\\
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 <pmap> <nphotons> -apc <pmap> <nphotons> <octree>\\
rpict -apg <pmap> <bwidth> -apc <pmap> <bwidth> -ab 1 -vf <view>
<octree>}
\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 <nbounces>}\\ 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 <file> <bwidth>}\\ Loads the global photon map from the
file and uses the specified number of photons (bandwidth) for a
global irradiance estimate.
\item{\tt -apgb <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth
to the global irradiance estimate.
\item{\tt -apgt <thresh>} \\ Irradiance threshold for global photon
map in $W/m^2$.
\item{\tt -app <file>}\\ Loads the precomputed global photon map from
the file and uses the precomputed irradiance for final gather.
\item{\tt -apc <file> <bwidth>}\\ Loads the caustic photon map from
the file and uses the specified number of photons (bandwidth) for a
caustic irradiance estimate.
\item{\tt -apcb <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth
to the caustic irradiance estimate.
\item{\tt -apct <thresh>} \\ Irradiance threshold for caustic photon
map in $W/m^2$.
\item{\tt -apv <file> <bwidth>}\\ 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 <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth
to the volume irradiance estimate.
\item{\tt -apvt <thresh>} \\ Irradiance threshold for volume photon
map in $W/m^2$.
\item{\tt -apd <file> <bwidth>}\\ 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 <file> <minbwidth> <maxbwidth>}\\ Same as above, but
applying bias compensation within the minimum and maximum bandwidth
to the direct irradiance estimate.
\item{\tt -apdt <thresh>} \\ 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 <nphotons>} & 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 <bwidth>} & 50--2000 \\
{\tt <thresh>} & 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 &
@
c4science · Help