Path Tracer

This integrator implements a basic path tracer and is a good default choice when there is no strong reason to prefer another method.
To use the path tracer appropriately, it is instructive to know roughly how it works: its main operation is to tracemany light paths using randomwalks starting fromthe sensor. A single randomwalk is shown below, which entails casting a ray associated with a pixel in the output image and searching for the first visible intersection. A new direction is then chosen at the intersection, and the ray-casting step repeats over and over again (until one of several stopping criteria applies).
At every intersection, the path tracer tries to create a connection to the light source in an attempt to find a complete path along which light can flow from the emitter to the sensor. This of course only works when there is no occluding object between the intersection and the emitter.
This directly translates into a category of scenes where a path tracer can be expected to produce reasonable results: this is the casewhen the emitters are easily “accessible” by the contents of the scene.
For instance, an interior scene that is lit by an area light will be considerably harder to render when this area light is inside a glass enclosure (which effectively counts as an occluder).
Like the direct plugin, the path tracer internally relies on multiple importance sampling to combine BSDF and emitter samples. The main difference in comparison to the former plugin is that it considers light paths of arbitrary length to compute both direct and indirect illumination.
For good results, combine the path tracer with one of the low-discrepancy sample generators (i.e. ldsampler, halton, or sobol).
Strict normals: 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.
The strictNormals parameter specifies the intended behavior when such cases arise.The default (false, 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.
When set to true, 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 strictNormals set to true. Hence, another use of this parameter is to match renderings created by these methods.

• This integrator does not handle participating media
• This integrator has poor convergence properties when rendering caustics and similar effects. In this case, bdpt or one of the photon mappers may be preferable.


  • Max. path depth : integer
    • Specifies the longest path depth in the generated output image (where -1 corresponds to ∞). A value of 1 will only render directly visible light sources. 2 will lead to singlebounce (direct-only) illumination, and so on. (Default: -1 -> 24 @ blender)

  • Russian roulette starting depth : integer
    • Specifies the minimum path depth, after which the implementation will start to use the “russian roulette” path termination criterion. (Default: 5 -> 10 @ blender)

  • Strict Normals : boolean
    • Be strict about potential inconsistencies involving shading normals? See the description below for details. (Default: no, i.e. false)

  • Hide Emitters : boolean
    • Hide directly visible emitters? See page 149 for details. (Default: no, i.e. false)

  • 最終更新:2014-05-20 15:27:40