MaterialX add-on #100894

Open
opened 2022-09-07 23:27:33 +02:00 by Brian Savery (AMD) · 25 comments

This feature would be to enable MaterialX nodes and workflows in Blender. There are two main purposes:

  • Enable MaterialX nodes to be used in a Blender Shader Nodegraph. This would also allow importing MaterialX materials into Blender.
  • Exporting a Blender Nodegraph (with Blender nodes or MaterialX nodes) to MaterialX. This is useful for interop with other packages, but moreso for exporting to USD Hydra renderers.

How it works:
Node types and their UI are generated from .xml specification in the MaterialX library. These create new node types which when enabling the add-on, would show in the Blender Material Nodegraph as available node types. (Alternatively we could only enable these nodes with certain render engines).

There is also a mapping of exporting Blender native nodes to MaterialX specification. In general the MaterialX nodes are much lower level and we have done most of the work already in our add-on for Hydra.

Importing MaterialX files will create nodes in the Material node graph with MaterialX nodes.

Exporting a Blender Material Node graph to MaterialX will create a MaterialX node graph with the exported blender nodes and materialX nodes depending on what is used.

There will be a function available in python and C++ for exporting a material via MaterialX

This feature would be to enable MaterialX nodes and workflows in Blender. There are two main purposes: - Enable MaterialX nodes to be used in a Blender Shader Nodegraph. This would also allow importing MaterialX materials into Blender. - Exporting a Blender Nodegraph (with Blender nodes or MaterialX nodes) to MaterialX. This is useful for interop with other packages, but moreso for exporting to USD Hydra renderers. How it works: Node types and their UI are generated from .xml specification in the MaterialX library. These create new node types which when enabling the add-on, would show in the Blender Material Nodegraph as available node types. (Alternatively we could only enable these nodes with certain render engines). There is also a mapping of exporting Blender native nodes to MaterialX specification. In general the MaterialX nodes are much lower level and we have done most of the work already in our add-on for Hydra. Importing MaterialX files will create nodes in the Material node graph with MaterialX nodes. Exporting a Blender Material Node graph to MaterialX will create a MaterialX node graph with the exported blender nodes and materialX nodes depending on what is used. There will be a function available in python and C++ for exporting a material via MaterialX
Brian Savery (AMD) self-assigned this 2022-09-07 23:27:33 +02:00
Author
Member
Added subscribers: @BrianSavery, @SonnyCampbell_Unity, @AlexeyAdamitsky, @DagerD, @Peine_Perdue, @Plyro, @EstebanCovo, @satishgoda1, @ianhsieh, @ahmed.hindy96, @JulianEisel, @Zhen-Dai, @paulgolter, @Scaredyfish, @JamesBarrie, @lichtwerk, @platerytter, @Yuro, @Roggii-4, @Alaska, @makowalski, @LazyDodo, @brecht, @dr.sybren

A few overall questions about this:

  • Since this is proposed to be an add-on, it's not obvious how this will integrate with the C++ USD importer/exporter. Will it be implemented in Python or C++? I would expect this to be a native C++ feature to be able to integrate properly with the rest of the USD code. The USD importer/exporter code invoking a Python add-on seems not ideal.
  • Is the MaterialX node graph a completely different type than Blender shader nodes? If so, the path forward to native integration with Cycles, Eevee, painting and texturing tools is not so obvious. When those gain MaterialX support in the feature, we'd probably have to do a difficult merge to unify things to avoid having to maintain two completely different shader node systems. The correct design is not obvious to me, I think it we should have an idea of how this can evolve over time to integrate more closely in Blender before deciding on which way to go.
  • This is something that would only be used by external renderers for now, but eventually this should be supported by Cycles and Eevee as well. Is this something that AMD interested in working on after the initial integration, or would the expectation be for other developers to address the technical debt?
  • How does this integrate UI wise? How are MaterialX node graphs attached to materials assuming they are not native shader nodes? What does Material Preview shading mode show, or Texture color in solid mode? What happens in texture paint mode?
A few overall questions about this: * Since this is proposed to be an add-on, it's not obvious how this will integrate with the C++ USD importer/exporter. Will it be implemented in Python or C++? I would expect this to be a native C++ feature to be able to integrate properly with the rest of the USD code. The USD importer/exporter code invoking a Python add-on seems not ideal. * Is the MaterialX node graph a completely different type than Blender shader nodes? If so, the path forward to native integration with Cycles, Eevee, painting and texturing tools is not so obvious. When those gain MaterialX support in the feature, we'd probably have to do a difficult merge to unify things to avoid having to maintain two completely different shader node systems. The correct design is not obvious to me, I think it we should have an idea of how this can evolve over time to integrate more closely in Blender before deciding on which way to go. * This is something that would only be used by external renderers for now, but eventually this should be supported by Cycles and Eevee as well. Is this something that AMD interested in working on after the initial integration, or would the expectation be for other developers to address the technical debt? * How does this integrate UI wise? How are MaterialX node graphs attached to materials assuming they are not native shader nodes? What does Material Preview shading mode show, or Texture color in solid mode? What happens in texture paint mode?

Added subscriber: @TheRedWaxPolice

Added subscriber: @TheRedWaxPolice

Added subscriber: @bnagirniak

Added subscriber: @bnagirniak

Hello,
We already have MaterialX addon for blender, it is implemented in our forked repo of blender-addons. I'll answer to questions:

Will it be implemented in Python or C++?

It is implemented in Python.

Is the MaterialX node graph a completely different type than Blender shader nodes?

Yes, this is separate node graph.

This is something that would only be used by external renderers for now

Yes, currently this would be used by USD Hydra render addon only, on which we are working on. Integration with Cycles, Eevee is possible only from their side, but this is absolutely different task.

How does this integrate UI wise? How are MaterialX node graphs attached to materials assuming they are not native shader nodes?

MaterialX node graph should be attached to Blender material as custom python properties. MaterialX addon adds additional UI panels with tools to attach MaterialX nodegraph to Blender material. Also there will be a tool to convert Blender material shading nodes to MaterialX nodes.

What does Material Preview shading mode show, or Texture color in solid mode? What happens in texture paint mode?

This is relates to external renderer such as USD Hydra render addon.

Also, AMD has MaterialX online library https://matlib.gpuopen.com, and such addon provides UI to work with it: show list of materials with icons, select, download etc.

Hello, We already have MaterialX addon for blender, it is implemented in our forked repo of blender-addons. I'll answer to questions: > Will it be implemented in Python or C++? It is implemented in Python. > Is the MaterialX node graph a completely different type than Blender shader nodes? Yes, this is separate node graph. > This is something that would only be used by external renderers for now Yes, currently this would be used by USD Hydra render addon only, on which we are working on. Integration with Cycles, Eevee is possible only from their side, but this is absolutely different task. > How does this integrate UI wise? How are MaterialX node graphs attached to materials assuming they are not native shader nodes? MaterialX node graph should be attached to Blender material as custom python properties. MaterialX addon adds additional UI panels with tools to attach MaterialX nodegraph to Blender material. Also there will be a tool to convert Blender material shading nodes to MaterialX nodes. > What does Material Preview shading mode show, or Texture color in solid mode? What happens in texture paint mode? This is relates to external renderer such as USD Hydra render addon. Also, AMD has MaterialX online library https://matlib.gpuopen.com, and such addon provides UI to work with it: show list of materials with icons, select, download etc.

If this MaterialX support is not designed to integrate well, I don't think we should bundle it and maintain it as part of the Blender project. For the Blender project to say to external renderers, here's the official way to use MaterialX in Blender that we will support going forward, I don't think this is good enough.

If this MaterialX support is not designed to integrate well, I don't think we should bundle it and maintain it as part of the Blender project. For the Blender project to say to external renderers, here's the official way to use MaterialX in Blender that we will support going forward, I don't think this is good enough.

I created diff ticket https://developer.blender.org/D16044. I wrote there more description of what it does and what it provides to user.

I created diff ticket https://developer.blender.org/D16044. I wrote there more description of what it does and what it provides to user.

We've already been working on MaterialX addon and here I'd like to open more details of proposed design of this project.

Dependencies

  1. MaterialX addon is written on python using MaterialX python bindings. It requires MaterialX library to be placed into Blender build as external dependency https://developer.blender.org/D15989.
  2. Project should be placed to https://github.com/blender/blender-addons repo under materialx folder.

Project design

  1. Addon adds new Nodegraph type 'MaterialX' which has node types generated from MaterialX XML nodedefs.
    image.png
    Python code of node types are generated at first registration of addon and is placed into Blender appdata folder. Here is the example of nodes.
    image.png

  2. Addon adds 'materialx' python extension with MaterialX properties to Blender material type. It has mx_node_tree field which links to MaterialX nodegraph type:

>>> material

bpy.data.materials['Material']

>>> material.materialx

bpy.data.materials['Material'].materialx

>>> type(material.materialx)

<class 'materialx.material.properties.MaterialProperties'>

>>> material.materialx.mx_node_tree

bpy.data.node_groups['MX_Material']

>>> type(material.materialx.mx_node_tree)

<class 'materialx.node_tree.MxNodeTree'>

Renderers can access to MaterialX nodegraph from Blender material via material.materialx.mx_node_tree. MxNodeTree has method export() which returns MaterialX document.

>>> material.materialx.mx_node_tree.export()

<MaterialX.PyMaterialXCore.Document object at 0x000001AC10C86CF0>

Addon provides UI to automatic convert Blender shaders to MaterialX nodegraph, link/unlink available MaterialX nodegraph
{F13560321}image.png

Additional tools

  • Addon provides import MaterialX XML files. It reads and parses mtlx file and creates MaterialX nodegraph with proper nodes and places them in user friendly positions in node tree:
    image.png
  • Export MaterialX nodegraph to mtlx file (including textures) which can be shared.

Online MaterialX library
AMD has MaterialX online library https://matlib.gpuopen.com, and such addon provides UI to work with it: show list of materials with icons, select, download etc. Here is some screenshots:
image.png
image.png
image.png

We've already been working on MaterialX addon and here I'd like to open more details of proposed design of this project. **Dependencies** 1. MaterialX addon is written on python using MaterialX python bindings. It requires MaterialX library to be placed into Blender build as external dependency https://developer.blender.org/D15989. 2. Project should be placed to https://github.com/blender/blender-addons repo under materialx folder. **Project design** 1. Addon adds new Nodegraph type 'MaterialX' which has node types generated from MaterialX XML nodedefs. ![image.png](https://archive.blender.org/developer/F13560129/image.png) Python code of node types are generated at first registration of addon and is placed into Blender appdata folder. Here is the example of nodes. ![image.png](https://archive.blender.org/developer/F13560123/image.png) 2. Addon adds 'materialx' python extension with MaterialX properties to Blender material type. It has mx_node_tree field which links to MaterialX nodegraph type: ``` >>> material bpy.data.materials['Material'] >>> material.materialx bpy.data.materials['Material'].materialx >>> type(material.materialx) <class 'materialx.material.properties.MaterialProperties'> >>> material.materialx.mx_node_tree bpy.data.node_groups['MX_Material'] >>> type(material.materialx.mx_node_tree) <class 'materialx.node_tree.MxNodeTree'> ``` **Renderers** can access to MaterialX nodegraph from Blender material via `material.materialx.mx_node_tree`. `MxNodeTree` has method `export()` which returns MaterialX document. ``` >>> material.materialx.mx_node_tree.export() <MaterialX.PyMaterialXCore.Document object at 0x000001AC10C86CF0> ``` Addon provides UI to automatic convert Blender shaders to MaterialX nodegraph, link/unlink available MaterialX nodegraph {[F13560321](https://archive.blender.org/developer/F13560321/image.png)}![image.png](https://archive.blender.org/developer/F13560324/image.png) **Additional tools** - Addon provides import MaterialX XML files. It reads and parses mtlx file and creates MaterialX nodegraph with proper nodes and places them in user friendly positions in node tree: ![image.png](https://archive.blender.org/developer/F13560357/image.png) - Export MaterialX nodegraph to mtlx file (including textures) which can be shared. **Online MaterialX library** AMD has MaterialX online library https://matlib.gpuopen.com, and such addon provides UI to work with it: show list of materials with icons, select, download etc. Here is some screenshots: ![image.png](https://archive.blender.org/developer/F13560397/image.png) ![image.png](https://archive.blender.org/developer/F13560399/image.png) ![image.png](https://archive.blender.org/developer/F13560402/image.png)

