Incorrect UsdPreviewSurface opacity-metallic interaction

[pablode]

I believe to have stumbled upon a difference between the OpenUSD and MaterialX implementations of the UsdPreviewSurface standard.

In this image, you can see on the left side a native UsdPreviewSurface and on the right side a corresponding MaterialX material with parameters opacity=0.5 and metallic=1.0:

(image rendered with USD dev and MaterialX 1.38.7, but the latest usd_preview_surface.mtlx)

Basically, the difference is that in the MaterialX implementation, the 'metalness' is layered over the transmission BTDF, meaning that when metallic=1.0, the material is opaque regardless of the value of opacity. The UsdPreviewSurface standard says for the opacity input: "[...] if it is smaller than 1.0 then the prim is translucent [...]", which is then not the case. Therefore, I believe this to be a violation of the spec.

I've attached a PoC for OpenUSD here: OpacityMetallicComp.zip

Perhaps this has been overlooked when validating the correctness a while ago? (cc @spiffmon, @klucknav I hope you don't mind)

[jstone-lucasfilm]

@pablode This sounds like the topic that @erich666 and I brought up in an ASWF thread titled "Expected behavior of Transmission effects in UsdPreviewSurface metals":

https://academysoftwarefdn.slack.com/archives/C02HJH53RN3/p1702324085845039

Near the end of the thread, both @klucknav and @spiffmon had a change to weigh in, and I believe the conclusion was that the MaterialX behavior is correct, but some earlier implementations of UsdPreviewSurface still need to be updated to match this behavior.

Let me know if there are any updates beyond this, and we're happy to work with the USD team to make adjustments as needed.

[pablode]

Ah, sorry for missing that - I remember it being largely about “how it should be done” but wasn’t aware of how this topic actually manifests in the wild. Nonetheless, it’s good to have this logged outside of Slack.

In fact, I ran into this issue while rendering a supposedly transparent USDZ-converted asset from Sketchfab. Of course, similar assets will be broken if the spec and OpenUSD implementation get adjusted, unless some explicit versioning is used - which is another can of worms that probably has been discussed a lot and will delay any progress towards alignment of both implementations.

[jstone-lucasfilm]

That's a good point about making this question visible outside of Slack, and I'll post some highlights from the original question and its resolution here:

In shading models such as Autodesk Standard Surface, it's most common for transmission effects to fade out as the metallic slider is moved from zero to one, since there isn't a clear physical interpretation of refraction effects in metals.
In the comparison below, we're seeing the Standard Surface Carpaint material with Transmission set to one, where the top image has Metalness set to Zero and the bottom image has Metalness set to one:

The same approach is currently used in the MaterialX graph for UsdPreviewSurface, and you can see the corresponding comparison for UsdPreviewSurface Carpaint below.
Both of these images have Opacity set to Zero, but the top image has Metallic set to Zero, and the bottom image has Metallic set to One:

The question that Eric Haines and I would like to resolve is whether this behavior is expected in UsdPreviewSurface, or whether transmission effects should persist in metals (despite this being tricky from a physically based shading perspective). The specification for UsdPreviewSurface isn't clear on this point, so we wanted to reach out to Spiff, Karen, and other domain experts for their thoughts.

[jstone-lucasfilm]

Karen Lucknavalai:

I agree I think opacity should not affect metallic materials. We did find some issues with our implementation when verifying the MaterialX spec, unfortunately they have not yet been fixed so the latest usdview would give you the same visuals as you are currently seeing.

Eric Haines:

Oh, good to know, thanks for the update on usdview. I'm glad it's on the radar as something to fix - people (well, me, at least) rely on it for how materials work.

[jstone-lucasfilm]

@pablode I'll go ahead and close this issue for now, but let us know if you believe any changes are needed on the MaterialX side, and we'll follow up.