Page Menu
Home
c4science
Search
Configure Global Search
Log In
Files
F60269475
pmap-manual.tex
No One
Temporary
Actions
Download File
Edit File
Delete File
View Transforms
Subscribe
Mute Notifications
Award Token
Subscribers
None
File Metadata
Details
File Info
Storage
Attached
Created
Sun, Apr 28, 19:21
Size
178 KB
Mime Type
text/x-tex
Expires
Tue, Apr 30, 19:21 (2 d)
Engine
blob
Format
Raw Data
Handle
17328871
Attached To
R12290 RADIANCE Photon Map Documentation
pmap-manual.tex
View Options
\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
.
51
$
\RCS
$
Date:
2022
/
05
/
10
23
:
31
:
52
$
\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
}
Event Timeline
Log In to Comment