Thanks for the details. But my main concern with this remains the same, I see no path from this implementation to better Blender MaterialX integration. I don't think it makes sense for the Blender project to adopt this as the official MaterialX support, when we already know there will need to be significant design changes and rewrites.

Obviously this is all very useful to get an external renderer working with MaterialX support, but then the renderer should just bundle this functionality themselves.

Thanks for the details. But my main concern with this remains the same, I see no path from this implementation to better Blender MaterialX integration. I don't think it makes sense for the Blender project to adopt this as the official MaterialX support, when we already know there will need to be significant design changes and rewrites. Obviously this is all very useful to get an external renderer working with MaterialX support, but then the renderer should just bundle this functionality themselves.

Added subscriber: @MikePan

Added subscriber: @MikePan
Author
Member

Hi @brecht . I get where Blender is coming from on wanting this to be better integrated into the existing node system. As we discussed in the rendering meeting, part of the issue with integrating MaterialX to work closer with Cycles and EEVEE, is the nodes in MaterialX sometimes being "lower level" than Blender nodes. And them being hard to mix. BUT, MaterialX can export GLSL or OSL code, which potentially either renderer could use.

Given that, there are maybe two ways to do this. And maybe a question for you.

  1. The current implementation we have makes a completely separate MaterialX node tree. It could generate an OSL shader or GLSL shader, but some work would have to be done to hook those into EEVEE or Cycles. Are you proposing we should do that?

Alternatively:
2. We could make this system work somewhat differently, where a MaterialX file is loaded like a .osl "Script node", but then creates a Group Node, instead of a single node. That Group Node would then point at a MaterialX Nodetree instance for it's .node_tree attribute which is populated from the MaterialX file. This would have the same implication of course that the osl or glsl from the MaterialX would have to be tied in to the respective EEVEE or Cycles render export.

Screen Shot 2022-09-26 at 11.52.29 AM.png

Screen Shot 2022-09-26 at 11.51.50 AM.png

Would either of these alternatives help be "better integrated"?

Hi @brecht . I get where Blender is coming from on wanting this to be better integrated into the existing node system. As we discussed in the rendering meeting, part of the issue with integrating MaterialX to work closer with Cycles and EEVEE, is the nodes in MaterialX sometimes being "lower level" than Blender nodes. And them being hard to mix. BUT, MaterialX can export GLSL or OSL code, which potentially either renderer could use. Given that, there are maybe two ways to do this. And maybe a question for you. 1. The current implementation we have makes a completely separate MaterialX node tree. It could generate an OSL shader or GLSL shader, but some work would have to be done to hook those into EEVEE or Cycles. Are you proposing we should do that? Alternatively: 2. We could make this system work somewhat differently, where a MaterialX file is loaded like a `.osl` "Script node", but then creates a Group Node, instead of a single node. That Group Node would then point at a MaterialX Nodetree instance for it's `.node_tree` attribute which is populated from the MaterialX file. This would have the same implication of course that the osl or glsl from the MaterialX would have to be tied in to the respective EEVEE or Cycles render export. ![Screen Shot 2022-09-26 at 11.52.29 AM.png](https://archive.blender.org/developer/F13576326/Screen_Shot_2022-09-26_at_11.52.29_AM.png) ![Screen Shot 2022-09-26 at 11.51.50 AM.png](https://archive.blender.org/developer/F13576325/Screen_Shot_2022-09-26_at_11.51.50_AM.png) Would either of these alternatives help be "better integrated"?
Added subscribers: @HooglyBoogly, @fclem, @JacquesLucke, @Jeroen-Bakker

I don't think either adding Eevee/Cycles support based on the current separate node types, or using OSL script nodes in the existing shader nodes is the solution. It still makes the shading nodes somehow foreign to Blender.

For native MaterialX support in Eevee and Cycles, I think we should add MaterialX nodes to the existing native shading nodes, and add native support for the all the required socket types. Editing shader nodes would still be done in the same Shader Editor, and the properties editor would have some understanding of MaterialX output nodes to be able to display the relevant nodes in panel. I think it's important that for the user that we don't end up with two parallel shading node systems, with two editors, two surface/volume shaders for each material, two ways to select the active texture for painting, etc.

