metadata
Wenzel Jakob 2012-10-22 00:02:28 -04:00
parent 3a21619eec
commit 6137c21db5
7 changed files with 226 additions and 212 deletions

View File

@ -54,7 +54,7 @@ struct TangentSpace {
/** \brief Abstract triangle mesh base class
* \ingroup librender
e \ingroup libpython
* \ingroup libpython
*/
class MTS_EXPORT_RENDER TriMesh : public Shape {
public:

View File

@ -27,7 +27,7 @@ plugins += bidirEnv.SharedLibrary('bdpt',
plugins += bidirEnv.SharedLibrary('pssmlt',
['pssmlt/pssmlt.cpp', 'pssmlt/pssmlt_sampler.cpp',
'pssmlt/pssmlt_proc.cpp']);
'pssmlt/pssmlt_proc.cpp']);
plugins += bidirEnv.SharedLibrary('mlt',
['mlt/mlt.cpp', 'mlt/mlt_proc.cpp']

View File

@ -42,7 +42,7 @@ static StatsCounter avgPathLength("Volumetric path tracer", "Average path length
* }
*
* This plugin provides a basic volumetric path tracer that can be used to
* compute approximate solutions to the radiative transfer equation. This
* compute approximate solutions of the radiative transfer equation. This
* particular integrator is named ``simple'' because it does not make use of
* multiple importance sampling. This results in a potentially
* faster execution time. On the other hand, it also means that this
@ -50,6 +50,16 @@ static StatsCounter avgPathLength("Volumetric path tracer", "Average path length
* highly glossy materials. In this case, please use \pluginref{volpath}
* or one of the bidirectional techniques.
*
* This integrator has special support for \emph{index-matched} transmission
* events (i.e. surface scattering events that do not change the direction
* of light). As a consequence, particating media enclosed by a stencil shape (see
* \secref{shapes} for details) are rendered considerably more efficiently when this
* shape has \emph{no}\footnote{this is what signals to Mitsuba that the boundary is
* index-matched and does not interact with light in any way. Alternatively,
* the \pluginref{mask} and \pluginref{thindielectric} BSDF can be used to specify
* index-matched boundaries that involve some amount of interaction.} BSDF assigned
* to it (as compared to, say, a \pluginref{dielectric} or \pluginref{roughdielectric} BSDF).
*
* \remarks{
* \item This integrator performs poorly when rendering
* participating media that have a different index of refraction compared

View File

@ -67,6 +67,10 @@ void Shape::configure() {
bsdf->configure();
addChild(bsdf);
}
if ((m_bsdf->getType() & BSDF::ENull) && (isEmitter() || isSensor() || hasSubsurface()))
Log(EError, "Shape \"%s\" has an index-matched BSDF and an "
"emitter/sensor/subsurface attachment. This is not allowed!", getName().c_str());
}
bool Shape::isCompound() const {

View File

@ -33,18 +33,18 @@ struct MaterialEntry {
static MaterialEntry materialData[] = {
/* Fitted data from "A Practical Model for Subsurface scattering" (Jensen et al.). No anisotropy data available. */
{ "Apple", { 2.29f, 2.39f, 1.97f }, { 0.0030f, 0.0034f, 0.046f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Chicken1", { 0.15f, 0.21f, 0.38f }, { 0.0015f, 0.077f, 0.19f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Chicken2", { 0.19f, 0.25f, 0.32f }, { 0.0018f, 0.088f, 0.20f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Cream", { 7.38f, 5.47f, 3.15f }, { 0.0002f, 0.0028f, 0.0163f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Ketchup", { 0.18f, 0.07f, 0.03f }, { 0.061f, 0.97f, 1.45f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Marble", { 2.19f, 2.62f, 3.00f }, { 0.0021f, 0.0041f, 0.0071f }, { 1.0f, 1.0f, 1.0f }, 1.5f },
{ "Potato", { 0.68f, 0.70f, 0.55f }, { 0.0024f, 0.0090f, 0.12f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Skimmilk", { 0.70f, 1.22f, 1.90f }, { 0.0014f, 0.0025f, 0.0142f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Skin1", { 0.74f, 0.88f, 1.01f }, { 0.032f, 0.17f, 0.48f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Skin2", { 1.09f, 1.59f, 1.79f }, { 0.013f, 0.070f, 0.145f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Spectralon", { 11.6f, 20.4f, 14.9f }, { 0.00f, 0.00f, 0.00f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Wholemilk", { 2.55f, 3.21f, 3.77f }, { 0.0011f, 0.0024f, 0.014f }, { 1.0f, 1.0f, 1.0f }, 1.3f },
{ "Apple", { 2.29f, 2.39f, 1.97f }, { 0.0030f, 0.0034f, 0.046f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Chicken1", { 0.15f, 0.21f, 0.38f }, { 0.0015f, 0.077f, 0.19f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Chicken2", { 0.19f, 0.25f, 0.32f }, { 0.0018f, 0.088f, 0.20f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Cream", { 7.38f, 5.47f, 3.15f }, { 0.0002f, 0.0028f, 0.0163f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Ketchup", { 0.18f, 0.07f, 0.03f }, { 0.061f, 0.97f, 1.45f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Marble", { 2.19f, 2.62f, 3.00f }, { 0.0021f, 0.0041f, 0.0071f }, { 0.0f, 0.0f, 0.0f }, 1.5f },
{ "Potato", { 0.68f, 0.70f, 0.55f }, { 0.0024f, 0.0090f, 0.12f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Skimmilk", { 0.70f, 1.22f, 1.90f }, { 0.0014f, 0.0025f, 0.0142f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Skin1", { 0.74f, 0.88f, 1.01f }, { 0.032f, 0.17f, 0.48f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Skin2", { 1.09f, 1.59f, 1.79f }, { 0.013f, 0.070f, 0.145f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Spectralon", { 11.6f, 20.4f, 14.9f }, { 0.00f, 0.00f, 0.00f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
{ "Wholemilk", { 2.55f, 3.21f, 3.77f }, { 0.0011f, 0.0024f, 0.014f }, { 0.0f, 0.0f, 0.0f }, 1.3f },
/* From "Acquiring Scattering Properties of Participating Media by Dilution"
by Narasimhan, Gupta, Donner, Ramamoorthi, Nayar, Jensen (SIGGRAPH 2006) */

View File

@ -152,7 +152,7 @@ void RenderSettingsDialog::setDocumentation(const QString &text) {
ui->groupBox->setTitle(tr("Documentation"));
}
ui->helpViewer->setHtml(comments + m_currentDocumentation);
ui->helpViewer->setHtml(comments + "<div style='font-size:10pt'>" + m_currentDocumentation + "</div>");
ui->buttonBox->button(QDialogButtonBox::Ok)->setEnabled(!hasErrors);
}

View File

@ -14,12 +14,12 @@
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
<param name="strictNormals" readableName="Strict surface normals" type="boolean" default="false" importance="1">
<p>
@ -31,11 +31,11 @@
situations where a light ray impinges on an object from a direction that is classified as "outside"
according to the shading normal, and "inside" according to the true geometric normal.</p>
<p>The <tt>strictNormals</tt>
parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on")
parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on")
gives precedence to information given by the shading normal and considers such light paths to be valid.
This can theoretically cause light "leaks" through boundaries, but it is not much of a problem in practice.</p>
<p>When set to <tt>true</tt>, the path tracer detects inconsistencies and ignores these paths. When objects
are poorly tesselated, this latter option may cause them to lose a significant amount of the incident
are poorly tesselated, this latter option may cause them to lose a significant amount of the incident
radiation (or, in other words, they will look dark).
The bidirectional integrators in Mitsuba (BDPT, PSSMLT, MLT, ..)
implicitly have <tt>strictNormals</tt> activated. Hence, another use of this parameter
@ -46,21 +46,21 @@
<plugin type="integrator" name="irrcache" readableName="Irradiance cache"
className="IrradianceCacheIntegrator">
<descr>
<p>Irradiance caching integrator - forwards all radiance computations
<p>Irradiance caching integrator - forwards all radiance computations
to an arbitrary nested sampling-based integrator - with one exception:
whenever a Lambertian surface is intersected, an internal irradiance
cache is queried for the indirect illumination at the surface position in
question. If this query is successful, the sub-integrator is only
used to compute the remaining types of radiance (direct, in-scatter,
cache is queried for the indirect illumination at the surface position in
question. If this query is successful, the sub-integrator is only
used to compute the remaining types of radiance (direct, in-scatter,
emission) and their sum is returned afterwards.
When a query is unsuccessful, a new data point is generated by a final
gathering step.</p>
<p>The generality of this implementation allows it to be used in conjunction
with photon mapping (the most likely application) as well as all other
with photon mapping (the most likely application) as well as all other
sampling-based integrators in Mitsuba. Several optimizations are used to
improve the achieved interpolation quality, namely irradiance gradients
[Ward et al.], neighbor clamping [Krivanek et al.], a screen-space
improve the achieved interpolation quality, namely irradiance gradients
[Ward et al.], neighbor clamping [Krivanek et al.], a screen-space
clamping metric and an improved error function [Tabellion et al.].
By default, this integrator also performs a distributed overture pass before
rendering, which is recommended to avoid artifacts resulting from the
@ -69,7 +69,7 @@
<param name="resolution" readableName="Final Gather resolution" type="integer" default="14">
Elevational resolution of the stratified final gather hemisphere.
The azimuthal resolution is three times this value. Default: <tt>14</tt>, which
leads to <tt>14x(2*14)=392</tt> samples
leads to <tt>14x(2*14)=392</tt> samples
</param>
<param name="quality" readableName="Quality" type="float" default="1">
Quality setting ("kappa" in the [Tabellion et al.] paper).
@ -80,13 +80,13 @@
significantly improve the interpolation quality.
</param>
<param name="clampNeighbor" readableName="Neighbor clamping" type="boolean" default="true">
Should neighbor clamping [Krivanek et al.] be used? This
propagates geometry information amongst close-by samples
and generally leads to better sample placement.
Should neighbor clamping [Krivanek et al.] be used? This
propagates geometry information amongst close-by samples
and generally leads to better sample placement.
</param>
<param name="clampScreen" readableName="Screen-space clamping" type="boolean" default="true">
If set to true, the influence region of samples will be clamped
using the screen-space metric by [Tabellion et al.]?
using the screen-space metric by [Tabellion et al.]?
Turning this off may lead to excessive sample placement.
</param>
<param name="overture" readableName="Overture pass" type="boolean" default="true">
@ -98,10 +98,10 @@
Multiplicative factor for the quality parameter following an
overture pass. This can be used to interpolate amongst more
samples, creating a visually smoother result. Must be
1 or less.
1 or less.
</param>
<param name="indirectOnly" readableName="Show indirect illumination only" type="boolean" default="false">
If set to true, direct illumination will be suppressed -
If set to true, direct illumination will be suppressed -
useful for checking the interpolation quality
</param>
<param name="debug" readableName="Visualize sample placement" type="boolean" default="false">
@ -114,17 +114,17 @@
<plugin type="integrator" name="adaptive" readableName="Adaptive integrator"
className="AdaptiveIntegrator">
<descr>
Adaptive integrator - runs a secondary integrator until the
the computed radiance achieves a specifiable relative error
threshold (5% by default) with a certain probability (95% by default).
Adaptive integrator - runs a secondary integrator until the
the computed radiance achieves a specifiable relative error
threshold (5% by default) with a certain probability (95% by default).
Internally, it uses a Z-test to decide when to stop collecting samples.
While not entirely rigorous in the statistical sense, this provides a
useful stopping criterion.
While not entirely rigorous in the statistical sense, this provides a
useful stopping criterion.
</descr>
<param name="maxError" readableName="Maximum relative error" type="float" default="0.05">Maximum relative error threshold</param>
<param name="maxSampleFactor" readableName="Maximum number of samples" type="integer" default="32">
Maximum number of samples to be generated <em>relative</em> to the number of configured pixel samples. The adaptive integrator
will stop after this many samples, regardless of whether or not the error criterion was satisfied. A negative value will be
will stop after this many samples, regardless of whether or not the error criterion was satisfied. A negative value will be
interpreted as ∞.
</param>
<param name="pValue" readableName="Required P-value" type="float" default="0.05" importance="1">Required P-value to accept a sample.</param>
@ -150,21 +150,21 @@
show="true" className="MIDirectIntegrator" extends="SampleIntegrator">
<descr>
<p>This integrator implements a direct illumination technique that makes use
of <em>multiple importance sampling</em>: for each pixel sample, the
of <em>multiple importance sampling</em>: for each pixel sample, the
integrator generates a user-specifiable number of BSDF and emitter
samples and combines them using the power heuristic. Usually, the BSDF
sampling technique works very well on glossy objects but does badly
everywhere else, while the opposite is true for the emitter sampling
sampling technique works very well on glossy objects but does badly
everywhere else, while the opposite is true for the emitter sampling
technique. By combining these approaches, one
can obtain a rendering technique that works well in both cases.</p>
<p>The number of samples spent on either technique is configurable, hence
it is also possible to turn this plugin into an emitter sampling-only
<p>The number of samples spent on either technique is configurable, hence
it is also possible to turn this plugin into an emitter sampling-only
or BSDF sampling-only integrator.</p>
<p>For best results, combine the direct illumination integrator with the
low-discrepancy sample generator. Generally, the number
of pixel samples of the sample generator can be kept relatively
of pixel samples of the sample generator can be kept relatively
low (e.g. <tt>sampleCount=4</tt>), whereas the emitter and BSDF sample
parameters of this integrator should be increased until the variance in
the output renderings is acceptable.</p>
@ -181,11 +181,11 @@
situations where a light ray impinges on an object from a direction that is classified as "outside"
according to the shading normal, and "inside" according to the true geometric normal.</p>
<p>The <tt>strictNormals</tt>
parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on")
parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on")
gives precedence to information given by the shading normal and considers such light paths to be valid.
This can theoretically cause light "leaks" through boundaries, but it is not much of a problem in practice.</p>
<p>When set to <tt>true</tt>, the path tracer detects inconsistencies and ignores these paths. When objects
are poorly tesselated, this latter option may cause them to lose a significant amount of the incident
are poorly tesselated, this latter option may cause them to lose a significant amount of the incident
radiation (or, in other words, they will look dark).
The bidirectional integrators in Mitsuba (BDPT, PSSMLT, MLT, ..)
implicitly have <tt>strictNormals</tt> activated. Hence, another use of this parameter
@ -198,11 +198,11 @@
<descr>
This integrator implements a basic path tracer with multiple importance sampling and is a <em>good
default choice</em> when there is no strong reason to prefer another method.
It does not account for participating media, such as fog or smoke&mdash;see
It does not account for participating media, such as fog or smoke&mdash;see
the volumetric path tracer if this is needed.
</descr>
</plugin>
<plugin type="integrator" name="volpath_simple" readableName = "Volumetric path tracer (Simple)"
show="true" className="SimpleVolumetricPathTracer" extends="MonteCarloIntegrator">
<descr>
@ -221,10 +221,10 @@
show="true" className="VolumetricPathTracer" extends="MonteCarloIntegrator">
<descr>
This plugin provides a volumetric path tracer that can be used to
compute approximate solutions to the radiative transfer equation.
compute approximate solutions to the radiative transfer equation.
Its implementation makes use of multiple importance sampling to
combine BSDF and phase function sampling with direct illumination
sampling strategies. On surfaces, this integrator behaves exactly
combine BSDF and phase function sampling with direct illumination
sampling strategies. On surfaces, this integrator behaves exactly
like the standard path tracer.
</descr>
</plugin>
@ -232,7 +232,7 @@
<plugin type="integrator" name="ptracer" readableName="Adjoint particle tracer" show="true"
className="ParticleTracer" extends="ImageBasedIntegrator">
<descr>
<p>This plugin implements a simple adjoint particle tracer. It does
<p>This plugin implements a simple adjoint particle tracer. It does
essentially the exact opposite of the simple volumetric path tracer:
instead of tracing rays from the sensor
and attempting to connect them to the light source, this integrator
@ -241,21 +241,21 @@
<p>Usually, this is a relatively useless rendering technique due to
its high variance, but there are some cases where it excels.
In particular, it does a good job on scenes where most scattering
In particular, it does a good job on scenes where most scattering
events are directly visible to the camera.</p>
<p>When rendering with a finite-aperture sensor
this integrator is able to intersect the actual aperture, which allows it to
<p>When rendering with a finite-aperture sensor
this integrator is able to intersect the actual aperture, which allows it to
handle certain caustic paths that would otherwise not be visible.</p>
<p>It also supports a specialized "brute force" mode, where the integrator
does not attempt to create connections to the sensor and purely relies on
hitting it via ray tracing. This is one of the worst conceivable rendering
and not recommended for any applications. It is mainly included for
and not recommended for any applications. It is mainly included for
debugging purposes.</p>
<p>The number of traced particles is given by the number of "samples per
pixel" of the sample generator times the pixel count of the output image.
pixel" of the sample generator times the pixel count of the output image.
For instance, 16 samples per pixel on a 512x512 image will cause 4M particles
to be generated.</p>
</descr>
@ -267,12 +267,12 @@
network) is not the bottleneck.
</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="bruteForce" readableName="Brute force" type="boolean" default="false">
@ -285,20 +285,20 @@
<plugin type="integrator" name="vpl" readableName = "Virtual point light renderer"
show="true" className="VPLIntegrator" extends="Integrator">
<descr>
<p>This integrator implements a hardware-accelerated global illumination
<p>This integrator implements a hardware-accelerated global illumination
rendering technique based on the Instant Radiosity method by Keller.
This is the same approach that is also used in
Mitsuba's real-time preview; the reason for providing it as a separate
integrator plugin is to enable automated (e.g. scripted) usage.</p>
<p>The method roughly works as follows: during a pre-process pass, any present direct
and indirect illumination is converted into a set of <em>virtual point light</em>
sources (VPLs). The scene is then separately rendered many times, each time using
<p>The method roughly works as follows: during a pre-process pass, any present direct
and indirect illumination is converted into a set of <em>virtual point light</em>
sources (VPLs). The scene is then separately rendered many times, each time using
a different VPL as a source of illumination. All of the renderings created in this
manner are accumulated to create the final output image.</p>
<p>Because the individual rendering steps can be exectuted on a
graphics card, it is possible to render many (i.e. 100-1000) VPLs
graphics card, it is possible to render many (i.e. 100-1000) VPLs
per second. The method is not without problems, however. In particular,
it performs poorly when rendering glossy materials, and it produces
artifacts in corners and creases . Mitsuba automatically limits
@ -310,7 +310,7 @@
<param name="shadowMapResolution" readableName="Shadow Map Resolution" type="integer" default="512">Resolution of the shadow maps that are used to compute the point-to-point visibility</param>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="clamping" readableName="Clamping factor" type="float" default="0.1">Relative clamping factor (0=no clamping, 1=full clamping)</param>
@ -328,15 +328,15 @@
unless an extremely large number of photons is used. A simple remedy is to combine the photon mapper with
an irradiance cache, which performs <em>final gathering</em> to remove these artifacts. Due to its caching nature,
the rendering process will be faster as well.</p>
<p>When the scene contains homogeneous participating media, the Beam Radiance Estimate by Jarosz et al.
<p>When the scene contains homogeneous participating media, the Beam Radiance Estimate by Jarosz et al.
is used to estimate the illumination due to volumetric scattering.</p>
</descr>
<param name="directSamples" readableName="Direct samples" type="integer" default="16">Number of luminaire samples for direct illumination</param>
<param name="glossySamples" readableName="Glossy samples" type="integer" default="32">Number of glossy samples for direct illumination</param>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="globalPhotons" readableName="Global photons" type="integer" default="250000">Number of photons to collect for the global photon map (if applicable)</param>
@ -347,42 +347,42 @@
<param name="lookupSize" readableName="Caustic photon map lookup size" type="integer" default="120">Number of photons that should be fetched in photon map queries</param>
<param name="granularity" readableName="Work unit granularity" importance="1" type="integer" default="0">Granularity of photon tracing work units (in shot particles, 0 => decide automatically)</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion when tracing photons (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion when tracing photons (set to <tt>-1</tt> to disable).
</param>
</plugin>
<plugin type="integrator" name="ppm" readableName="Progressive photon mapper"
show="true" className="ProgressivePhotonMapIntegrator" extends="Integrator">
<descr>
<p>This plugin implements the progressive photon mapping algorithm by Hachisuka et al.
<p>This plugin implements the progressive photon mapping algorithm by Hachisuka et al.
Progressive photon mapping is a variant of photon
mapping that alternates between photon shooting and gathering passes that involve
a relatively small (e.g. 250K) numbers of photons that are subsequently discarded.</p>
<p>This is done in a way such that the variance and bias of the resulting output
<p>This is done in a way such that the variance and bias of the resulting output
vanish as the number of passes tends to infinity. The progressive nature of this
method enables renderings with an effectively arbitrary number of photons
without exhausting the available system memory.</p>
<p>The desired sample count specified in the sample generator configuration
<p>The desired sample count specified in the sample generator configuration
determines how many photon query points are created per pixel. It should not be
set too high, since the rendering time is approximately proportional to
this number. For good results, use between 2-4 samples along with the
low-discrepancy sampler. Once started, the rendering process continues indefinitely
this number. For good results, use between 2-4 samples along with the
low-discrepancy sampler. Once started, the rendering process continues indefinitely
until it is manually stopped.</p>
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="initialRadius" readableName="Initial radius" type="float" default="0">Initial photon query radius (<tt>0</tt> = infer based on scene size and camera resolution)</param>
<param name="photonCount" readableName="Photons per iteration" type="integer" default="250000">Number of photons to shoot in each iteration</param>
<param name="granularity" readableName="Work unit granularity" importance="1" type="integer" default="0">Granularity of photon tracing work units (in numbers of traced particles, <tt>0</tt> = decide automatically)</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion when tracing photons (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion when tracing photons (set to <tt>-1</tt> to disable).
</param>
<param name="alpha" readableName="Size reduction parameter" type="float" default="0.7" importance="1">Alpha parameter from the paper (influences the speed, at which the photon radius is reduced)</param>
</plugin>
@ -390,26 +390,26 @@
<plugin type="integrator" name="sppm" readableName="Stochastic progressive photon mapper"
show="true" className="StochasticProgressivePhotonMapIntegrator" extends="Integrator">
<descr>
<p>This integrator implements stochastic progressive photon mapping (PPM) by Hachisuka et al.
This algorithm is an extension of progressive photon mapping that improves convergence
<p>This integrator implements stochastic progressive photon mapping (PPM) by Hachisuka et al.
This algorithm is an extension of progressive photon mapping that improves convergence
when rendering scenes involving depth-of-field, motion blur, and glossy reflections.</p>
<p>Note that this integrator ignores the sampler
configuration&mdash;hence, the usual steps of choosing a sample generator and a desired
number of samples per pixel are not necessary. As with PPM, once started,
configuration&mdash;hence, the usual steps of choosing a sample generator and a desired
number of samples per pixel are not necessary. As with PPM, once started,
the rendering process continues indefinitely until it is manually stopped.</p>
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="initialRadius" readableName="Initial radius" type="float" default="0">Initial photon query radius (<tt>0</tt> = infer based on scene size and camera resolution)</param>
<param name="photonCount" readableName="Photons per iteration" type="integer" default="250000">Number of photons to shoot in each iteration</param>
<param name="granularity" readableName="Work unit granularity" importance="1" type="integer" default="0">Granularity of photon tracing work units (in numbers of traced particles, <tt>0</tt> = decide automatically)</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
<param name="alpha" readableName="Size reduction parameter" type="float" default="0.7" importance="1">Alpha parameter from the paper (influences the speed, at which the photon radius is reduced)</param>
</plugin>
@ -421,9 +421,9 @@
BDPT) with support for multiple importance sampling.</p>
<p>A bidirectional path tracer generates a sample by starting two separate
random walks from an emitter and a sensor. The resulting <em>subpaths</em> are
random walks from an emitter and a sensor. The resulting <em>subpaths</em> are
connected at every possible position, creating a large number of complete paths
of different lengths. These paths are then used to estimate the amount of
of different lengths. These paths are then used to estimate the amount of
radiance that is transferred from the emitter to a pixel on the sensor.</p>
<p>Generally, some of the created paths will be unusable, since they lead to
@ -432,9 +432,9 @@
paths based on their predicted utility.</p>
<p>The bidirectional path tracer in Mitsuba is a complete implementation of the
technique that handles all sampling strategies, including those that involve
direct interactions with the sensor. For this purpose, finite-aperture sensors
are explicitly represented by surfaces in the scene so that they can be
technique that handles all sampling strategies, including those that involve
direct interactions with the sensor. For this purpose, finite-aperture sensors
are explicitly represented by surfaces in the scene so that they can be
intersected by random walks started at emitters.</p>
<p>Bidirectional path tracing is a relatively "heavy" rendering technique&mdash;for
@ -444,19 +444,19 @@
<p>The code parallelizes over multiple cores and machines, but with one caveat:
some of the BDPT path sampling strategies are incompatble with the usual
approach of rendering an image tile by tile, since they can potentially
approach of rendering an image tile by tile, since they can potentially
contribute to <em>any</em> pixel on the screen. This means that each
rendering work unit must be associated with a full-sized image!
When network render nodes are involved or the resolution of this <em>light image</em>
is very high, a bottleneck can arise where more work is spent accumulating or
is very high, a bottleneck can arise where more work is spent accumulating or
transmitting these images than actual rendering.</p>
<p>There are two possible resorts should this situation arise: the first one
is to reduce the number of work units so that there is approximately one
unit per core (and hence one image to transmit per core). This can be done by
increasing the block size in the GUI preferences or passing the <tt>-b</tt>
parameter to the <tt>mitsuba</tt> executable. The second option is to simply
disable these sampling strategies at the cost of reducing the
is to reduce the number of work units so that there is approximately one
unit per core (and hence one image to transmit per core). This can be done by
increasing the block size in the GUI preferences or passing the <tt>-b</tt>
parameter to the <tt>mitsuba</tt> executable. The second option is to simply
disable these sampling strategies at the cost of reducing the
effectiveness of bidirectional path tracing (particularly, when rendering
caustics). For this, set <tt>lightImage</tt> to <tt>false</tt>.
When rendering an image of a reasonable resolution without network nodes,
@ -464,14 +464,14 @@
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="lightImage" readableName="Create light image" type="boolean" default="true">
Include sampling strategies that connect
paths traced from emitters directly to the camera? (i.e. what the adjoint particle tracer does)
This improves the effectiveness of bidirectional path tracing
but severely increases the local and remote communication
but severely increases the local and remote communication
overhead, since large <em>light images</em> must be transferred between threads
or over the network. See the text below for a more detailed explanation.
</param>
@ -480,8 +480,8 @@
and sensors. Usually a good idea.
</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
</plugin>
@ -493,19 +493,19 @@
based on Markov Chain Monte Carlo (MCMC) integration.</p>
<p>In contrast to simple methods like path tracing that render
images by performing a naive and memoryless random search for light paths,
PSSMLT actively searches for <em>relevant</em> light paths (as is the case
for other MCMC methods). Once such a path is found, the algorithm tries to
images by performing a naive and memoryless random search for light paths,
PSSMLT actively searches for <em>relevant</em> light paths (as is the case
for other MCMC methods). Once such a path is found, the algorithm tries to
explore neighboring paths to amortize the cost of the search. This can
significantly improve the convergence rate of difficult input.
Scenes that were already relatively easy to render usually don't benefit
much from PSSMLT, since the MCMC data management causes additional
much from PSSMLT, since the MCMC data management causes additional
computational overheads.</p>
<p>The PSSMLT implementation in Mitsuba can operate on top of either a simple
unidirectional volumetric path tracer or a fully-fledged bidirectional path
tracer with multiple importance sampling, and this choice is controlled by the
<tt>bidirectional</tt> flag. The unidirectional path tracer is generally
<p>The PSSMLT implementation in Mitsuba can operate on top of either a simple
unidirectional volumetric path tracer or a fully-fledged bidirectional path
tracer with multiple importance sampling, and this choice is controlled by the
<tt>bidirectional</tt> flag. The unidirectional path tracer is generally
much faster, but it produces lower-quality samples. Depending on the input, either may be preferable.</p>
<p><b>Caveats</b>:
@ -513,20 +513,20 @@
to know. The first one is that they only render "relative" output images,
meaning that there is a missing scale factor that must be applied to
obtain proper scene radiance values. The implementation in Mitsuba relies
on an additional Monte Carlo estimator to recover this scale factor. By
default, it uses 100K samples (controlled by the <tt>luminanceSamples</tt>
on an additional Monte Carlo estimator to recover this scale factor. By
default, it uses 100K samples (controlled by the <tt>luminanceSamples</tt>
parameter), which should be adequate for most applications.</p>
<p>The second caveat is that the amount of computational expense
associated with a pixel in the output image is roughly proportional to
its intensity. This means that when a bright object (e.g. the sun) is
visible in a rendering, most resources are committed to rendering the
sun disk at the cost of increased variance everywhere else. Since this is
sun disk at the cost of increased variance everywhere else. Since this is
usually not desired, the <tt>twoStage</tt> parameter can be used to
enable <em>Two-stage MLT</em> in this case. </p>
<p>In this mode of operation, the renderer first creates a low-resolution
version of the output image to determine the approximate distribution of
<p>In this mode of operation, the renderer first creates a low-resolution
version of the output image to determine the approximate distribution of
luminance values. The second stage then performs the actual rendering, while
using the previously collected information to ensure that
the amount of time spent rendering each pixel is uniform.</p>
@ -542,19 +542,19 @@
for everything. This can be accomplished by setting
<tt>directSamples=-1</tt>.</p>
</descr>
<param name="bidirectional" readableName="Bidirectional" type="boolean" default="true">
<param name="bidirectional" readableName="Bidirectional" type="boolean" default="true">
If set to <tt>true</tt>, the MLT algorithm runs on top of a
bidirectional path tracer with multiple importance sampling.
Otherwise, the implementation reverts to a unidirectional path tracer.
</param>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="directSamples" readableName="Direct samples" type="integer" default="16">
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
that uses low-discrepancy number sequences for superior performance
(in other words, it is <em>not</em> rendered by PSSMLT). This
parameter specifies the number of samples allocated to that method. To
@ -570,7 +570,7 @@
is approximately twice as bright as another one, but the absolute
scale is unknown. To recover it, this plugin computes
the average luminance arriving at the sensor by generating a
number of samples.
number of samples.
</param>
<param name="pLarge" readableName="Large step probability" type="float" default="0.3" importance="1">
Rate at which the implementation tries to replace the current path
@ -578,15 +578,15 @@
this.
</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
Specifies the minimum path depth, after which the implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
</plugin>
<plugin type="integrator" name="mlt" readableName="Path Space MLT" show="true"
className="MLT" extends="Integrator">
<descr>
<p>Metropolis Light Transport (MLT) is a seminal rendering technique proposed by Veach and
<p>Metropolis Light Transport (MLT) is a seminal rendering technique proposed by Veach and
Guibas, which applies the Metropolis-Hastings
algorithm to the path-space formulation of light transport.
Please refer to the PSSMLT documentation for a general description of MLT-type
@ -600,9 +600,9 @@
not use such an indirection: it operates directly on the actual light
paths. </p>
<p>This means that the algorithm has access to considerably more
<p>This means that the algorithm has access to considerably more
information about the problem to be solved, which allows it to perform a
directed exploration of certain classes of light paths. The main downside
directed exploration of certain classes of light paths. The main downside
is that the implementation is rather complex, which may make it more
susceptible to unforeseen problems. Mitsuba reproduces the full MLT
algorithm except for the lens subpath mutation. In addition, the plugin also provides the
@ -610,12 +610,12 @@
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="directSamples" readableName="Direct samples" type="integer" default="16">
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
that uses low-discrepancy number sequences for superior performance
(in other words, it is <em>not</em> rendered by MLT). This
parameter specifies the number of samples allocated to that method. To
@ -631,7 +631,7 @@
is approximately twice as bright as another one, but the absolute
scale is unknown. To recover it, this plugin computes
the average luminance arriving at the sensor by generating a
number of samples.
number of samples.
</param>
<param name="bidirectionalMutation" readableName="Bidirectional mutation" type="boolean" default="true" importance="1">
Selectively enable/disable the bidirectional mutation
@ -656,25 +656,25 @@
<plugin type="integrator" name="erpt" readableName="Energy redistribution path tracing" show="true"
className="EnergyRedistributionPathTracer" extends="Integrator">
<descr>
<p>Energy Redistribution Path Tracing (ERPT) by Cline et al.
<p>Energy Redistribution Path Tracing (ERPT) by Cline et al.
combines Path Tracing with the perturbation strategies of Metropolis Light Transport.</p>
<p>An initial set of <em>seed paths</em> is generated using a standard bidirectional
path tracer, and for each one, a MLT-style Markov Chain is subsequently started
<p>An initial set of <em>seed paths</em> is generated using a standard bidirectional
path tracer, and for each one, a MLT-style Markov Chain is subsequently started
and executed for some number of steps.
This has the effect of redistributing the energy of the individual samples
over a larger area, hence the name of this method.</p>
<p>This plugin shares all the perturbation strategies of the MLT plugin, and
the same rules for selecting them apply. In contrast to the original
paper by Cline et al., the Mitsuba implementation uses a bidirectional
(rather than an unidirectional) bidirectional path tracer to create seed paths.
Also, since they add bias to the output, this plugin does not use the image
Also, since they add bias to the output, this plugin does not use the image
post-processing filters proposed by the authors.</p>
</descr>
<param name="maxDepth" readableName="Maximum depth" type="integer" default="-1">
Specifies the longest path depth in the generated output image (where <tt>-1</tt>
corresponds to ∞). A value of 1 will only render directly visible light sources.
corresponds to ∞). A value of 1 will only render directly visible light sources.
2 will lead to single-bounce (direct-only) illumination, and so on.
</param>
<param name="numChains" readableName="Average number of chains" type="float" default="1">
@ -689,8 +689,8 @@
Specifies the number of mutations to be performed in each Markov Chain
</param>
<param name="directSamples" readableName="Direct samples" type="integer" default="16">
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
By default, this plugin renders the direct illumination component
separately using an optimized direct illumination sampling strategy
that uses low-discrepancy number sequences for superior performance
(in other words, it is <em>not</em> rendered by ERPT). This
parameter specifies the number of samples allocated to that method. To
@ -720,15 +720,15 @@
Probability factor ("lambda") of the manifold perturbation
</param>
<param name="rrDepth" readableName="Russian Roulette starting depth" type="integer" default="5" importance="1">
When creating seed paths, this parameter specifies the minimum path depth, after which the
implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
When creating seed paths, this parameter specifies the minimum path depth, after which the
implementation will start to use the
"russian roulette" path termination criterion (set to <tt>-1</tt> to disable).
</param>
</plugin>
<plugin type="rfilter" readableName="Box filter" name="box" show="true" className="BoxFilter" extends="ReconstructionFilter">
<descr>Box filter: the fastest, but also about the worst possible
reconstruction filter, since it is extremely prone to aliasing.
<descr>Box filter: the fastest, but also about the worst possible
reconstruction filter, since it is extremely prone to aliasing.
It is included mainly for completeness, though some rare situations
may warrant its use.</descr>
</plugin>
@ -736,7 +736,7 @@
<plugin type="rfilter" readableName="Tent filter" name="tent" show="true" className="TentFilter" extends="ReconstructionFilter">
<descr>
Simple tent, or triangle filter. This reconstruction filter never
suffers from ringing and usually causes less aliasing than a naive
suffers from ringing and usually causes less aliasing than a naive
box filter. When rendering scenes with sharp brightness discontinuities,
this may be useful; otherwise, negative-lobed filters will be preferable
(e.g. Mitchell-Netravali or Lanczos Sinc)
@ -746,7 +746,7 @@
<plugin type="rfilter" readableName="Gaussian filter" name="gaussian" show="true" className="GaussianFilter" extends="ReconstructionFilter">
<descr>
This is a windowed Gaussian filter with configurable standard deviation.
It produces pleasing results and never suffers from ringing, but may
It produces pleasing results and never suffers from ringing, but may
occasionally introduce too much blurring.
When no reconstruction filter is explicitly requested, this is the default
choice in Mitsuba.
@ -758,8 +758,8 @@
<descr>
Separable cubic spline reconstruction filter by Mitchell and Netravali.
This is often a good compromise between sharpness and ringing.
The plugin has two <tt>float</tt>-valued parameters named <tt>B</tt> and <tt>C</tt> that
The plugin has two <tt>float</tt>-valued parameters named <tt>B</tt> and <tt>C</tt> that
correspond to the two parameters in the original research paper. By default, these
are set to the recommended value of 1/3, but can be tweaked if desired.
</descr>
@ -769,7 +769,7 @@
<plugin type="rfilter" readableName="Catmull-Rom filter" name="catmullrom" show="true" className="CatmullRomFilter" extends="ReconstrutionFilter">
<descr>
This is a special version of the Mitchell-Netravali filter that has the
This is a special version of the Mitchell-Netravali filter that has the
constants <tt>B</tt> and <tt>C</tt> adjusted to produce higher sharpness at the
cost of increased susceptibility to ringing.
</descr>
@ -778,11 +778,11 @@
<plugin type="rfilter" readableName="Lanczos Sinc filter" name="lanczos" show="true" className="LanczosSincFilter" extends="ReconstructionFilter">
<descr>
<p>This is a windowed version of the theoretically optimal low-pass filter.
It is generally one of the best available filters in terms of producing sharp
high-quality output. Its main disadvantage is that it produces strong ringing around
discontinuities, which can become a serious problem when rendering bright objects
with sharp edges (for instance, a directly visible light source will have black
fringing artifacts around it).
It is generally one of the best available filters in terms of producing sharp
high-quality output. Its main disadvantage is that it produces strong ringing around
discontinuities, which can become a serious problem when rendering bright objects
with sharp edges (for instance, a directly visible light source will have black
fringing artifacts around it).
This is also the computationally slowest reconstruction filter.</p>
<p>This plugin has an <tt>integer</tt>-valued parameter named <tt>lobes</tt>, that
@ -798,29 +798,29 @@
<p>The independent sampler produces a stream of independent and uniformly
distributed pseudorandom numbers. Internally, it relies on a fast SIMD version
of the Mersenne Twister random number generator.</p>
<p>This is the most basic sample generator; because no precautions are taken to avoid
<p>This is the most basic sample generator; because no precautions are taken to avoid
sample clumping, images produced using this plugin will usually take longer to converge.
In theory, this sampler is initialized using a deterministic procedure, which means
that subsequent runs of Mitsuba should create the same image. In practice, when
rendering with multiple threads and/or machines, this is not true anymore, since the
that subsequent runs of Mitsuba should create the same image. In practice, when
rendering with multiple threads and/or machines, this is not true anymore, since the
ordering of samples is influenced by the operating system scheduler.</p>
<p>Note that the Metropolis-type integrators implemented in Mitsuba are incompatible with
the more sophisticated sample generators shown in this section. They <em>require</em> this
the more sophisticated sample generators shown in this section. They <em>require</em> this
specific sampler and refuse to work otherwise.</p>
</descr>
</descr>
<param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">Number of samples per pixel</param>
</plugin>
<plugin type="sampler" name="stratified" readableName="Stratified sampler" show="true" className="StratifiedSampler" extends="Sampler">
<descr>
<p>The stratified sample generator divides the domain into a discrete number
of strata and produces a sample within each one of them. This generally leads to less
sample clumping when compared to the independent sampler, as well as better
convergence. Due to internal storage costs, stratified samples are only provided up to a
of strata and produces a sample within each one of them. This generally leads to less
sample clumping when compared to the independent sampler, as well as better
convergence. Due to internal storage costs, stratified samples are only provided up to a
certain dimension, after which independent sampling takes over.</p>
<p>Like the independent sampler, multicore and network renderings
will generally produce different images in subsequent runs due to the nondeterminism
introduced by the operating system scheduler.</p>
@ -830,43 +830,43 @@
</param>
<param name="dimension" readableName="Effective dimension" type="integer" default="4">
Effective dimension, up to which stratified samples are provided. The
number here is to be interpreted as the number of subsequent 1D or 2D sample
requests that can be satisfied using "good" samples. Higher high values
number here is to be interpreted as the number of subsequent 1D or 2D sample
requests that can be satisfied using "good" samples. Higher high values
increase both storage and computational costs.
</param>
</plugin>
<plugin type="sampler" name="ldsampler" readableName="Low discrepancy sampler" show="true" className="LowDiscrepancySampler" extends="Sampler">
<descr>
<p>This plugin implements a simple hybrid sampler that combines aspects of a Quasi-Monte
Carlo sequence with a pseudorandom number generator based on a technique proposed
<p>This plugin implements a simple hybrid sampler that combines aspects of a Quasi-Monte
Carlo sequence with a pseudorandom number generator based on a technique proposed
by Kollig and Keller.
It is a good and fast general-purpose sample generator and therefore chosen as
It is a good and fast general-purpose sample generator and therefore chosen as
the default option in Mitsuba. Some of the QMC samplers in the following pages can generate
even better distributed samples, but this comes at a higher cost in terms of performance.</p>
<p>Roughly, the idea of this sampler is that all of the individual 2D sample dimensions are
first filled using the same (0, 2)-sequence, which is then randomly scrambled and permuted
using numbers generated by a Mersenne Twister pseudorandom number generator
Note that due to internal storage costs, low discrepancy samples are only provided
<p>Roughly, the idea of this sampler is that all of the individual 2D sample dimensions are
first filled using the same (0, 2)-sequence, which is then randomly scrambled and permuted
using numbers generated by a Mersenne Twister pseudorandom number generator
Note that due to internal storage costs, low discrepancy samples are only provided
up to a certain dimension, after which independent sampling takes over.
The name of this plugin stems from the fact that (0, 2) sequences minimize the so-called
<em>star disrepancy</em>, which is a quality criterion on their spatial distribution. By
The name of this plugin stems from the fact that (0, 2) sequences minimize the so-called
<em>star disrepancy</em>, which is a quality criterion on their spatial distribution. By
now, the name has become slightly misleading since there are other samplers in Mitsuba
that just as much try to minimize discrepancy, namely the Sobol and Halton plugins.</p>
<p>Like the independent sampler, multicore and network renderings
will generally produce different images in subsequent runs due to the nondeterminism
introduced by the operating system scheduler.</p>
</descr>
<param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">
Number of samples per pixel; should be a power of two
(e.g. 1, 2, 4, 8, 16, etc.), or it will be rounded up to the next one
(e.g. 1, 2, 4, 8, 16, etc.), or it will be rounded up to the next one
</param>
<param name="dimension" readableName="Effective dimension" type="integer" default="4">
Effective dimension, up to which low discrepancy samples are provided. The
number here is to be interpreted as the number of subsequent 1D or 2D sample
requests that can be satisfied using "good" samples. Higher high values
number here is to be interpreted as the number of subsequent 1D or 2D sample
requests that can be satisfied using "good" samples. Higher high values
increase both storage and computational costs.
</param>
</plugin>
@ -875,19 +875,19 @@
<descr>
<p>This plugin implements a Quasi-Monte Carlo (QMC) sample generator based on the
Hammersley sequence. QMC number sequences are designed to reduce sample clumping
across integration dimensions, which can lead to a higher order of
across integration dimensions, which can lead to a higher order of
convergence in renderings. Because of the deterministic character of the samples,
errors will manifest as grid or moiré patterns rather than random noise, but
these diminish as the number of samples is increased.</p>
<p>The Hammerlsey sequence is closely related to the Halton sequence and yields a very
high quality point set that is slightly more regular (and has lower discrepancy),
especially in the first few dimensions. As is the case with the Halton sequence,
the points should be scrambled to reduce patterns that manifest due due to correlations
in higher dimensions. </p>
<p>Note that this sampler will cause odd-looking intermediate results when combined with rendering
techniques that trace paths starting at light source (e.g. the adjoint particle tracer)—these vanish
<p>Note that this sampler will cause odd-looking intermediate results when combined with rendering
techniques that trace paths starting at light source (e.g. the adjoint particle tracer)—these vanish
by the time the rendering process finishes.</p>
</descr>
<param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">Number of generated samples / samples per pixel</param>
@ -897,7 +897,7 @@
<li>When set to <tt>0</tt>, the implementation will provide the standard Hammersley sequence.</li>
<li>When set to <tt>-1</tt>, the implementation will compute
a scrambled variant of the Hammersley sequence based on permutations by
a scrambled variant of the Hammersley sequence based on permutations by
Faure, which has better equidistribution properties
in high dimensions.</li>
@ -907,8 +907,8 @@
the frames of an animation—in this case, simply set the parameter to the current frame index.
</li>
</ul>
Default: <tt>-1</tt>, i.e. use the Faure permutations. Note that permutations rely on a
precomputed table that consumes approximately 7 MiB of additional memory at run time.
Default: <tt>-1</tt>, i.e. use the Faure permutations. Note that permutations rely on a
precomputed table that consumes approximately 7 MiB of additional memory at run time.
</param>
</plugin>
@ -916,27 +916,27 @@
<descr>
<p>This plugin implements a Quasi-Monte Carlo (QMC) sample generator based on the
Halton sequence. QMC number sequences are designed to reduce sample clumping
across integration dimensions, which can lead to a higher order of
across integration dimensions, which can lead to a higher order of
convergence in renderings. Because of the deterministic character of the samples,
errors will manifest as grid or moiré patterns rather than random noise, but
these diminish as the number of samples is increased.</p>
<p>The Halton sequence in particular provides a very high quality point set that unfortunately
becomes increasingly correlated in higher dimensions. To ameliorate this problem, the Halton
<p>The Halton sequence in particular provides a very high quality point set that unfortunately
becomes increasingly correlated in higher dimensions. To ameliorate this problem, the Halton
points are usually combined with a scrambling permutation, and this is also the default.
Because everything that happens inside this sampler is completely deterministic and
independent of operating system scheduling behavior, subsequent runs of Mitsuba will always
compute the same image, and this even holds when rendering with multiple threads
Because everything that happens inside this sampler is completely deterministic and
independent of operating system scheduling behavior, subsequent runs of Mitsuba will always
compute the same image, and this even holds when rendering with multiple threads
and/or machines.</p>
<p>By default, the implementation provides a scrambled variant of the Halton sequence based
<p>By default, the implementation provides a scrambled variant of the Halton sequence based
on permutations by Faure that has better equidistribution properties
in high dimensions, but this can be changed using the <tt>scramble</tt> parameter.
Internally, the plugin uses a table of prime numbers to provide elements
Internally, the plugin uses a table of prime numbers to provide elements
of the Halton sequence up to a dimension of 1024. Because of this upper bound,
the maximum path depth of the integrator must be limited (e.g. to 100), or
rendering might fail with the following error message: <tt>Lookup dimension
exceeds the prime number table size! You may have to reduce the 'maxDepth'
rendering might fail with the following error message: <tt>Lookup dimension
exceeds the prime number table size! You may have to reduce the 'maxDepth'
parameter of your integrator</tt>.</p>
</descr>
<param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">Number of generated samples / samples per pixel</param>
@ -946,7 +946,7 @@
<li>When set to <tt>0</tt>, the implementation will provide the standard Hammersley sequence.</li>
<li>When set to <tt>-1</tt>, the implementation will compute
a scrambled variant of the Hammersley sequence based on permutations by
a scrambled variant of the Hammersley sequence based on permutations by
Faure, which has better equidistribution properties
in high dimensions.</li>
@ -956,8 +956,8 @@
the frames of an animation—in this case, simply set the parameter to the current frame index.
</li>
</ul>
Default: <tt>-1</tt>, i.e. use the Faure permutations. Note that permutations rely on a
precomputed table that consumes approximately 7 MiB of additional memory at run time.
Default: <tt>-1</tt>, i.e. use the Faure permutations. Note that permutations rely on a
precomputed table that consumes approximately 7 MiB of additional memory at run time.
</param>
</plugin>
@ -966,7 +966,7 @@
<descr>
<p>This plugin implements a Quasi-Monte Carlo (QMC) sample generator based on the
Sobol sequence. QMC number sequences are designed to reduce sample clumping
across integration dimensions, which can lead to a higher order of
across integration dimensions, which can lead to a higher order of
convergence in renderings. Because of the deterministic character of the samples,
errors will manifest as grid or moiré patterns rather than random noise, but
these diminish as the number of samples is increased. </p>
@ -976,22 +976,22 @@
in the generated image. To minimize these artifacts, it is advisable to use
a number of samples per pixel that is a power of two.</p>
<p>Because everything that happens inside this sampler is completely
deterministic and independent of operating system scheduling behavior, subsequent
runs of Mitsuba will always compute the same image, and this even holds when rendering
<p>Because everything that happens inside this sampler is completely
deterministic and independent of operating system scheduling behavior, subsequent
runs of Mitsuba will always compute the same image, and this even holds when rendering
with multiple threads and/or machines.</p>
<p>The plugin relies on a fast implementation of the Sobol sequence by Leonhard
Grünschloß using direction numbers provided by Joe and Kuo.
These direction numbers are given up to a dimension of 1024. Because of this
These direction numbers are given up to a dimension of 1024. Because of this
upper bound, the maximum path depth of the integrator must be limited (e.g. to 100), or
rendering might fail with the following error message: <tt>Lookup dimension
exceeds the direction number table size! You may have to reduce the 'maxDepth'
rendering might fail with the following error message: <tt>Lookup dimension
exceeds the direction number table size! You may have to reduce the 'maxDepth'
parameter of your integrator</tt>.</p>
</descr>
<param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">Number of samples per pixel</param>
<param name="scramble" readableName="Scramble value" type="integer" default="0">
Scramble value that can be used to break up temporally coherent
Scramble value that can be used to break up temporally coherent
noise patterns. For stills, this parameter is irrelevant. When rendering an animation,
simply set it to the current frame index.
</param>