OK osl is not good and isn’t what I’m saying in the second post, and we agree but but it is a system composed of varying material layers and this can also be generated with the Cycles nodes can this be implemented as a Python Add-on In Blender?
I’m not sure, Because if the BRDF is different to the ones in cycles that part cannot be modified, but a layered material system, yes, ir can already be created, that why before Principled BSDF there were a ton of Uber Shaders out there, and the Surface shader you showed is basically the same as the principled bsdf with some additions I think.
Si basically with nodes you can implement many things, but I’m not sure if the internal algo can be created right now or how can it be handled with Material-X
On Pixar RenderMan Manual there are many info and this can help for the discussion. and how this can be implemented in Blender. MaterialX+Lama
1 Like
Here in this page are available examples with MeterialX and Lama with Blender for Renderman Examples in Blender
1 Like
Seems to me all these material-definition formats have limitations that would be solved by implementing a general shader language like OSL. But GPU owners don’t like OSL because you can’t implement a custom language like that on a GPU. So you have to invent yet another material-definition format. And another. And another.
By the way, the original ancestor of OSL and its ilk was RenderMan Shading Language, RSL, from Pixar. And that’s long been in professional use, to make big-budget Hollywood movies and the like, without GPU support.
It’s not “don’t like” is that it cannot be used, so it’s not about liking it or not 
Besides OSL is slower than pre-compiled shaders, so it’s not the ideal solution either
I am not sure that OSL being slower than compiled C++ shader is always true. OSL is a shading language that allows the user to build custom shaders/ultils in a very efficient way if done properly.
Why chose between MaterialX and OSL ? Go for both OSL is an industry standard, its usability has been proven in many production already.
It is not like OSL can’t be ported/rewriten to work on GPU neither.
@brecht said it many times, porting OSL to GPU/Cycles would be a incredible amount of work and would delay many other more important things.
Resources are not unlimited
Regarding performance, once again @brecht may have a more educated guess than mine.
I never said it was blender foundation’s jobs to do it. With the popularity of GPU rendering tech, I wouldn’t be surprised if some studios would make this happen.
Yep, maybe, but I suspect that OSL implementation for Cycles is something quite big, so I’m not sure if some studio will jump into this task, however I’m sure they will be very welcome
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 
Yep, you guess wrong
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.
In the meantime one can play with osl subset that works on GPU…
1 Like
I have not maintained that in quite a bit, unsure how well that still runs
3 Likes
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.
Why do you think OSL is rejected?
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.