I don't expect Eevee and Cycles to be able to render using MaterialX nodes in a first implementation. But I would like them to be saved in a .blend file and edited in the Python API in a way that is future proof, so that when the time comes we don't have to completely change both storage and APIs. And then we can also incrementally add support for MaterialX nodes to work with for example Textured shading in solid mode, integration with Material Preview shading mode, etc. Additionally if the implementation is in C++, the USD importer/exporter can also more easily hook into this.

This seems doable to me, but it will take some work. You could try to make a mapping between all data types supported by MaterialX and Blender native socket types, figure out what is missing and how it could be added, and see what kind of challenges that creates.

At least to me this seems like the right design for good integration. Maybe there are reasons why this would not work well in practice, or there is some inbetween solution possible. This is the same type of question raised by USD collections as their own datablock, or Hydra render delegates not being a regular render engine but some sort of sub-engine of a Hydra render engine. Long term it seems problematic for users and developer maintenance to have two parallel systems for the same functionality.

Will also CC a few other developers whose modules this affects: @fclem @Jeroen-Bakker @JacquesLucke @HooglyBoogly.

I don't think either adding Eevee/Cycles support based on the current separate node types, or using OSL script nodes in the existing shader nodes is the solution. It still makes the shading nodes somehow foreign to Blender. For native MaterialX support in Eevee and Cycles, I think we should add MaterialX nodes to the existing native shading nodes, and add native support for the all the required socket types. Editing shader nodes would still be done in the same Shader Editor, and the properties editor would have some understanding of MaterialX output nodes to be able to display the relevant nodes in panel. I think it's important that for the user that we don't end up with two parallel shading node systems, with two editors, two surface/volume shaders for each material, two ways to select the active texture for painting, etc. I don't expect Eevee and Cycles to be able to render using MaterialX nodes in a first implementation. But I would like them to be saved in a .blend file and edited in the Python API in a way that is future proof, so that when the time comes we don't have to completely change both storage and APIs. And then we can also incrementally add support for MaterialX nodes to work with for example Textured shading in solid mode, integration with Material Preview shading mode, etc. Additionally if the implementation is in C++, the USD importer/exporter can also more easily hook into this. This seems doable to me, but it will take some work. You could try to make a mapping between all data types supported by MaterialX and Blender native socket types, figure out what is missing and how it could be added, and see what kind of challenges that creates. At least to me this seems like the right design for good integration. Maybe there are reasons why this would not work well in practice, or there is some inbetween solution possible. This is the same type of question raised by USD collections as their own datablock, or Hydra render delegates not being a regular render engine but some sort of sub-engine of a Hydra render engine. Long term it seems problematic for users and developer maintenance to have two parallel systems for the same functionality. Will also CC a few other developers whose modules this affects: @fclem @Jeroen-Bakker @JacquesLucke @HooglyBoogly.
Author
Member

I see. We were operating on the assumption that MaterialX shader nodes should be kept separate.

This seems doable to me, but it will take some work. You could try to make a mapping between all data types supported by MaterialX and Blender native socket types, figure out what is missing and how it could be added, and see what kind of challenges that creates.

Ok let me start with that. The socket types are different for sure. The biggest difference is probably in things like illustrated here:

 <nodedef name="ND_displacement_float" node="displacement" nodegroup="pbr" doc="A constructor node for the displacementshader type.">
    <input name="displacement" type="float" value="0.0" doc="Scalar displacement amount along the surface normal direction." />
    <input name="scale" type="float" value="1.0" doc="Scale factor for the displacement vector" />
    <output name="out" type="displacementshader" />
  </nodedef>
  <nodedef name="ND_displacement_vector3" node="displacement" nodegroup="pbr" doc="A constructor node for the displacementshader type.">
    <input name="displacement" type="vector3" value="0.0, 0.0, 0.0" doc="Vector displacement in (dPdu, dPdv, N) tangent/normal space." />
    <input name="scale" type="float" value="1.0" doc="Scale factor for the displacement vector" />
    <output name="out" type="displacementshader" />
  </nodedef>

This is the Displacement node def(s) for MaterialX c4a6c71cf8/libraries/pbrlib/pbrlib_defs.mtlx (L254)
the "displacement" node can take a vector or float input, and generally you would decide based on the incoming type which noddef to use. So, actually representing the "socket type" is a bit abstracted.

