Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
niklasharrysson opened this issue Oct 7, 2021 · 4 comments
Closed

Comments

@niklasharrysson
Copy link
Contributor

As pointed out by @code-monkey in this issue (Autodesk/standard-surface#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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

colored_opacity1

colored_opacity2

colored_opacity3

colored_opacity4

colored_opacity5

graph

@jstone-lucasfilm
Copy link
Member

Following up on this thread in 2024, I believe Niklas makes a good case above for handling colored shadows using a technique other than colored opacity, and I'll note that the new OpenPBR Surface aligns with MaterialX in using simple float values for opacity.

We're still open to additional discussion on this topic, but for now I'll mark this issue as resolved pending further proposals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants