I was with you until the last paragraph. What do you mean by Material-X having prerequisites?
For the record. MaterialX is NOT a shading language. It’s a spec of nodes and xml format for making node graphs. Those node graphs can generate OSL, or GLSL or any other code you wanted to write a generator for. And actually MaterialX does include a baking function to generate maps for a given node graph too.
When did he say that? There is a CUDA/Optix port of OSL, and it’s part of the official OSL distribution for quite a while now.
Quite a lot of time ago, so things may have changed.
@brecht whats your opinion on this? Do you think this could be implemented? It could be pretty awesome 
Depends on how easy to integrate and how complete it is. I haven’t looked at it in too much detail yet, I just saw that it got added a while ago.
I meant prerequisites of baking OSL to an image which could be used on GPU.
We need to have a mesh, the mesh needs to be UV-Unwrapped. If met, we could use Blender to bake OSL to images. Those images could be used in a GPU compatible shader.
For Material-X, we sadly cannot rely on OSL, because we need GPU support. Without these prerequisites.
OptiX support for OSL in Cycles is something we could add at some point. It should be complete enough for someone to try this seeing as it’s being used in Arnold, but it’s not an immediate priority for Cycles development.
Note that the OSL support is OptiX only, there are no other GPU backends.
Amd released a free open source Material-X library
FYI in case
IMHO eventually sooner or later USD pipeline will commit to material x.
What I am seeing from other app industries and pipeline the pipeline will go like this:
Texturing > PBR
Shading > Material X
Scene exchange > USD
Render > Hydra
Correct me if I’m wrong, but USD comes from Pixar, right – a company which doesn’t exactly have a pedigree in gaming …
Yes, but it’s now backed up by game engineers and corps as well. GLTF is another one in this as well.
This is already the case. You can render MaterialX with USD’s GL renderer in hydra.
Yes.
It seems AMD has made a complete standard shader, op and pattern set for material X which I was successful to import in materialviewer and some other beta apps. It should be as it just needs to describe xml linking.
I think it might become a good starting point for blender devs.
Till now what I am seeing material X is treated as a separate shader bundle rather than a default one in other render engines. So I think rather than adjusting cycle PBR and hacking it here and there a complete subset will be required just Like AMD did.
And matX ops are very different as well.
Just my observations till now.
A person involved in Material-X development said in Thai forum (don’t remember where and when) that Cycles nodes were VERY similar to Material-X nodes, and only some nodes are missing, so the best approach IMHO would be to have a 1:1 correlation between Cycles and Material-X nodes, and keep it as up to date as possible.
GLTF and USD are vastly different tho.
It was once simple in 2.8. But now all noise are updated and different.
Although it’s completely upto devs how they want to handle it. If cycle can do native ops like matx then it will need to take care of backward compatibility and a re write of most of the nodes chain system. As matx needs all models to be exact. OSL is another giant mole here.
That is a headache and probably synergy will fall down. As matx is not rocksolid till now and is updating constantly. Maybe a step by step process is required. I have faith in Blender team and I know they can map it out.
The question I am often asked, “What is the point of this?”
Nvidia, Pixar, Sony, ILM, AMD and others are trying to shift towards a “Common” way of doing things. Just like DisneyPBR, it will give all the artists a time to breathe. I remember CynicatPro first introduced pbr model in Blender community 5 years ago and from there things went out like magic. So it’s about time.
Yes, of course, it should be.
@brecht
I am not sure but does cycle use XPU architecture? As I am seeing cycle can use CPU+GPU?
What if we compile OSL with cpu and feed back to GPU? Not an expert in it. Just something popped in my mind.
As @brecht said, the main benefit of MaterialX seems to be interoperability, and now the MaterialX is going to be supported in UnrealEngine 5 (5.1 to be exact, see ROADMAP: https://portal.productboard.com/epicgames/1-unreal-engine-public-roadmap/tabs/80-unreal-engine-5-1-in-progress ), I think now is the right time to revive this feature request. USD support has developed to a good stage both in Unreal and Blender, and I have recently switched over to USD workflow completely/mostly.
Also, btw I heard in the OSL stack server, that GPU support is coming soon.
I’m waiting for the day, when I can make my materials in Blender, and export them to Unreal, without any hitch.