...

Note that the term opacity has traditionally be used to describe several notions, including presence. In RenderMan RIS, the presence is a separate notion from opacity.

...

It is important to note that in this usage, presence conceptually have has no bearing on light scattering (and vice-versa). Where a material is partially present, its light scattering properties do not change. Instead, this is interpreted as the material scattering less often, with each scatter event being identical to what would happen with a totally present material. Critically, this mean that presence is not a way to model transparent surfaces such as glass, because the light scattering and refractive properties of the glass cannot be modelled by presence alone.

...

Bxdfs wishing to use a non-trivial presence must implement do the following:

• implement the RixBxdfFactory::GetInstanceHints() method and return a bit vector which includes the k_ComputesPresence bit
• implement the RixBxdfFactory::BeginOpacity() method and return a RixOpacity object that implements theRixOpacity::GetPresence() method

The RixOpacity object is bound to a shading context, similarly to a RixBxdf object. RixOpacity::GetPresence() will typically use this shading context (along with any pattern inputs) to return an array of presence values. There are RixShadingContext::numPts presence values in the array. These presence values need to range from 0 to 1 and 0, where:

• 1 is fully present
• 0 is fully absent
• any value in between denotes a probabilistic presence for anti-aliasing

Presence vs. Continuation

When dealing with opaque objects using presence maps, it is usually the case that the objects are either entirely present or not present at all. In practical terms: the presence map is used as a cut-out map, and consists mostly of 0-or-1 values. RenderMan takes advantage of this by combining presence with probabilistic hit-testing, actually interpreting the presence value as the probability that we actually hit a surface.

The compelling advantage of this approach is that for camera rays and indirect rays, the renderer only needs to shade the surface and run the associated bxdf when the surface is actually hit (due to a non-zero presence). This means the renderer doesn't need to institute a policy of automatic continuation rays.

For Presence should not be used for cases where the intention is to model a thin semi-transparent surface (rather than an opaque object), presence shouldn't be used. Instead, the bxdf should generate a transmitted bxdf sample, with the appropriate properties (transmission color for example). Even if those samples are generated in the exact same direction ( as the incoming ray), without refraction (i.e. to model a thin translucency), they have to be generated by RixBxdf::GenerateSample(), which means that the presence needs to be 1. Depending on the intention, this transmitted sample may be generated as a continuation sample.

Cached Presence

RenderMan overs offers an additional service that may improve performances for scene scenes making heavy use of presence (e.g. a forest of trees with presence-mapped leaves). By having RixBxdfFactory::GetInstanceHints() return a bit vector that also includes the k_PresenceCanBeCached bit, the bxdf can request RenderMan to cache presence values. This would prevent re-evaluation of thethe presence values for every ray that intersects the surface.

However, note that as with most of the caching systems, this may introduce bias, manifesting itself as blurred results due to the interpolation from the cached values. Presence caching efficiency is driven by the opacitycachememory setting – a speed vs memory trade-off.

Opacity

As explained in the Presence section, it would be the responsibility of a semi-translucent thin glass-like bxdf to capture light transport across its surface (instead of using presence). However, when it comes to transmission rays, requiring a similar responsibility is problematic for two reasons:

...

Nonetheless, it can be desirable to have a method by which approximate colored shadows can be efficiently produced. These are often preferable to the physically realistic, but noisy, color shadows produced by considering indirect paths. RenderMan allows the bxdf to return an opacity color, which will influence the colors of shadow resulting from tracing transmission rays. An opaque object would yield black shadows, as if returning an opacity of 1 (white)[1 1 1], i.e. white.

Note that opacity:

• only applies to transmission rays
• describe the transmittancetransmittance straight through the surface (no bending)

...

If we were to model the stained glass window as a physically accurate piece of glass, complete with full refraction, then the crepuscular rays (also called god "God rays") shining through the volume would be very expensive to render because the only lighting that could be considered for the volume is entirely indirect; the glass would have to be an opaque object and transmission rays from the volume would not reach the light source.

If we instead model the stained glass window as a thin, non-physically accurate piece of glass with an colored opacity shader, then transmission rays from the volume can now directly reach the light (running the opacity shader of the glass window along the way to get a colored contribution). This allows the scene to be rendered with the direct lighting optimization, which allows for a much faster render.

...

• implement the RixBxdfFactory::GetInstanceHints() method and return a bit vector which includes the k_ComputesOpacity bit
• implement the RixBxdfFactory::BeginOpacity() method and return a RixOpacity object that implements the RixOpacity::GetOpacity() method

The RixOpacity object is bound to a shading context, similarly to a RixBxdf object. RixOpacity::GetOpacity() will typically use this shading context (along with any pattern inputs) to return RixShadingContext::numPts opacity an array of opacity values. These opacity values need be colors, ranging from [0 0 0] (black) to [1 1 1] (white), where each channel is:

• 1 (white) is opaque
• 0 (black) is non-opaque
• any value in between will yield colored transmission shadows (the shadow color is 1 - opacity)
  

...

As with cached presence, RenderMan overs offers an additional service that may improve performances performance for scene scenes making heavy use of opacity (e. g. a forest of trees with presence-mapped leaves). By having RixBxdfFactory::GetInstanceHints() return a bit vector that also includes the k_OpacityCanBeCached bit, the bxdf can request RenderMan to cache opacity values. This would prevent re-evaluation of the opacity values for every ray that intersects the surface.

However, note that as with most of the caching systems, this may introduce bias, manifesting itself as blurred shadows due to the interpolation from of the cached opacity values. Opacity caching efficiency is driven by the opacitycachememory setting --the more memory is allocated to this cache, the more efficient the opacity reuse will be.

Using Both Presence and Opacity

...