@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: @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: 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: 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: 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: 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: The MaterialX repo has examples and it comes with a GLSL generator
@rgkovach: same here, we have alot of custom shaders that do crazy things, layers and blends, non-standard channel usage…
@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: 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
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
@dhruv: Yeah I wish the tooling was in a better spot.
It’ll happen but it’s chicken and egg
@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: 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: 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