Material-X adopted as an official standard by ASF, possibilities for cycles/Eevee?

I agree for this case.

What I wrote about OSL/GPU did not relate directly to this topic.

There are prerequisites.
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.

That is what I meant with indirect OSL GPU support. OSL does not support GPU directly, but we could bake PBR set to images. Images are kind of a static cache to Store OSL generated data, the ‘cached’ data could be used on GPU based shading.

That won’t do the job for Material-X, because there musn’t be prerequisites. It needs to work generally (for all objects which could be rendered, not only those we could bake pbr (static cache) images for).

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.

2 Likes

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.

1 Like

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 :smiley:

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.

1 Like

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.

11 Likes

Amd released a free open source Material-X library

https://matlib.gpuopen.com/main/materials/all

4 Likes

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

1 Like

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.

1 Like

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.

1 Like

pixelgrip very cool materials !

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.

1 Like

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.