-
Notifications
You must be signed in to change notification settings - Fork 360
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
Comments
When we designed the Physically Based Shading nodes our thinking was for the opacity on 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:
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). |
Many renderers use opacity to compute shadow color. If you want colored shadows, you need colored opacity. |
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. |
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. |
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.The text was updated successfully, but these errors were encountered: