<?xml version="1.0"?>
<documentation version="2.0.2">
    <plugin type="integrator" className="SampleIntegrator" abstract="true">
        <shortDescr>Base class of all sampling-based integrators</shortDescr>
        <descr>Base class of all sampling-based integrators</descr>
    </plugin>

    <plugin type="integrator" className="MonteCarloIntegrator" abstract="true" extends="SampleIntegrator">
        <shortDescr>Base class of recursive MC integrators</shortDescr>
        <descr>
            Base class of all recursive Monte Carlo integrators, which compute
            unbiased solutions to the rendering equation (and optionally
            the radiative transfer equation).
         </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.
            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).
        </param>
        <param name="strictNormals" readableName="Strict surface normals" type="boolean" default="false" importance="1">
            <p>
                Be strict about potential inconsistencies involving shading normals?
            </p>
            <p>Triangle meshes often rely on interpolated shading normals
            to suppress the inherently faceted appearance of the underlying geometry. These
            "fake" normals are not without problems, however. They can lead to paradoxical
            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")
            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
            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
            is to match renderings created by these methods.</p>
        </param>
        <param name="hideEmitters" readableName="Hide directly visible emitters" type="boolean" default="false" importance="1">
            Hide light sources (e.g. area or environment light sources) that are directly visible to the camera?
            Reflections of light sources remain unaffected.
        </param>
    </plugin>

    <plugin type="integrator" name="irrcache" readableName="Irradiance cache"
            className="IrradianceCacheIntegrator">
        <descr>
            <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,
            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
            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
            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
            addition of samples as rendering proceeds.</p>
        </descr>
        <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
        </param>
        <param name="quality" readableName="Quality" type="float" default="1">
           Quality setting ("kappa" in the [Tabellion et al.] paper).
           A value of 1 should be adequate in most cases.
        </param>
        <param name="gradients" readableName="Irradiance gradients" type="boolean" default="true">
           Should irradiance gradients be used? Generally, this will
           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.
        </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.]?
           Turning this off may lead to excessive sample placement.
        </param>
        <param name="overture" readableName="Overture pass" type="boolean" default="true">
           If set to true, the irradiance cache will be filled by a
           parallel overture pass before the main rendering process starts.
           This is strongly recommended.
        </param>
        <param name="qualityAdjustment" readableName="Quality adjustment" type="float" default=".5">
           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.
        </param>
        <param name="indirectOnly" readableName="Show indirect illumination only" type="boolean" default="false">
           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">
            If set to true, sample locations are visually highlighted as they are generated.
            This is useful for checking the quality of their placement.
        </param>
        <child type="integrator" count="1" extends="SampleIntegrator">Requires a sampling-based sub-integrator</child>
    </plugin>

    <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).
            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.
        </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
            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>
        <child type="integrator" count="1" extends="SampleIntegrator">Requires a sampling-based sub-integrator</child>
    </plugin>

    <plugin type="integrator" name="ao" readableName="Ambient occlusion"
            show="true" className="AmbientOcclusionIntegrator" extends="SampleIntegrator">
        <descr>
            Ambient Occlusion is a non-photorealistic rendering technique that simulates the exposure of an object
            to uniform illumination incident from all direction. It produces approximate shadowing between closeby
            objects, as well as darkening in corners, creases, and cracks.
        </descr>
        <param name="shadingSamples" readableName="Shading samples" type="integer" default="1">
            Specifies the number of shading samples that should be computed per primary ray
        </param>
        <param name="rayLength" readableName="Occlusion ray length" type="float" default="-1">
            Specifies the world-space length of the ambient occlusion rays that will be cast. Default: -1, i.e. automatic
        </param>
    </plugin>

    <plugin type="integrator" name="direct" readableName="Direct illumination"
            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
                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
                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
                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
                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>
        </descr>
        <param name="emitterSamples" readableName="Emitter samples" type="integer" default="1">Number of samples to take using the emitter sampling technique</param>
        <param name="bsdfSamples" readableName="BSDF samples" type="integer" default="1">Number of samples to take using the BSDF sampling technique</param>
        <param name="strictNormals" readableName="Strict surface normals" type="boolean" default="false" importance="1">
            <p>
                Be strict about potential inconsistencies involving shading normals?
            </p>
            <p>Triangle meshes often rely on interpolated shading normals
            to suppress the inherently faceted appearance of the underlying geometry. These
            "fake" normals are not without problems, however. They can lead to paradoxical
            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")
            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
            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
            is to match renderings created by these methods.</p>
        </param>
        <param name="hideEmitters" readableName="Hide directly visible emitters" type="boolean" default="false" importance="1">
            Hide light sources (e.g. area or environment light sources) that are directly visible to the camera?
            Reflections of light sources remain unaffected.
        </param>
    </plugin>

    <plugin type="integrator" name="path" readableName="Path tracer"
            show="true" className="MIPathTracer" extends="MonteCarloIntegrator">
        <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
            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>
            This plugin provides a basic volumetric path tracer that can be used to
            compute approximate solutions to 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
            plugin will likely not perform well when given a scene that contains
            highly glossy materials. In this case, please use the extended volumetric
            path tracer or one of the bidirectional techniques.
        </descr>
    </plugin>

    <plugin type="integrator" name="volpath" readableName = "Volumetric path tracer (Extended)"
            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.
            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
            like the standard path tracer.
        </descr>
    </plugin>

    <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
            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
            shoots particles from the light source and attempts to connect them to
            the sensor.</p>

            <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
            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
            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
            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.
            For instance, 16 samples per pixel on a 512x512 image will cause 4M particles
            to be generated.</p>
        </descr>
        <param name="granularity" readableName="Work unit granularity" type="integer" default="200000" importance="1">
            Specifies the work unit granularity used to parallize the
            the particle tracing task (default: 200K samples per work unit).
            This should be high enough so that accumulating
            partially exposed images (and potentially sending them over the
            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).
        </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.
            2 will lead to single-bounce (direct-only) illumination, and so on.
        </param>
        <param name="bruteForce" readableName="Brute force" type="boolean" default="false">
            If set to <tt>true</tt> the integrator does not attempt to create
            connections to the sensor and purely relies on hitting it via ray
            tracing. This is mainly intended for debugging purposes.
        </param>
    </plugin>

    <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
            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
            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
            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
            the "glossyness" of materials to reduce the effects of the former
            problem. A clamping parameter is provided to control the latter
            (see the documentation for details). The number of samples per pixel specified to
            the sampler is interpreted as the number of VPLs that should be rendered.</p>
        </descr>
        <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.
            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>
    </plugin>

    <plugin type="integrator" name="photonmapper" readableName="Photon mapper" show="true"
            className="PhotonMapIntegrator" extends="SampleIntegrator">
        <descr>
                <p>This plugin implements the two-pass photon mapping algorithm as proposed by Jensen.
                The implementation partitions the illumination into three different classes (diffuse, caustic, and volumetric),
                and builds a separate photon map for each class.</p>

                <p>Following this, a standard recursive ray tracing pass is started which performs kernel density estimation
                using these photon maps. Since the photon maps are visualized directly, the result will appear "blotchy"
                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.
                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.
            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>
        <param name="causticPhotons" readableName="Caustic photons" type="integer" default="250000">Number of photons to collect for the caustic photon map (if applicable)</param>
        <param name="volumePhotons" readableName="Volume photons" type="integer" default="250000">Number of photons to collect for the volume photon map (if applicable)</param>
        <param name="globalLookupRadius" readableName="Lookup radius (global)" type="float" default="0.05">Radius of lookups in the global photon map (relative to the scene size)</param>
        <param name="causticLookupRadius" readableName="Lookup radius (caustic)" type="float" default="0.0125">Radius of lookups in the caustic photon map (relative to the scene size)</param>
        <param name="lookupSize" readableName="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).
        </param>
        <param name="hideEmitters" readableName="Hide directly visible emitters" type="boolean" default="false" importance="1">
            Hide light sources (e.g. area or environment light sources) that are directly visible to the camera?
            Reflections of light sources remain unaffected.
        </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.
            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
            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
            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
            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.
            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).
        </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>

    <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
            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,
            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.
            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).
        </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>

    <plugin type="integrator" name="bdpt" readableName="Bidirectional path tracer" show="true"
            className="BidirectionalIntegrator" extends="Integrator">
        <descr>
            <p>This plugin implements a Veach-style bidirectional path tracer (short:
            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
            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
            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
            high-variance radiance estimates. To alleviate this situation, BDPT makes
            use of <em>multiple importance sampling</em> which, roughly speaking, weights
            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
            intersected by random walks started at emitters.</p>

            <p>Bidirectional path tracing is a relatively "heavy" rendering technique&mdash;for
            the same number of samples per pixel, it is easily 3-4 times slower than regular
            path tracing. However, it usually makes up for this by producing considerably
            lower-variance radiance estimates (i.e. the output images have less noise).</p>

            <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
            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
            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
            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,
            this is not a big concern, hence these strategies are enabled by default.</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.
            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
            overhead, since large <em>light images</em> must be transferred between threads
            or over the network. See the main documentation for a more detailed explanation.
        </param>
        <param name="sampleDirect" readableName="Use direct sampling methods" type="boolean" default="true">
            Enable direct sampling strategies? This is a generalization of direct illumination sampling that works with both emitters
            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).
        </param>
    </plugin>

    <plugin type="integrator" name="pssmlt" readableName="Primary Sample Space MLT" show="true"
            className="PSSMLT" extends="Integrator">
            <descr>
                <p>Primary Sample Space Metropolis Light Transport (PSSMLT) is a rendering
                technique developed by Kelemen et al. which is
                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
                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
                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
                much faster, but it produces lower-quality samples. Depending on the input, either may be preferable.</p>

                <p><b>Caveats</b>:
                There are a few general caveats about MLT-type algorithms that are good
                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>
                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
                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
                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>

                <p>The third caveat is that, while PSMLT can work with scenes that are extremely
                difficult for other methods to handle, it is not particularly efficient
                when rendering simple things such as direct illumination (which is more easily
                handled by a brute-force type algorithm). By default, the
                implementation in Mitsuba therefore delegates this to such a method
                (with the desired quality being controlled by the <tt>directSamples</tt> parameter).
                In very rare cases when direct illumination paths are very difficult to find,
                it is preferable to disable this separation so that PSSMLT is responsible
                for everything. This can be accomplished by setting
                <tt>directSamples=-1</tt>.</p>
        </descr>
        <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.
            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
           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
           force PSSMLT to be responsible for the direct illumination
           component as well, set this parameter to <tt>-1</tt>.
       </param>
       <param name="twoStage" readableName="Two-stage MLT" type="boolean" default="false">
           Use two-stage MLT? Please see the documentation for details.
        </param>
        <param name="luminanceSamples" readableName="Luminance samples" type="integer" default="100000" importance="1">
            MLT-type algorithms create output images that are only
            <em>relative</em> The algorithm can e.g. determine that a certain pixel
            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.
        </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
            with a completely new one. Usually, there is little need to change
            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).
        </param>
        <param name="timeout" readableName="Timeout" type="integer" default="0">
            Rendering budget in seconds
        </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
            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
            algorithms and a list of caveats that also apply to this plugin.</p>

            <p>Like PSSMLT, this integrator explores the space of light paths,
            searching with preference for those that carry a significant amount of
            energy from an emitter to the sensor. The main difference is that PSSMLT
            does this exploration by piggybacking on another rendering technique and
            "manipulating" the random number stream that drives it, whereas MLT does
            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
            information about the problem to be solved, which allows it to perform a
            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
            manifold perturbation proposed by Jakob and Marschner.</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.
            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
           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
           force MLT to be responsible for the direct illumination
           component as well, set this parameter to <tt>-1</tt>.
       </param>
       <param name="twoStage" readableName="Two-stage MLT" type="boolean" default="false">
           Use two-stage MLT? Please see the documentation for details.
        </param>
        <param name="luminanceSamples" readableName="Luminance samples" type="integer" default="100000" importance="1">
            MLT-type algorithms create output images that are only
            <em>relative</em> The algorithm can e.g. determine that a certain pixel
            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.
        </param>
        <param name="bidirectionalMutation" readableName="Bidirectional mutation" type="boolean" default="true" importance="1">
            Selectively enable/disable the bidirectional mutation
        </param>
        <param name="lensPerturbation" readableName="Lens perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the lens perturbation
        </param>
        <param name="causticPerturbation" readableName="Caustic perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the caustic perturbation
        </param>
        <param name="multiChainPerturbation" readableName="Multi-chain perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the multi-chain perturbation
        </param>
        <param name="manifoldPerturbation" readableName="Manifold perturbation" type="boolean" default="false" importance="1">
            Selectively enable/disable the manifold perturbation
        </param>
        <param name="probFactor" readableName="Probability factor" type="float" default="50" importance="1">
            Probability factor ("lambda") of the manifold perturbation
        </param>
        <param name="timeout" readableName="Timeout" type="integer" default="0">
            Rendering budget in seconds
        </param>
    </plugin>

    <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.
                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
            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
            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.
            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">
            Specifies the number of Markov Chains that, on average, are
            started per pixel
        </param>
        <param name="maxChains" readableName="Max. number of chains" type="integer" default="0">
            Specifies a limit for the number of chains that will be started at
            a pixel. '0' disables this option.
        </param>
        <param name="chainLength" readableName="Mutations per chain" type="integer" default="100">
            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
           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
           force ERPT to be responsible for the direct illumination
           component as well, set this parameter to <tt>-1</tt>.
       </param>
        <param name="luminanceSamples" readableName="Luminance samples" type="integer" default="15000" importance="1">
            Number of samples used to estimate the average contribution of a
            single sample. Usually, this parameter can be left untouched.
        </param>
        <param name="bidirectionalMutation" readableName="Bidirectional mutation" type="boolean" default="false" importance="1">
            Selectively enable/disable the bidirectional mutation
        </param>
        <param name="lensPerturbation" readableName="Lens perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the lens perturbation
        </param>
        <param name="causticPerturbation" readableName="Caustic perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the caustic perturbation
        </param>
        <param name="multiChainPerturbation" readableName="Multi-chain perturbation" type="boolean" default="true" importance="1">
            Selectively enable/disable the multi-chain perturbation
        </param>
        <param name="manifoldPerturbation" readableName="Manifold perturbation" type="boolean" default="false" importance="1">
            Selectively enable/disable the manifold perturbation
        </param>
        <param name="probFactor" readableName="Probability factor" type="float" default="50" importance="1">
            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).
        </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.
            It is included mainly for completeness, though some rare situations
            may warrant its use.</descr>
    </plugin>

    <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
            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)
        </descr>
    </plugin>

    <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
            occasionally introduce too much blurring.
            When no reconstruction filter is explicitly requested, this is the default
            choice in Mitsuba.
        </descr>
        <param name="stddev" readableName="Standard deviation" type="float" default=".5">Standard deviation of the Gaussian</param>
    </plugin>

    <plugin type="rfilter" readableName="Mitchell-Netravali filter" name="mitchell" show="true" className="MitchellNetravaliFilter" extends="ReconstructionFilter">
        <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
            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>
        <param name="B" readableName="B parameter" type="float" default="0.33333">B parameter from the paper</param>
        <param name="C" readableName="C parameter" type="float" default="0.33333">C parameter from the paper</param>
    </plugin>

    <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
            constants <tt>B</tt> and <tt>C</tt> adjusted to produce higher sharpness at the
            cost of increased susceptibility to ringing.
        </descr>
    </plugin>

    <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).
            This is also the computationally slowest reconstruction filter.</p>

            <p>This plugin has an <tt>integer</tt>-valued parameter named <tt>lobes</tt>, that
            sets the desired number of filter side-lobes. The higher, the closer
            the filter will approximate an optimal low-pass filter, but this also
            increases the susceptibility to ringing. Values of 2 or 3 are common (3 is the default).</p>
        </descr>
        <param name="lobes" readableName="Number of lobes" type="integer" default="3">Number of filter lobes</param>
    </plugin>

    <plugin type="sampler" name="independent" readableName="Independent sampler" show="true" className="IndependentSampler" extends="Sampler">
        <descr>
            <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
            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
            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
            specific sampler and refuse to work otherwise.</p>
        </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
            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>
        </descr>
        <param name="sampleCount" readableName="Samples per pixel" type="integer" default="4">
            Number of samples per pixel; should be a perfect square (e.g. 1, 4, 9, 16, 25, 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 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
            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
            by Kollig and Keller.
            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
            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
            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
        </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
            increase both storage and computational costs.
        </param>
    </plugin>

    <plugin type="sampler" name="hammersley" readableName="Hammersley QMC sampler" show="true" className="HammersleySequence" extends="Sampler">
        <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
            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
            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>
        <param name="scramble" readableName="Scramble value" type="integer" default="-1">
            This plugin can operate in one of three scrambling modes:
            <ul>
                <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
                Faure, which has better equidistribution properties
                in high dimensions.</li>

                <li>
                When set to a value greater than one, a random permutation is chosen based
                on this number. This is useful to break up temporally coherent noise when rendering
                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.
        </param>
    </plugin>

    <plugin type="sampler" name="halton" readableName="Halton QMC sampler" show="true" className="HaltonSequence" extends="Sampler">
        <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
            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
            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
            and/or machines.</p>

            <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
            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'
            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>
        <param name="scramble" readableName="Scramble value" type="integer" default="-1">
            This plugin can operate in one of three scrambling modes:
            <ul>
                <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
                Faure, which has better equidistribution properties
                in high dimensions.</li>

                <li>
                When set to a value greater than one, a random permutation is chosen based
                on this number. This is useful to break up temporally coherent noise when rendering
                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.
        </param>
    </plugin>


    <plugin type="sampler" name="sobol" readableName="Sobol QMC sampler" show="true" className="SobolSampler" extends="Sampler">
        <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
            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 Sobol sequence in particular provides a relatively good point set that can
            be computed extremely efficiently. One downside is the susceptibility to pattern artifacts
            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
            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
            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'
            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
            noise patterns. For stills, this parameter is irrelevant. When rendering an animation,
            simply set it to the current frame index.
        </param>
    </plugin>
</documentation>
