Statement of Problem 

Many Computer Graphics production studios use workflows involving multiple software tools for different parts of the production pipeline. There is also a significant amount of sharing and outsourcing of work across multiple facilities, requiring companies to hand off fully look­developed models to other divisions or studios which may use different software packages and rendering systems. In addition, studio rendering pipelines that previously used monolithic shaders built by expert programmers or technical directors with fixed, predetermined texture­to­shader connections and hard­coded texture color­correction options are moving toward more flexible node graph­based shader networks built up by connecting input texture images to various inputs of shaders through a tree of image processing and blending operators.


There are at least four distinct interrelated data relationships needed to specify the complete "look" of a CG object:

 1. Define the texture processing networks of image sources, image processing operators, connections and parameters used to combine and process one or more sources (e.g. textures) to produce the texture images that will eventually be connected to various shader inputs (e.g. "diffuse_albedo" or "bumpmap"). 
 2. Define geometry­specific information such as associated texture filenames or IDs for various map types. 
 3. Define the parameter values and connections to texture processing networks for the inputs of one or more rendering or post­render blending shaders, resulting in a number of materials. 
 4. Define the associations between geometries in a model and materials to create number of looks for the model.

1. イメージソースのテクスチャ処理ネットワークの定義、画像処理オペレーター、合成に使用される接続とパラメータ、テクスチャ画像を生成するための1つまたは複数のソースなどは、最終的には、様々なシェーダ入力へ接続される(例えば、"diffuse_albedo"や"bumpmap")

At the moment, there is no common, open standard for transferring all of the above data relationships. Various applications have their own file formats to store this information, but these are either closed, proprietary, inadequately documented or implemented in such a way that using them involves opening or replicating a full application.

Thus, there is a need for an open, platform­independent, well­defined standard for specifying the "look" of computer graphics objects built using shader networks so that these looks or sub­components of a look can be passed from one software package to another or between different facilities.

The purpose of this proposal is to define a schema for Computer Graphics material looks with exact operator and connection behavior for all data components, and a standalone file format for reading and writing material content using this schema. The proposal will not attempt to impose any particular shading models or any interpretation of images or data.

This proposal is not intended to represent any particular workflow or dictate data representations that a tool must support, but rather to define a flexible interchange standard compatible with many different possible ways of working. A particular tool might not support multi­layer images or even shader networks, but it could still write out looks and materials in the proposed format for interchange and read them back in.


The following are requirements that the proposed standard must satisfy:
● The material schema and file format must be open and well­defined. 
● Texture processing operations and their behavior must be well­defined. 
● Data flow and connections must be robust and unambiguous.
● The specification must be extensible, and robustly define the processing behavior when an operator type, input or parameter is encountered that is not understood by an implementation. 


The following are desirable features that would make a proposed file format easier to use, implement, and integrate into existing workflows:
● The material schema should be both expressible as a standalone file format and embeddable within file formats that support embedded material data, such as OpenEXR and Alembic. 
● The file format should consist of human­readable, editable text files based upon open international standards. 
● Texture processing networks should natively support baking or caching of operator graph outputs. 
● It should be possible to store parameter values and input/output filenames within material content, but it should also be possible to expose certain parameters as externally­accessible "knobs" for users to edit and/or allow external applications to read the file and supply their own values for files or parameters so that the file can be used as a template or in different contexts. 
● Color computations should support modern color management systems, and it should be possible to specify the precise color space for any input image or color value, as well as the working color space for computations. 
● Data types of all inputs and outputs should be explicitly specified rather than inferred in order to enable type checking upon file read rather than requiring additional information from external files or the host application to resolve ambiguous or undefined data types. 


We propose a new material content schema, MaterialX​, along with a corresponding XML­based file format to read and write MaterialX content. The MaterialX schema defines several primary element types plus a number of supplemental and sub­element types. The primary element types are: 
​<opgraph> for defining data­processing network operator graphs 
​<geominfo> for declaring and defining uniform geometric attributes that may be referenced from operator graphs 
● <shader> ​for declarations of shader programs, including the sets of inputs and outputs that they support 
● <material> ​for defining material instances, which assign specific values and opgraph output connections to shader inputs 
● <look> ​for defining object looks, which assign materials and other properties to geometries 


<opgraph> データプロセッシングネットワークオペレーターグラフの定義
<geominfo> オペレータぐふぁるから参照されるかもしれないuniformジオメトリアトリビュートの定義と宣言
<shader> シェーダプログラムの宣言、それらがサポートする入出力のセットを含む。
<material> マテリアルインスタンスの定義、シェーダ入力へ接続するopgraphの出力と、特手の値のアサイン
<look> オブジェクトルックを定義するため、ジオメトリへの、マテリアルと他のプロパティのアサイン

MaterialX Overview Diagram 
The diagram on the following page gives a high­level overview of what each element defines and how the elements connect together to form a complete set of look definitions. Details of the <opgraph>, <geominfo>, <shader>, <material> and <look>  elements are described in the sections that follow

Flow of information generally proceeds counterclockwise through the diagram. The green "GeomInfo GeomAttrs" box shows how elements can define named string attributes associated with geometries. The red "Opgraphs" box defines a number of texture processing networks, which generally determine which input texture images to read by substituting geominfo strings for each geometry into the specified portion of the image file name. The blue "Shaders" and cyan "Materials" boxes show that shaders connect to opgraph outputs, and materials reference shaders as well as define values for certain public shader or opgraph parameters. The violet "Looks" box shows how looks connect geometry to materials via MaterialAssigns ("MA" in the diagram).

 The example diagram defines two looks: L1 and L2. L1 uses materials M1 (assigned to geometry /a/g1 through /a/g6), while L2 uses materials M1 (to /a/g1, /a/g2 and /a/g3) and M2 (to /a/g4, /a/g5 and /a/g6). Both materials reference shader "srf1", but M2 also references shader "dsp1", and each of the materials read from opgraphs N1, N2 and N3, but set different overriding values for the public opgraph parameters "altmix" and (for M2) "bumpmult" as well as different value bindings for srf1's "roughness" and "fresnel_exp" parameters).


略図は反時計回りで情報の進み方を表している。緑の"GeomInfo GeomAttrs"のボックスは、ジオメトリに関連した文字列アトリビュートにどのように名前が定義されるかを表している。
青い"Shaders"とシアンの"Materials"のボックスは、いくらかのパブリックシェーダやopgraphパラメータのために定義された値と同様に、opgraph 出力へ接続するシェーダと、シェーダを参照するマテリアルを表している。

サンプルの略図は、L1, L2の2つのlookを定義している。L1は、マテリアルM1を使用していて、L2はマテリアルM1とM2を使用している。
どちらのマテリアルも"srf1"シェーダを参照しているが、M2は"dsp1"シェーダも参照している。そして、各マテリアルはopgraphs N1, N2, N3から読まれるが、
srf1の"roughness"と"fresnel_exp"パラメータの異なる値のバインディイングと同様に、パブリックopgraph パラメータ"altmix"と"bumpmult"のための異なるオーバライドバリューをセットする。


MaterialX Names 

All elements in MaterialX (opgraphs, nodes, materials, shaders, etc.) are required to have a name attribute of type "string". The nameattribute of a MaterialX element is its unique identifier, and no two elements at the same scope (i.e. elements with the same parent) may share a name. Some element types (e.g. ) serve the role of referencing an element at a different scope, and in this situation the referencing element will share a nameattribute with the element it references. For maximum compatibility, it is recommended that element names consist of only upper­ and lower­case letters, numbers and underscores ("_"). Element names cannot​include spaces or any of the following symbols:
! @ # $ % ^ & * ? ( ) [ ] { } < > \ / . , : ' " |


