MaterialX interchange.... someday

Frieder_Erdmann @Frieder_Erdmann: Has anyone here worked on translating Unreal Nodegraph shaders or Unity’s shadergraph to DCC shaders (Substance/Maya/etc) programmatically and if so how did you go about it?

archo5 @archo5: @Frieder_Erdmann I’ve only created my own shader graph thingy and generated shader code from that (by necessity)
the baseline solution that should work everywhere is going through the nodes manually and generating the necessary code for each node
it might be possible to also copy and modify a part of the respective libraries to skip some part of the work (I assume they can’t be used directly as iirc they both would generate some kind of hlsl and afaict substance/maya both need glsl)
though perhaps if a hlsl->glsl translator is added to the process, the hlsl generated by the engine/package code could be used directly (but it’s hard to say without checking if the input/output model used by the translated shaders will be easy enough to massage into something a DCC accepts)

theodox @theodox: This is supposed to be the goal of MaterialX --but AFAIK nobody’s done the practical part of converting a conceptual materialX graph into concrete examples of either ShaderGraph or UE Shaders

Mark_Sneddon @Mark_Sneddon: as with any standard the goal is pretty smart but without adoption it just falls flat on its face. these kinds of standards have historically never worked that well in games, getting wide adoption is a herculean task

dhruv @dhruv: MaterialX adoption is fairly early but I think it will catch on. It’s being adopted into USD now which encourages adoption of it as the shader abstraction system. DCCs are similarly adopting it for shader authoring.

So it’ll remain up to the engines but I would bet they’d at least support ingest

Frieder_Erdmann @Frieder_Erdmann: Is there any example shaders authored in materialx? The type of shaders we usually build and that make interchange so annoying are the shaders where we provide to the artist only a mask with some channels that’s often on uv2 and everything else is provided/controlled by the shader and lots of math and logic in the shader to make sense of the mask
Of course in the end we always write out the usual PBR Infos to the gbuffer, but the logic before that gets fairly intricate
So materialx would have to support at least most hlsl operations to be able to represent our stuff

dhruv @dhruv: The MaterialX repo has examples and it comes with a GLSL generator

rgkovach @rgkovach: same here, we have alot of custom shaders that do crazy things, layers and blends, non-standard channel usage…

dhruv @dhruv:

Frieder_Erdmann @Frieder_Erdmann: can i get materialx (with its node editor and viewer) prebuild somewhere?
i might sound really stupid here, but is there an existing materialx nodegraph editor somewhere?

dhruv @dhruv: Sort of but not standalone.
There’s a blender extension from AMD, Houdini can do it, Autodesk have LookdevX coming
Substance Designer has an old one that’s outdated now. Not sure why they haven’t updated yet since it’s been years and they’re a big pusher for MaterialX

Frieder_Erdmann @Frieder_Erdmann: thanks!
alright, blender looks pretty useful for this - its just incredibly unstable right now with the amd addon
but at least i feel like i can understand the materialx format a little bit better with that type of visualization :slightly_smiling_face:

dhruv @dhruv: Yeah I wish the tooling was in a better spot.
It’ll happen but it’s chicken and egg

Frieder_Erdmann @Frieder_Erdmann: yeah from what i’ve seen today (thanks to all your links/explanations) i think i can make a rudimentary translator from our own shader graph format to materialx
so i can make our engine a materialx generator
if substance painter and maya/blender can read mtx that would be fantastic
and probably much better than going the route of glsl translations

YouTube Video: GLSL Shaders for Substance Painter with MaterialX

a damn, no idea how i’ve never seen this video before, but this is almost perfectly what i want
if i can generate materialx from our engine and then conform it to what the designer/painter connection wants, it will be fairly easy to get shaders exposed
while being very easily readable/debuggable

dhruv @dhruv: Unfortunately the substance plugin hasn’t seen updates in a while and is using MaterialX 1.37 instead of 1.38 afaik.
But might be possible to update it or ping adobe about it too

Frieder_Erdmann @Frieder_Erdmann: yeah, i think if this would work at all for us, it would be something i’d be willing to push adobe about
but until now i was going down a path of trying to manually figure out the shaders from our engine hlsl to glsl and that’s fairly painful and a lot of dependencies
while this seems like a pretty well contained step

How does materialX handles features found on a render engine and not the others?

For instance, Renderman RIS standard surface shaders allow for bump roughness or separates diffuse bump, specular bump, etc…
Features which don’t exist on Arnold.

Will MaterialX only allow for basic channels to make sure the mat will work everywhere?

There are two kinds of matx shader. You can build one that only works with the same render engine. Like Arnold is doing. You can render those in all DCCs supporting Arnold. Or you can build one with the native matx nodes. Or use multiple shaders “looks” and fallbacks. USD does similar stuff with “looks” and fallback shaders.

There should be some news at Siggraph.

1 Like

Here are two interesting talks about matX.

Slides from the open source days.

1 Like