minor

include/mitsuba/render/trimesh.h

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

src/integrators/SConscript

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

src/integrators/path/volpath_simple.cpp

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

src/librender/shape.cpp

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

src/medium/materials.h

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

src/mtsgui/rendersettingsdlg.cpp

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

src/mtsgui/resources/docs.xml

@@ -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 
+			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). 
+			"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 
+			cache is queried for the indirect illumination at the surface position in
-			question. If this query is successful, the sub-integrator is only 
+			question. If this query is successful, the sub-integrator is only
-			used to compute the remaining types of radiance (direct, in-scatter, 
+			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 
+			improve the achieved interpolation quality, namely irradiance gradients
-			[Ward et al.], neighbor clamping [Krivanek et al.], a screen-space 
+			[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 
+		   Should neighbor clamping [Krivanek et al.] be used? This
-		   propagates geometry information amongst close-by samples 
+		   propagates geometry information amongst close-by samples
-		   and generally leads to better sample placement. 
+		   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 
+			Adaptive integrator - runs a secondary integrator until the
-			the computed radiance achieves a specifiable relative error 
+			the computed radiance achieves a specifiable relative error
-			threshold (5% by default) with a certain probability (95% by default). 
+			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 
+			While not entirely rigorous in the statistical sense, this provides a
-			useful stopping criterion. 
+			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 
+				sampling technique works very well on glossy objects but does badly
-				everywhere else, while the opposite is true for the emitter sampling 
+				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 
+				<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 
+				it is also possible to turn this plugin into an emitter sampling-only
 				or BSDF sampling-only integrator.</p>
 
 				<p>For best results, combine the direct illumination integrator with the
 				low-discrepancy sample generator. Generally, the number
-				of pixel samples of the sample generator can be kept relatively 
+				of pixel samples of the sample generator can be kept relatively
 				low (e.g. <tt>sampleCount=4</tt>), whereas the emitter and BSDF sample
 				parameters of this integrator should be increased until the variance in
 				the output renderings is acceptable.</p>
@@ -181,11 +181,11 @@
 			situations where a light ray impinges on an object from a direction that is classified as "outside"
 			according to the shading normal, and "inside" according to the true geometric normal.</p>
 			<p>The <tt>strictNormals</tt>
-			parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on") 
+			parameter specifies the intended behavior when such cases arise. The default (<tt>false</tt>, i.e. "carry on")
 			gives precedence to information given by the shading normal and considers such light paths to be valid.
 			This can theoretically cause light "leaks" through boundaries, but it is not much of a problem in practice.</p>
 			<p>When set to <tt>true</tt>, the path tracer detects inconsistencies and ignores these paths. When objects
-			are poorly tesselated, this latter option may cause them to lose a significant amount of the incident 
+			are poorly tesselated, this latter option may cause them to lose a significant amount of the incident
 			radiation (or, in other words, they will look dark).
 			The bidirectional integrators in Mitsuba (BDPT, PSSMLT, MLT, ..)
 			implicitly have <tt>strictNormals</tt> activated. Hence, another use of this parameter
@@ -198,11 +198,11 @@
 		<descr>
 			This integrator implements a basic path tracer with multiple importance sampling and is a <em>good
 			default choice</em> when there is no strong reason to prefer another method.
-			It does not account for participating media, such as fog or smoke&mdash;see 
+			It does not account for participating media, such as fog or smoke&mdash;see
 			the volumetric path tracer if this is needed.
 		</descr>
 	</plugin>
- 
+
 	<plugin type="integrator" name="volpath_simple" readableName = "Volumetric path tracer (Simple)"
 			show="true" className="SimpleVolumetricPathTracer" extends="MonteCarloIntegrator">
 		<descr>
@@ -221,10 +221,10 @@
 			show="true" className="VolumetricPathTracer" extends="MonteCarloIntegrator">
 		<descr>
 			This plugin provides a volumetric path tracer that can be used to
-			compute approximate solutions to the radiative transfer equation. 
+			compute approximate solutions to the radiative transfer equation.
 			Its implementation makes use of multiple importance sampling to
-			combine BSDF and phase function sampling with direct illumination 
+			combine BSDF and phase function sampling with direct illumination
-			sampling strategies. On surfaces, this integrator behaves exactly 
+			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 
+			<p>When rendering with a finite-aperture sensor
-			this integrator is able to intersect the actual aperture, which allows it to 
+			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 
+			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). 
+			"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 
+			<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> 
+			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 
+			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 
+			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). 
+			"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 
+			this number. For good results, use between 2-4 samples along with the
-			low-discrepancy sampler. Once started, the rendering process continues indefinitely 
+			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 
+			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). 
+			"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. 
+			<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 
+			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 
+			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, 
+			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 
+			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). 
+			"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 
+			technique that handles all sampling strategies, including those that involve
-			direct interactions with the sensor. For this purpose, finite-aperture sensors 
+			direct interactions with the sensor. For this purpose, finite-aperture sensors
-			are explicitly represented by surfaces in the scene so that they can be 
+			are explicitly represented by surfaces in the scene so that they can be
 			intersected by random walks started at emitters.</p>
 
 			<p>Bidirectional path tracing is a relatively "heavy" rendering technique&mdash;for
