Should opacity input on node "surface" be color instead of float

[niklasharrysson]

As pointed out by @code-monkey in this issue (https://github.com/Autodesk/standard-surface/issues/20), the surface node in MaterialX pbrlib only supports monochromatic opacity with a float input. In order to support colored opacity we should consider chaining this to a color3 input.

[niklasharrysson]

When we designed the Physically Based Shading nodes our thinking was for the opacity on surface to only be used for cutout opacity or "presence", to mask out surface details by texturing, and not to be used for colored transmission. So conceptually a geometry feature rather than a shading feature.

To simulate things like colored / stained glass we thought proper transmission would be used instead, since normally you want coloring/darkening dependent on depth through absorption, as well as refraction effects. So for the cutout opacity we used a float for simplicity and efficiency.

However, Mark is right that there are use-cases out there where a colored cutout opacity is supported. Autodesk Standard Surface is one example.

There are a couple of issues I see with changing what we have to support colored opacity this way:

• Controlling colored transmission using opacity is not very artist friendly, as opacity gives complementary colors with regards to transmission, you might get unexpected results. Using proper transmission with a dielectric BSDF instead is more artist friendly and gives additional controls for refraction and absorption.

• Cutout opacity in MDL is monochromatic, so the MaterialX/MDL back-end would have to be changed, simulating this through a transmissive BSDF instead (I'm not sure how that would affect performance). Or the MDL spec would have to be changed along with the MaterialX spec.

• The GLSL and OSL back-ends would have to be updated as well of course, but that's a smaller fix since it's supported in the languages there.

But it would be interesting to hear about other use-cases for colored opacity, if there are cases where real transmission is not a good option?

One possibility would be to change the MaterialX nodegraph for Standard Surface, to use a transmissive BSDF there to simulate this. Then at least we would support what the Standard Surface spec supports, but we avoid making colored opacity available everywhere in MaterialX (that is if we agree it's not a good direction to go).

[code-monkey]

But it would be interesting to hear about other use-cases for colored opacity

Many renderers use opacity to compute shadow color. If you want colored shadows, you need colored opacity. You can always convert a color to a scalar if needed.

[niklasharrysson]

Thanks Mark for the additional details.

Colored shadows are rendered by the transmission lobe as well though. And in my experience it's easier to control compared to colored opacity. Here's an example to illustrate what I mean:

As shown in image 1 and 2, when working with opacity you first need to find and set the complementary color of the look you want. With transmission it's straight forward to set the transmission color. If you don't want refractions, supported by the transmission lobe, you can switch to thin-walled mode, as seen in image 3.

In addition, with opacity you get problems with coloring of the other shading components. In image 4 I've enabled the diffuse lobe and set 50% cyan opacity on the left sphere and 50% red transmission on the right sphere. The cyan color gets mixed into the diffuse lighting on the left sphere, a hint of this is seen on the lower part of the sphere. The effect is more clear if I disable the white environment, as seen in image 5.

The problem is that opacity, the color, is multiplied in with all other shading contributions from layers below (marked in red in the standard surface graph below). For transmission on the other hand only the transmission float weight is multiplied in (marked in green in the graph), and not the transmission color, so there is no complementary coloring there.