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.
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.
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
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.
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.
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.
@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.