@@ -444,19 +444,19 @@
 
 			<p>The code parallelizes over multiple cores and machines, but with one caveat:
 			some of the BDPT path sampling strategies are incompatble with the usual
-			approach of rendering an image tile by tile, since they can potentially 
+			approach of rendering an image tile by tile, since they can potentially
 			contribute to <em>any</em> pixel on the screen. This means that each
 			rendering work unit must be associated with a full-sized image!
 			When network render nodes are involved or the resolution of this <em>light image</em>
-			is very high, a bottleneck can arise where more work is spent accumulating or 
+			is very high, a bottleneck can arise where more work is spent accumulating or
 			transmitting these images than actual rendering.</p>
 
 			<p>There are two possible resorts should this situation arise: the first one
-			is to reduce the number of work units so that there is approximately one 
+			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 
+			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> 
+			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 
+			parameter to the <tt>mitsuba</tt> executable. The second option is to simply
-			disable these sampling strategies at the cost of reducing the 
+			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 
+			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). 
+			"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, 
+				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 
+				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 
+				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 
+				<p>The PSSMLT implementation in Mitsuba can operate on top of either a simple
-				unidirectional volumetric path tracer or a fully-fledged bidirectional path 
+				unidirectional volumetric path tracer or a fully-fledged bidirectional path
-				tracer with  multiple importance sampling, and this choice is controlled by the 
+				tracer with  multiple importance sampling, and this choice is controlled by the
-				<tt>bidirectional</tt> flag. The unidirectional path tracer is generally 
+				<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 
+				on an additional Monte Carlo estimator to recover this scale factor. By
-				default, it uses 100K samples (controlled by the <tt>luminanceSamples</tt> 
+				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 
+				<p>In this mode of operation, the renderer first creates a low-resolution
-				version of the output image to determine the approximate distribution of 
+				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 
+	       By default, this plugin renders the direct illumination component
-	       separately using an optimized direct illumination sampling strategy 
+	       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 
+			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). 
+			"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 
+	       By default, this plugin renders the direct illumination component
-	       separately using an optimized direct illumination sampling strategy 
+	       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 
+			<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 
+			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 
+	       By default, this plugin renders the direct illumination component
-	       separately using an optimized direct illumination sampling strategy 
+	       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 
+			When creating seed paths, this parameter specifies the minimum path depth, after which the
-			implementation will start to use the 
+			implementation will start to use the
-			"russian roulette" path termination criterion (set to <tt>-1</tt> to disable). 
+			"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 
+		<descr>Box filter: the fastest, but also about the worst possible
-			reconstruction filter, since it is extremely prone to aliasing. 
+			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 
+			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 
+			high-quality output. Its main disadvantage is that it produces strong ringing around
-			discontinuities, which can become a serious problem when rendering bright objects 
+			discontinuities, which can become a serious problem when rendering bright objects
-			with sharp edges (for instance, a directly visible light source will have black 
+			with sharp edges (for instance, a directly visible light source will have black
-			fringing artifacts around it). 
+			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 
+			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 
+			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 
+			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 
+			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 
+			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 
+			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 
+			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 
+			<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 
+			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 
+			<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 
+			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 
+			using numbers generated by a Mersenne Twister pseudorandom number generator
-			Note that due to internal storage costs, low discrepancy samples are only provided 
+			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 
+			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 
+			<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 
+			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 
+			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 
+			<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 
+			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 
+			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. 
+			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 
+			<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 
+			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 
+			Because everything that happens inside this sampler is completely deterministic and
-			independent of operating system scheduling behavior, subsequent runs of Mitsuba will always 
+			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 
+			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 
+			rendering might fail with the following error message: <tt>Lookup dimension
-			exceeds the prime number table size! You may have to reduce the 'maxDepth' 
+			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 
+			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. 
+			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 
+			<p>Because everything that happens inside this sampler is completely
-			deterministic and independent of operating system scheduling behavior, subsequent 
+			deterministic and independent of operating system scheduling behavior, subsequent
-			runs of Mitsuba will always compute the same image, and this even holds when rendering 
+			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 
+			rendering might fail with the following error message: <tt>Lookup dimension
-			exceeds the direction number table size! You may have to reduce the 'maxDepth' 
+			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>