And the other thing to notice is that the "displacement" node is much simpler than the blender one. There is probably all the existing code there already for generating the shader for Cycles / Eevee, but would need to be refactored or separated out.

So we can outline all those gaps, and how we can map the Blender nodes -> MaterialX which should be doable. To properly bring MaterialX back in to blender we would need to figure out how to make these more "basic" materials nodes in Blender.

At least to me this seems like the right design for good integration. Maybe there are reasons why this would not work well in practice, or there is some inbetween solution possible. This is the same type of question raised by USD collections as their own datablock, or Hydra render delegates not being a regular render engine but some sort of sub-engine of a Hydra render engine. Long term it seems problematic for users and developer maintenance to have two parallel systems for the same functionality.

Well I can see that, but in the case of Hydra, I disagree a bit. There are already two systems for rendering addons, in essence. Cycles and Eevee vs all others. Hydra Render Engine support would allow a faster export and additionally less duplicated code between render addons so that seems like a win there.

On the Hydra subject, the above mentioned mapping of Blender nodes -> MaterialX would be crucial for that as well, so it's a good place to start.

I see. We were operating on the assumption that MaterialX shader nodes should be kept separate. > > This seems doable to me, but it will take some work. You could try to make a mapping between all data types supported by MaterialX and Blender native socket types, figure out what is missing and how it could be added, and see what kind of challenges that creates. > Ok let me start with that. The socket types are different for sure. The biggest difference is probably in things like illustrated here: ``` <nodedef name="ND_displacement_float" node="displacement" nodegroup="pbr" doc="A constructor node for the displacementshader type."> <input name="displacement" type="float" value="0.0" doc="Scalar displacement amount along the surface normal direction." /> <input name="scale" type="float" value="1.0" doc="Scale factor for the displacement vector" /> <output name="out" type="displacementshader" /> </nodedef> <nodedef name="ND_displacement_vector3" node="displacement" nodegroup="pbr" doc="A constructor node for the displacementshader type."> <input name="displacement" type="vector3" value="0.0, 0.0, 0.0" doc="Vector displacement in (dPdu, dPdv, N) tangent/normal space." /> <input name="scale" type="float" value="1.0" doc="Scale factor for the displacement vector" /> <output name="out" type="displacementshader" /> </nodedef> ``` This is the Displacement node def(s) for MaterialX https://github.com/AcademySoftwareFoundation/MaterialX/blob/c4a6c71cf8c8f23d93a0b87e39b298d3fbfaadf4/libraries/pbrlib/pbrlib_defs.mtlx#L254 the "displacement" node can take a vector or float input, and generally you would decide based on the incoming type which noddef to use. So, actually representing the "socket type" is a bit abstracted. And the other thing to notice is that the "displacement" node is much simpler than the blender one. There is probably all the existing code there already for generating the shader for Cycles / Eevee, but would need to be refactored or separated out. So we can outline all those gaps, and how we can map the Blender nodes -> MaterialX which should be doable. To properly bring MaterialX back in to blender we would need to figure out how to make these more "basic" materials nodes in Blender. > At least to me this seems like the right design for good integration. Maybe there are reasons why this would not work well in practice, or there is some inbetween solution possible. This is the same type of question raised by USD collections as their own datablock, or Hydra render delegates not being a regular render engine but some sort of sub-engine of a Hydra render engine. Long term it seems problematic for users and developer maintenance to have two parallel systems for the same functionality. Well I can see that, but in the case of Hydra, I disagree a bit. There are already two systems for rendering addons, in essence. Cycles and Eevee vs all others. Hydra Render Engine support would allow a faster export and additionally less duplicated code between render addons so that seems like a win there. On the Hydra subject, the above mentioned mapping of Blender nodes -> MaterialX would be crucial for that as well, so it's a good place to start.

In #100894#1423153, @BrianSavery wrote:
This is the Displacement node def(s) for MaterialX c4a6c71cf8/libraries/pbrlib/pbrlib_defs.mtlx (L254)
the "displacement" node can take a vector or float input, and generally you would decide based on the incoming type which noddef to use. So, actually representing the "socket type" is a bit abstracted.

And the other thing to notice is that the "displacement" node is much simpler than the blender one. There is probably all the existing code there already for generating the shader for Cycles / Eevee, but would need to be refactored or separated out.

So we can outline all those gaps, and how we can map the Blender nodes -> MaterialX which should be doable. To properly bring MaterialX back in to blender we would need to figure out how to make these more "basic" materials nodes in Blender.

There's different ways to handle this. But I would imagine this node to be represented as a new "Mx Displacement" node with an enum to choose between scalar or vector displacement, similar to the new Mix node. Automatic deduction from the linked socket is also possible, but that is more of a UI thing that would need to figured out for Blender nodes in general.

I think being able to represent a MaterialX shader graph unchanged with all the same node types is fine, and useful for those who want to work with the same nodes across multiple applications.

For the purpose of I/O figuring out how to map to Blender shader nodes is important, but that's separate from how we represent the MaterialX nodes as data structures in Blender. I would imagine that to be done with a function that gets as input a Blender shader nodetree and outputs a Blender shader nodetree, just with different nodes in it. And then that could be used for import/export, hydra, an operator for users to convert shaders, and maybe rendering in Eevee/Cycles.

The main question for me is about how to map the socket types. For example Blender (and OSL) make no distinction bsdf/edf/vdf and surfaceshader/volumeshader/displacementshader, it's all one shader/closure socket. Maybe it's fine to just keep that one socket type and add some validation.

And then there's vector2, vector4, matrix and arrays, which may need to be added to Blender as native socket types. That raises some questions if geometry nodes should get the same types (eventually), or if they remain MaterialX specific.

Well I can see that, but in the case of Hydra, I disagree a bit. There are already two systems for rendering addons, in essence. Cycles and Eevee vs all others. Hydra Render Engine support would allow a faster export and additionally less duplicated code between render addons so that seems like a win there.

I think Hydra as an additional method to integrate renderers is fine, for that case I was mainly referring to how it is represented to the user. You select just another renderer from the list, and it may have some different features, but as far as Blender is concerned it's still a render engine.

Somewhat similarly for MaterialX, I think it's ok for a material to contain either Blender shader nodes or MaterialX shader nodes, and leave the choice to the user. There's not really any practical alternative I think. Mixing them would be useful and could be made to work at some point, but it's not really my immediate concern. What I think is important is that a given material datablock has one shader node graph.

> In #100894#1423153, @BrianSavery wrote: > This is the Displacement node def(s) for MaterialX https://github.com/AcademySoftwareFoundation/MaterialX/blob/c4a6c71cf8c8f23d93a0b87e39b298d3fbfaadf4/libraries/pbrlib/pbrlib_defs.mtlx#L254 > the "displacement" node can take a vector or float input, and generally you would decide based on the incoming type which noddef to use. So, actually representing the "socket type" is a bit abstracted. > > And the other thing to notice is that the "displacement" node is much simpler than the blender one. There is probably all the existing code there already for generating the shader for Cycles / Eevee, but would need to be refactored or separated out. > > So we can outline all those gaps, and how we can map the Blender nodes -> MaterialX which should be doable. To properly bring MaterialX back in to blender we would need to figure out how to make these more "basic" materials nodes in Blender. There's different ways to handle this. But I would imagine this node to be represented as a new "Mx Displacement" node with an enum to choose between scalar or vector displacement, similar to the new Mix node. Automatic deduction from the linked socket is also possible, but that is more of a UI thing that would need to figured out for Blender nodes in general. I think being able to represent a MaterialX shader graph unchanged with all the same node types is fine, and useful for those who want to work with the same nodes across multiple applications. For the purpose of I/O figuring out how to map to Blender shader nodes is important, but that's separate from how we represent the MaterialX nodes as data structures in Blender. I would imagine that to be done with a function that gets as input a Blender shader nodetree and outputs a Blender shader nodetree, just with different nodes in it. And then that could be used for import/export, hydra, an operator for users to convert shaders, and maybe rendering in Eevee/Cycles. The main question for me is about how to map the socket types. For example Blender (and OSL) make no distinction bsdf/edf/vdf and surfaceshader/volumeshader/displacementshader, it's all one shader/closure socket. Maybe it's fine to just keep that one socket type and add some validation. And then there's vector2, vector4, matrix and arrays, which may need to be added to Blender as native socket types. That raises some questions if geometry nodes should get the same types (eventually), or if they remain MaterialX specific. > Well I can see that, but in the case of Hydra, I disagree a bit. There are already two systems for rendering addons, in essence. Cycles and Eevee vs all others. Hydra Render Engine support would allow a faster export and additionally less duplicated code between render addons so that seems like a win there. I think Hydra as an additional method to integrate renderers is fine, for that case I was mainly referring to how it is represented to the user. You select just another renderer from the list, and it may have some different features, but as far as Blender is concerned it's still a render engine. Somewhat similarly for MaterialX, I think it's ok for a material to contain either Blender shader nodes or MaterialX shader nodes, and leave the choice to the user. There's not really any practical alternative I think. Mixing them would be useful and could be made to work at some point, but it's not really my immediate concern. What I think is important is that a given material datablock has one shader node graph.
Member

