Look / Variant authoring in USD or MaterialX

[swillisart]

Hello, I'm looking to start a discussion on the direction Maya-USD is taking on the implementation of material assignments with "looks" or "variants" support.
(Please let me know if this discussion is better suited for Pixar's USD repository or MaterialX's)

MaterialX has concepts of VariantSet, Collections, Looks... ect.

USD has concepts of Scopes, VariantSets, Shader Connections... ect.

Since they both are able to execute material assignments and looks, is the future of development direction up in the air for this feature or is there already a plan to tackle variable material assignments to USD geometry within Maya?

An example Idea to illustrate:

Enable the USD MaterialX plugin and provide the ability to handle references to .mtlx files for dynamic shader generation per-purpose.
Use MaterialX's GenGLSL to generate shader code for the Proxy Preview in Viewport 2.0, And GenOSL for generating and binding shaders to the render-only geometry representation that Arnold, VRay or PRman can use.

An Asset's ModelVariants are authored entirely in USD.
An Asset's ShadingVariants are authored and bound in a MaterialX file which USD references and exposes to the user & renderer.

The end goal being to enable Maya the ability to represent both render and preview USD-compatible looks in a render-agnostic way which are easily exchangeable based on desired Look from the user.

[kxl-adsk]

Great question, Sean. Our phase 1 of MaterialX support in MayaUSD focused on interop and visualization. Maya's standard surface and preview surface translating in and out of UsdShade with MaterialX node definitions. Such material networks we can then visualize in VP2 directly from USD. We touched more on this and current limitations in https://github.com/Autodesk/maya-usd/blob/dev/doc/MaterialX.md

As you can notice, in interop we didn't yet have to deal with the problem you are describing. Visualization on the other hand is something that can receive mtlx document referenced directly, but here we rely on the USD file format plugin to do the translation and by the time the network gets to Hydra, we don't have to worry about anything else than UsdShade/HdMaterialNetwork.

You mention render-agnostic material networks, but USD brings in as well render context, that is render-specific. It is something we want to understand better how it fits into the translation framework. For example, we can currently translate to preview surface, or Arnold (with limitations), or VRay, or MaterialX. Preview surface lives in the universal render context, where MaterialX and Arnold have their own. What if you want to export to multiple render contexts at once?

Anyway, finally onto material bindings in MaterialX and/or USD. I would hope all the options can be available, and one cold chose to use MaterialX only for material interop (leaving binding to USD), or interop+binding. Which path is the one you would like to take and why?

Cheers,
KxL

[swillisart]

Yes! There have been some very cool progress made in the adsk fork of MaterialX.
From what I could gather from testing is the USD MaterialX export option was creating USD schemas instead of the MaterialX documents themselves as external reference. I may have missed something though.

I think having MaterialX for geometry binding would be necessary to take advantage of it's native texture baking. I agree supporting both USD & MaterialX feature-sets are ideal. I personally lean towards leveraging USD to handle the looks, variants and LOD's and leave graphing, node connections and geometry bindings inside a MaterialX definition file (.mtlx) one file for each look / variant for a given asset.
This way they can also be set as USD payloads so variant textures aren't loaded every time.

As for render contexts I'm not entirely sure I'm familiar enough with that area of USD to speak on the matter outside of a feature request / user perspective.
Most of the production renders support .osl files through their own shading node plugin Arnold OSL node , V-Ray OSL node (which MaterialX is capable of generating .osl) so I'm not sure where or how that can fit into this USD discussion. Perhaps it should be a topic on it's own.

I realize how loaded of a topic this is and I'll work on getting an example workflows together. Having some visual cues and example code may help illustrate the topic better.

If I need elaborate on something further let me know!
-Sean