Lighting in PRMan's RIS mode is done via Geometric Area Lights. In a sense, the introduction of Geometric Area Lights in PRMan 18 set the stage for RIS, ceding sample management to the renderer and limiting shader execution for improved efficiency.
Geometric Area Lights can be arbitrary geometry (for emissive effects), but at their core they are meant to mimic typical light sources. They can be distant lights, environment lights, planes, discs, spheres, et cetera.
Specialized Light Geometry
PRMan includes a set of basic geometric lights, built-in. These specialized shapes - envsphere, distantlight, rectlight, and spherelight (particularly the latter two) - can provide superior sampling behavior, compared with arbitrary geometry (i.e. standard geometric primitives with a light Bxdf attached). Note that due to these optimizations, the spherelight requires that all scale transformations on the light geometry be uniform.
In scenes with multiple light sources, the decisions made about the relative frequency with which sources are sampled are crucial in determining how quickly an image converges. The number of light samples taken for a given point being shaded is primarily determined by the numLightSamples parameter of the integrator. These samples are spread among the available lights. Lights which have specified positive fixedsamplecount values to their emit() calls are treated separately, and these samples are in addition to ''numLightSamples''. See Light Sampling for more information about these.
Localization is a set of schemes by which the renderer chooses light samples for lights. Four modes are available in PRMan. Note that any mode other than mode 0 will disable the fixedsamplecount property of lights, causing them instead to be treated the same as all other lights, as described below.
Localization defaults to mode 0 in RIS, and to mode 1 in REYES. The following line in rib allows alternate schemes to be selected:
Option "shading" "int directlightinglocalizedsampling" [n]
where n is one of the following values:
- 0: the default for RIS. Mode 0 is a global scheme, where the choice of lights is independent of any properties of the point being shaded. As such, it is very fast to execute. It cannot, however, determine the relative influence of infinite (environment/distant) and local lights. Instead, samples are evenly divided between groups of the two types. The distribution of samples within each of these groups is done according to the relative power of lights within the group. For the shading of samples inside a volume with equiangular sampling enabled (equiangularWeight is non-zero), modes other than 0 are not yet supported and, and for these points mode 0 will be automatically selected.
- 1: the default for REYES. Mode 1 will compute the relative importance of all lights with respect to the shade point under consideration. As well as power of the lights, distance and orientation are also taken into account. There's a speed cost to this computation. The cost is amortized over all light samples taken for the shade point. In REYES there is typically a large number of light samples per shade point, so this technique performs well. For RIS, where numLightSamples is small, this technique is normally - but not always - too expensive.
- 3. Like mode 1, mode 3 computes the relative importance of all lights with respect to the shade point under consideration. The computations are simpler and faster than those in mode 1, making this mode more suitable for use with RIS, where the number of light samples is typically lower. In nearly all test cases, mode 3 provides an improved image over mode 0 for the same render time. However, its cost means that for some scenes with trivial lighting a faster high-quality image can be achieved with mode 0. For this reason, we do not enable this mode by default.
- 4. Mode 4 is introduced with PRMan 20.0, and is only available in RIS. Rather than computing the relative importance of lights with respect to a shade point, it does so with respect to spherical regions of space, and the results are cached (unlike those of modes 1 and 3, which discard results immediately after use). Subsequent shading points choose the nearest spherical region from which to retrieve light importances. This caching implies both a memory overhead and an acceleration of light-importance calculations over mode 3. In addition, mode 4 uses a learning heuristic, whereby the results of shading are fed back into the system as the render progresses, enabling it to take into account whether or not individual lights are occluded or visible to a cache sphere, and to take into account surfaces' bxdf responses. This latter can be valuable for glossy surfaces where one light is further away than another, but more significant since it lies closer to the reflection direction from the surface. In testing of scenes with moderate to high complexity lighting, we've found mode 4 to be superior to both modes 0 and 3 in terms of quality for equal time renders. In rare cases of simple occlusion you may find mode 3 to be more beneficial, and in cases of basic lighting you may find mode 0 is best.
Note that mode 2 is a deprecated experimental mode, and should not be used.
The importance that a localization scheme assigns to a light can be modified by a per-light multiplier. This is done with the importance parameter to the light's emit() call.
For non-zero localization modes, the influence of lights on a shade point is computed at shutter open time, and does not currently take into account the relative motion between light and shade point. Under very rare circumstances, you may experience artifacts where a light is incorrectly deemed invisible to the shade point for the duration of the shutter-open period. The only recourse in such circumstances currently is to disable localization by setting the option to '0'.
PRMan ships with a set of standard light shaders, built-in:
Camera Visible Lights
Lights may be made visible to the camera, but must also have a Bxdf specified. The PxrLightEmission Bxdf allows lighting values specified with any light shader to automatically be mapped to emission for display, by communicating with the renderer's lighting database.