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

Archive User Feedback
1

Material-X seems to have been adopted officially by the ASF, and it is useful in many ways, like with USD (AFAIK).

Could be possible to shift Cycles / Eevee to natively use Material-X definition and files?

Up to my understanding Material-X is something like Substance SBSAR but OpenSource and way more powerful for many reasons, Cycles has the power to do similar things to Substance Designer, so that’s why I wondered if this could be useful as the future of materials in Blender, being it open, easily shareable and procedural or semi-procedural.

13 Likes
2

Hey! I can help here…
I’m on the ASWF working group. I don’t know too much about the .sbsar format, but MaterialX is pretty cool. It’s an xml file based format that defines nodes and materials / nodetrees from those node definitions. There’s also a good set of node building blocks (think like math nodes and the Reflection / refraction nodes) that it defines. Finally, there is the ability to generate OSL / GLSL code from a materialX definition of a material.

TLDR: The real goal of materialX is to be able to share materials between renderers.

And I think that would be great for Cycles. Cycles nodetrees, let’s be honest are not that portable to things outside blender. And bringing in a material from say Maya is also not easy. So what could Blender support in MaterialX?

  • Import a MaterialX material and put into a cycles node tree. Probably pretty easy, the only tough part would supporting MaterialX nodes Cycles doesn’t currently support (which are a few but not a ton)
  • Export Cycles node tree to MaterialX. The hard part here is you’d have to define cycles nodes some of which are kinda complex in a materialx node graph definition (kinda like a node group)
  • Alternatively, you could probably move cycles to use material code generated directly from materialx, but right now it only generates GLSL or OSL code and only use materialx nodes…

Two more final points. IMO MaterialX is most interesting when used with USD. It gives a standard set of nodes you can export your shaders with in USD and be used other places. The USD OpenGL renderer can render MaterialX as well as some other USD compliant renderers.

Shameless plug, we’re working on a USD / Hydra / MaterialX add-on for blender which may make a lot of sense built in to blender: GitHub - GPUOpen-LibrariesAndSDKs/BlenderUSDHydraAddon

31 Likes
3

What would it look like for a procedural material to be defined in MaterialX? I haven’t come across an example that would show how it would be defined in a way that all MaterialX viewers would do the right thing.

Example: A Voronoi texture (4d, smooth f1, Manhattan) distance connected to the principled bsdf color

The principled bsdf is the easy part, but what about the voronoi? Do you have to xml-ify the Voronoi math so that everyone else can calculate the exact same pattern correctly?

4

Well,

maybe not voronoi but here’s a noise connected to color. There is a Worley noise node, too, and yeah you’d have to do a bit of math in the xml to make a node def that you’d save as a Voronoi node,

3 Likes
5

I only took a quick gander through the spec, it seems more like a declarative language to easily connect predefined blocks, rather than one that allows you to create new blocks from scratch, I didn’t stumble across anything that would allow for loops/control flow like structures in a material.

I suspect you’d have the same limitations as we have in cycles/eevee graphs, could you do a mandelbrot shader? you probably could, I think the math blocks are capable, but you’ll end up unrolling the whole thing.

Think what you’re looking for not be what material-x is designed for (but osl is though)

unless I completely misread you… there’s always that chance :slight_smile:

6

Yeah, I’m not looking for full programmability :slight_smile: I’m just unclear on the following 3 questions:

  1. What does the following Blender Material look like in MaterialX? As it stands there’s no native equivalent in MaterialX for either Voronoi (goes beyond basic Worley) or a multi-step ColorRamp. Seems like it would be possible if you xml-ify all the math AND hope all the other implementations use the same random numbers etc:
    example

  2. What does it look like if you load that hypothetical xml into another software? What does their UI look like?

  3. Pretend this setup was authored first by some other software; and they had to come up with a way to express the Voronoi and a ColorRamp on their own. What would it look like in Blender when it loads that material? We wouldn’t be able to reconstruct a nice UI most likely. It would be an ugly list of node names and inputs probably :slight_smile:

Not impossible to use MaterialX in some form (simple import/export). It’s just unclear what a nice, native, solution would really look like. Perhaps I lack “vision” :slight_smile: and will have to wait and see how more complex materials actually look like in a real UI from the “other guys”.

[Edit] Maybe a dedicated “MaterialX” option on materials would help? If that option is set for a given material, you only get access to the native MaterialX nodes and features. Import/export becomes simple and the UI can be nice if you build it directly around those specific nodes. It would remove all the nonsense with converting things like the above, you’ll just lose access to those nicer things…

7

It seems the point of material-X is to agree on a set of standard nodes, that transfer easily between applications, using anything outside that set is likely met with a “don’t do that”, sure you’re limited, but this limited set can easily be read by other apps. @bsavery can you confirm this is indeed the case?

I’d see it as the .obj of materials, lacks everything but the bare essentials, but every app has an importer for it, and there’s something to be said for that :slight_smile:

1 Like
8

I think the main benefit of MaterialX would be interop with other applications. From a user point of view it’s mostly a subset of what you can do with Cycles and Eevee nodes, with a few things we should add to support the most important MaterialX nodes and closures. Doing that and implementing a good conversion in both directions seems like a reasonable step to take.

I’m not personally convinced this is something we should integrate more closely into Cycles and Eevee itself. There is some benefit to keeping control of our shader node/graph implementation and being able to align it with other features of Blender.

@JuanGea, compared to Substance SBSAR, I’d expect MaterialX to be less powerful for procedural texture generation, since it lacks image processing capabilities. It’s more similar to shader nodes that we have in Blender now.

@deadpin, it should be possible to have a nice UI for nodes, Applications can export more complex builtin nodes as custom nodes (node groups) and hide the low level MaterialX nodes inside it. Of course that depends on both Blender and other apps doing a good job of importing/exporting those, but it’s not a limitation of the standard.

A dedicated MaterialX option on materials is something I think we should really avoid. Having two parallel shader node evaluation systems with different limitations is not great for users or developers in the long term.

13 Likes
9

Interop of shading networks to and from Cycles and other applications certainly IS a worthy potential benefit. And to more accurately answer @deadpin 's question here, how would we take a Cycles “voronoi” node (or something with complex logic) and export it to materialx. Well you’d define the node ui in the xml and then give materialx some OSL code or GLSL code for that node as well. (There’s a bit in the spec about shader gen).

3 Likes
10

I guess in this case, the best would be to bake everything, like you do for a game engine asset.This way you can import export the typical Albedo,Normal,Roughness,Metallic maps easy.

11

If baking down everything is good depends on the use case. But what MaterialX adds is exactly the ability to not have to do that, and export an arbitrary procedural shader graph instead.

1 Like
12

I see,maybe the shadergen is usefull for this?

13

Yes, I know that, that part is not the same, however Substance files can be exported to Material-X keeping as much procedural as possible and making them easily portable, of course SBSAR has a processor outside the software (as an exe or as a dll) so it’s a different thing.

I agree with this, specially since Cycles nodes are some of the most powerful node system out there, with some few limitations, having Cycles nodes on pair with Material-X and the other way around can be a win-win for everyone.

One of the good things that can be extracted from the Material-X concept could be to have dynamically linked materials, like that you can prepare a material, it is composed by a series of nodes, and the only thing you save in the blend file are the settings, if that Material-X definition file changes, the material could be automatically updated to reflect the changes, some settings may be lost or act differently, but that’s up to the TD and the artist to be aware of this, but the shaders could be highly improved by the TD’s while the artists focuses only on using them.

This is somewhat similar to what we have today with node groups, but this would be as software agnostic as possible and could enable us to have full USD compatibility.

By no means I’m saying that we should have a different set of nodes, Cycles nodes are the nodes inside Blender, they are just “translated” from Cycles to Material-X and the other way around.

Regarding the Voronoi or other procedural nodes compatibility, this is a matter of a working algo, since both systems are open source, the current Blender Voronoi could be ported over to Material-X, and other procedural algos present in Material-X could be integrated, this can only bring more capabilities to the users.

