...

The former would usually use probabilistic hit-testing, where each camera ray would use the (scalar) presence value as a probability to hit the surface, and either result in an actual hit, or a continuation (without a hit). In this case, for each original ray, only one shading event is computed (on the actual hit), although multiple presence evaluations may have happened.

The latter would usually usually use blending-and-continuation. On hitting a surface with (colored) opacity, shading would be computed, and weighted by (1 - opacity). A continuation ray would then be traced from this hit point (carrying a colored weight equal to opacity), and the process repeats, until hitting a surface with full opacity. In this case, for each original ray, multiple shading events may be computed (and special care needs to be taken to prevent a combinatoric explosion of the number of rays and shading events).

In Renderman RenderMan RIS 22, it is possible to use both approaches in all cases, independently of the final opacity being scalar or colored. This means:

...

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

It is also important to consider the effect of caching and view-dependent shading signals. It is not possible to meaningfully cache any presence or opacity values when these depend on the viewing direction (e.g. facing ratio). In case it is attempted the caching of a view-dependent signal, the result will not be deterministic, varying on which ray hit will trigger the evaluation of the opacity for a portion of a surface.

[Historical] Presence vs. Bxdf Continuation

...