Volume opacity/attenuation coefficient definition about anari-docs HOT 8 CLOSED

See also the attenuation features in glTF which expresses $\mu$ indirectly through attenuation distance and color. https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_materials_volume/README.md#attenuation

from anari-docs.

I think opacity is more related to $T$ than to $\mu$, with some implicit assumptions about the integration distance, because that is how traditionally the volumes were rendered.

Regardless, I recommend to consistently (i.e., physically based) define the behavior within ANARI, even if this breaks with some SciVis traditions (but provide means to compensate). Concretely: Different SpatialFields (e.g. structuredRegular with different size or spacing or filter, or a yet to come unstructured Field with different cell forms and sizes), all representing the same constant scalar value (i.e. being homogeneous) in the same world-space bounds, combined with the same TFN should result in the same appearance. What then directly follows is

• the (implicit, or maybe explicit) "distance" is in world-space, just like with glTF
• scaling a volume with an instance transform will change its appearance

from anari-docs.

inspired by this: https://github.com/KhronosGroup/glTF/tree/main/extensions/2.0/Khronos/KHR_materials_volume#attenuation

Volume shading follows Beer's law:

$T = e^{-\int_0^l\sigma_t(z)dz}$

We define the attenuation coefficient as gltf does: $\sigma_t = log(color)/d$ where d is the attenuation distance.

The question is now where does d come from and how does opacity/alpha interact with it? The simple answer: We add it as a parameter (attenuationDistance of FLOAT32) instead of trying to come up with some convention and we maintain consistency with the pbr material. Opacity gets premultiplied into the color which maintains it's "linear" behavior after integration.

$\sigma_t = log(color*opacity)/d$

I still have to convince myself that this is equivalent to what our current implementations do but I think this is broadly speaking the way and the main question is where exactly opacity needs to be included.

from anari-docs.

I think the attenuation coefficient should actually be:

$\sigma_t = log(color*opacity + white*(1-opacity))/d$

in the formula from the gltf documentation color is the attenuation color which is defined as:

The color that white light turns into due to absorption when reaching the attenuation distance.

And the common interpretation of opacity is that an opacity of 1 applies the color and 0 is transparent. Meaning at opacity 0 white light turns into white light.

from anari-docs.

This only deals with attenuation but not with how light is emitted or reflected off volume elements. The easiest way to accomodate those would be to also have emission and scattering coefficient parameters. The emission at any point in the volume would then be color*emissionCoefficient and the scattering would be color*light*scatteringCoefficient.

Where it would then be up to the device to decide if emission just means emission into the current ray direction or if it means it also acts as a light source illuminating itself and/or the environment. Similarly the light in the scattering could include only direct lighting, shadows or even attenuated light (self shadowing of the volume). Similar to how it is up to the device to implement shadows for surface scattering.
Where appropriate renderers could provide switches to configure this down as required. For example If one wanted a paraview style scivis volume in a path tracer one would probably want to disable self illumination and shadowing.

from anari-docs.

Here is how OSPRay is interpreting the volume and TFN.
The SciVis renderer uses ray marching and the more "classic" SciVis interpretation: a weighted blend of color and opacity, i.e., color is "emissive" and the volume is visible regardless of illumination or background color (although opacity is modified similar to above, using Beer's law and taking the distance between samples and the densityScale parameter into account). The volume transmittance is affecting lights, thus the volume casts a shadow (but no self-shadowing, b/c "emissive").
The Path Tracer uses free-path sampling and delta-tracking and a more physically-based interpretation: opacity is a proxy of the volume's density and the color is seen as the albedo of a scattering function. Thus the volume is affected by illumination and shows self-shadowing.

SciVis	Path Tracer

from anari-docs.

I updated PR #97 according to the WG discussion. I hope I got the forward blending algorithm correct this time.

I always stumble over this sentence:

The values in the color and opacity arrays are assumed to be uniformly distributed within valueRange

It's not the values that are uniformly distributed but their "sample locations", right? What is the correct wording there?

from anari-docs.

Some experiments. First is just changing OSPRay's pathtracer to interpret color as emissive: looks more consistent to scivis (but as expected, illumination and self-shadowing is not present anymore).

SciVis	Path Tracer

OSPRay interprets the TFN opacity directly as absorption cross section (density); changing that to the proposal of the PR (combining with an "attenuationDistance") leads to a subtle difference, emphasizing dense (more opaque) parts (better visible when flipping back and forth vs. above images).

SciVis mu	Path Tracer mu

from anari-docs.