! @ # $ % ^ & * ? ( ) [ ] { } < > \ / . , : ' " |

MaterialX Attribute Types 


MTLX File Format Definition 

<?xml version="1.0" encoding="UTF-8"?>

<xi:include href="includedfile.mtlx"/>
<!-- this is a comment-->


 version    ○ MaterialXのバージョン番号
 require  実装依存のcapabilityのリスト。コンマ区切り。
 cms   カラーマネジメントシステムの名前
 cmsconfig  CMSのコンフィギュレーションファイルのURI
 colorspace  作業カラースペースの名前 

Implementation Compatibility Checking


 customtype カスタムタイプの定義と使用
geomopssurface position, normal, tangentのような、ローカルジオメトリックfeatureのためのopgraphノードの使用 
 multilayer複数レイヤーの画像ファイルから、個別のレイヤー を読む
override 一般に公開されたパラメータや入力に対して、オーバライドを使用する
shadergraph opgraphで定義される、shaderの<implementation> の使用


Color Spaces and Color Management Systems 


Geometry Representation 

Geometry is referenced by but not specifically defined within MaterialX content. The file in which geometry is defined can optionally be declared using geomfileattributes within any element; that geomfiledeclaration will then apply to any geometry name referenced within the scope of that element, e.g. any geomor regexattributes, including those defining the contents of collections (but not when referencing the contents of a collection via a collectionattribute). If a geomfile is not defined for the scope of any particular geomor regexattribute, it is presumed that the host application can resolve the location of the geometry definition

The geometry naming conventions used in the MaterialX specification are designed to be compatible with those used in Alembic ( "Geometry" can be any particular geometric object that a host application may support, including but not limited to polygons, meshes, subdivision surfaces, NURBS patches or meshes, implicit surfaces, particle sets, volumes, procedurally­defined objects, etc. The only requirements for MaterialX are that geometries are named using the convention specified below, can be assigned to a material and can be rendered.

 The naming of geometry should follow a syntax similar to UNIX full paths:



Geometry and File Prefixes 


     <collection name="c_plastic">
        <collectionadd geom="/a/b/g1,/a/b/g2,/a/b/g5,/a/b/c/d/g6" />

Public Names 

Image Filename Substitutions 
The filename for an input imagefile or an outputcache file can include one or more special strings, which will be replaced as follows. Substitution strings beginning with "%" or "@" come from the MaterialX state, while substitution strings beginning with "$" come from the host application environment. 



Regex Expressions 


Parameter Expressions and Function Curves 


Operator Graph Elements 

Operator graph ("opgraph") elements describe an arbitrary acyclic data processing graph applied to one or more source nodes in order to produce input values to a shader for rendering. A MaterialX document can contain multiple opgraph elements, each defining one or more output names. Operator graphs can be shared by several different shaders or even different inputs to the same shader because each material element specifies which opgraph element and output to connect to various shader inputs, and perhaps specifying different values for public opgraph parameters.


Opgraph Definition 


OSLのようなアプリケーション独自のコードについては、custom opgraph nodesのセクションを参照。

Standard Node Types 
The node types listed below are used to define and select inputs and outputs for the network. Each must declare the MaterialX type of its output, which is most commonly a float, colorN, or vectorN.



<?xml version="1.0" encoding="UTF-8"?>
  <collection name="collection1">
    <collectionadd name="ca1" geom="/a/g1">

  <opgraph name="op1">
    <image name="cc1" type="color3">
      <parameter name="file" type="filename" value="txt/color/asset.color.tif"/>
    <output name="diffuse" type="color3">
      <parameter name="in" type="opgraphnode" value="cc1"/>

  <shader name="srf1" shadertype="surface" shaderprogram="basic_surface">
    <input name="diff_albedo" type="color3" opgraph="op1" graphoutput="diffuse"/>

  <material name="material1">
    <shaderref name="srf1">

  <look name="lookA">
    <materialassign name="material1" collection="collection1">