MaterialX

検索で来た方へ:最新の調査結果はこちら→http://memo.render.jp/materialx



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.

多くのCGプロダクションは、プロダクションパイプラインの異なる箇所で複数のソフトウェアツールを隔たる、ワークフローを使用します。また、複数の施設を隔てた膨大なアウトソーシングや、異なるソフトウェアパッケージやレンダリングシステムを使用する異なる部署やスタジオへ、ルックデブモデルを渡すことが要求されたりすることもあります。
加えて、エキスパートプログラマやテクニカルディレクタの修正や、事前に定義されたテクスチャからシェーダへの接続や、ハードコードされたテクスチャのカラコレオプションが入った自シェーダーを使用したスタジオレンダリングパイプラインは、入力テクスチャ画像を、画像処理やブレンドオペレータのツリーを通じた、様々なシェーダ入力に接続することによる、よりフレキシブルなグラフベースのシェーダネットワークへ移行しています。

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")
2. 



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.

Requirements 

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. 

簡単に使用したり、実装したり、既存ワークフローに組み込むために、提案されたファイルフォーマットについて、望ましい特徴は以下の通りです。
・マテリアルスキーマは、スタンドアロンなファイルフォーマットとして表現可能であり、かつ、組み込みマテリアルデータをサポートするOpenEXRやAlembicなどのファイルフォーマットの中に、組み込み可能であるべきである。
・ファイルフォーマットは、ヒューマンリーダブルで、オープンな国際標準規格に基づいた編集可能なテキストファイルで構成されるべきである。
・テクスチャ処理ネットワークは、グラフ出力処理のキャッシュやベイクをネイティブにサポートするべきである。
・パラメータの値や、マテリアルコンテンツの中の入出力ファイル名を保存できるようにするべきであるが、ユーザーが編集したり、テンプレートや別のコンテキストとしてファイルを使用できるようにするために、外部アプリケーションにそれらのファイルを読んで独自の値を与えたりできるようにするために、外部からアクセス可能な"knobs"のようなパラメータを晒すこともできなければならない。
・カラーの計算は、モダンなカラーマネジメントシステムをサポートするべきであり、どんな入力画像やカラーの値に対しても、計算のためのワーキングカラースペースと同様に、正確なカラースペースを特定できるべきである。
・すべての入力や出力のデータタイプは、曖昧性や未定義データ型を解決するために外部ファイルやホストアプリケーションからの追加情報を要求して推測するのではなく、ファイル読み込みの型チェックを有効にするために、明示的に仕様にされるべきである。

Proposal 
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 

我々は新しいマテリアルコンテキストスキーマである、MaterialXを提案する。それはMaterialXコンテキストを読み書きするための、XMLベースのファイルフォーマットである。
MaterialXスキーマは、いくつかのプライマリエレメントタイプと、多くの追加サブエレメントタイプで定義される。

<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"のボックスは、ジオメトリに関連した文字列アトリビュートにどのように名前が定義されるかを表している。
赤い"Opgraphs"のボックスは、多くのテクスチャ処理ネットワークを定義していて、代替geominfo文字列を読むことにより、各ジオメトリに画像ファイル名を明確に割り当て、入力テックスチャイメージを定義する。
青い"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"のための異なるオーバライドバリューをセットする。

Definitions 
(略)

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のすべてのエレメントは、stringタイプのnameアトリビュートが要求される。
MaterialXエレメントのnameアトリビュートは、ユニークな識別子で、同じスコープ内で2つのエレメントが同じ名前になるかもしれないということは無い。
いくつかのエレメントタイプ(shaderrefのような)は、他のスコープのエレメントへの参照を保持していて、この状況では、参照エレメントはnameアトリビュートを参照として共有する。

最大限の互換性を保持するため、文字列、数値、アンダースコアからなることを推奨している。
エレメント名にスペースや次のシンボルを1つでも含んではいけない
! @ # $ % ^ & * ? ( ) [ ] { } < > \ / . , : ' " |

MaterialX Attribute Types 

(略)

MTLX File Format Definition 
 
MTLXファイル(拡張子は.mtlx)は、次のフォームを保持する

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

materialxルートエレメントによる、標準XML宣言のラインは、サブエレメントとしてmaterialxエレメントのすべてのエレメントを含む。
標準XMLのXIncludesと、標準XMLコメントがサポートされている。
<xi:include href="includedfile.mtlx"/>
<!-- this is a comment-->

ルートエレメント<materialx>のアトリビュート

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

Implementation Compatibility Checking

(略)

現在のMaterialXで定義されている実装依存のcapabilityのリスト
 customtype カスタムタイプの定義と使用
 customnodeカスタムopgraphノードの定義と使用 
geomopssurface position, normal, tangentのような、ローカルジオメトリックfeatureのためのopgraphノードの使用 
 globalops非ローカルジオメトリックfeatureへのアクセスを要求する、opgraphノードの使用 
 matopgraphシェーダ入力に接続するopgraphを保持するマテリアルの使用 
 matshadergraph他のシェーダ入力に互いに接続するシェーダ出力を保持するマテリアルの使用 
 matvarvalueマテリアルパラメータ、入力値でのmaterialvar置き換えの使用
 multiassign非オーバーラップタイプでの、同じジオメトリへのアサインのある、複数のマテリアルの許容 
 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 (http://www.alembic.io/). "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:
/string1/string2/string3/... 

ジオメトリはMaterialXコンテンツで、明確に定義されるものではないが、参照される。
ファイル内では、geomfileアトリビュートを使用して宣言することができる(必須ではない)。
geomfile宣言は、・・・

(略)

Geometry and File Prefixes 

collectionでジオメトリを定義、
geominfoでジオメトリのアトリビュートを定義

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


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. 

入力imagefileやoutputcacheファイルのためのファイル名は、1つまたは複数のスペシャルな文字列を含むことができ、
次のように置換される。MaterialXステートからくる、置換文字列は、"%"か"@"で始まり、一方ホストアプリケーション環境からくる置換文字列は、"$"で始まる。

 %geomatr 
 %UDIM 
 %UVTILE  
 @materialvar 
 $hostattr 
 $frame 
 $0Nframe 
 $CONTAINER 

Regex Expressions 

(略)

Parameter Expressions and Function Curves 

MaterialXではサポートしていない。


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エレメントは、レンダリングのためにシェーダに引き渡す入力値を生成するために、1つかそれ以上のソースノードに対して適用する、任意のDAGを表す。
MaterialXドキュメントは、複数のopgraphエレメントを含むことができ、各定義は1つまたは複数の出力名を持つ。
opgraphは、いくつかの異なるシェーダによって共有することができるし、同じシェーダに対して異なる入力があっても共有することができる。なぜなら、各マテリアルエレメントは、opgraphエレメントと、他の様々なシェーダ入力に接続するためのoutputと、必要に応じた公開opgraphパラメータのための異なる値が指定されているためである。

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.

 



たぶん1オブジェクトに1マテリアルでテクスチャ適用するだけだと、こんな感じ?

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

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

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

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

  <look name="lookA">
    <materialassign name="material1" collection="collection1"/>
  </look>
</materialx>
Comments