================================================================================
SmallVCM
================================================================================
SmallVCM is a small physically based renderer that implements the vertex
connection and merging algorithm described in the paper
"Light Transport Simulation with Vertex Connection and Merging"
Iliyan Georgiev, Jaroslav Krivanek, Tomas Davidovic, Philipp Slusallek
ACM Transactions on Graphics 31(6) (SIGGRAPH Asia 2012)
as well as a number of other algorithms, notably including progressive photon
mapping, (progressive) bidirectional photon mapping, and bidirectional path
tracing. The code compiles to a command line program that can render images of a
number of predefined scenes using the provided algorithms.
Disclaimer:
* Unless you really care, you can safely ignore all licenses in the source
code.
* This code is meant for educational purposes, and is not the code that was
used to render the images in the aforementioned paper. The provided scenes
are too simple to provide a complete understanding of the performance of
every implemented rendering algorithm and the differences between them.
* We are aware that the description below is not as detailed as it can be, and
apologize for any errors and confusion.
* If you have any questions and/or input w.r.t. improving and adding
explanations, feel free to contact Tomas Davidovic <tomas@davidovic.cz>,
the primary maintainer of this project, or Iliyan Georgiev <me@iliyan.com>,
the primary author of the above paper, and we will figure out whatever you
might need.
With that out of the way, let's go over the usual stuff.
================================================================================
1) INSTALLATION and COMPILATION
================================================================================
Synopsis: Compile smallvcm.cxx with OpenMP. If you don't have C++11 support,
define LEGACY_RNG (automatic for VS2008, found in rng.hxx).
The whole program consists of one C++ source file and a multiple header files.
It was developed in VS2010, however we did some limited testing on Linux, and
the provided Makefile works for g++ 4.4 and 4.6.3 at least.
The major hurdle can come from the fact that the C++11 <random> library is used,
but an alternative random number generator is also provided (`make old_rng` on
Linux). The code expects OpenMP is available, but getting rid of that is very
straightforward (simply comment out the few #pragma omp directives in the code).
Other than that, there are no dependencies, so simply compile smallvcm.cxx.
================================================================================
2) OPERATION
================================================================================
Quick start: Run `smallvcm --report -t 10`. In about 5-6 minutes it will
generate an index.html file that compares 7 different algorithms on 4 different
Cornell box variants (listed below).
The features and settings of the program can be explored by running
`smallvcm --help`, which outputs the following information:
Usage: smallvcm [ -s <scene_id> | -a <algorithm> |
-t <time> | -i <iteration> | -o <output_name> | --report ]
-s Selects the scene (default 0):
0 glossy small spheres + sun (directional)
1 glossy large mirror sphere + ceiling (area)
2 glossy small spheres + point
3 glossy small spheres + background (env. lighting)
-a Selects the rendering algorithm (default vcm):
el eye light
pt path tracing
lt light tracing
ppm progressive photon mapping
bpm bidirectional photon mapping
bpt bidirectional path tracing
vcm vertex connection and merging
-t Number of seconds to run the algorithm
-i Number of iterations to run the algorithm (default 1)
-o User specified output name, with extension .bmp or .hdr (default .bmp)
--report
Renders all scenes using all algorithms and generates an index.html file
that displays all images. Obeys the -t and -i options, ignores the rest.
Recommended usage: --report -i 1 (fastest preview)
Recommended usage: --report -t 10 (takes 5.5 min)
Recommended usage: --report -t 60 (takes 30 min)
Note: Time (-t) takes precedence over iterations (-i) if both are defined
'glossy' applies to the floor of the Cornell box.
'small spheres' variants have one mirror and one glass spheres in the box.
The program can run in two modes:
1) If --report is not set, a single image of the specified scene will be
rendered using the specified algorithm. If no option is specified, the output
is a 512x512 image of scene 0 is rendered using vertex connection and merging
with 1 iteration.
2) Setting the --report option renders all scenes using all algorithms, obeying
the (optional) number of iterations and/or maximum runtime for each
scene-algorithm configuration, ignoring the other options.
All default settings are set in the ParseCommandline function in config.hxx.
Some settings have no command line switch, but can be changed in the code:
mNumThreads Number of rendering threads (default 0, means 1 thread/core)
mBaseSeed Seed for random number generators (default 1234)
mMinPathLength Minimal path length (i.e. number of segments) (default 0)
mMaxPathLength Maximal path length (i.e. number of segments) (default 10)
mResolution Image resolution (default 512x512)
mRadiusFactor Scene diameter fraction for the merging radius (default 0.003)
mRadiusAlpha Merging radius reduction parameter (default 0.75)
================================================================================
3) VCM RENDERER
================================================================================
The VertexCM renderer implements a number of algorithms that share almost
identical code paths. The main differences between the algorithms lie in the
multiple importance sampling (MIS) weight computation, as well as shortcuts
through unused code. In order to make the understanding of the code easier,
below we describe how the VertexCM renderer operates. On a high level, it runs
in three stages:
1) Light sub-path tracing (ppm, bpm, bpt, vcm)
2) Range search hash grid construction over light vertices (ppm, bpm, vcm)
3) Camera sub-path tracing (all but lt)
PathVertex (also PathElement variant and typedefs CameraVertex and LightVertex)
is the basic structure describing the state of a random walk. The only unusual
members are dVCM, dVC, dVM, which are used for iterative MIS weight computation:
dVCM used for both connections (bpt, vcm) and merging (bpm, vcm)
dVC used for connections (bpt, vcm)
dVM used for merging (bpm, vcm)
Note: All bidirectional algorithms sample the same number of light and camera
sub-paths per iteration, which is the number of pixels in the image.
* Light tracing (lt)
Utilizes only light sub-path tracing. Each path vertex is directly connected
to camera and then discarded (i.e. not stored). No MIS, hash grid, or camera
tracing are used.
* Progressive photon mapping (ppm)
Light sub-paths are traced, storing their vertices (as LightVertex objects) on
surfaces with non-specular (i.e. non-delta) materials, and building a hash
grid over them. The camera sub-paths are traced until hitting a non-specular
surface, where merging with light vertices (i.e. photon lookup) is performed,
terminating the camera sub-path thereafter. No MIS is used, and the radiance
from directly hit lights is accounted for only when all surface interactions
on the path are specular.
* Bidirectional photon mapping (bpm)
An extension to ppm, terminates camera sub-paths stochastically (unlike ppm)
and performs merging at all non-specular vertices. MIS is used (dVCM and dVM)
to weight the different possible ways of constructing the same path by merging
at any (non-specular) interior path vertex.
* Bidirectional path tracing (bpt)
Light sub-paths are traced, their non-specular vertices are first connected to
the camera (as in light tracing) and then stored (without a hash grid). Next,
the camera sub-paths are traced, connecting each non-specular vertex to a
light source and to all non-specular vertices of the light sub-path
corresponding to the current pixel. MIS is used (dVCM, dVC).
* Vertex connection and merging (vcm)
Effectively a combination of bidirectional photon mapping and bidirectional
path tracing. Light sub-path tracing projects and stores the non-specular
vertices, and also builds a hash grid over them. In the camera sub-path
tracing, each vertex is connected to a light source, to the vertices of the
corresponding light sub-path, and also merged with the nearby vertices of all
light sub-paths. MIS is used (dVCM, dVM, dVC).
================================================================================
4) FEATURES and LIMITATIONS
================================================================================
The renderer was originally intended to be a compact reference implementation,
akin to smallpt, however it grew over time. Here is a list of the features and
the limitations of the framework:
Infrastructural features:
* All basic light source types -- area, point, directional, and env. map --
are supported, although the current env. map implementation uses a constant
radiance distribution.
* Basic surface scattering models are implemented, including diffuse, glossy
(Phong), as well as specular reflection and refraction. It should be fairly
straightforward to implement new materials. Also, the material interfaces
should suffice for most purposes, as the bidirectional algorithms provided
are already quite demanding on them.
* The material/shading instance for a given ray hit point is represented by
a BSDF object. In addition to storing the the surface scattering properties,
this object also holds the local shading frame, as well we the incoming
(fixed) direction; all its methods (sample, evaluate, pdf) compute their
results always w.r.t. this direction.
Rendering features:
* A simple renderer with eye light (dot normal) shading for fast previews.
Red color denotes backface orientation. Implementation is in eyelight.hxx.
* Traditional path tracing with next even estimation (area and env. map).
Kept as a separate implementation is in pathtracer.hxx.
* Light tracing (lt), progressive photon mapping (ppm), bidirectional photon
mapping (bpm), bidirectional path tracing (bpt), and our vertex connection
and merging (vcm). All these are implemented in the VertexCM renderer, with
code path switches for the different algorithms.
Limitations:
* No acceleration structure for ray intersection (can be added to scene.hxx).
* Scenes are hard-coded (see LoadCornellBox in scene.hxx).
* The ppm algorithm does not handle diffuse+specular materials correctly.
This limitation can be lifted by adding a parameter to the BSDF::Sample
method that would specify the types of scattering events to be sampled.
The ppm implementation could then be modified to continue camera sub-paths
only for the specular parts of diffuse+specular materials.
* Each area light is an individual triangle, and requires its very own
material for identification. This can and should be changed if code is
used for scenes with complex area light sources. Also, the way of finding
whether and which area light is hit by a random ray can be improved.
* No shading normals. Extending the framework with shading normals should
happen within the BSDF object (which already supports adjoint BSDFs required
by refraction).
* No infrastructural support for participating media or subsurface scattering.