# MaterialX / glTF / USD material interop

**URL:** <https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500>\
**Category:** USD\
**Created:** [August 29, 2023, 6:15pm UTC](https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500 "2023-08-29T18:15:53Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![bernardkwok](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/bernardkwok/32/172_2.png) [@bernardkwok](https://forum.aousd.org/u/bernardkwok)\
**Post date:** [August 29, 2023, 6:15pm UTC](https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500/1 "2023-08-29T18:15:53Z")

</div>

Continuing the discussion from [SIGGRAPH 2023, Open Source Days 2023, etc. Sessions Round-Up](https://forum.aousd.org/t/siggraph-2023-open-source-days-2023-etc-sessions-round-up/366/6)  
which mentions GLTF, MaterialX, and USD in the presentations:

I’m curious what the thoughts are on maintaining this “triplet” in terms of materials, as there can be any or all of these bidirectional transfers occurring depending on workflow:

1. USD ↔ MaterialX
2. USD ↔ glTF
3. MaterialX ↔ glTF

I’d assume you’d want each to be as lossless as possible and kept in sync as much as possible.

Thanks,  
Bernard

---

<div class="post-metadata">

**Author:** ![nporcino](https://avatars.discourse-cdn.com/v4/letter/n/3d9bf3/32.png) [@nporcino](https://forum.aousd.org/u/nporcino)\
**Post date:** [October 28, 2023, 8:41pm UTC](https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500/2 "2023-10-28T20:41:22Z")

</div>

USD can encode more than MaterialX can encode more than glTF. So if there’s a glTF MaterialX file, you could losslessly

gltF → MaterialX → USD

There’s talk of adopting MaterialX into glTF but until such a thing happens, the reverse direction, USD → MaterialX → glTF is strictly a narrowing.

---

<div class="post-metadata">

**Author:** ![trusktr](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/trusktr/32/521_2.png) [@trusktr](https://forum.aousd.org/u/trusktr)\
**Post date:** [April 23, 2024, 8:00pm UTC](https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500/3 "2024-04-23T20:00:06Z")

</div>

Three.js already has a MaterialX loader. A MaterialX extension for glTF sounds exciting! Could that make glTF useful as an _editing_ format more so than just _transmission_?

---

<div class="post-metadata">

**Author:** ![bernardkwok](https://sea2.discourse-cdn.com/flex016/user_avatar/forum.aousd.org/bernardkwok/32/172_2.png) [@bernardkwok](https://forum.aousd.org/u/bernardkwok)\
**Post date:** [April 24, 2024, 8:55pm UTC](https://forum.aousd.org/t/materialx-gltf-usd-material-interop/500/4 "2024-04-24T20:55:07Z")

</div>

You might want to keep an eye on [this extension proposal](https://github.com/KhronosGroup/glTF/tree/KHR_texture_procedurals/extensions/2.0/Khronos/KHR_texture_procedurals) which could feed into ThreeJS shader nodes (or other node systems). Graph editing ability has been stated as a requirement.

This will also minimize narrowing as adherence to only using “standard” MaterialX node definitions is also a requirement.