Some technical details
In this version of the layering shaders, the passes available have the following LPE description. Note that the closest typical pass name follows it in the third column.
| LPE | descriptive name | typical pass name |
|---|---|---|
| "L<RD>E" | "direct_diffuse" (reflection) | "diffuse" |
| "L<R[GS]>E" | "direct_glossy_specular" | "specular"/"highlight" |
| "L<RG>E" | "direct_glossy" | "specular"/"highlight", glossy part |
| "L<RS>E" | "direct_specular" | "specular"/"highlight", specular part |
| "L.+<RD>E" | "indirect_diffuse" | "indirect" |
| "L.+<R[GS]>E" | "indirect_glossy_specular" | "reflection" |
| "L.+<RG>E" | "indirect_glossy" | "reflection", glossy part |
| "L.+<RS>E" | "indirect_specular" | "reflection", specular part |
| "L.+<TD>E" | "diffuse_transmission" | "translucency" |
| "L.+<T[GS]>E" | "indirect_glossy_specular_transmission" | refraction" |
| "L.+<TG>E" | "glossy_transmission" | refraction", glossy part |
| "L.+<TS>E" | "specular_transmission" | "refraction", specular part |
| "<L'front'>.*TV[VR]*TE" | "front_scatter" | |
| "<L'back'>.*TV[VR]*TE" | "back_scatter" | |
| "L.*VE" | ||
| "LaE" | "emission" | |
| "La<RS>E" | ||
| "debug_highlight" | ||
| "debug_reflection" | ||
| "L<RD><TS>+E" | "direct_diffuse_transmitted" | |
| "L<RG><TS>+E" | "direct_glossy_transmitted" | |
| "L<RS><TS>+E" | "direct_specular_transmitted" | |
| "L.+<RD><TS>+E" | "indirect_diffuse_transmitted" | |
| "L.+<RG><TS>+E" | "indirect_glossy_transmitted" | |
| "L.+<RS><TS>+E" | "indirect_specular_transmitted" |
This LPE name may be used exactly as is with the LPE attribute on a framebuffer, or through string options, an alternate descriptive name for any of the above given LPE names can be arbitrarily assigned. If one does not specify by an LPE name, the above descriptive names can be used directly as framebuffer names. This means that any user framebuffer named the descriptive name above will be written automatically by the layering components.
Glossy/Specular highlights (directly visible lights through reflective surfaces) have been a trick in computer graphics when using traditional light loops. In reality, they are a reflection of the light source. But for this to occur in computer graphics with traced reflection rays, the light source must be an area light, ie, not an infinitessimal point, and also set to be visible in the scene. Rendering implmentations that do or do not use light loops can easily confuse terms for users in how to specify what they are used to using. This string options allows defining this more clearly to all the glossy shaders.
Note The "mila use visible area highlight" on/off enables or disables use of the feature. The "mila visible area highlight" string option has a default of -1 which means automatic. In most cases you leave it at that and forget about it.
Here is the logic applied to the option:
Area lights set not to be visible always generate specular highlights, as do any non area lights. This is the same behavior as mia_material has.
The "mila visible area highlight" string option is an extension of the old mia_materials parameter no_visible_area_hl, which ONLY turned specular highlights on/off for visible area lights, and did not change visible area lights reflections in any way.
In contrast, this parameter is actually a proper balancing tool between actual reflections of visible area lights, or doing specular highlights of said lights.
Here are some example images to illustrate the problem caused by sampling visible areas in the two different ways. These images are intentionally rendered with low setting to clearly drive home the issues with grain in the two cases:
As we can see, high gloss and low gloss surfaces have different "good" settings for the "mila visible area highlight" parameter. For this reason, a heuristic setting "-1" exists, which computes the actual value used based on the glossiness. This is useful together with variable glossiness:
