It feels like you assume OSL is Cycles only ? Sorry if I guess wrong
SPI Imageworks created it for their production needs with their Arnold fork. It is now implemented in Arnold retail, Redshift, Renderman, Octane, Clarisse, 3Delight and Octane. It is big for everyone because it opened a lot of possibilities, it is simple to use and it is quite efficient.
MaterialX is promising but its main feature, the interoperability of shading networks, to me, is specially interesting for big production house where they might need to use multiple rendering engine in one production, or share big chunks of data to another studios. Is this useful for blender/cycles users ? Is it a top priority ?
I don’t have answers to those questions, but I believe the blender foundation is in the best position to judge if the amount of work needed to implement it is worth it or not, and at which priority.
I would personally prefer texture caching, better volume rendering, deep id support and some CPU rendering love hehe, but that’s my own wish list
I’m fully aware of OSL, the GPU engines that support OSL has to do more complex and costly implementations, specially if they support CPU + GPU, is the case of Arnold, supporting OSL in Arnold GPU has not been an easy task AFAIK
I’m not against supporting it, I just say that I asked for this before and it seems the OSL implementation for CPU is rather complex and a big amount of work.
Material-X is not just interoperability, it’s also configurability and agnostic proceduralism, and that’s useful for everyone.
Anyways I don’t thing both are exclusive, but I suspect implementing Material-X may be more direct and realist than OSL for GPU, since Material-X will work with native Cycles nodes.
Think of it this way: OSL is a full programming language. In a way, it is for material definitions what JavaScript is for the Web: once you have OSL, you can accept whatever other simpler format you like (MaterialX or whatever), and translate it to an OSL shader.
For example, some have complained that you cannot use IES textures to control lamp intensities if you enable OSL in Cycles. The answer is simple: compile the IES data into an OSL shader.
Sad, if OSL gets rejected because it does not run on GPU Cycles.
There is an indirect support for OSL/GPU.
One could bake image textures from an OSL shader tree. After, these textures could be used in a GPU-compatible render engine. Including EEVEE or LuxCoreRender.
OSL is already supported for CPU, and Cycles-X will continue supporting OSL so I don’t understand your comment.
We are talking about a different thing, portaibility, procedurality, etc… OSL could be good, but does not cover all the user base, GPU’s are very important in Cycles so if OSL cannot be efficiently ported to GPU, then it’s normal to dismiss it from what it’s being talked here.
That does not mean that OSL support will disappear for CPU.
When you are talking about procedurality in MaterialX, which feature are you referring to ? I don’t think MaterialX will bring more procedural feature than what you already have in Cycles.
When I speak about procedurality is the one already present in Cycles, but Subtances could be exported to Material-X (there is a demo somewhere) so it could be similar to bring a substance translated ro Cycles nodes, keeping in mind that there are some nodes not compatible, but AFAIK those nodes would not be Material-X compatible either.
Procedurality would mean things like being able to use the wide range of mathematical functions available in OSL. For example, Gabor noise. When you bake things, they turn into image textures. That means you get repeating patterns in the renders.
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
