|
|
|
@ -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—see
|
|
|
|
|
It does not account for participating media, such as fog or smoke—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—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—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—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>
|
|
|
|
|