From my limited knowledge of the area, integrating MaterialX nodes more with shader nodes sounds like a good goal if that's going to be the standard way to interchange materials.
I would say using lower level nodes as building blocks has generally worked out well for geometry nodes-- providing the same sort of building blocks for shading nodes sounds useful as well.

And then there's vector2, vector4, matrix and arrays, which may need to be added to Blender as native socket types. That raises some questions if geometry nodes should get the same types (eventually), or if they remain MaterialX specific.

All of those socket types would be quite useful for geometry nodes, and we've had loose plans to add them anyway.

  • 2D vectors would help to make UV operations more obvious. (#92765)
  • 4D vectors would help to make 4D noise more intuitive. (we also planned rotation/quaternion sockets, which could use the same type with a subtype, I suppose #92967)
  • Matrix types would be helpful for object transforms and more advanced displacement as well as interaction with instance transforms, and eventual rigging nodes.
  • List/array sockets would be useful for containing neighboring geometry elements.
    So as far as I'm concerned, these should all be builtin socket types.
From my limited knowledge of the area, integrating MaterialX nodes more with shader nodes sounds like a good goal if that's going to be the standard way to interchange materials. I would say using lower level nodes as building blocks has generally worked out well for geometry nodes-- providing the same sort of building blocks for shading nodes sounds useful as well. >And then there's vector2, vector4, matrix and arrays, which may need to be added to Blender as native socket types. That raises some questions if geometry nodes should get the same types (eventually), or if they remain MaterialX specific. All of those socket types would be quite useful for geometry nodes, and we've had loose plans to add them anyway. - 2D vectors would help to make UV operations more obvious. (#92765) - 4D vectors would help to make 4D noise more intuitive. (we also planned rotation/quaternion sockets, which could use the same type with a subtype, I suppose #92967) - Matrix types would be helpful for object transforms and more advanced displacement as well as interaction with instance transforms, and eventual rigging nodes. - List/array sockets would be useful for containing neighboring geometry elements. So as far as I'm concerned, these should all be builtin socket types.

Added subscriber: @GeorgiaPacific

Added subscriber: @GeorgiaPacific

Added subscriber: @tlinde

Added subscriber: @tlinde

Added subscriber: @davidnr

Added subscriber: @davidnr

For reference: in conversation at the Blender Conference we agreed that the nodes should be implemented natively in C/C++ as shader nodes, and that we should add new native socket types where needed, rather than having a completely separate node system for MaterialX.

For reference: in conversation at the Blender Conference we agreed that the nodes should be implemented natively in C/C++ as shader nodes, and that we should add new native socket types where needed, rather than having a completely separate node system for MaterialX.

Added subscriber: @lvxejay

Added subscriber: @lvxejay

Added subscriber: @Gabe

Added subscriber: @Gabe
Member

Added subscriber: @GregZaal

Added subscriber: @GregZaal

Added subscriber: @Lennart-Demes

Added subscriber: @Lennart-Demes

Added subscriber: @matthewlow-dwa

Added subscriber: @matthewlow-dwa
Bastien Montagne added this to the Pipeline, Assets & IO project 2023-02-09 15:39:30 +01:00
Philipp Oeser removed the
Interest
Pipeline, Assets & IO
label 2023-02-10 08:54:01 +01:00
Iliya Katushenock removed the
Status
Needs Triage
label 2023-08-24 17:32:59 +02:00
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
14 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#100894
No description provided.