Support StandardSurface

[DennisSmolek]

I originally put this in the main GLTF repo here but realized the main issue isn't with the procedural graph itself but this conversion script.

In ThreeJS we support both the standard GLTF PBR material AND Standard Surface materials. A significant amount of MaterialX materials are made with the Standard Surface so simply dropping them is a bit disappointing.

So much so I've been playing with doing our own XML > JSON..

We currently don't have a MatX > JSON workflow but as Three is currently moving towards it's own node system (TSL) I figured we'd eventually do TSL > GLTF JSON flow for an export option.

I saw the conversion map function which I guess is actually just a placeholder for the end user but I think a strategy of injecting this node and maybe a flag/marker on it would be ideal. (or just detect this SPECIFIC conversion node) The marker would let conversion/export know what the actual desired matx material was.

Why it matters: Say we had a GLTF like the test chess set with multiple matX materials. If they were all standard surfaces the meshes would all get their materials dropped and while the procedural graphs are all there we have no idea where they map on the inputs of the material and which index goes where.

All of the AMD Sample materials (largest public library I can find) and the PhysicallyBased MaterialX library are with the StandardSurface

---

To get wider adoption MaterialX needs more libraries, editors, loaders, etc that don't take a deep understanding of CMAKE to play with and only supporting ones with GLTFPBR output limits this significantly.

[ashwinbhat]

Hi @DennisSmolek
I wanted to share this OpenPBR announcement that was made around SIGGRAPH 2024. OpenPBR will be the successor to Autodesk Standard Surface and Adobe Standard Material.

In order to provide a path for assets created with Standard Surface, MaterialX provides translation graphs
Standard Surface to OpenPBR that could be used to convert MaterialX documents.

The glTF specification defines glTF PBR as the material model. During WebGL + WebGPU Meetup - March 2024, we shared this roadmap for MaterialX in glTF
https://www.youtube.com/watch?v=bxsQMlymLEw&t=4086s
The first phase of this work is to support use of procedural patterns described using MaterialX and be able to bring them into glTF as an extension and use them with glTF PBR see KhronosGroup/glTF#2381

[DennisSmolek]

In order to provide a path for assets created with Standard Surface, MaterialX provides translation graphs

Standard Surface to OpenPBR that could be used to convert MaterialX documents.

Very cool, the translation graphs will be helpful,and probably something this library should inject automatically when converting to JSON.

Regarding OpenPBR, I attended SIGGRAPH Asia in December and asked during the GLTF BOF where OpenPBR also presented about their GLTF plans, and there is no plans for GLTF itself to support OpenPBR but instead they will share similar algorithms/plans moving forward.

This means for graphs with OpenPBR as the surface shader, we will need to also port from OpenPBR to GltfPBR.

The glTF specification defines glTF PBR as the material model.

While this is true, I don't think the conversion tool(s) should only support graphs with the GltfPBR output.

The extension itself can expect the final node to output as an acceptable shader (gltfPBR, unlit) but I think conversion tools should handle this last step for the user.

So few existing graphs have this now, and with OpenPBR being the standard in the coming future it is unlikely they will then as well.

The near 1,000 graphs currently commonly shared (AMD, PhysicallyBased, etc) are all made with the standard surface so to help with adoption and use it should be expected for users to try and use graphs with different outputs.

---

Although we use a much more basic parser in ThreeJS (we don't use MatX shadeGen) I think we will eventually be creating a converter as well to accommodate web runtimes. With that it would definitely support standard and GltfPBR, I'll work on the OpenPBR with that transition graph!