One of the things I hope with Principled BSDF v2 is, that we will get a shader that can work with different render engines, called MaterialX. Some people might not know how time consuming it is in a production to get assets from one software or render into another. If we would have one model for all, we could easily build things in Blender that can be exchanged via FBX or USD to, lets say Maya with Arnold render, or the opposite way.
I can’t even understand people not wanting an improvement, thats totally crazy.
1 Like
I don’t believe that Material X is planned quite yet. Pixar has been pushing it, but even other industry standard DCC packages like Houdini have been slow to adopt it.
There is always this risk behind the corner
11 Likes
It has been mentioned a few times by brecht, like this one:
https://developer.blender.org/D11965#311139
It seems he has some thoughts about supporting Material X, but it looks like currently it’s still just a thought, no solid plan yet.
1 Like
I don’t think it’s the case with MaterialX though. All renderers have the same shading paradigm more or less. And there is a huge value in getting rid of the need to rebuild materials for assets when switching render engines. It’s a lot of man hours wasted on pointless labor.
I really hope MaterialX can figure out how to handle edge cases and get to one universal format. This would be amazing for artists and production companies as well.
4 Likes
Um…
Limitations
- Currently, Karma does not support MaterialX light shaders.
- MaterialX nodes have Color Space parameters, but this is actually metadata which USD’s Hydra interface currently doesn’t pass on to the render delegate.
- MaterialX defines a few tokens (for example
{frame}for time) for use in file paths, but these are currently not used by Karma or Houdini. You can use the<UDIM>token, however. - Karma only supports Volume materials on volume primitives (VDBs).
- Karma does not currently support Surface and Volume materials on the same prim.
- The Compositing nodes are not supported by Karma.
Do you think that those limitations constitute “slow adoption”? Those are pretty minor IMO.
3 Likes
Yes.
As a Houdini user, I can tell you that SideFX is keeping Material X in their sights, but it’s not even close to being the standard used by Houdini at the moment.
Further, there is an awful lot of misconceptions about it, as well as debate whether it’s all that it’s cracked up to be. Of course if you’re Pixar it’s in your best interest to push it hard, but not everyone agrees that it’s the best solution for the issue.
Can you please elaborate? What are the most argued points and what the usual counter points?
Just like everything else, there are personal subjective opinions as to whether Pixar’s decisions fit the needs of everyone (a bit like USD, or even VDB). I heard some criticism of the physical accuracy of the surface shaders, or how it handles certain shading operations vs. say the way Arnold or VRay handle them. Ultimately if it works for you that’s all that matters.
one thing that drives me crazy about the current principal is, that you have no color input for metal and specular, but only can use diffuse input for that. That alone would make a huge positive impact. The whole metal import was not needed before and its more or less for those who dislike the control via IOR. The metal switch was mostly a work around for games and it should never replace physical shading. Sadly Blender choose this was, without considering other user, simple because it did fit better to Eevee. I understand that limited resources forced them to do some decisions, but truly hope that this will be different in the future.
I was using 3Delight with Houdini and it had some incredibly powerful metal shading options that even accounted for oxidation and other surface effects. Unfortunately it’s not available for Blender, and quite honestly it has other limitations and issues that would not make it useful for many other things.
Like everything else in life, it’s all a compromise and ultimately what ends up being adopted has to fit the lowest common denominator.
Going off topic here, but do you have any source to point to on this?
From my limited understanding of Eevee it shouldn’t be an issue rendering pipeline wise at all. Even less so on recent versions. Eevee only Specular BSDF with color inputs for both diffuse and spec support that.
Metalness workflow with single color input makes sense for games due to reduced memory cost over specular workflow. Especially with deferred rendering where albedo for both is single buffer. Only color buffer like that in Eevee was input to SSR which was Specular only and later on (start of 2021) used on every specular BSDF not only ones with SSR.
@Midphase No personal offense but you’re kinda wrong here and frankly I’m not sure you know what you’re talking about. Inaccuracies:
- MaterialX came originally from ILM, Pixar has less to do with it except for contributing the LAMA shading nodes which were collaborated with ILM.
- OpenVDB came from Dreamworks and other than Pixar being on the Academy software foundation is not making a ton of decisions for openvdb.
- You cite Arnold surface shader being more accurate but one of the Surface shaders defined in MaterialX is Arnold/Autodesk Standard Surface… so not sure what you mean here.
- The previous comment about Houdini and others being slow on the uptake of MaterialX… Both SideFX and Autodesk are pretty gung-ho on the standard. Things like this don’t happen overnight.
(bias warning: I’m involved on the steering committee for MaterialX).
6 Likes
Thanks for the answer. What you provided are personal opinions and you didn’t even attribute it to anyone. So, to be honest, I don’t see a real discussion about pros and cons of MaterialX. I was truly interested because I though maybe I was missing something and I like to know about a range of opinions.
I was also cautious about MaterialX at first but I still fail to see the downsides to having this format and that all, or at least major renderers, support it.
MaterialX is open source and there is a pretty big group of professional leading it’s development. Some major industry stakeholders are taking active development of the standard. So it’s already a good news.
The biggest value or have MaterialX is saving so much time by not wasting it on rebuilding materials for each popular renderer. It saves time for:
- Artists. If you decide to switch engine for whatever reason you can easily bring your whole library of materials to the new engine and just keep working.
- Productions. Productions accumulate assets and they might need change their render engine for a different one between projects or in mid-processe. Or they might need to use different bought assets and there is no need to convert anything manually if asset materials are build with MaterialX.
- Asset Libraries. You don’t need to produce material for each renderer you want to reach for you market and artist can get access to, potentially, all assets produced if their materials converted to MaterailX.
There is probably more. But if MaterialX turns out what it’s promised to be it’s going to be huge for 3D artists. We won’t know how we lived without it before.
Of course, I’m cautiously optimistic here because there are quite a few things I don’t yet see how can be resolved to achieve 100% compatibility between renders. The whole initiative can maybe fail for numerous reasons. Even if it’s good the adoption might not reach the good level.
Still I hope smart people will figure it out since on paper MateriaX seems amazing for the artist.
Afaik the problem with MaterialX are not the shader in Blender,but how to convert all Blender material nodes builds to MaterialX for export?.
To import the MaterialX might be easyer then i guess.But how to convert all the nodes to MaterialX?
I have a idea how it could work.
In the MaterialX “paper or github doc” are template examples of materials,like for carpaint,clothes,etc.
In Blender we could make such templates.
Then click on create new material,maybe named “new material MaterialX carpaint template” etc.(Then Blender creates templates with the same nodes structure as in the MaterialX examples)
You guess the idea,then it should be easy to export.
If you want now to export all nodes you have to deconstruct the e.g. principled shader in parts like translucent,metallic,glass and what not.And think about all big giant node builds.
Templates are maybe a solution.
I don’t really see the issue here. The Principled Shader was always designed to be an easy, but limited solution to quickly approximate most real-world materials. That’s all it is and what it’s meant to be. When you need more complex setups there is still the possibility to build a custom shader with the other shadernodes or build your custom node-groups. I think this should be encouraged more.
1 Like
The vast majority of the real world materials will be reproducible with the new Principled material, and majority of them can already be done with the current one. The use cases for atomic shader nodes are little to none. There is only handful of people out there who can utilize them for something that’s actually useful, and those use cases are disappearing fast.
It’s the exact opposite. Usage of the atomic shader nodes should be discouraged as much as possible. It should be left only to the expert users and only for use cases which literally can’t be done with Principled/PrincipledV2. There’s not much of those.
3 Likes
Hm - you’re probably right. Now that I think about it, most materials I didn’t use Principled for in the past years were either vegetation, clearcoated (because current pincipled clearcoat breaks energy conservation and behaves weird in general) or stylized materials. The first two of those should be addressed with the new shader. I still think knowing how to use the atomic nodes is a usefull skill to have in general.