The question of course could be “how hard could be to maintain all this on pair”, and that is something that I assume has to be analysed by devs on both systems, Cycles and Material-X, to reach a conclusion :slight_smile:

14

I’m sorry to cut in, but when I was looking for professional material scanning services I found out about AxF - Appearance exchange Format. It’s developed by X-Rite, owner of Pantone. It is a format used in their scanning machines.

Here’s a PDF specification of the format and sample library.

It’s supported in some capacity by Substance Designer, Unreal Engine, Arnold. I wondered what you guys think about it.

15

Nvidia Material Definition Language is doing a similar way to build materials form node blocks.
http://mdlhandbook.com/
Enterprise PBR Shading model uses Material subtypes like carpaint,textile ect.
https://dassaultsystemes-technology.github.io/EnterprisePBRShadingModel/spec-2022x.md.html
Hopefully not to offtopic

1 Like
16

It would be amazing if Blender adopts this. Seems like a great match on many levels.

17

I looked at this recently, maybe the solution to this could be an OSL script like Standard Surface OSL by Autodesk combined whit an add-on.
I’ve tested is almost a Principled shader with more slot.

STSurface_01
STSurface_011365×745 256 KB

STSurface_02
STSurface_02398×674 36.5 KB

1 Like
18

OSL has two major limitations:

1.- Speed, is slower than native cycles shaders
2.- CPU Only

Unless some JIT Compiler is created for Cycles and can turn an OSL shader into a Cycles compiled shader and cycles can add it dynamically, this is not a solution I’m afraid

19

But Materiel-X is an xml interchange file, it is only used to exchange materials, between the various applications, However for now there are many proposals, so at this point maybe an addon with a specific Cycles Uber Shader could still go well, both to export and to import a Material-X in xml format without necessarily creating anything new.
Or creating a node with Python for this specific problem as a Material X addon, such as nodes for Blender render engines like Renderman LuxCoreRender and Octane.

Here in this video it says that it is already possible to use Material X with Blender too https://youtu.be/e2DLIbZ1SKE?t=66

20

I don’t get your proposal.

What do you think OSL would solve?

I mean, right now if we use OSL to import Material-X then we get non supported shaders for GPU and slower performance.

To export a cycles shader to Material-X you don’t need OSL AFAIK, you just need to compose the node tree as per Material-X specifications, as has been said before, Cycles lacks some nodes compared to Material-X but not so many.

IMHO the proper approach would be to create those lacking nodes to be on pair with Material-X, and I’m sure those nodes will be useful for the user.

Then a 1-to-1 export would be probably possible, and most probably already covered by the addon showed here before.

So I’m not sure where the OSL part comes into play.

What I was proposing was to have a live link to the Material-X files, so the node tree is changed when the Material-X defintion has changed, and the user modifications go OVER that link, so if something changes and cannot be applied a warning can be given to the user, but there is no OSL involved, everything is native Cycles.

Now for other engines, those engines should support Material-X definition, no need to go OSL, specially because it’s CPU limited, and they can be sure to attend the Material-X specifications so in the end all the engines can have the same nodes, and in the end the interpreter for each engine should be done by the engine developers, in the case of LuxCore is the same, the Material-X should be read by the addon and generate the node tree accordingly, is something similar wo what it already does when it reads Cycles material, but it’s something internal, it interprets Cycles nodes and generate Lux nodes internally to pass them to the engine.

The good thing is that if Material-X defintino is taken as a standard, and Lux for example embraces the Material-X definition, then probably it will be capable to interpret Cycles materials without effort, of course there could be specific features that are present in Lux and not in Cycles, but I can imagine that those are more like attributes/variables that can be exported/created accordingly to the needs.

And of course there could be specific nodes that will not be present in the Material-X definition, those could be pushed by the every engine developers I assume, as long as they are generally useful, since Material-X is open source.
And those that are not generally useful will remain as Render engine specific nodes that won’t be possible to export, in the case of Lux those would be specific settings for PGI for example.

In the end, I’m not sure where OSL comes into play :slight_smile: