Skip to content

Change transmission_scatter to control scatter albedo directly #275

@portsmouth

Description

@portsmouth

We have discussed this on Slack a bit previously, but the existing transmission_scatter parametrization is quite unintuitive. I'd like to propose we improve it for v1.2, as we still have a window to do it.

I was looking recently for example at making a volume (with grey transmission_color components 0.8) satisfy the white furnace test. We state in the spec that this requires transmission_scatter (1, 1, 1). But in fact, any (grey) transmission_scatter $\ge \ln$ transmission_color = (0.223.., 0.223.., 0.223..) works. What happens is that the absorption is made zero when (*) $\mathbf{S} = -\ln\mathbf{C}$, and for higher $\mathbf{S}$ the absorption stays zero but the extinction changes to compensate, so the volume starts getting denser. So the density of the volume is dependent on the scattering color.

(*) with $\mathbf{C}$=transmission_color and $\mathbf{S}$=transmission_scatter.

I show below the behavior of the current volume compared to dense SSS, with:

  • transmission_depth 0.11157, transmission_color (0.8, 0.8, 0.8) (so extinction is 2 for $\mathbf{S} \le 0.223$). This is a sort of typical intermediate density volume, for a thick liquid etc.
  • subsurface_radius 0.01 (so extinction is 100), so very dense volume as SSS is designed for.

for various "scatter color" (i.e. transmission_scatter for volume or subsurface_color for SSS) of the form (R, 0.5, 0), plus white furnace tests.

For comparison, in the "volume (proposed)" column I show the result of making the transmission_scatter color define the (single-scattering) albedo of the volume directly:

scatter color dense SSS volume (current) volume (proposed)
(1,1,1) Image Image Image
(0.223, 0.233, 0.223) Image Image Image
(0, 0.5, 0) Image Image Image
(0.223, 0.5, 0) Image Image Image
(0.5, 0.5, 0) Image Image Image
(0.75, 0.5, 0) Image Image Image
(1, 0.5, 0) Image Image Image

Commentary:

  • Note that the furnace test for the current volume passes even with transmission_scatter (0.223, 0.223, 0.223). So for example for grey volumes, the current parametrization appears to do not much (to the color) if the channels exceed this value, rather oddly. (Actually, it gets darker as the grey value increases, due to the extinction increasing requiring higher ray depth to get a passing furnace test).

  • The dense SSS color is essentially the same as the user selected transmission_scatter color, which we enforce in the spec. The selected color of the SSS and the (much thinner) volume generally match better with the albedo parametrization, except at very high albedo. This presumably is just the physical effect of the high albedo in the red channel at some point making it much more likely for the red channel to escape.

  • In contrast, the current volume parametrization is always much brighter and more saturated than the selected color. This happens because the extinction (of all channels) is being increased (if any channel value > 0.223), which leads to a more saturated color as the rays are less likely to escape.

  • With the proposed parametrization, the requested extinction (i.e. density) is exactly the same in all cases (e.g. see the SSS bars). Whereas with the current one, it varies with the transmission_scatter color, so the density is not independent of the color, which I think is obviously a bad property.

  • For OpenPBR Volume, we will have the albedo color specified directly, so the proposed change would be more consistent with that.

  • The spec is also inconsistent currently since transmission_scatter color should be allowed to have components exceeding 1. But, we have it clamped to $[0,1]$ range explicitly in the parameters. Having the color of a volume allowed to be an HDR value seems unintuitive, but in the current setup it should be allowed as it is not an albedo (it simply defines an arbitrary scattering coefficient, after division by the depth). Making it an albedo would make that clamping correct.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions