Short Contents

7.10 Exclusive Output Variables


IMPORTANT

Although this functionality is still implemented and useful in some occasions, we consider that the display subsets feature (see section Display Subsets) supersedes exclusive output variables and offer even more flexibility.



By Moritz Moeller
3Delight possesses the ability of rendering data to an arbitrary number of so called "secondary displays", usually image files on disk. These displays are fed with certain variables from shaders attached to the geometry. Since any variable in a shader can be used to output data this way, they are also called "Arbitrary Output Variables" or AOVs for short(56).
The main use of AOVs is decomposing the inner workings of a shader for later recombination in a compositing package, where each AOV can be altered rather quick (compared to the time it would require to re-render a "beauty" image containing all of them combined into a final and more or less fixed result).
However, AOVs come with two problems. Firstly, every shader that doesn't write to an AOV explicitly is treated as implicitly rendering black to it. Thus, if you had, say, a furry creature and you wanted to render a diffuse pass for the creature's skin and its fur each, respectively, the skin geometry would correctly occlude the fur on the back of the creature and the fur geometry would correctly occlude any skin of which it was in front of. When you add those two AOVs together in a compositing package, not using any alpha channel at this stage yet, you get the exact same image as if you had rendered them into one image.

Commonly, one stage in compositing is all about adjusting black and white points, gain, gamma and color correction of image data. In the described example, this might give edge issues with geometry like fur. Particularly with many AOVs that make up a single element this requires a lot of precautions and even then, artifacts will often show up (think of several specular-, diffuse- and translucency AOVs making up the fur with each element requiring individual adjustments in the compositing package). To circumvent this problem altogether one can ask 3Delight not to matte certain AOVs. This is done with the `exclusive' flag (see Table 5.1). This flag is accepted by the RiDisplay and RiDisplayChannel calls. When set to `1', the respective display (channel) will not be matted by any other AOV. Still, certain objects might matte such an "exclusive" AOV, if they have the RiMatte attribute switched on and output the AOV. To suppress even those objects from matting an AOV, 3Delight supports a `matte' flag for RiDisplay and RiDisplayChannel. A totally unmatted AOV can be produced by setting `matte' to `0' and `exclusive' to `1'.

The second problem that arises is that certain AOVs contain geometry that requires an alpha channel different from the primary display's alpha. One could of course just output another single channel AOV with the coverage information of each AOV that might need an individual alpha in compositing. For your convenience, 3Delight provides a shortcut for this: the calculatealpha flag, supported by the Display, when set to `1', will add a correctly identified(57) alpha channel to the display(58).

To complete the set of features that make a compositor's life a happier one, 3Delight provides a way to produce images with unassociated alpha. It is called "associatealpha" and has to be turned off by setting it to 0, to get unmultiplied output. The AOVs that the renderer then produces are ready to be adjusted in the target compositing application, with the requirement removed, of dividing them by their alpha first. For example, in Apple's Shake, this means you can skip the MDiv node behind each FileIn node that loads AOVs produced by 3Delight.

3Delight 10.0. Copyright 2000-2011 The 3Delight Team. All Rights Reserved.