diff --git a/MaterialX/documents/CMakeLists.txt b/MaterialX/documents/CMakeLists.txt
old mode 100644
new mode 100755
index c58bb4d..d270eb7
--- a/MaterialX/documents/CMakeLists.txt
+++ b/MaterialX/documents/CMakeLists.txt
@@ -1,46 +1,45 @@
-set(DOXYGEN_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR})
-set(DOXYGEN_HTML_OUTPUT_DIR ${DOXYGEN_OUTPUT_DIR}/html)
-set(DOXYGEN_INPUT_LIST ${CMAKE_CURRENT_BINARY_DIR}/MainPage.md)
-
-set(MATERIALX_DOXYGEN_SOURCE_FOLDERS
- ${PROJECT_SOURCE_DIR}/source/MaterialXCore
- ${PROJECT_SOURCE_DIR}/source/MaterialXFormat
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenShader
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenShader/Nodes
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenGlsl
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenGlsl/Nodes
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenSlang
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenOsl
- ${PROJECT_SOURCE_DIR}/source/MaterialXGenMdl
- ${PROJECT_SOURCE_DIR}/source/MaterialXRender
- ${PROJECT_SOURCE_DIR}/source/MaterialXRenderHw
- ${PROJECT_SOURCE_DIR}/source/MaterialXRenderGlsl
- ${PROJECT_SOURCE_DIR}/source/MaterialXRenderOsl)
-
-find_package(Doxygen REQUIRED)
-
-foreach(FOLDER ${MATERIALX_DOXYGEN_SOURCE_FOLDERS})
- file(GLOB FOLDER_HEADERS ${FOLDER}/*.h)
- list(APPEND DOXYGEN_INPUT_LIST ${FOLDER_HEADERS})
-endforeach()
-
-string (REPLACE ";" " " DOXYGEN_INPUT_STR "${DOXYGEN_INPUT_LIST}")
-
-configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)
-
-add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/MainPage.md
- COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/DeveloperGuide/MainPage.md ${CMAKE_CURRENT_BINARY_DIR}
- WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
- DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/DeveloperGuide/MainPage.md)
-
-add_custom_command(OUTPUT ${DOXYGEN_HTML_OUTPUT_DIR}/index.html
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/DoxygenAwesome ${CMAKE_CURRENT_BINARY_DIR}
- COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/Images ${CMAKE_CURRENT_BINARY_DIR}
- COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
- WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
- DEPENDS ${DOXYGEN_INPUT_LIST} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
- COMMENT "Generating HTML documentation: ${DOXYGEN_HTML_OUTPUT_DIR}/index.html")
-add_custom_target(MaterialXDocs ALL DEPENDS ${DOXYGEN_HTML_OUTPUT_DIR}/index.html)
-
-install(DIRECTORY ${DOXYGEN_HTML_OUTPUT_DIR}
- DESTINATION "documents" MESSAGE_NEVER)
+set(DOXYGEN_OUTPUT_DIR ${CMAKE_CURRENT_BINARY_DIR})
+set(DOXYGEN_HTML_OUTPUT_DIR ${DOXYGEN_OUTPUT_DIR}/html)
+set(DOXYGEN_INPUT_LIST ${CMAKE_CURRENT_BINARY_DIR}/MainPage.md)
+
+set(MATERIALX_DOXYGEN_SOURCE_FOLDERS
+ ${CMAKE_SOURCE_DIR}/source/MaterialXCore
+ ${CMAKE_SOURCE_DIR}/source/MaterialXFormat
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenShader
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenShader/Nodes
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenGlsl
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenGlsl/Nodes
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenOsl
+ ${CMAKE_SOURCE_DIR}/source/MaterialXGenMdl
+ ${CMAKE_SOURCE_DIR}/source/MaterialXRender
+ ${CMAKE_SOURCE_DIR}/source/MaterialXRenderHw
+ ${CMAKE_SOURCE_DIR}/source/MaterialXRenderGlsl
+ ${CMAKE_SOURCE_DIR}/source/MaterialXRenderOsl)
+
+find_package(Doxygen REQUIRED)
+
+foreach(FOLDER ${MATERIALX_DOXYGEN_SOURCE_FOLDERS})
+ file(GLOB FOLDER_HEADERS ${FOLDER}/*.h)
+ list(APPEND DOXYGEN_INPUT_LIST ${FOLDER_HEADERS})
+endforeach()
+
+string (REPLACE ";" " " DOXYGEN_INPUT_STR "${DOXYGEN_INPUT_LIST}")
+
+configure_file(${CMAKE_CURRENT_SOURCE_DIR}/Doxyfile.in ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile)
+
+add_custom_command(OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/MainPage.md
+ COMMAND ${CMAKE_COMMAND} -E copy ${CMAKE_CURRENT_SOURCE_DIR}/DeveloperGuide/MainPage.md ${CMAKE_CURRENT_BINARY_DIR}
+ WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+ DEPENDS ${CMAKE_CURRENT_SOURCE_DIR}/DeveloperGuide/MainPage.md)
+
+add_custom_command(OUTPUT ${DOXYGEN_HTML_OUTPUT_DIR}/index.html
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/DoxygenAwesome ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND ${CMAKE_COMMAND} -E copy_directory ${CMAKE_CURRENT_SOURCE_DIR}/Images ${CMAKE_CURRENT_BINARY_DIR}
+ COMMAND ${DOXYGEN_EXECUTABLE} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
+ WORKING_DIRECTORY ${CMAKE_CURRENT_BINARY_DIR}
+ DEPENDS ${DOXYGEN_INPUT_LIST} ${CMAKE_CURRENT_BINARY_DIR}/Doxyfile
+ COMMENT "Generating HTML documentation: ${DOXYGEN_HTML_OUTPUT_DIR}/index.html")
+add_custom_target(MaterialXDocs ALL DEPENDS ${DOXYGEN_HTML_OUTPUT_DIR}/index.html)
+
+install(DIRECTORY ${DOXYGEN_HTML_OUTPUT_DIR}
+ DESTINATION "documents" MESSAGE_NEVER)
diff --git a/MaterialX/documents/DeveloperGuide/GraphEditor.md b/MaterialX/documents/DeveloperGuide/GraphEditor.md
old mode 100644
new mode 100755
index 43b7f03..2375410
--- a/MaterialX/documents/DeveloperGuide/GraphEditor.md
+++ b/MaterialX/documents/DeveloperGuide/GraphEditor.md
@@ -1,82 +1,81 @@
-# MaterialX Graph Editor
-
-The MaterialX Graph Editor is an example application for visualizing, creating, and editing MaterialX graphs. It utilizes the ImGui framework as well as additional ImGui extensions such as the Node Editor.
-
-## Example Images
-
-**Figure 1:** MaterialX Graph Editor with procedural marble example
-
-
-
-## Building the MaterialX Graph Editor
-Select the `MATERIALX_BUILD_GRAPH_EDITOR` option in CMake to build the MaterialX Graph Editor. Installation will copy the **MaterialXGraphEditor** executable to a `/bin` directory within the selected install folder.
-
-## Summary of Graph Editor Features
-
-1. **`Load Material`**: Load a material document in the MTLX format.
-2. **`Save Material`**: Save out a graph as a material document in MTLX format.
-3. **`New Material`**: Clear all information to set up for the creation of a new material
-4. **`Node Property Editor`**: View or edit properties of the selected node.
-5. **`Render View`**: View the rendered material.
-
-## Buttons
-
-To display a new material and graph, click the `Load Material` button and navigate to the [Materials/Examples](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Materials/Examples) folder, which contains a selection of materials in the MTLX format, and select a document to load. The Graph Editor will display the graph hierarchy of the selected document for visualization and editing.
-
-To save out changes to the graphs as MTLX files click the `Save Material` button. This will save the position of the nodes in the graph for future use as well.
-
-## Editor Window
-
-The MaterialX document is displayed as nodes in the Editor window. When a file is initially loaded the material node, surface shader node, and any enclosing nodegraphs will be displayed. Double-clicking on a nodegraph, or any node defined as a subgraph, will display the contents of that graph.
-
-The current graph hierarchy is displayed above the editor. To back up and out of a subgraph click the `<` button to the left of the graph names.
-
-Each node and nodegraph displays its name and pins for all of its inputs and outputs. Nodes can be connected by clicking on the output pin of one node and connecting it to the input pin of another node, thus creating a link. Links can only be created if the input and output pins have the same type, as designated by the color of the pin. When a new link is created the material in the render view will automatically be updated.
-
-Using the tab key on the editor allows the user to add a certain node by bringing up the `Add Node` pop-up. The nodes are organized in the pop-up window based on their node group but a specific node can also be searched for by name. To create a nodegraph select `Node Graph` in the `Add Node` popup and dive into the node in order to add nodes inside of it and populate it.
-
-In order to connect to the nodegraph to a shader add output nodes inside the nodegraph then travel back up outside the nodegraph and connect the corresponding output pin to the surface shader. By default, the nodegraph does not contain any output nodes or pins.
-
-Another type of node present in the `Add Node` pop-up is the group, or background node. This background node can be used to group specific nodes and label by them by dragging them on to the background node.
-
-To search the editor window for a specific node use `CTRL` + `F` to bring up the search bar.
-
-## Node Property Editor
-When a node is selected in the graph, its information is displayed on the left-hand column in the `Node Property Editor`. This editor displays the name of the node, its category, its inputs, the input name, types and values. Inputs that are connected to other nodes will not display a value.
-
-This is where a node's properties such as its name and input values can be adjusted. When an input value is changed the material is automatically updated to reflect that change. The node info button displays the `doc` string for the selected node and its inputs if they exist. This `doc` string is currently read only.
-
-The show All Inputs checkbox displays all possible inputs for a node. With the box unchecked only inputs that have a connection or have had a value set will be shown. Only these inputs will be saved out when the graph is saved.
-
-## Render View
-Above the `Node Property Editor`, the `Render View` displays the current material on the Arnold Shader Ball. If inside a subgraph it will display the material associated with that subgraph; otherwise it will display the output of the selected node. It automatically updates when any changes are made to the graph.
-
-To adjust the relative sizes of the Node Property Editor and Render View windows, drag the separator between these windows in the application. The render view window camera can be changed using the left or right mouse buttons to manipulate the shader ball.
-
-## Keyboard Shortcuts
-
-- `TAB`: Add Node Popup
-- `Right Click`: pan along the editor
-- `Double Click on Node`: Dive into node's subgraph if it has one
-- `U`: Go up and out of a subgraph
-- `F`: Frame selected node(s)
-- `Ctrl + F` to search for a node in the editor by name
-- `Ctrl/Cmd + C` for Copying Nodes
-- `Ctrl/Cmd+X` for Cutting Nodes
-- `Ctrl/Cmd+V` for Pasting Nodes
-- `+` : Zoom in with the camera when mouse is over the Render View Window.
-- `-` : Zoom out with the camera when mouse is over the Render View Window.
-
-## Command-Line Options
-
-The following are common command-line options for MaterialXGraphEditor, and a complete list can be displayed with the `--help` option.
-- `--material [FILENAME]` : Specify the filename of the MTLX document to be displayed in the graph editor
-- `--mesh [FILENAME]` : Specify the filename of the OBJ or glTF mesh to be displayed in the graph editor
-- `--path [FILEPATH]` : Specify an additional data search path location (e.g. '/projects/MaterialX'). This absolute path will be queried when locating data libraries, XInclude references, and referenced images.
-- `--library [FILEPATH]` : Specify an additional data library folder (e.g. 'vendorlib', 'studiolib'). This relative path will be appended to each location in the data search path when loading data libraries.
-- `--captureFilename [FILENAME]` : Specify the filename to which the first rendered frame should be written
-
-## Known Limitations
-
-- Creating new connections using the `channels` attribute of an input is not yet supported, though existing `channels` connections will be displayed in graphs.
-- Assigning a new `colorspace` attribute to an input is not yet supported, though existing `colorspace` attributes on inputs will be respected by the render view.
+# MaterialX Graph Editor
+
+The MaterialX Graph Editor is an example application for visualizing, creating, and editing MaterialX graphs. It utilizes the ImGui framework as well as additional ImGui extensions such as the Node Editor.
+
+### Example Images
+
+**Figure 1:** MaterialX Graph Editor with procedural marble example
+
+
+## Building The MaterialX Graph Editor
+Select the `MATERIALX_BUILD_GRAPH_EDITOR` option in CMake to build the MaterialX Graph Editor. Installation will copy the **MaterialXGraphEditor** executable to a `/bin` directory within the selected install folder.
+
+### Summary of Graph Editor Features
+
+1. **Load Material**: Load a material document in the MTLX format.
+2. **Save Material**: Save out a graph as a mterial document in MTLX format.
+3. **New Material**: Clear all information to set up for the creation of a new material
+4. **Node Property Editor**: View or edit properties of the selected node.
+5. **Render View**: View the rendered material.
+
+### Buttons
+
+To display a new material and graph, click the `Load Material` button and and navigate to the [Example Materials](../../resources/Materials/Examples) folder, which contains a selection of materials in the MTLX format, and select a document to load. The Graph Editor will display the graph hierarchy of the selected document for visualization and editing.
+
+To save out changes to the graphs as MTLX files click the `Save Material` button. This will save the position of the nodes in the graph for future use as well.
+
+### Editor Window
+
+The MaterialX document is displayed as nodes in the Editor window. When a file is intially loaded the material node, surface shader node, and any enclosing nodegraphs will be displayed. Double-clicking on a nodegraph, or any node defined as a subgraph, will display the contents of that graph.
+
+The current graph hierarchy is displayed above the editor. To back up and out of a subgraph click the `<` button to the left of the graph names.
+
+Each node and nodegraph displays its name and pins for all of its inputs and outputs. Nodes can be connected by clicking on the output pin of one node and connecting it to the input pin of another node, thus creating a link. Links can only be created if the input and output pins have the same type, as designated by the color of the pin. When a new link is created the material in the render view will automatically be updated.
+
+Using the tab key on the editor allows the user to add a certain node by bringing up the `Add Node` pop-up. The nodes are organized in the pop-up window based on their node group but a specfic node can also be searched for by name. To create a nodegraph select `Node Graph` in the `Add Node` popup and dive into the node in order to add nodes inside of it and populate it.
+
+In order to connect to the nodegraph to a shader add output nodes inside the nodegraph then travel back up outside the nodegraph and connect the corresponding output pin to the surface shader. By default, the nodegraph does not contain any output nodes or pins.
+
+Another type of node present in the `Add Node` pop-up is the group, or background node. This background node can be used to group specific nodes and label by them by dragging them on to the background node.
+
+To search the editor window for a specific node use `CTRL` + `F` to bring up the search bar.
+
+### Node Property Editor
+When a node is selected in the graph, its information is displayed on the left-hand column in the `Node Property Editor`. This editor displays the name of the node, its category, its inputs, the input name, types and values. Inputs that are connected to other nodes will not display a value.
+
+This is where a node's properties such as its name and input values can be adjusted. When an input value is changed the material is automatically updated to reflect that change. The node info button displays the `doc` string for the selected node and its inputs if they exist. This `doc` string is currently read only.
+
+The show All Inputs checkbox displays all possible inputs for a node. With the box unchecked only inputs that have a connection or have had a value set will be shown. Only these inputs will be saved out when the graph is saved.
+
+### Render View
+Above the `Node Property Editor`, the `Render View` displays the current material on the Arnold Shader Ball. If inside a subgraph it will display the material associated with that subgraph; otherwise it will display the output of the selected node. It automatically updates when any changes are made to the graph.
+
+To adjust the relative sizes of the Node Property Editor and Render View windows, drag the separator between these windows in the application. The render view window camera can be changed using the left or right mouse buttons to manipulate the shader ball.
+
+### Keyboard Shortcuts
+
+- `TAB`: Add Node Popup
+- `Right Click`: pan along the editor
+- `Double Click on Node`: Dive into node's subgraph if it has one
+- `U`: Go up and out of a subgraph
+- `F`: Frame selected node(s)
+- `Ctrl + F` to search for a node in the editor by name
+- `Ctrl/Cmd + C` for Copying Nodes
+- `Ctrl/Cmd+X` for Cutting Nodes
+- `Ctrl/Cmd+V` for Pasting Nodes
+- `+` : Zoom in with the camera when mouse is over the Render View Window.
+- `-` : Zoom out with the camera when mouse is over the Render View Window.
+
+### Command-Line Options
+
+The following are common command-line options for MaterialXGraphEditor, and a complete list can be displayed with the `--help` option.
+- `--material [FILENAME]` : Specify the filename of the MTLX document to be displayed in the graph editor
+- `--mesh [FILENAME]` : Specify the filename of the OBJ or glTF mesh to be displayed in the graph editor
+- `--path [FILEPATH]` : Specify an additional data search path location (e.g. '/projects/MaterialX'). This absolute path will be queried when locating data libraries, XInclude references, and referenced images.
+- `--library [FILEPATH]` : Specify an additional data library folder (e.g. 'vendorlib', 'studiolib'). This relative path will be appended to each location in the data search path when loading data libraries.
+- `--captureFilename [FILENAME]` : Specify the filename to which the first rendered frame should be written
+
+### Known Limitations
+
+- Creating new connections using the `channels` attribute of an input is not yet supported, though existing `channels` connections will be displayed in graphs.
+- Assigning a new `colorspace` attribute to an input is not yet supported, though existing `colorspace` attributes on inputs will be respected by the render view.
diff --git a/MaterialX/documents/DeveloperGuide/MainPage.md b/MaterialX/documents/DeveloperGuide/MainPage.md
old mode 100644
new mode 100755
index 1c6a031..20068e4
--- a/MaterialX/documents/DeveloperGuide/MainPage.md
+++ b/MaterialX/documents/DeveloperGuide/MainPage.md
@@ -1,110 +1,85 @@
-# MaterialX Overview
-
-MaterialX is an open standard for representing rich material and look-development content in computer graphics, enabling its platform-independent description and exchange across applications and renderers. Launched at [Industrial Light & Magic](https://www.ilm.com/) in 2012, MaterialX has been a key technology in their feature films and real-time experiences since _Star Wars: The Force Awakens_ and _Millennium Falcon: Smugglers Run_. The project was released as open source in 2017, with companies including Sony Pictures Imageworks, Pixar, Autodesk, Adobe, and SideFX contributing to its ongoing development. In 2021, MaterialX became the seventh hosted project of the [Academy Software Foundation](https://www.aswf.io/).
-
-## Quick Start for Developers
-
-- Download the latest version of the [CMake](https://cmake.org/) build system.
-- Point CMake to the root of the MaterialX library and generate C++ projects for your platform and compiler.
-- Select the `MATERIALX_BUILD_PYTHON` option to build Python bindings.
-- Select the `MATERIALX_BUILD_VIEWER` option to build the [MaterialX Viewer](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/Viewer.md).
-- Select the `MATERIALX_BUILD_GRAPH_EDITOR` option to build the [MaterialX Graph Editor](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/DeveloperGuide/GraphEditor.md).
-
-## Supported Platforms
-
-The MaterialX codebase requires a compiler with support for C++17, and can be built with any of the following:
-
-- Microsoft Visual Studio 2017 or newer
-- GCC 8 or newer
-- Clang 5 or newer
-
-The Python bindings for MaterialX are based on [PyBind11](https://github.com/pybind/pybind11), and support Python versions 3.9 and greater.
-
-On macOS, you'll need to [install Xcode](https://developer.apple.com/xcode/resources/), in order to get access to the Metal Tools as well as compiler toolchains.
-
-## Building MaterialX
-
-### Building MaterialX C++
-
-The MaterialX C++ libraries are automatically included when building MaterialX through CMake.
-
-To enable OpenImageIO and OpenColorIO support in MaterialX builds, the following additional options may be used:
-
-- `MATERIALX_BUILD_OIIO`: Requests that MaterialXRender be built with OpenImageIO in addition to stb_image, extending the set of supported image formats. The minimum supported version of OpenImageIO is 2.2.
-- `MATERIALX_BUILD_OCIO`: Requests that MaterialXGenShader be built with support for custom OpenColorIO color spaces and transforms. The minimum supported version of OpenColorIO is 2.4.
-
-See the [MaterialX Unit Tests](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/source/MaterialXTest) page for documentation on shader generation and render testing in GLSL, OSL, and MDL.
-
-### Building MaterialX Python
-
-By default, the `MATERIALX_BUILD_PYTHON` option will use the active version of Python in the developer's path. To select a specific version of Python, use one or more of the following advanced options:
-
-- `MATERIALX_PYTHON_VERSION`: Python version to be used in building the MaterialX Python package (e.g. `3.9`)
-- `MATERIALX_PYTHON_EXECUTABLE`: Python executable to be used in building the MaterialX Python package (e.g. `C:/Python39/python.exe`)
-
-Additional options for the generation of MaterialX Python include the following:
-
-- `MATERIALX_PYTHON_PYBIND11_DIR`: Path to a folder containing the PyBind11 source to be used in building MaterialX Python. Defaults to the included PyBind11 source.
-
-### Building The MaterialX Viewer
-
-Select the `MATERIALX_BUILD_VIEWER` option to build the MaterialX Viewer. Installation will copy the `MaterialXView` executable to a `bin/` directory within the selected install folder.
-
-### Building API Documentation
-
-To generate HTML documentation for the MaterialX C++ API, make sure a version of [Doxygen](https://www.doxygen.org/) is on your path, and select the advanced option `MATERIALX_BUILD_DOCS` in CMake. This option will add a target named `MaterialXDocs` to your project, which can be built as an independent step from your development environment.
-
-## Editor Setup
-
-MaterialX should work in any editor that supports CMake, or that CMake can generate a project for.
-Some common Editors are listed here to help developers get started.
-
-### CLion
-
-[CLion](https://www.jetbrains.com/clion/) is a cross-platform IDE that can be used to develop MaterialX.
-Additionally, it includes CMake and is free for non-commercial Use.
-
-To get started with CLion, open the MaterialX repository directly, and it will load the CMake project for you.
-If you want to enable features like Python, go to `Settings -> Build, Execution and Deployment -> CMake` and configure
-the CMake Options, for example:
-
-```
--DMATERIALX_BUILD_PYTHON=ON
--DMATERIALX_BUILD_VIEWER=ON
--DMATERIALX_BUILD_GRAPH_EDITOR=ON
-```
-
-To build, either select `Build -> Build Project` or select a specific configuration to build.
-To install, select `Build -> Install`
-
-## Installing MaterialX
-
-Building the `install` target of your project will install the MaterialX C++ and Python libraries to the folder specified by the `CMAKE_INSTALL_PREFIX` setting, and will install MaterialX Python as a third-party library in your Python environment. Installation of MaterialX Python as a third-party library can be disabled by setting `MATERIALX_INSTALL_PYTHON` to `OFF`.
-
-## MaterialX Versioning
-
-The MaterialX codebase uses a modified semantic versioning system where the *major* and *minor* versions match that of the corresponding [MaterialX Specification](https://materialx.org/Specification.html), and the *build* version represents engineering advances within that specification version. MaterialX documents are similarly marked with the specification version they were authored in, and they are valid to load into any MaterialX codebase with an equal or higher specification version.
-
-Upgrading of MaterialX documents from earlier versions is handled at import time by the `Document::upgradeVersion()` method, which applies the syntax and node interface upgrades that have occurred in previous specification revisions. This allows the syntax conventions of MaterialX and the names and interfaces of nodes to evolve over time, without invalidating documents from earlier versions.
-
-### MaterialX API Changes
-
-The following rules describe the categories of changes to the [MaterialX API](https://materialx.org/docs/api/classes.html) that are allowed in version upgrades:
-
-- In *build* version upgrades, only non-breaking changes to the MaterialX API are allowed. For any API call that is modified in a build version upgrade, backwards compatibility should be maintained using deprecated C++ and Python wrappers for the original API call.
-- In *minor* and *major* version upgrades, breaking changes to the MaterialX API are allowed, though their benefit should be carefully weighed against their cost. Any breaking changes to API calls should be highlighted in the release notes for the new version.
-
-### MaterialX Data Library Changes
-
-The following rules describe the categories of changes to the [MaterialX Data Libraries](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/libraries) that are allowed in version upgrades:
-
-- In *build* version upgrades, only additive changes and fixes to the MaterialX data libraries are allowed. Additive changes are allowed to introduce new nodes, node versions, and node inputs with backwards-compatible default values. Data library fixes are allowed to update a node implementation to improve its alignment with the specification, without making any changes to its name or interface.
-- In *minor* version upgrades, changes to the names and interfaces of MaterialX nodes are allowed, with the requirement that version upgrade logic be used to maintain the validity and visual interpretation of documents from earlier versions.
-- In *major* version upgrades, changes to the syntax rules of MaterialX documents are allowed, with the requirement that version upgrade logic be used to maintain the validity and visual interpretation of documents from earlier versions. These changes usually require synchronized updates to both the MaterialX API and data libraries.
-
-## Additional Links
-
-- The main [MaterialX website](http://www.materialx.org) provides background on the project's history, industry collaborations, and recent presentations.
-- The [Python Scripts](https://github.com/materialx/MaterialX/tree/main/python/Scripts) folder contains standalone examples of MaterialX Python code.
-- The [MaterialX Unit Tests](https://github.com/materialx/MaterialX/tree/main/source/MaterialXTest) folder contains examples of useful patterns for MaterialX C++.
-- The [MaterialX Viewer](https://github.com/materialx/MaterialX/blob/main/documents/DeveloperGuide/Viewer.md) is a complete, cross-platform C++ application based upon [MaterialX Shader Generation](https://github.com/materialx/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md)
+# MaterialX Overview
+
+MaterialX is an open standard for representing rich material and look-development content in computer graphics, enabling its platform-independent description and exchange across applications and renderers. Launched at [Industrial Light & Magic](https://www.ilm.com/) in 2012, MaterialX has been a key technology in their feature films and real-time experiences since _Star Wars: The Force Awakens_ and _Millennium Falcon: Smugglers Run_. The project was released as open source in 2017, with companies including Sony Pictures Imageworks, Pixar, Autodesk, Adobe, and SideFX contributing to its ongoing development. In 2021, MaterialX became the seventh hosted project of the [Academy Software Foundation](https://www.aswf.io/).
+
+### Quick Start for Developers
+
+- Download the latest version of the [CMake](https://cmake.org/) build system.
+- Point CMake to the root of the MaterialX library and generate C++ projects for your platform and compiler.
+- Select the `MATERIALX_BUILD_PYTHON` option to build Python bindings.
+- Select the `MATERIALX_BUILD_VIEWER` option to build the MaterialX viewer.
+
+### Supported Platforms
+
+The MaterialX codebase requires a compiler with support for C++17, and can be built with any of the following:
+
+- Microsoft Visual Studio 2017 or newer
+- GCC 8 or newer
+- Clang 5 or newer
+
+The Python bindings for MaterialX are based on [PyBind11](https://github.com/pybind/pybind11), and support Python versions 3.6 and greater.
+
+### Building MaterialX
+
+#### Building MaterialX C++
+
+The MaterialX C++ libraries are automatically included when building MaterialX through CMake.
+
+To enable OpenImageIO support in MaterialX builds, the following additional options may be used:
+
+- `MATERIALX_BUILD_OIIO`: Requests that MaterialXRender be built with OpenImageIO in addition to stb_image, extending the set of supported image formats.
+- `MATERIALX_OIIO_DIR`: Path to the root folder of an OpenImageIO installation. If MATERIALX_BUILD_OIIO has been enabled, then this option may be used to select which installation is used.
+
+See the [MaterialX Unit Tests](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/source/MaterialXTest) page for documentation on shader generation and render testing in GLSL, OSL, and MDL.
+
+#### Building MaterialX Python
+
+By default, the `MATERIALX_BUILD_PYTHON` option will use the active version of Python in the developer's path. To select a specific version of Python, use one or more of the following advanced options:
+
+- `MATERIALX_PYTHON_VERSION`: Python version to be used in building the MaterialX Python package (e.g. `3.9`)
+- `MATERIALX_PYTHON_EXECUTABLE`: Python executable to be used in building the MaterialX Python package (e.g. `C:/Python39/python.exe`)
+
+Additional options for the generation of MaterialX Python include the following:
+
+- `MATERIALX_PYTHON_OCIO_DIR`: Path to a folder containing the default OCIO configuration to be packaged with MaterialX Python. The recommended OpenColorIO configuration for MaterialX is [ACES 1.2](https://github.com/colour-science/OpenColorIO-Configs/tree/feature/aces-1.2-config/aces_1.2).
+- `MATERIALX_PYTHON_PYBIND11_DIR`: Path to a folder containing the PyBind11 source to be used in building MaterialX Python. Defaults to the included PyBind11 source.
+
+#### Building The MaterialX Viewer
+
+Select the `MATERIALX_BUILD_VIEWER` option to build the MaterialX Viewer. Installation will copy the **MaterialXView** executable to a `bin/` directory within the selected install folder.
+
+#### Building API Documentation
+
+To generate HTML documentation for the MaterialX C++ API, make sure a version of [Doxygen](https://www.doxygen.org/) is on your path, and select the advanced option `MATERIALX_BUILD_DOCS` in CMake. This option will add a target named `MaterialXDocs` to your project, which can be built as an independent step from your development environment.
+
+### Installing MaterialX
+
+Building the `install` target of your project will install the MaterialX C++ and Python libraries to the folder specified by the `CMAKE_INSTALL_PREFIX` setting, and will install MaterialX Python as a third-party library in your Python environment. Installation of MaterialX Python as a third-party library can be disabled by setting `MATERIALX_INSTALL_PYTHON` to `OFF`.
+
+### MaterialX Versioning
+
+The MaterialX codebase uses a modified semantic versioning system where the *major* and *minor* versions match that of the corresponding MaterialX [specification](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/documents/Specification/MaterialX.Specification.md), and the *build* version represents engineering advances within that specification version. MaterialX documents are similarly marked with the specification version they were authored in, and they are valid to load into any MaterialX codebase with an equal or higher specification version.
+
+Upgrading of MaterialX documents from earlier versions is handled at import time by the `Document::upgradeVersion` method, which applies the syntax and node interface upgrades that have occurred in previous specification revisions. This allows the syntax conventions of MaterialX and the names and interfaces of nodes to evolve over time, without invalidating documents from earlier versions.
+
+#### MaterialX API Changes
+
+The following rules describe the categories of changes to the [MaterialX API](https://materialx.org/docs/api/classes.html) that are allowed in version upgrades:
+
+- In *build* version upgrades, only non-breaking changes to the MaterialX API are allowed. For any API call that is modified in a build version upgrade, backwards compatibility should be maintained using deprecated C++ and Python wrappers for the original API call.
+- In *minor* and *major* version upgrades, breaking changes to the MaterialX API are allowed, though their benefit should be carefully weighed against their cost. Any breaking changes to API calls should be highlighted in the release notes for the new version.
+
+#### MaterialX Data Library Changes
+
+The following rules describe the categories of changes to the [MaterialX Data Libraries](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/libraries) that are allowed in version upgrades:
+
+- In *build* version upgrades, only additive changes and fixes to the MaterialX data libraries are allowed. Additive changes are allowed to introduce new nodes, node versions, and node inputs with backwards-compatible default values. Data library fixes are allowed to update a node implementation to improve its alignment with the specification, without making any changes to its name or interface.
+- In *minor* version upgrades, changes to the names and interfaces of MaterialX nodes are allowed, with the requirement that version upgrade logic be used to maintain the validity and visual interpretation of documents from earlier versions.
+- In *major* version upgrades, changes to the syntax rules of MaterialX documents are allowed, with the requirement that version upgrade logic be used to maintain the validity and visual interpretation of documents from earlier versions. These changes usually require synchronized updates to both the MaterialX API and data libraries.
+
+### Additional Links
+
+- The main [MaterialX website](http://www.materialx.org) provides background on the project's history, industry collaborations, and recent presentations.
+- The [Python Scripts](https://github.com/materialx/MaterialX/tree/main/python/Scripts) folder contains standalone examples of MaterialX Python code.
+- The [MaterialX Unit Tests](https://github.com/materialx/MaterialX/tree/main/source/MaterialXTest) folder contains examples of useful patterns for MaterialX C++.
+- The [MaterialX Viewer](https://github.com/materialx/MaterialX/blob/main/documents/DeveloperGuide/Viewer.md) is a complete, cross-platform C++ application based upon [MaterialX Shader Generation](https://github.com/materialx/MaterialX/blob/main/documents/DeveloperGuide/ShaderGeneration.md)
diff --git a/MaterialX/documents/DeveloperGuide/ShaderGeneration.md b/MaterialX/documents/DeveloperGuide/ShaderGeneration.md
old mode 100644
new mode 100755
index 9bfd835..3296fca
--- a/MaterialX/documents/DeveloperGuide/ShaderGeneration.md
+++ b/MaterialX/documents/DeveloperGuide/ShaderGeneration.md
@@ -1,356 +1,356 @@
-# Shader Generation
-
-## 1.1 Scope
-A shader generation framework is implemented as part of MaterialX. This can help applications to transform the agnostic MaterialX data description into executable shader code for a specific renderer. A library module named MaterialXGenShader contains the core shader generation features, and support for specific languages resides in separate libraries, e.g. [MaterialXGenGlsl](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/source/MaterialXGenGlsl), [MaterialXGenOsl](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/source/MaterialXGenOsl).
-
-Note that this system has no runtime and the output produced is source code, not binary executable code. The source code produced needs to be compiled by a shading language compiler before being executed by the renderer. See Figure 1 for a high level overview of the system.
-
-
-
-**Figure 1:** Shader generation with multiple shader generators.
-
-## 1.2 Languages and Shader Generators
-The MaterialX description is free from device specific details and all implementation details needs to be taken care of by shader generators. There is one shader generator for each supported shading language. However for each language there can also be variations needed for different renderers. For example; OpenGL renderers supporting GLSL can use forward rendering or deferred rendering, each with very different requirements for how the shaders are constructed. Another example is different renderers supporting OSL but with different sets of closures or closure parameters. Hence a separate shader generator can be defined for each language/target combination.
-
-Class inheritance and specialization is used to create support for new languages or to customize existing language support for a new target. To add a new shader generator for a target you add a new C++ class derived from the base class `ShaderGenerator`, or one of the existing derived shader generator classes (`GlslShaderGenerator`, `OslShaderGenerator`, etc.), and override the methods you need to customize. You might also need to derive a new `Syntax` class, which is used to handle syntactical differences between different shading languages. Then you need to make sure there are implementations defined for all the nodes you want to support, standard library nodes and nodes from other libraries, by either reusing existing implementations where applicable or adding in new ones. See **1.3 Node Implementations** on how that is done.
-
-Note that a shader generator doesn’t need to be defined at the time when node definitions are added. New shader generators can be added later, and node implementations for new targets can be added for existing nodes.
-
-## 1.3 Node Implementations
-There are four different methods to define the implementation of a node:
-1. Using an inline expression.
-2. Using a function written in the target language.
-3. Using a nodegraph that defines the operation performed by the node.
-4. Using a C++ class that emits code dynamically during shader generation.
-
-In the following sub-sections each of these methods are explained. For all methods the implementation is tied to a specific `nodedef` with a well defined interface of typed inputs and outputs.
-
-### 1.3.1 Inline Expression
-Provided code generators support a very simple expression language for inlining code. This is useful for simple nodes where the operation can be expressed as a single line of code. Inlining will reduce the number of function calls and produce more compact code. The syntax to use is the same as the target shading language, with the addition of using the node’s input ports as variables wrapped in double curly brackets: `{{input}}`. The code generator will replace these variables with values assigned or connected to the respective inputs. Figure 2 gives an example.
-
-Connecting the expression to the `nodedef` is done using an `` element as seen in
-Figure 2. The first option is to keep inline code in a file. The file extension is used to differentiate inline expressions from source code functions, using `filename.inline`. The second option is to directly embed the inlined code using `sourcecode`. This is the recommended approach for inlining if there the logic can fit on one line of code.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-```c++
-// File 'mx_add.inline' contains:
-{{in1}} + {{in2}}
-```
-
-**Figure 2:** Inline expressions for implementing nodes `` and ``. The code for `` is stored in an additional file, while the code for `` is specified as part of the
-`` declaration.
-
-### 1.3.2 Shading Language Function
-For nodes that can’t be implemented by inline expressions a function definition can be used instead. The function signature should match the nodedefs interface with inputs and outputs. See Figure 3 for an example. Connecting the source code to the nodedef is done using an `` element, see the [MaterialX Specification](https://materialx.org/Specification.html) for more information.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-```c++
-// File 'mx_image_color3.osl' contains:
-void mx_image_color3(string file, string layer, color defaultvalue,
- vector2 texcoord, string uaddressmode, string vaddressmode, string filtertype,
- string framerange, int frameoffset, string frameendaction,
- output color out)
-{
- // Sample the texture
- out = texture(file, texcoord.x, texcoord.y,
- "interp", filtertype,
- "subimage", layer,
- "missingcolor", defaultvalue,
- "wrap", uaddressmode);
-}
-```
-**Figure 3:** Shading language function's implementation for node `` in OSL.
-
-### 1.3.3 Node Graph Implementation
-As an alternative to defining source code, there is also an option to reference a nodegraph as the implementation of a nodedef. The only requirement is that the nodegraph and nodedef have matching inputs and outputs.
-
-This is useful for creating a compound for a set of nodes performing some common operation. It can then be referenced as a node inside other nodegraphs. It is also useful for creating compatibility graphs for unknown nodes. If a node is created by some third party, and its implementation is unknown or proprietary, a compatibility graph can be created using known nodes and be referenced as a stand-in implementation. Linking a nodegraph to a nodedef is done by simply setting a nodedef attribute on the nodegraph definition. See Figure 4 for an example.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-**Figure 4:** Checker node implementation using a nodegraph.
-
-### 1.3.4 Dynamic Code Generation
-In some situations static source code is not enough to implement a node. The code might need to be customized depending on parameters set on the node. Or for a hardware render target vertex streams or uniform inputs might need to be created in order to supply the data needed for the node implementation.
-
-In this case, a C++ class can be added to handle the implementation of the node. The class should be derived from the base class `ShaderNodeImpl`. It should specify what target it is for by overriding `getTarget()`. It then needs to be registered for a `ShaderGenerator` by calling `ShaderGenerator::registerImplementation()`. See Figure 5 for an example.
-
-When a `ShaderNodeImpl` class is used for a nodedef the corresponding `` element doesn’t need a file attribute, since no static source code is used. The `` element will then act only as a declaration that there exists an implementation for the nodedef for a particular target.
-
-Note that by using a `ShaderNodeImpl` class for your node's implementation it is no longer data driven, as in the other three methods above. So it's recommended to use this only when inline expressions or static source code functions are not enough to handle the implementation of a node.
-
-```c++
-/// Implementation of ’foo' node for OSL
-class FooOsl : public ShaderNodeImpl
-{
- public:
- static ShaderNodeImplPtr create() { return std::make_shared(); }
-
- const string& getTarget() const override { return OslShaderGenerator::TARGET; }
-
- void emitFunctionDefinition(const ShaderNode& node, GenContext& context,
- ShaderStage& stage) const override
- {
- // Emit function definition if needed for the node
- }
-
- void emitFunctionCall(const ShaderNode& node, GenContext& context,
- ShaderStage& stage) const override
- {
- // Emit function call, or inline shader code, for the node
- }
-};
-```
-```c++
-OslShaderGenerator::OslShaderGenerator() :
- ShaderGenerator(std::make_shared())
-{
- ...
- // Register foo implementation for nodedefs it should be used for
- registerImplementation("IM_foo_color2_osl", FooOsl::create);
- registerImplementation("IM_foo_color3_osl", FooOsl::create);
- registerImplementation("IM_foo_color4_osl", FooOsl::create);
- ...
-}
-```
-**Figure 5:** C++ class for dynamic code generation.
-
-## 1.4 Shader Generation Steps
-This section outlines the steps taken in general to produce a shader from the MaterialX description. The `ShaderGenerator` base class and its supporting classes will handle this for you, but it’s good to know the steps involved if custom changes are needed to support a new target.
-
-Shader generation supports generating a shader starting from either an `output` element or a `shaderref` element in a material. The `output` can be an output port on a nodegraph or an output element inserted anywhere in a node network. A shader is generated by calling your shader generator class with either of these element types as input. The given element and all dependencies upstream will be translated into a single monolithic shader in the target shading language.
-
-```c++
-// Generate a shader starting from the given element, translating
-// the element and all dependencies upstream into shader code.
-ShaderPtr ShaderGenerator::generate(const string& name,
- ElementPtr element,
- GenContext& context)
-```
-
-The shader generation process can be divided into initialization and code generation. The initialization consists of a number of steps:
-1. Create an optimized version of the graph as a tree with the given input element as root, and with only the used dependencies connected upstream. This involves removing unused paths in the graph, converting constant nodes to constant values, and adding in any default nodes for ports that are unconnected but have default connections specified. Removal of unused paths typically involves constant folding and pruning of conditional branches that will never be taken. Since the resulting shader in the end will be compiled by a shading language compiler, and receive a lot of additional optimizations, we don’t need to do too much work in this optimization step. However, a few graph level optimizations can make the resulting shader a lot smaller and save time and memory during shader compilation. It will also produce more readable source code which is good for debugging purposes. This optimization step is also a good place to do other custom optimizations needed by a particular target. For example simplification of the graph, which could involve substituting expensive nodes with approximate nodes, identification of common subgraphs that can be merged, etc.
-2. The nodes are sorted in topological order. Since a node can be referenced by many other nodes in the graph we need an ordering of the nodes so that nodes that have a dependency on other nodes come after all dependent nodes. This step also makes sure there are no cyclic dependencies in the graph.
-3. The stages for the shader are created. For a HW shader this is normally a vertex stage and a pixel stage, but other stages can be added as needed. At the minimum a single pixel stage is required, so even shaders that has no concept of multiple stages, like OSL, needs to have a single pixel stage created.
-4. The shader stages interface of uniforms and varyings are established. This consists of the graph interface ports that are in use, as well as internal ports that have been published to the interface (an example of the latter is for a hardware shader generator where image texture filenames get converted to texture samplers which needs to be published in order to be bound by the target application). Each node in the graph is also called for a chance to create any uniforms or varyings needed by its implementation.
-5. Information about scope is tracked for each node. This information is needed to handle branching by conditional nodes. For example, if a node is used only by a particular branch on a varying conditional we want to calculate this node only inside that scope, when that corresponding branch is taken. A node can be used in global scope, in a single conditional scope or by multiple conditional scopes.
-
-The output from the initialization step is a new graph representation constructed using the classes `ShaderNode`, `ShaderInput`, `ShaderOutput`, `ShaderGraph`, etc. This is a graph representation optimized for shader generation with quick access and traversal of nodes and ports, as well as caching of extra information needed by shader generation.
-
-After initialization the code generation steps are handled by the `ShaderGenerator` class and derived classes. This part is specific to the particular generator being used, but in general it consists of the following steps:
-1. Typedefs are emitted as specified by the Syntax class.
-2. Function definitions are emitted for all the atomic nodes that have shading
-language functions for their implementations. For nodes using dynamic code generation their `ShaderNodeImpl` instances are called to generate the functions. For nodes that are implemented by graphs a function definition representing the graph computation is emitted.
-3. The shader signature is emitted with all uniforms set to default values. The shader uniforms can later be accessed on the returned `Shader` instance in order for applications to be able to bind values to them.
-4. The function calls for all nodes are emitted, in the right dependency order, propagating
-output results from upstream nodes as inputs to downstream nodes. Inline expressions are
-emitted instead of functions calls for nodes that use this.
-5. The final shader output is produced and assigned to the shader output variable.
-
-Note that if a single monolithic shader for the whole graph is not appropriate for your system, the generator can be called on `output` elements at any point in your graph, and generate code for sub-parts. It is then up to the application to decide where to split the graph, and to assemble the shader code for sub-parts after all have been generated.
-
-## 1.5 Shader Stages
-
-Creation of multiple shader stages is supported. This is needed in order to generate separate code for multiple stages on hardware render targets. A `pixel` stage must always be created by all targets, even for shading languages like OSL that natively doesn't have a concept of stages. The stage is where the generated shader code is stored as well as all uniforms, inputs and outputs for the shader. This is handled by the `ShaderStage` class, and the data can be retrieved from it when generation is completed.
-
-One or more `ShaderStage` instances are created and stored on the `Shader` class. In addition to the `pixel` stage, hardware generators always specify a `vertex` stage. If additional stages are needed they can be added as well. When creating shader input variables you specify which stage the variable should be used in, see 1.7 for more information on shader variable creation.
-
-Node implementations using static source code (function or inline expressions) are always emitted to the `pixel` stage. Controlling the `vertex` stage, or other stages, is not supported using static source code. In order to do that you must use dynamic code generation with a custom `ShaderNodeImpl` sub-class for your node. You are then able to control how it affects all stages separately. Inside `emitFunctionDefinition` and `emitFunctionCall` you can add separate sections for each stage using begin/end shader stage macros. Figure 6 shows how the texcoord node for GLSL is emitting different code into the `vertex` and `pixel` stages.
-
-## 1.6 Shader Variables
-When generating a shader from a node graph or shaderref the inputs and parameters on those elements will be published as shader uniforms on the resulting shader. A listing of the created uniforms can be read from the produced `Shader` and `ShaderStage` instances. The shader uniforms can then be presented to the user and have their values set by the application.
-
-### 1.6.1 Variable Creation
-Adding new uniforms, input and outputs to a shader stage is done by first creating a `VariableBlock` to store them. There are some predefined identifiers for commonly used variable blocks. For uniforms there are e.g. one named `HW::PUBLIC_UNIFORMS` and another named `HW::PRIVATE_UNIFORMS`. Public is used for uniforms to be published to the user, as described above, and private is used for uniforms needed by node implementations but set by the application and not published. For hardware targets there are also specific variable blocks called `connector blocks` which are used to send data from one stage to another, connecting the stages. A connector block named `HW::VERTEX_DATA` is used for sending data from the `vertex` stage to the `pixel` stage. Variable block creation and handling can be customized as needed by each shader generator target.
-
-All variable blocks can be queried and accessed by the application from the `ShaderStage` instances after generation.
-
-Figure 6 shows how creation of shader inputs and connector variables are done for a node implementation that requires this.
-
-```c++
-// Implementation of 'texcoord' node for GLSL
-class TexCoordGlsl : public ShaderNodeImpl
-{
- public:
- static ShaderNodeImplPtr create()
- {
- return std::make_shared();
- }
-
- void TexCoordNodeGlsl::createVariables(const ShaderNode& node, GenContext&,
- Shader& shader) const
- {
- const ShaderOutput* output = node.getOutput();
- const ShaderInput* indexInput = node.getInput(INDEX);
- const string index = indexInput ? indexInput->getValue()->getValueString() : "0";
-
- ShaderStage& vs = shader.getStage(Stage::VERTEX);
- ShaderStage& ps = shader.getStage(Stage::PIXEL);
-
- addStageInput(HW::VERTEX_INPUTS, output->getType(), "i_texcoord_" + index, vs);
- addStageConnector(HW::VERTEX_DATA, output->getType(), "texcoord_" + index, vs, ps);
- }
-
- void TexCoordNodeGlsl::emitFunctionCall(const ShaderNode& node,
- GenContext& context,
- ShaderStage& stage) const
- {
- const ShaderGenerator& shadergen = context.getShaderGenerator();
-
- const ShaderInput* indexInput = node.getInput(INDEX);
- const string index = indexInput ? indexInput->getValue()->getValueString() : "0";
- const string variable = "texcoord_" + index;
-
- DEFINE_SHADER_STAGE(stage, Stage::VERTEX)
- {
- VariableBlock& vertexData = stage.getOutputBlock(HW::VERTEX_DATA);
- const string prefix = vertexData.getInstance() + ".";
- ShaderPort* texcoord = vertexData[variable];
- if (!texcoord->isEmitted())
- {
- shadergen.emitLine(prefix + texcoord->getVariable() + " = i_" + variable, stage);
- texcoord->setEmitted();
- }
- }
-
- DEFINE_SHADER_STAGE(stage, Stage::PIXEL)
- {
- VariableBlock& vertexData = stage.getInputBlock(HW::VERTEX_DATA);
- const string prefix = vertexData.getInstance() + ".";
- ShaderPort* texcoord = vertexData[variable];
- shadergen.emitLineBegin(stage);
- shadergen.emitOutput(node.getOutput(), true, false, context, stage);
- shadergen.emitString(" = " + prefix + texcoord->getVariable(), stage);
- shadergen.emitLineEnd(stage);
- }
- }
-};
-```
-**Figure 6:** Implementation of node `texcoord` in GLSL. Using a `ShaderNodeImpl` sub-class in order to control shader variable creation and code generation into separate shader stages.
-
-### 1.6.2 Variable Naming Convention
-
-Creating shader variables and binding values to them needs to be done in agreement with the shader generator side and application side. The application must know what a variable is for in order to bind meaningful data to it. One way of handling this is by using semantics. All shader variables created can be assigned a semantic if that is used by the target application. Shader generation does not impose a specific set of semantics to use, so for languages and applications that use this any semantics can be used. For languages that do not use semantics a variable naming convention needs to be used instead.
-
-Built-in shader generators and accompanying node implementations have a naming convention for shader variables. A custom shader generator that derives from and takes advantage of built-in features should preferably use the same convention. Uniform variables are prefixed with `u_` and vertex inputs with `i_` . For languages not using semantics, Figure 7 shows the naming used for variables (inputs and uniforms) with predefined binding rules:
-
-App data input variables
-
-| NAME | TYPE | BINDING |
-| :--- | :--: | :--- |
-| i_position | vec3 | Vertex position in object space. |
-| i_normal | vec3 | Vertex normal in object space. |
-| i_tangent | vec3 | Vertex tangent in object space. |
-| i_bitangent | vec3 | Vertex bitangent in object space. |
-| i_texcoord_N | vec2 | Vertex texture coord for N:th uv set. |
-| i_color_N | vec4 | Vertex color for N:th color set. |
-
-
-Uniform variables
-
-| NAME | TYPE | BINDING |
-| :--- | :--: | :--- |
-| u_worldMatrix | mat4 | World transform. |
-| u_worldInverseMatrix | mat4 | World transform, inverted. |
-| u_worldTransposeMatrix | mat4 | World transform, transposed. |
-| u_worldInverseTransposeMatrix | mat4 | World transform, inverted, transposed. |
-| u_viewMatrix | mat4 | View transform. |
-| u_viewInverseMatrix | mat4 | View transform, inverted. |
-| u_viewTransposeMatrix | mat4 | View transform, transposed. |
-| u_viewInverseTransposeMatrix | mat4 | View transform, inverted, transposed. |
-| u_projectionMatrix | mat4 | Projection transform. |
-| u_projectionInverseMatrix | mat4 | Projection transform, inverted. |
-| u_projectionTransposeMatrix | mat4 | Projection transform, transposed. |
-| u_projectionInverseTransposeMatrix | mat4 | Projection transform, inverted, transposed. |
-| u_worldViewMatrix | mat4 | World-view transform. |
-| u_viewProjectionMatrix | mat4 | View-projection transform. |
-| u_worldViewProjectionMatrix | mat4 | World-view-projection transform. |
-| u_viewPosition | vec3 | World-space position of the viewer. |
-| u_viewDirection | vec3 | World-space direction of the viewer. |
-| u_frame | float | The current frame number as defined by the host application. |
-| u_time | float | The current time in seconds. |
-| u_geomprop_\ | \ | A named property of given \ where \ is the name of the variable on the geometry. |
-| u_numActiveLightSources | int | The number of currently active light sources. Note that in shader this is clamped against the maximum allowed number of light sources. |
-| u_lightData[] | struct | Array of struct LightData holding parameters for active light sources. The `LightData` struct is built dynamically depending on requirements for bound light shaders. |
-| u_\UnitTarget[] | integer | An attribute indicating the target unit for a given unit type definition (\). |
-
-**Figure 7:** Listing of predefined variables with their binding rules.
+# Shader Generation
+
+## 1.1 Scope
+A shader generation framework is implemented as part of MaterialX. This can help applications to transform the agnostic MaterialX data description into executable shader code for a specific renderer. A library module named MaterialXGenShader contains the core shader generation features, and support for specific languages resides in separate libraries, e.g. [MaterialXGenGlsl](/source/MaterialXGenGlsl), [MaterialXGenOsl](/source/MaterialXGenOsl).
+
+Note that this system has no runtime and the output produced is source code, not binary executable code. The source code produced needs to be compiled by a shading language compiler before being executed by the renderer. See Figure 1 for a high level overview of the system.
+
+
+
+**Figure 1**: Shader generation with multiple shader generators.
+
+## 1.2 Languages and Shader Generators
+The MaterialX description is free from device specific details and all implementation details needs to be taken care of by shader generators. There is one shader generator for each supported shading language. However for each language there can also be variations needed for different renderers. For example; OpenGL renderers supporting GLSL can use forward rendering or deferred rendering, each with very different requirements for how the shaders are constructed. Another example is different renderers supporting OSL but with different sets of closures or closure parameters. Hence a separate shader generator can be defined for each language/target combination.
+
+Class inheritance and specialization is used to create support for new languages or to customize existing language support for a new target. To add a new shader generator for a target you add a new C++ class derived from the base class `ShaderGenerator`, or one of the existing derived shader generator classes (`GlslShaderGenerator`, `OslShaderGenerator`, etc.), and override the methods you need to customize. You might also need to derive a new `Syntax` class, which is used to handle syntactical differences between different shading languages. Then you need to make sure there are implementations defined for all the nodes you want to support, standard library nodes and nodes from other libraries, by either reusing existing implementations where applicable or adding in new ones. See **1.3 Node Implementations** on how that is done.
+
+Note that a shader generator doesn’t need to be defined at the time when node definitions are added. New shader generators can be added later, and node implementations for new targets can be added for existing nodes.
+
+## 1.3 Node Implementations
+There are four different methods to define the implementation of a node:
+1. Using an inline expression.
+2. Using a function written in the target language.
+3. Using a nodegraph that defines the operation performed by the node.
+4. Using a C++ class that emits code dynamically during shader generation.
+
+In the following sub-sections each of these methods are explained. For all methods the implementation is tied to a specific `nodedef` with a well defined interface of typed inputs and outputs.
+
+### 1.3.1 Inline Expression
+Provided code generators support a very simple expression language for inlining code. This is useful for simple nodes where the operation can be expressed as a single line of code. Inlining will reduce the number of function calls and produce more compact code. The syntax to use is the same as the target shading language, with the addition of using the node’s input ports as variables wrapped in double curly brackets: `{{input}}`. The code generator will replace these variables with values assigned or connected to the respective inputs. Figure 2 gives an example.
+
+Connecting the expression to the nodedef is done using an `` element as seen in
+Figure 2. The first option is to keep inline code in a file. The file extension is used to differentiate inline expressions from source code functions, using `filename.inline`. The second option is to directly embed the inlined code using `sourcecode`. This is the recommended approach for inlining if there the logic can fit on one line of code.
+
+```xml
+// Nodedef elements for node
+
+
+
+
+
+
+
+
+
+
+<... more types ...>
+
+// Implementation elements for node
+
+
+<... more types ...>
+
+// Nodedef elements for node
+
+
+
+
+
+
+
+
+
+
+
+
+<... more types ...>
+
+// Implementation elements for node
+
+
+<... more types ...>
+```
+```c++
+// File 'mx_add.inline' contains:
+{{in1}} + {{in2}}
+```
+
+**Figure 2**: Inline expressions for implementing nodes `` and ``. The code for `` is stored in an additional file, while the code for `` is specified as part of the
+`` declaration.
+
+### 1.3.2 Shading Language Function
+For nodes that can’t be implemented by inline expressions a function definition can be used instead. The function signature should match the nodedefs interface with inputs and outputs. See Figure 3 for an example. Connecting the source code to the nodedef is done using an `` element, see the [MaterialX specification](../Specification/MaterialX.v1.36.Spec.pdf) for more information.
+
+```xml
+// Nodedef element
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+// Implementation element
+
+```
+```c++
+// File 'mx_image_color3.osl' contains:
+void mx_image_color3(string file, string layer, color defaultvalue,
+ vector2 texcoord, string uaddressmode, string vaddressmode, string filtertype,
+ string framerange, int frameoffset, string frameendaction,
+ output color out)
+{
+ // Sample the texture
+ out = texture(file, texcoord.x, texcoord.y,
+ "interp", filtertype,
+ "subimage", layer,
+ "missingcolor", defaultvalue,
+ "wrap", uaddressmode);
+}
+```
+**Figure 3**: Shading language function's implementation for node `` in OSL.
+
+### 1.3.3 Node Graph Implementation
+As an alternative to defining source code, there is also an option to reference a nodegraph as the implementation of a nodedef. The only requirement is that the nodegraph and nodedef have matching inputs and outputs.
+
+This is useful for creating a compound for a set of nodes performing some common operation. It can then be referenced as a node inside other nodegraphs. It is also useful for creating compatibility graphs for unknown nodes. If a node is created by some third party, and its implementation is unknown or proprietary, a compatibility graph can be created using known nodes and be referenced as a stand-in implementation. Linking a nodegraph to a nodedef is done by simply setting a nodedef attribute on the nodegraph definition. See Figure 4 for an example.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+**Figure 4**: Checker node implementation using a nodegraph.
+
+### 1.3.4 Dynamic Code Generation
+In some situations static source code is not enough to implement a node. The code might need to be customized depending on parameters set on the node. Or for a hardware render target vertex streams or uniform inputs might need to be created in order to supply the data needed for the node implementation.
+
+In this case, a C++ class can be added to handle the implementation of the node. The class should be derived from the base class `ShaderNodeImpl`. It should specify what target it is for by overriding `getTarget()`. It then needs to be registered for a `ShaderGenerator` by calling `ShaderGenerator::registerImplementation()`. See Figure 5 for an example.
+
+When a `ShaderNodeImpl` class is used for a nodedef the corresponding `` element doesn’t need a file attribute, since no static source code is used. The `` element will then act only as a declaration that there exists an implementation for the nodedef for a particular target.
+
+Note that by using a `ShaderNodeImpl` class for your node's implementation it is no longer data driven, as in the other three methods above. So it's recommended to use this only when inline expressions or static source code functions are not enough to handle the implementation of a node.
+
+```c++
+/// Implementation of ’foo' node for OSL
+class FooOsl : public ShaderNodeImpl
+{
+ public:
+ static ShaderNodeImplPtr create() { return std::make_shared(); }
+
+ const string& getTarget() const override { return OslShaderGenerator::TARGET; }
+
+ void emitFunctionDefinition(const ShaderNode& node, GenContext& context,
+ ShaderStage& stage) const override
+ {
+ // Emit function definition if needed for the node
+ }
+
+ void emitFunctionCall(const ShaderNode& node, GenContext& context,
+ ShaderStage& stage) const override
+ {
+ // Emit function call, or inline shader code, for the node
+ }
+};
+```
+```c++
+OslShaderGenerator::OslShaderGenerator() :
+ ShaderGenerator(std::make_shared())
+{
+ ...
+ // Register foo implementation for nodedefs it should be used for
+ registerImplementation("IM_foo_color2_osl", FooOsl::create);
+ registerImplementation("IM_foo_color3_osl", FooOsl::create);
+ registerImplementation("IM_foo_color4_osl", FooOsl::create);
+ ...
+}
+```
+**Figure 5**: C++ class for dynamic code generation.
+
+## 1.4 Shader Generation Steps
+This section outlines the steps taken in general to produce a shader from the MaterialX description. The `ShaderGenerator` base class and its supporting classes will handle this for you, but it’s good to know the steps involved if custom changes are needed to support a new target.
+
+Shader generation supports generating a shader starting from either an `output` element or a `shaderref` element in a material. The `output` can be an output port on a nodegraph or an output element inserted anywhere in a node network. A shader is generated by calling your shader generator class with either of these element types as input. The given element and all dependencies upstream will be translated into a single monolithic shader in the target shading language.
+
+```c++
+// Generate a shader starting from the given element, translating
+// the element and all dependencies upstream into shader code.
+ShaderPtr ShaderGenerator::generate(const string& name,
+ ElementPtr element,
+ GenContext& context)
+```
+
+The shader generation process can be divided into initialization and code generation. The initialization consists of a number of steps:
+1. Create an optimized version of the graph as a tree with the given input element as root, and with only the used dependencies connected upstream. This involves removing unused paths in the graph, converting constant nodes to constant values, and adding in any default nodes for ports that are unconnected but have default connections specified. Removal of unused paths typically involves constant folding and pruning of conditional branches that will never be taken. Since the resulting shader in the end will be compiled by a shading language compiler, and receive a lot of additional optimizations, we don’t need to do too much work in this optimization step. However, a few graph level optimizations can make the resulting shader a lot smaller and save time and memory during shader compilation. It will also produce more readable source code which is good for debugging purposes. This optimization step is also a good place to do other custom optimizations needed by a particular target. For example simplification of the graph, which could involve substituting expensive nodes with approximate nodes, identification of common subgraphs that can be merged, etc.
+2. The nodes are sorted in topological order. Since a node can be referenced by many other nodes in the graph we need an ordering of the nodes so that nodes that have a dependency on other nodes come after all dependent nodes. This step also makes sure there are no cyclic dependencies in the graph.
+3. The stages for the shader are created. For a HW shader this is normally a vertex stage and a pixel stage, but other stages can be added as needed. At the minumum a single pixel stage is required, so even shaders that has no concept of multiple stages, like OSL, needs to have a single pixel stage created.
+4. The shader stages interface of uniforms and varyings are established. This consists of the graph interface ports that are in use, as well as internal ports that have been published to the interface (an example of the latter is for a hardware shader generator where image texture filenames get converted to texture samplers which needs to be published in order to be bound by the target application). Each node in the graph is also called for a chance to create any uniforms or varyings needed by its implementation.
+5. Information about scope is tracked for each node. This information is needed to handle branching by conditional nodes. For example, if a node is used only by a particular branch on a varying conditional we want to calculate this node only inside that scope, when that corresponding branch is taken. A node can be used in global scope, in a single conditional scope or by multiple conditional scopes.
+
+The output from the initialization step is a new graph representation constructed using the classes `ShaderNode`, `ShaderInput`, `ShaderOutput`, `ShaderGraph`, etc. This is a graph representation optimized for shader generation with quick access and traversal of nodes and ports, as well as caching of extra information needed by shader generation.
+
+After initialization the code generation steps are handled by the `ShaderGenerator` class and derived classes. This part is specific to the particular generator being used, but in general it consists of the following steps:
+1. Typedefs are emitted as specified by the Syntax class.
+2. Function definitions are emitted for all the atomic nodes that have shading
+language functions for their implementations. For nodes using dynamic code generation their `ShaderNodeImpl` instances are called to generate the functions. For nodes that are implemented by graphs a function definition representing the graph computation is emitted.
+3. The shader signature is emitted with all uniforms set to default values. The shader uniforms can later be accessed on the returned `Shader` instance in order for applications to be able to bind values to them.
+4. The function calls for all nodes are emitted, in the right dependency order, propagating
+output results from upstream nodes as inputs to downstream nodes. Inline expressions are
+emitted instead of functions calls for nodes that use this.
+5. The final shader output is produced and assigned to the shader output variable.
+
+Note that if a single monolithic shader for the whole graph is not appropriate for your system the generator can be called on `output` elements at any point in your graph, and generate code for sub-parts. It is then up to the application to decide where to split the graph, and to assemble the shader code for sub-parts after all have been generated.
+
+## 1.5 Shader Stages
+
+Creation of multiple shader stages is supported. This is needed in order to generate separate code for multiple stages on hardware render targets. A `pixel` stage must always be created by all targets, even for shading languages like OSL that natively doensn't have a concept of stages. The stage is where the generated shader code is stored as well as all uniforms, inputs and outputs for the shader. This is handled by the `ShaderStage` class, and the data can be retrieved from it when generation is completed.
+
+One or more `ShaderStage` instances are created and stored on the `Shader` class. In addition to the `pixel` stage, hardware generators always specify a `vertex` stage. If additional stages are needed they can be added as well. When creating shader input variables you specify which stage the variable should be used in, see 1.7 for more information on shader variable creation.
+
+Node implementations using static source code (function or inline expressions) are always emitted to the `pixel` stage. Controlling the `vertex` stage, or other stages, is not supported using static source code. In order to do that you must use dynamic code generation with a custom `ShaderNodeImpl` sub-class for your node. You are then able to control how it affects all stages separately. Inside `emitFunctionDefinition` and `emitFunctionCall` you can add separate sections for each stage using begin/end shader stage macros. Figure 6 shows how the texcoord node for GLSL is emitting different code into the `vertex` and `pixel` stages.
+
+## 1.6 Shader Variables
+When generating a shader from a node graph or shaderref the inputs and parameters on those elements will be published as shader uniforms on the resulting shader. A listing of the created uniforms can be read from the produced `Shader` and `ShaderStage` instances. The shader uniforms can then be presented to the user and have their values set by the application.
+
+### 1.6.1 Variable Creation
+Adding new uniforms, input and outputs to a shader stage is done by first creating a `VariableBlock` to store them. There are some predefined identifiers for commonly used variable blocks. For uniforms there are e.g. one named `HW::PUBLIC_UNIFORMS` and another named `HW::PRIVATE_UNIFORMS`. Public is used for uniforms to be published to the user, as described above, and private is used for uniforms needed by node implementations but set by the application and not published. For hardware targets there are also specific variable blocks called `connector blocks` which are used to send data from one stage to another, connecting the stages. A connector block named `HW::VERTEX_DATA` is used for sending data from the `vertex` stage to the `pixel` stage. Variable block creation and handling can be customized as needed by each shader generator target.
+
+All variable blocks can be queried and accessed by the application from the `ShaderStage` instances after generation.
+
+Figure 6 shows how creation of shader inputs and connector variables are done for a node implementation that requires this.
+
+```c++
+// Implementation of 'texcoord' node for GLSL
+class TexCoordGlsl : public ShaderNodeImpl
+{
+ public:
+ static ShaderNodeImplPtr create()
+ {
+ return std::make_shared();
+ }
+
+ void TexCoordNodeGlsl::createVariables(const ShaderNode& node, GenContext&,
+ Shader& shader) const
+ {
+ const ShaderOutput* output = node.getOutput();
+ const ShaderInput* indexInput = node.getInput(INDEX);
+ const string index = indexInput ? indexInput->getValue()->getValueString() : "0";
+
+ ShaderStage& vs = shader.getStage(Stage::VERTEX);
+ ShaderStage& ps = shader.getStage(Stage::PIXEL);
+
+ addStageInput(HW::VERTEX_INPUTS, output->getType(), "i_texcoord_" + index, vs);
+ addStageConnector(HW::VERTEX_DATA, output->getType(), "texcoord_" + index, vs, ps);
+ }
+
+ void TexCoordNodeGlsl::emitFunctionCall(const ShaderNode& node,
+ GenContext& context,
+ ShaderStage& stage) const
+ {
+ const ShaderGenerator& shadergen = context.getShaderGenerator();
+
+ const ShaderInput* indexInput = node.getInput(INDEX);
+ const string index = indexInput ? indexInput->getValue()->getValueString() : "0";
+ const string variable = "texcoord_" + index;
+
+ DEFINE_SHADER_STAGE(stage, Stage::VERTEX)
+ {
+ VariableBlock& vertexData = stage.getOutputBlock(HW::VERTEX_DATA);
+ const string prefix = vertexData.getInstance() + ".";
+ ShaderPort* texcoord = vertexData[variable];
+ if (!texcoord->isEmitted())
+ {
+ shadergen.emitLine(prefix + texcoord->getVariable() + " = i_" + variable, stage);
+ texcoord->setEmitted();
+ }
+ }
+
+ DEFINE_SHADER_STAGE(stage, Stage::PIXEL)
+ {
+ VariableBlock& vertexData = stage.getInputBlock(HW::VERTEX_DATA);
+ const string prefix = vertexData.getInstance() + ".";
+ ShaderPort* texcoord = vertexData[variable];
+ shadergen.emitLineBegin(stage);
+ shadergen.emitOutput(node.getOutput(), true, false, context, stage);
+ shadergen.emitString(" = " + prefix + texcoord->getVariable(), stage);
+ shadergen.emitLineEnd(stage);
+ }
+ }
+};
+```
+**Figure 6**: Implementation of node `texcoord` in GLSL. Using a `ShaderNodeImpl` sub-class in order to control shader variable creation and code generation into separate shader stages.
+
+### 1.6.2 Variable Naming Convention
+
+Creating shader variables and binding values to them needs to be done in agreement with the shader generator side and application side. The application must know what a variable is for in order to bind meaningful data to it. One way of handling this is by using semantics. All shader variables created can be assigned a semantic if that is used by the target application. Shader generation does not impose a specific set of semantics to use, so for languages and applications that use this any semantics can be used. For languages that do not use semantics a variable naming convention needs to be used instead.
+
+Built-in shader generators and accompanying node implementations have a naming convention for shader variables. A custom shader generator that derives from and takes advantage of built-in features should preferably use the same convention. Uniform variables are prefixed with `u_` and vertex inputs with `i_` . For languages not using semantics, Figure 7 shows the naming used for variables (inputs and uniforms) with predefined binding rules:
+
+App data input variables
+
+| NAME | TYPE | BINDING |
+| :--- | :--: | :--- |
+| i_position | vec3 | Vertex position in object space. |
+| i_normal | vec3 | Vertex normal in object space. |
+| i_tangent | vec3 | Vertex tangent in object space. |
+| i_bitangent | vec3 | Vertex bitangent in object space. |
+| i_texcoord_N | vec2 | Vertex texture coord for N:th uv set. |
+| i_color_N | vec4 | Vertex color for N:th color set. |
+
+
+Uniform variables
+
+| NAME | TYPE | BINDING |
+| :--- | :--: | :--- |
+| u_worldMatrix | mat4 | World transform. |
+| u_worldInverseMatrix | mat4 | World transform, inverted. |
+| u_worldTransposeMatrix | mat4 | World transform, transposed. |
+| u_worldInverseTransposeMatrix | mat4 | World transform, inverted, transposed. |
+| u_viewMatrix | mat4 | View transform. |
+| u_viewInverseMatrix | mat4 | View transform, inverted. |
+| u_viewTransposeMatrix | mat4 | View transform, transposed. |
+| u_viewInverseTransposeMatrix | mat4 | View transform, inverted, transposed. |
+| u_projectionMatrix | mat4 | Projection transform. |
+| u_projectionInverseMatrix | mat4 | Projection transform, inverted. |
+| u_projectionTransposeMatrix | mat4 | Projection transform, transposed. |
+| u_projectionInverseTransposeMatrix | mat4 | Projection transform, inverted, transposed. |
+| u_worldViewMatrix | mat4 | World-view transform. |
+| u_viewProjectionMatrix | mat4 | View-projection transform. |
+| u_worldViewProjectionMatrix | mat4 | World-view-projection transform. |
+| u_viewPosition | vec3 | World-space position of the viewer. |
+| u_viewDirection | vec3 | World-space direction of the viewer. |
+| u_frame | float | The current frame number as defined by the host application. |
+| u_time | float | The current time in seconds. |
+| u_geomprop_\ | \ | A named property of given \ where \ is the name of the variable on the geometry. |
+| u_numActiveLightSources | int | The number of currently active light sources. Note that in shader this is clamped against the maximum allowed number of light sources. |
+| u_lightData[] | struct | Array of struct LightData holding parameters for active light sources. The `LightData` struct is built dynamically depending on requirements for bound light shaders. |
+| u_\UnitTarget[] | integer | An attribute indicating the target unit for a given unit type definition (\). |
+
+**Figure 7** : Listing of predefined variables with their binding rules.
diff --git a/MaterialX/documents/DeveloperGuide/Viewer.md b/MaterialX/documents/DeveloperGuide/Viewer.md
old mode 100644
new mode 100755
index 17155b1..0fed2eb
--- a/MaterialX/documents/DeveloperGuide/Viewer.md
+++ b/MaterialX/documents/DeveloperGuide/Viewer.md
@@ -1,114 +1,102 @@
-# MaterialX Viewer
-
-The MaterialX Viewer leverages shader generation to build GLSL shaders from MaterialX graphs, rendering the results using the NanoGUI framework. The standard set of pattern and physically based shading nodes is supported, and libraries of custom nodes can be included as additional library paths.
-
-## Example Images
-
-**Figure 1:** Procedural and uniform materials in the MaterialX viewer
-
-
-
-
-
-
-
-**Figure 2:** Textured, color-space-managed materials in the MaterialX viewer
-
-
-
-
-
-## Building The MaterialX Viewer
-Select the `MATERIALX_BUILD_VIEWER` option in CMake to build the MaterialX Viewer. Installation will copy the **MaterialXView** executable to a `/bin` directory within the selected install folder.
-
-## Summary of Viewer Options
-
-1. **`Load Mesh`**: Load a new geometry in the OBJ or glTF format.
-2. **`Load Material`**: Load a material document in the MTLX format.
-3. **`Load Environment`**: Load a lat-long environment light in the HDR format.
-4. **`Property Editor`**: View or edit properties of the current material.
-5. **`Advanced Settings`** : Asset and rendering options.
-
-## Geometry
-
-The default display geometry for the MaterialX viewer is the Arnold Shader Ball, which was contributed to the MaterialX project by the Solid Angle team at Autodesk. To change the display geometry, click `Load Mesh` and navigate to the [Geometry](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Geometry) folder for additional models in the OBJ format.
-
-If a loaded geometry contains more than one geometric group, then a `Select Geometry` drop-down box will appear, allowing the user to select which group is active. The active geometric group will be used for subsequent actions such as material assignment and rendering property changes.
-
-## Materials
-
-To change the displayed material, click `Load Material` and navigate to the [Materials/Examples/StandardSurface](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Materials/Examples/StandardSurface) or [Materials/Examples/UsdPreviewSurface](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Materials/Examples/UsdPreviewSurface) folders, which contain a selection of example materials in the MTLX format.
-
-Once a material is loaded into the viewer, its parameters may be inspected and adjusted by clicking the `Property Editor` and scrolling through the list of parameters. An edited material may be saved to the file system by clicking `Save Material`.
-
-Multiple material documents can be combined in a single session by navigating to `Advanced Settings` and enabling `Merge Materials`. Loading new materials with this setting enabled will add them to the current material list, where they can be assigned to geometry via the `Assigned Material` drop-down box. Alternatively the `LEFT` and `RIGHT` arrows can be used to cycle through the list of available materials.
-
-If a material document containing `look` elements is loaded into the viewer, then any material assignments within the look will be applied to geometric groups that match the specified geometry strings. See [standard_surface_look_brass_tiled.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Materials/Examples/StandardSurface/standard_surface_look_brass_tiled.mtlx) for an example of a material document containing look elements.
-
-## Lighting
-
-The default lighting environment for the viewer is the San Giuseppe Bridge environment from HDRI Haven. To load another environment into the viewer, click `Load Environment` and navigate to the [Lights](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/resources/Lights) folder, or load any HDR environment in the latitude-longitude format. If the HDR file on disk has a companion MaterialX document with a matching name, then this document will be loaded as the direct lighting rig for the environment; otherwise only indirect lighting will be rendered. If the HDR file on disk has a companion image in an `irradiance` subfolder, then this image will be loaded as the diffuse convolution of the environment; otherwise, a diffuse convolution will be generated at load-time using spherical harmonics.
-
-Shadow maps from the primary directional light may be enabled with the `Shadow Map` option under `Advanced Settings`. Ambient occlusion, if available for the given geometry, may be enabled with the `Ambient Occlusion` option. The fidelity of environment lighting may be improved by increasing the value of `Environment Samples`, though this requires additional GPU resources and can affect the interactivity of the viewer.
-
-## Images
-
-By default, the MaterialX viewer loads and saves image files using `stb_image`, which supports common 8-bit formats such as JPEG, PNG, TGA, and BMP, as well as the HDR format for high-dynamic-range images. If you need access to additional image formats such as EXR and TIFF, then the MaterialX viewer can be built with support for `OpenImageIO`. To build MaterialX with OpenImageIO, check the `MATERIALX_BUILD_OIIO` option in CMake, and specify the location of your OpenImageIO installation with the `MATERIALX_OIIO_DIR` option.
-
-## Keyboard Shortcuts
-
-- `R`: Reload the current material from file. Hold `SHIFT` to reload all standard libraries as well.
-- `G`: Save the current GLSL shader source to file.
-- `O`: Save the current OSL shader source to file.
-- `M`: Save the current MDL shader source to file.
-- `L`: Load GLSL shader source from file. Editing the source files before loading provides a way to debug and experiment with shader source code.
-- `D`: Save each node graph in the current material as a DOT file. See www.graphviz.org for more details on this format.
-- `F`: Capture the current frame and save to file.
-- `W`: Create a wedge rendering and save to file. See `Advanced Settings` for additional controls.
-- `T`: Translate the current material to a different shading model. See `Advanced Settings` for additional controls.
-- `B`: Bake the current material to textures. See `Advanced Settings` for additional controls.
-- `UP` : Select the previous geometry.
-- `DOWN` : Select the next geometry.
-- `RIGHT` : Switch to the next material.
-- `LEFT` : Switch to the previous material.
-- `+` : Zoom in with the camera.
-- `-` : Zoom out with the camera.
-
-## Command-Line Options
-
-The following are common command-line options for MaterialXView, and a complete list can be displayed with the `--help` option.
-- `--material [FILENAME]` : Specify the filename of the MTLX document to be displayed in the viewer
-- `--mesh [FILENAME]` : Specify the filename of the OBJ or glTF mesh to be displayed in the viewer
-- `--meshRotation [VECTOR3]` : Specify the rotation of the displayed mesh as three comma-separated floats, representing rotations in degrees about the X, Y, and Z axes (defaults to 0,0,0)
-- `--meshScale [FLOAT]` : Specify the uniform scale of the displayed mesh
-- `--cameraPosition [VECTOR3]` : Specify the position of the camera as three comma-separated floats (defaults to 0,0,5)
-- `--cameraTarget [VECTOR3]` : Specify the position of the camera target as three comma-separated floats (defaults to 0,0,0)
-- `--cameraViewAngle [FLOAT]` : Specify the view angle of the camera, or zero for an orthographic projection (defaults to 45)
-- `--cameraZoom [FLOAT]` : Specify the zoom factor for the camera, implemented as a mesh scale multiplier (defaults to 1)
-- `--envRad [FILENAME]` : Specify the filename of the environment light to display, stored as HDR environment radiance in the latitude-longitude format
-- `--envMethod [INTEGER]` : Specify the environment lighting method (0 = filtered importance sampling, 1 = prefiltered environment maps, defaults to 0)
-- `--envSampleCount [INTEGER]` : Specify the environment sample count (defaults to 16)
-- `--lightRotation [FLOAT]` : Specify the rotation in degrees of the lighting environment about the Y axis (defaults to 0)
-- `--path [FILEPATH]` : Specify an additional data search path location (e.g. '/projects/MaterialX'). This absolute path will be queried when locating data libraries, XInclude references, and referenced images.
-- `--library [FILEPATH]` : Specify an additional data library folder (e.g. 'vendorlib', 'studiolib'). This relative path will be appended to each location in the data search path when loading data libraries.
-- `--screenWidth [INTEGER]` : Specify the width of the screen image in pixels (defaults to 1280)
-- `--screenHeight [INTEGER]` : Specify the height of the screen image in pixels (defaults to 960)
-- `--screenColor [VECTOR3]` : Specify the background color of the viewer as three comma-separated floats (defaults to 0.3,0.3,0.32)
-- `--captureFilename [FILENAME]` : Specify the filename to which the first rendered frame should be written
-- `--refresh [FLOAT]` : Specify the refresh period for the viewer in milliseconds (defaults to 50, set to -1 to disable)
-- `--remap [TOKEN1:TOKEN2]` : Specify the remapping from one token to another when MaterialX document is loaded
-- `--skip [NAME]` : Specify to skip elements matching the given name attribute
-- `--terminator [STRING]` : Specify to enforce the given terminator string for file prefixes
-- `--help` : Display the complete list of command-line options
+# MaterialX Viewer
+
+The MaterialX Viewer leverages shader generation to build GLSL shaders from MaterialX graphs, rendering the results using the NanoGUI framework. The standard set of pattern and physically based shading nodes is supported, and libraries of custom nodes can be included as additional library paths.
+
+### Example Images
+
+**Figure 1:** Procedural and uniform materials in the MaterialX viewer
+
+
+
+
+
+
+
+**Figure 2:** Textured, color-space-managed materials in the MaterialX viewer
+
+
+
+
+
+## Building The MaterialX Viewer
+Select the `MATERIALX_BUILD_VIEWER` option in CMake to build the MaterialX Viewer. Installation will copy the **MaterialXView** executable to a `/bin` directory within the selected install folder.
+
+### Summary of Viewer Options
+
+1. **Load Mesh**: Load a new geometry in the OBJ or glTF format.
+2. **Load Material**: Load a material document in the MTLX format.
+3. **Load Environment**: Load a lat-long environment light in the HDR format.
+4. **Property Editor**: View or edit properties of the current material.
+5. **Advanced Settings** : Asset and rendering options.
+
+### Geometry
+
+The default display geometry for the MaterialX viewer is the Arnold Shader Ball, which was contributed to the MaterialX project by the Solid Angle team at Autodesk. To change the display geometry, click `Load Mesh` and navigate to the [Geometry](../../resources/Geometry) folder for additional models in the OBJ format.
+
+If a loaded geometry contains more than one geometric group, then a `Select Geometry` drop-down box will appear, allowing the user to select which group is active. The active geometric group will be used for subsequent actions such as material assignment and rendering property changes.
+
+### Materials
+
+To change the displayed material, click `Load Material` and navigate to the [Materials/Examples/StandardSurface](../../resources/Materials/Examples/StandardSurface) or [Materials/Examples/UsdPreviewSurface](../../resources/Materials/Examples/UsdPreviewSurface) folders, which contain a selection of example materials in the MTLX format.
+
+Once a material is loaded into the viewer, its parameters may be inspected and adjusted by clicking the `Property Editor` and scrolling through the list of parameters. An edited material may be saved to the file system by clicking `Save Material`.
+
+Multiple material documents can be combined in a single session by navigating to `Advanced Settings` and enabling `Merge Materials`. Loading new materials with this setting enabled will add them to the current material list, where they can be assigned to geometry via the `Assigned Material` drop-down box. Alternatively the `LEFT` and `RIGHT` arrows can be used to cycle through the list of available materials.
+
+If a material document containing `look` elements is loaded into the viewer, then any material assignments within the look will be applied to geometric groups that match the specified geometry strings. See [standard_surface_look_brass_tiled.mtlx](../../resources/Materials/Examples/StandardSurface/standard_surface_look_brass_tiled.mtlx) for an example of a material document containing look elements.
+
+### Lighting
+
+The default lighting environment for the viewer is the San Giuseppe Bridge environment from HDRI Haven. To load another environment into the viewer, click `Load Environment` and navigate to the [Lights](../../resources/Lights) folder, or load any HDR environment in the latitude-longitude format. If the HDR file on disk has a companion MaterialX document with a matching name, then this document will be loaded as the direct lighting rig for the environment; otherwise only indirect lighting will be rendered. If the HDR file on disk has a companion image in an `irradiance` subfolder, then this image will be loaded as the diffuse convolution of the environment; otherwise, a diffuse convolution will be generated at load-time using spherical harmonics.
+
+Shadow maps from the primary directional light may be enabled with the `Shadow Map` option under `Advanced Settings`. Ambient occlusion, if available for the given geometry, may be enabled with the `Ambient Occlusion` option. The fidelity of environment lighting may be improved by increasing the value of `Environment Samples`, though this requires additional GPU resources and can affect the interactivity of the viewer.
+
+### Images
+
+By default, the MaterialX viewer loads and saves image files using `stb_image`, which supports commmon 8-bit formats such as JPEG, PNG, TGA, and BMP, as well as the HDR format for high-dynamic-range images. If you need access to additional image formats such as EXR and TIFF, then the MaterialX viewer can be built with support for `OpenImageIO`. To build MaterialX with OpenImageIO, check the `MATERIALX_BUILD_OIIO` option in CMake, and specify the location of your OpenImageIO installation with the `MATERIALX_OIIO_DIR` option.
+
+### Keyboard Shortcuts
+
+- `R`: Reload the current material from file. Hold `SHIFT` to reload all standard libraries as well.
+- `G`: Save the current GLSL shader source to file.
+- `O`: Save the current OSL shader source to file.
+- `M`: Save the current MDL shader source to file.
+- `L`: Load GLSL shader source from file. Editing the source files before loading provides a way to debug and experiment with shader source code.
+- `D`: Save each node graph in the current material as a DOT file. See www.graphviz.org for more details on this format.
+- `F`: Capture the current frame and save to file.
+- `W`: Create a wedge rendering and save to file. See `Advanced Settings` for additional controls.
+- `T`: Translate the current material to a different shading model. See `Advanced Settings` for additional controls.
+- `B`: Bake the current material to textures. See `Advanced Settings` for additional controls.
+- `UP` : Select the previous geometry.
+- `DOWN` : Select the next geometry.
+- `RIGHT` : Switch to the next material.
+- `LEFT` : Switch to the previous material.
+- `+` : Zoom in with the camera.
+- `-` : Zoom out with the camera.
+
+### Command-Line Options
+
+The following are common command-line options for MaterialXView, and a complete list can be displayed with the `--help` option.
+- `--material [FILENAME]` : Specify the filename of the MTLX document to be displayed in the viewer
+- `--mesh [FILENAME]` : Specify the filename of the OBJ or glTF mesh to be displayed in the viewer
+- `--meshRotation [VECTOR3]` : Specify the rotation of the displayed mesh as three comma-separated floats, representing rotations in degrees about the X, Y, and Z axes (defaults to 0,0,0)
+- `--meshScale [FLOAT]` : Specify the uniform scale of the displayed mesh
+- `--cameraPosition [VECTOR3]` : Specify the position of the camera as three comma-separated floats (defaults to 0,0,5)
+- `--cameraTarget [VECTOR3]` : Specify the position of the camera target as three comma-separated floats (defaults to 0,0,0)
+- `--cameraViewAngle [FLOAT]` : Specify the view angle of the camera, or zero for an orthographic projection (defaults to 45)
+- `--cameraZoom [FLOAT]` : Specify the zoom factor for the camera, implemented as a mesh scale multiplier (defaults to 1)
+- `--envRad [FILENAME]` : Specify the filename of the environment light to display, stored as HDR environment radiance in the latitude-longitude format
+- `--envMethod [INTEGER]` : Specify the environment lighting method (0 = filtered importance sampling, 1 = prefiltered environment maps, defaults to 0)
+- `--envSampleCount [INTEGER]` : Specify the environment sample count (defaults to 16)
+- `--lightRotation [FLOAT]` : Specify the rotation in degrees of the lighting environment about the Y axis (defaults to 0)
+- `--path [FILEPATH]` : Specify an additional data search path location (e.g. '/projects/MaterialX'). This absolute path will be queried when locating data libraries, XInclude references, and referenced images.
+- `--library [FILEPATH]` : Specify an additional data library folder (e.g. 'vendorlib', 'studiolib'). This relative path will be appended to each location in the data search path when loading data libraries.
+- `--screenWidth [INTEGER]` : Specify the width of the screen image in pixels (defaults to 1280)
+- `--screenHeight [INTEGER]` : Specify the height of the screen image in pixels (defaults to 960)
+- `--screenColor [VECTOR3]` : Specify the background color of the viewer as three comma-separated floats (defaults to 0.3,0.3,0.32)
+- `--captureFilename [FILENAME]` : Specify the filename to which the first rendered frame should be written
+- `--refresh [FLOAT]` : Specify the refresh period for the viewer in milliseconds (defaults to 50, set to -1 to disable)
+- `--remap [TOKEN1:TOKEN2]` : Specify the remapping from one token to another when MaterialX document is loaded
+- `--skip [NAME]` : Specify to skip elements matching the given name attribute
+- `--terminator [STRING]` : Specify to enforce the given terminator string for file prefixes
+- `--help` : Display the complete list of command-line options
diff --git a/MaterialX/documents/Doxyfile.in b/MaterialX/documents/Doxyfile.in
old mode 100644
new mode 100755
index 890d2d7..007bb59
--- a/MaterialX/documents/Doxyfile.in
+++ b/MaterialX/documents/Doxyfile.in
@@ -1,28 +1,25 @@
-PROJECT_NAME = MaterialX
-PROJECT_NUMBER = ${MATERIALX_MAJOR_VERSION}.${MATERIALX_MINOR_VERSION}.${MATERIALX_BUILD_VERSION}
-PROJECT_LOGO = MaterialXLogo_200x155.png
-
-USE_MDFILE_AS_MAINPAGE = MainPage.md
-HTML_EXTRA_STYLESHEET = doxygen-awesome.css
-
-INPUT = ${DOXYGEN_INPUT_STR}
-OUTPUT_DIRECTORY = ${DOXYGEN_OUTPUT_DIR}
-IMAGE_PATH = ${DOXYGEN_OUTPUT_DIR}
-HTML_OUTPUT = ${DOXYGEN_HTML_OUTPUT_DIR}
-STRIP_FROM_PATH = ${PROJECT_SOURCE_DIR}
-
-JAVADOC_AUTOBRIEF = YES
-HIDE_SCOPE_NAMES = YES
-EXTRACT_LOCAL_CLASSES = NO
-GENERATE_TODOLIST = NO
-GENERATE_LATEX = NO
-
-GENERATE_TREEVIEW = YES
-DISABLE_INDEX = NO
-FULL_SIDEBAR = NO
-
-QUIET = YES
-WARN_IF_UNDOCUMENTED = NO
-
-GENERATE_XML = YES
-XML_OUTPUT = doxygen_xml
+PROJECT_NAME = MaterialX
+PROJECT_NUMBER = ${MATERIALX_MAJOR_VERSION}.${MATERIALX_MINOR_VERSION}.${MATERIALX_BUILD_VERSION}
+PROJECT_LOGO = MaterialXLogo_200x155.png
+
+USE_MDFILE_AS_MAINPAGE = MainPage.md
+HTML_EXTRA_STYLESHEET = doxygen-awesome.css
+
+INPUT = ${DOXYGEN_INPUT_STR}
+OUTPUT_DIRECTORY = ${DOXYGEN_OUTPUT_DIR}
+IMAGE_PATH = ${DOXYGEN_OUTPUT_DIR}
+HTML_OUTPUT = ${DOXYGEN_HTML_OUTPUT_DIR}
+STRIP_FROM_PATH = ${CMAKE_SOURCE_DIR}
+
+JAVADOC_AUTOBRIEF = YES
+HIDE_SCOPE_NAMES = YES
+EXTRACT_LOCAL_CLASSES = NO
+GENERATE_TODOLIST = NO
+GENERATE_LATEX = NO
+
+GENERATE_TREEVIEW = YES
+DISABLE_INDEX = NO
+FULL_SIDEBAR = NO
+
+QUIET = YES
+WARN_IF_UNDOCUMENTED = NO
diff --git a/MaterialX/documents/DoxygenAwesome/LICENSE b/MaterialX/documents/DoxygenAwesome/LICENSE
old mode 100644
new mode 100755
index 1d8b99a..f0e249c
--- a/MaterialX/documents/DoxygenAwesome/LICENSE
+++ b/MaterialX/documents/DoxygenAwesome/LICENSE
@@ -1,21 +1,21 @@
-MIT License
-
-Copyright (c) 2021 jothepro
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
+MIT License
+
+Copyright (c) 2021 jothepro
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
diff --git a/MaterialX/documents/DoxygenAwesome/doxygen-awesome.css b/MaterialX/documents/DoxygenAwesome/doxygen-awesome.css
old mode 100644
new mode 100755
index abd2893..9b869aa
--- a/MaterialX/documents/DoxygenAwesome/doxygen-awesome.css
+++ b/MaterialX/documents/DoxygenAwesome/doxygen-awesome.css
@@ -1,2405 +1,2405 @@
-/**
-
-Doxygen Awesome
-https://github.com/jothepro/doxygen-awesome-css
-
-MIT License
-
-Copyright (c) 2021 - 2022 jothepro
-
-Permission is hereby granted, free of charge, to any person obtaining a copy
-of this software and associated documentation files (the "Software"), to deal
-in the Software without restriction, including without limitation the rights
-to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
-copies of the Software, and to permit persons to whom the Software is
-furnished to do so, subject to the following conditions:
-
-The above copyright notice and this permission notice shall be included in all
-copies or substantial portions of the Software.
-
-THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
-IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
-FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
-AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
-LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
-OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
-SOFTWARE.
-
-*/
-
-html {
- /* primary theme color. This will affect the entire websites color scheme: links, arrows, labels, ... */
- --primary-color: #1779c4;
- --primary-dark-color: #335c80;
- --primary-light-color: #70b1e9;
-
- /* page base colors */
- --page-background-color: #ffffff;
- --page-foreground-color: #2f4153;
- --page-secondary-foreground-color: #6f7e8e;
-
- /* color for all separators on the website: hr, borders, ... */
- --separator-color: #dedede;
-
- /* border radius for all rounded components. Will affect many components, like dropdowns, memitems, codeblocks, ... */
- --border-radius-large: 8px;
- --border-radius-small: 4px;
- --border-radius-medium: 6px;
-
- /* default spacings. Most components reference these values for spacing, to provide uniform spacing on the page. */
- --spacing-small: 5px;
- --spacing-medium: 10px;
- --spacing-large: 16px;
-
- /* default box shadow used for raising an element above the normal content. Used in dropdowns, search result, ... */
- --box-shadow: 0 2px 8px 0 rgba(0,0,0,.075);
-
- --odd-color: rgba(0,0,0,.028);
-
- /* font-families. will affect all text on the website
- * font-family: the normal font for text, headlines, menus
- * font-family-monospace: used for preformatted text in memtitle, code, fragments
- */
- --font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Fira Sans,Droid Sans,Helvetica Neue,sans-serif;
- --font-family-monospace: ui-monospace,SFMono-Regular,SF Mono,Menlo,Consolas,Liberation Mono,monospace;
-
- /* font sizes */
- --page-font-size: 15.6px;
- --navigation-font-size: 14.4px;
- --toc-font-size: 13.4px;
- --code-font-size: 14px; /* affects code, fragment */
- --title-font-size: 22px;
-
- /* content text properties. These only affect the page content, not the navigation or any other ui elements */
- --content-line-height: 27px;
- /* The content is centered and constraint in it's width. To make the content fill the whole page, set the variable to auto.*/
- --content-maxwidth: 1050px;
- --table-line-height: 24px;
- --toc-sticky-top: var(--spacing-medium);
- --toc-width: 200px;
- --toc-max-height: calc(100vh - 2 * var(--spacing-medium) - 85px);
-
- /* colors for various content boxes: @warning, @note, @deprecated @bug */
- --warning-color: #f8d1cc;
- --warning-color-dark: #b61825;
- --warning-color-darker: #75070f;
- --note-color: #faf3d8;
- --note-color-dark: #f3a600;
- --note-color-darker: #5f4204;
- --todo-color: #e4f3ff;
- --todo-color-dark: #1879C4;
- --todo-color-darker: #274a5c;
- --deprecated-color: #ecf0f3;
- --deprecated-color-dark: #5b6269;
- --deprecated-color-darker: #43454a;
- --bug-color: #e4dafd;
- --bug-color-dark: #5b2bdd;
- --bug-color-darker: #2a0d72;
- --invariant-color: #d8f1e3;
- --invariant-color-dark: #44b86f;
- --invariant-color-darker: #265532;
-
- /* blockquote colors */
- --blockquote-background: #f8f9fa;
- --blockquote-foreground: #636568;
-
- /* table colors */
- --tablehead-background: #f1f1f1;
- --tablehead-foreground: var(--page-foreground-color);
-
- /* menu-display: block | none
- * Visibility of the top navigation on screens >= 768px. On smaller screen the menu is always visible.
- * `GENERATE_TREEVIEW` MUST be enabled!
- */
- --menu-display: block;
-
- --menu-focus-foreground: var(--page-background-color);
- --menu-focus-background: var(--primary-color);
- --menu-selected-background: rgba(0,0,0,.05);
-
-
- --header-background: var(--page-background-color);
- --header-foreground: var(--page-foreground-color);
-
- /* searchbar colors */
- --searchbar-background: var(--side-nav-background);
- --searchbar-foreground: var(--page-foreground-color);
-
- /* searchbar size
- * (`searchbar-width` is only applied on screens >= 768px.
- * on smaller screens the searchbar will always fill the entire screen width) */
- --searchbar-height: 33px;
- --searchbar-width: 210px;
- --searchbar-border-radius: var(--searchbar-height);
-
- /* code block colors */
- --code-background: #f5f5f5;
- --code-foreground: var(--page-foreground-color);
-
- /* fragment colors */
- --fragment-background: #F8F9FA;
- --fragment-foreground: #37474F;
- --fragment-keyword: #bb6bb2;
- --fragment-keywordtype: #8258b3;
- --fragment-keywordflow: #d67c3b;
- --fragment-token: #438a59;
- --fragment-comment: #969696;
- --fragment-link: #5383d6;
- --fragment-preprocessor: #46aaa5;
- --fragment-linenumber-color: #797979;
- --fragment-linenumber-background: #f4f4f5;
- --fragment-linenumber-border: #e3e5e7;
- --fragment-lineheight: 20px;
-
- /* sidebar navigation (treeview) colors */
- --side-nav-background: #fbfbfb;
- --side-nav-foreground: var(--page-foreground-color);
- --side-nav-arrow-opacity: 0;
- --side-nav-arrow-hover-opacity: 0.9;
-
- --toc-background: var(--side-nav-background);
- --toc-foreground: var(--side-nav-foreground);
-
- /* height of an item in any tree / collapsable table */
- --tree-item-height: 30px;
-
- --memname-font-size: var(--code-font-size);
- --memtitle-font-size: 18px;
-
- --webkit-scrollbar-size: 7px;
- --webkit-scrollbar-padding: 4px;
- --webkit-scrollbar-color: var(--separator-color);
-}
-
-@media screen and (max-width: 767px) {
- html {
- --page-font-size: 16px;
- --navigation-font-size: 16px;
- --toc-font-size: 15px;
- --code-font-size: 15px; /* affects code, fragment */
- --title-font-size: 22px;
- }
-}
-
-@media (prefers-color-scheme: dark) {
- html:not(.light-mode) {
- color-scheme: dark;
-
- --primary-color: #1982d2;
- --primary-dark-color: #86a9c4;
- --primary-light-color: #4779ac;
-
- --box-shadow: 0 2px 8px 0 rgba(0,0,0,.35);
-
- --odd-color: rgba(100,100,100,.06);
-
- --menu-selected-background: rgba(0,0,0,.4);
-
- --page-background-color: #1C1D1F;
- --page-foreground-color: #d2dbde;
- --page-secondary-foreground-color: #859399;
- --separator-color: #38393b;
- --side-nav-background: #252628;
-
- --code-background: #2a2c2f;
-
- --tablehead-background: #2a2c2f;
-
- --blockquote-background: #222325;
- --blockquote-foreground: #7e8c92;
-
- --warning-color: #2e1917;
- --warning-color-dark: #ad2617;
- --warning-color-darker: #f5b1aa;
- --note-color: #3b2e04;
- --note-color-dark: #f1b602;
- --note-color-darker: #ceb670;
- --todo-color: #163750;
- --todo-color-dark: #1982D2;
- --todo-color-darker: #dcf0fa;
- --deprecated-color: #2e323b;
- --deprecated-color-dark: #738396;
- --deprecated-color-darker: #abb0bd;
- --bug-color: #2a2536;
- --bug-color-dark: #7661b3;
- --bug-color-darker: #ae9ed6;
- --invariant-color: #303a35;
- --invariant-color-dark: #76ce96;
- --invariant-color-darker: #cceed5;
-
- --fragment-background: #282c34;
- --fragment-foreground: #dbe4eb;
- --fragment-keyword: #cc99cd;
- --fragment-keywordtype: #ab99cd;
- --fragment-keywordflow: #e08000;
- --fragment-token: #7ec699;
- --fragment-comment: #999999;
- --fragment-link: #98c0e3;
- --fragment-preprocessor: #65cabe;
- --fragment-linenumber-color: #cccccc;
- --fragment-linenumber-background: #35393c;
- --fragment-linenumber-border: #1f1f1f;
- }
-}
-
-/* dark mode variables are defined twice, to support both the dark-mode without and with doxygen-awesome-darkmode-toggle.js */
-html.dark-mode {
- color-scheme: dark;
-
- --primary-color: #1982d2;
- --primary-dark-color: #86a9c4;
- --primary-light-color: #4779ac;
-
- --box-shadow: 0 2px 8px 0 rgba(0,0,0,.30);
-
- --odd-color: rgba(100,100,100,.06);
-
- --menu-selected-background: rgba(0,0,0,.4);
-
- --page-background-color: #1C1D1F;
- --page-foreground-color: #d2dbde;
- --page-secondary-foreground-color: #859399;
- --separator-color: #38393b;
- --side-nav-background: #252628;
-
- --code-background: #2a2c2f;
-
- --tablehead-background: #2a2c2f;
-
- --blockquote-background: #222325;
- --blockquote-foreground: #7e8c92;
-
- --warning-color: #2e1917;
- --warning-color-dark: #ad2617;
- --warning-color-darker: #f5b1aa;
- --note-color: #3b2e04;
- --note-color-dark: #f1b602;
- --note-color-darker: #ceb670;
- --todo-color: #163750;
- --todo-color-dark: #1982D2;
- --todo-color-darker: #dcf0fa;
- --deprecated-color: #2e323b;
- --deprecated-color-dark: #738396;
- --deprecated-color-darker: #abb0bd;
- --bug-color: #2a2536;
- --bug-color-dark: #7661b3;
- --bug-color-darker: #ae9ed6;
- --invariant-color: #303a35;
- --invariant-color-dark: #76ce96;
- --invariant-color-darker: #cceed5;
-
- --fragment-background: #282c34;
- --fragment-foreground: #dbe4eb;
- --fragment-keyword: #cc99cd;
- --fragment-keywordtype: #ab99cd;
- --fragment-keywordflow: #e08000;
- --fragment-token: #7ec699;
- --fragment-comment: #999999;
- --fragment-link: #98c0e3;
- --fragment-preprocessor: #65cabe;
- --fragment-linenumber-color: #cccccc;
- --fragment-linenumber-background: #35393c;
- --fragment-linenumber-border: #1f1f1f;
-}
-
-body {
- color: var(--page-foreground-color);
- background-color: var(--page-background-color);
- font-size: var(--page-font-size);
-}
-
-body, table, div, p, dl, #nav-tree .label, .title,
-.sm-dox a, .sm-dox a:hover, .sm-dox a:focus, #projectname,
-.SelectItem, #MSearchField, .navpath li.navelem a,
-.navpath li.navelem a:hover, p.reference, p.definition {
- font-family: var(--font-family);
-}
-
-h1, h2, h3, h4, h5 {
- margin-top: .9em;
- font-weight: 600;
- line-height: initial;
-}
-
-p, div, table, dl, p.reference, p.definition {
- font-size: var(--page-font-size);
-}
-
-p.reference, p.definition {
- color: var(--page-secondary-foreground-color);
-}
-
-a:link, a:visited, a:hover, a:focus, a:active {
- color: var(--primary-color) !important;
- font-weight: 500;
-}
-
-a.anchor {
- scroll-margin-top: var(--spacing-large);
- display: block;
-}
-
-/*
- Title and top navigation
- */
-
-#top {
- background: var(--header-background);
- border-bottom: 1px solid var(--separator-color);
-}
-
-@media screen and (min-width: 768px) {
- #top {
- display: flex;
- flex-wrap: wrap;
- justify-content: space-between;
- align-items: center;
- }
-}
-
-#main-nav {
- flex-grow: 5;
- padding: var(--spacing-small) var(--spacing-medium);
-}
-
-#titlearea {
- width: auto;
- padding: var(--spacing-medium) var(--spacing-large);
- background: none;
- color: var(--header-foreground);
- border-bottom: none;
-}
-
-@media screen and (max-width: 767px) {
- #titlearea {
- padding-bottom: var(--spacing-small);
- }
-}
-
-#titlearea table tbody tr {
- height: auto !important;
-}
-
-#projectname {
- font-size: var(--title-font-size);
- font-weight: 600;
-}
-
-#projectnumber {
- font-family: inherit;
- font-size: 60%;
-}
-
-#projectbrief {
- font-family: inherit;
- font-size: 80%;
-}
-
-#projectlogo {
- vertical-align: middle;
-}
-
-#projectlogo img {
- max-height: calc(var(--title-font-size) * 2);
- margin-right: var(--spacing-small);
-}
-
-.sm-dox, .tabs, .tabs2, .tabs3 {
- background: none;
- padding: 0;
-}
-
-.tabs, .tabs2, .tabs3 {
- border-bottom: 1px solid var(--separator-color);
- margin-bottom: -1px;
-}
-
-.main-menu-btn-icon, .main-menu-btn-icon:before, .main-menu-btn-icon:after {
- background: var(--page-secondary-foreground-color);
-}
-
-@media screen and (max-width: 767px) {
- .sm-dox a span.sub-arrow {
- background: var(--code-background);
- }
-
- #main-menu a.has-submenu span.sub-arrow {
- color: var(--page-secondary-foreground-color);
- border-radius: var(--border-radius-medium);
- }
-
- #main-menu a.has-submenu:hover span.sub-arrow {
- color: var(--page-foreground-color);
- }
-}
-
-@media screen and (min-width: 768px) {
- .sm-dox li, .tablist li {
- display: var(--menu-display);
- }
-
- .sm-dox a span.sub-arrow {
- border-color: var(--header-foreground) transparent transparent transparent;
- }
-
- .sm-dox a:hover span.sub-arrow {
- border-color: var(--menu-focus-foreground) transparent transparent transparent;
- }
-
- .sm-dox ul a span.sub-arrow {
- border-color: transparent transparent transparent var(--page-foreground-color);
- }
-
- .sm-dox ul a:hover span.sub-arrow {
- border-color: transparent transparent transparent var(--menu-focus-foreground);
- }
-}
-
-.sm-dox ul {
- background: var(--page-background-color);
- box-shadow: var(--box-shadow);
- border: 1px solid var(--separator-color);
- border-radius: var(--border-radius-medium) !important;
- padding: var(--spacing-small);
- animation: ease-out 150ms slideInMenu;
-}
-
-@keyframes slideInMenu {
- from {
- opacity: 0;
- transform: translate(0px, -2px);
- }
-
- to {
- opacity: 1;
- transform: translate(0px, 0px);
- }
-}
-
-.sm-dox ul a {
- color: var(--page-foreground-color) !important;
- background: var(--page-background-color);
- font-size: var(--navigation-font-size);
-}
-
-.sm-dox>li>ul:after {
- border-bottom-color: var(--page-background-color) !important;
-}
-
-.sm-dox>li>ul:before {
- border-bottom-color: var(--separator-color) !important;
-}
-
-.sm-dox ul a:hover, .sm-dox ul a:active, .sm-dox ul a:focus {
- font-size: var(--navigation-font-size) !important;
- color: var(--menu-focus-foreground) !important;
- text-shadow: none;
- background-color: var(--menu-focus-background);
- border-radius: var(--border-radius-small) !important;
-}
-
-.sm-dox a, .sm-dox a:focus, .tablist li, .tablist li a, .tablist li.current a {
- text-shadow: none;
- background: transparent;
- background-image: none !important;
- color: var(--header-foreground) !important;
- font-weight: normal;
- font-size: var(--navigation-font-size);
- border-radius: var(--border-radius-small) !important;
-}
-
-.sm-dox a:focus {
- outline: auto;
-}
-
-.sm-dox a:hover, .sm-dox a:active, .tablist li a:hover {
- text-shadow: none;
- font-weight: normal;
- background: var(--menu-focus-background);
- color: var(--menu-focus-foreground) !important;
- border-radius: var(--border-radius-small) !important;
- font-size: var(--navigation-font-size);
-}
-
-.tablist li.current {
- border-radius: var(--border-radius-small);
- background: var(--menu-selected-background);
-}
-
-.tablist li {
- margin: var(--spacing-small) 0 var(--spacing-small) var(--spacing-small);
-}
-
-.tablist a {
- padding: 0 var(--spacing-large);
-}
-
-
-/*
- Search box
- */
-
-#MSearchBox {
- height: var(--searchbar-height);
- background: var(--searchbar-background);
- border-radius: var(--searchbar-border-radius);
- border: 1px solid var(--separator-color);
- overflow: hidden;
- width: var(--searchbar-width);
- position: relative;
- box-shadow: none;
- display: block;
- margin-top: 0;
-}
-
-/* until Doxygen 1.9.4 */
-.left img#MSearchSelect {
- left: 0;
- user-select: none;
- padding-left: 8px;
-}
-
-/* Doxygen 1.9.5 */
-.left span#MSearchSelect {
- left: 0;
- user-select: none;
- margin-left: 8px;
- padding: 0;
-}
-
-.left #MSearchSelect[src$=".png"] {
- padding-left: 0
-}
-
-.SelectionMark {
- user-select: none;
-}
-
-.tabs .left #MSearchSelect {
- padding-left: 0;
-}
-
-.tabs #MSearchBox {
- position: absolute;
- right: var(--spacing-medium);
-}
-
-@media screen and (max-width: 767px) {
- .tabs #MSearchBox {
- position: relative;
- right: 0;
- margin-left: var(--spacing-medium);
- margin-top: 0;
- }
-}
-
-#MSearchSelectWindow, #MSearchResultsWindow {
- z-index: 9999;
-}
-
-#MSearchBox.MSearchBoxActive {
- border-color: var(--primary-color);
- box-shadow: inset 0 0 0 1px var(--primary-color);
-}
-
-#main-menu > li:last-child {
- margin-right: 0;
-}
-
-@media screen and (max-width: 767px) {
- #main-menu > li:last-child {
- height: 50px;
- }
-}
-
-#MSearchField {
- font-size: var(--navigation-font-size);
- height: calc(var(--searchbar-height) - 2px);
- background: transparent;
- width: calc(var(--searchbar-width) - 64px);
-}
-
-.MSearchBoxActive #MSearchField {
- color: var(--searchbar-foreground);
-}
-
-#MSearchSelect {
- top: calc(calc(var(--searchbar-height) / 2) - 11px);
-}
-
-#MSearchBox span.left, #MSearchBox span.right {
- background: none;
- background-image: none;
-}
-
-#MSearchBox span.right {
- padding-top: calc(calc(var(--searchbar-height) / 2) - 12px);
- position: absolute;
- right: var(--spacing-small);
-}
-
-.tabs #MSearchBox span.right {
- top: calc(calc(var(--searchbar-height) / 2) - 12px);
-}
-
-@keyframes slideInSearchResults {
- from {
- opacity: 0;
- transform: translate(0, 15px);
- }
-
- to {
- opacity: 1;
- transform: translate(0, 20px);
- }
-}
-
-#MSearchResultsWindow {
- left: auto !important;
- right: var(--spacing-medium);
- border-radius: var(--border-radius-large);
- border: 1px solid var(--separator-color);
- transform: translate(0, 20px);
- box-shadow: var(--box-shadow);
- animation: ease-out 280ms slideInSearchResults;
- background: var(--page-background-color);
-}
-
-iframe#MSearchResults {
- margin: 4px;
-}
-
-iframe {
- color-scheme: normal;
-}
-
-@media (prefers-color-scheme: dark) {
- html:not(.light-mode) iframe#MSearchResults {
- filter: invert() hue-rotate(180deg);
- }
-}
-
-html.dark-mode iframe#MSearchResults {
- filter: invert() hue-rotate(180deg);
-}
-
-#MSearchResults .SRPage {
- background-color: transparent;
-}
-
-#MSearchResults .SRPage .SREntry {
- font-size: 10pt;
- padding: var(--spacing-small) var(--spacing-medium);
-}
-
-#MSearchSelectWindow {
- border: 1px solid var(--separator-color);
- border-radius: var(--border-radius-medium);
- box-shadow: var(--box-shadow);
- background: var(--page-background-color);
- padding-top: var(--spacing-small);
- padding-bottom: var(--spacing-small);
-}
-
-#MSearchSelectWindow a.SelectItem {
- font-size: var(--navigation-font-size);
- line-height: var(--content-line-height);
- margin: 0 var(--spacing-small);
- border-radius: var(--border-radius-small);
- color: var(--page-foreground-color) !important;
- font-weight: normal;
-}
-
-#MSearchSelectWindow a.SelectItem:hover {
- background: var(--menu-focus-background);
- color: var(--menu-focus-foreground) !important;
-}
-
-@media screen and (max-width: 767px) {
- #MSearchBox {
- margin-top: var(--spacing-medium);
- margin-bottom: var(--spacing-medium);
- width: calc(100vw - 30px);
- }
-
- #main-menu > li:last-child {
- float: none !important;
- }
-
- #MSearchField {
- width: calc(100vw - 110px);
- }
-
- @keyframes slideInSearchResultsMobile {
- from {
- opacity: 0;
- transform: translate(0, 15px);
- }
-
- to {
- opacity: 1;
- transform: translate(0, 20px);
- }
- }
-
- #MSearchResultsWindow {
- left: var(--spacing-medium) !important;
- right: var(--spacing-medium);
- overflow: auto;
- transform: translate(0, 20px);
- animation: ease-out 280ms slideInSearchResultsMobile;
- width: auto !important;
- }
-
- /*
- * Overwrites for fixing the searchbox on mobile in doxygen 1.9.2
- */
- label.main-menu-btn ~ #searchBoxPos1 {
- top: 3px !important;
- right: 6px !important;
- left: 45px;
- display: flex;
- }
-
- label.main-menu-btn ~ #searchBoxPos1 > #MSearchBox {
- margin-top: 0;
- margin-bottom: 0;
- flex-grow: 2;
- float: left;
- }
-}
-
-/*
- Tree view
- */
-
-#side-nav {
- padding: 0 !important;
- background: var(--side-nav-background);
-}
-
-@media screen and (max-width: 767px) {
- #side-nav {
- display: none;
- }
-
- #doc-content {
- margin-left: 0 !important;
- }
-}
-
-#nav-tree {
- background: transparent;
-}
-
-#nav-tree .label {
- font-size: var(--navigation-font-size);
-}
-
-#nav-tree .item {
- height: var(--tree-item-height);
- line-height: var(--tree-item-height);
-}
-
-#nav-sync {
- bottom: 12px;
- right: 12px;
- top: auto !important;
- user-select: none;
-}
-
-#nav-tree .selected {
- text-shadow: none;
- background-image: none;
- background-color: transparent;
- position: relative;
-}
-
-#nav-tree .selected::after {
- content: "";
- position: absolute;
- top: 1px;
- bottom: 1px;
- left: 0;
- width: 4px;
- border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
- background: var(--primary-color);
-}
-
-
-#nav-tree a {
- color: var(--side-nav-foreground) !important;
- font-weight: normal;
-}
-
-#nav-tree a:focus {
- outline-style: auto;
-}
-
-#nav-tree .arrow {
- opacity: var(--side-nav-arrow-opacity);
-}
-
-.arrow {
- color: inherit;
- cursor: pointer;
- font-size: 45%;
- vertical-align: middle;
- margin-right: 2px;
- font-family: serif;
- height: auto;
- text-align: right;
-}
-
-#nav-tree div.item:hover .arrow, #nav-tree a:focus .arrow {
- opacity: var(--side-nav-arrow-hover-opacity);
-}
-
-#nav-tree .selected a {
- color: var(--primary-color) !important;
- font-weight: bolder;
- font-weight: 600;
-}
-
-.ui-resizable-e {
- background: var(--separator-color);
- width: 1px;
-}
-
-/*
- Contents
- */
-
-div.header {
- border-bottom: 1px solid var(--separator-color);
- background-color: var(--page-background-color);
- background-image: none;
-}
-
-@media screen and (min-width: 1000px) {
- #doc-content > div > div.contents,
- .PageDoc > div.contents {
- display: flex;
- flex-direction: row-reverse;
- flex-wrap: nowrap;
- align-items: flex-start;
- }
-
- div.contents .textblock {
- min-width: 200px;
- flex-grow: 1;
- }
-}
-
-div.contents, div.header .title, div.header .summary {
- max-width: var(--content-maxwidth);
-}
-
-div.contents, div.header .title {
- line-height: initial;
- margin: calc(var(--spacing-medium) + .2em) auto var(--spacing-medium) auto;
-}
-
-div.header .summary {
- margin: var(--spacing-medium) auto 0 auto;
-}
-
-div.headertitle {
- padding: 0;
-}
-
-div.header .title {
- font-weight: 600;
- font-size: 225%;
- padding: var(--spacing-medium) var(--spacing-large);
- word-break: break-word;
-}
-
-div.header .summary {
- width: auto;
- display: block;
- float: none;
- padding: 0 var(--spacing-large);
-}
-
-td.memSeparator {
- border-color: var(--separator-color);
-}
-
-span.mlabel {
- background: var(--primary-color);
- border: none;
- padding: 4px 9px;
- border-radius: 12px;
- margin-right: var(--spacing-medium);
-}
-
-span.mlabel:last-of-type {
- margin-right: 2px;
-}
-
-div.contents {
- padding: 0 var(--spacing-large);
-}
-
-div.contents p, div.contents li {
- line-height: var(--content-line-height);
-}
-
-div.contents div.dyncontent {
- margin: var(--spacing-medium) 0;
-}
-
-@media (prefers-color-scheme: dark) {
- html:not(.light-mode) div.contents div.dyncontent img,
- html:not(.light-mode) div.contents center img,
- html:not(.light-mode) div.contents > table img,
- html:not(.light-mode) div.contents div.dyncontent iframe,
- html:not(.light-mode) div.contents center iframe,
- html:not(.light-mode) div.contents table iframe {
- filter: hue-rotate(180deg) invert();
- }
-}
-
-html.dark-mode div.contents div.dyncontent img,
-html.dark-mode div.contents center img,
-html.dark-mode div.contents > table img,
-html.dark-mode div.contents div.dyncontent iframe,
-html.dark-mode div.contents center iframe,
-html.dark-mode div.contents table iframe {
- filter: hue-rotate(180deg) invert();
-}
-
-h2.groupheader {
- border-bottom: 0px;
- color: var(--page-foreground-color);
- box-shadow:
- 100px 0 var(--page-background-color),
- -100px 0 var(--page-background-color),
- 100px 0.75px var(--separator-color),
- -100px 0.75px var(--separator-color),
- 500px 0 var(--page-background-color),
- -500px 0 var(--page-background-color),
- 500px 0.75px var(--separator-color),
- -500px 0.75px var(--separator-color),
- 900px 0 var(--page-background-color),
- -900px 0 var(--page-background-color),
- 900px 0.75px var(--separator-color),
- -900px 0.75px var(--separator-color),
- 1400px 0 var(--page-background-color),
- -1400px 0 var(--page-background-color),
- 1400px 0.75px var(--separator-color),
- -1400px 0.75px var(--separator-color),
- 1900px 0 var(--page-background-color),
- -1900px 0 var(--page-background-color),
- 1900px 0.75px var(--separator-color),
- -1900px 0.75px var(--separator-color);
-}
-
-blockquote {
- margin: 0 var(--spacing-medium) 0 var(--spacing-medium);
- padding: var(--spacing-small) var(--spacing-large);
- background: var(--blockquote-background);
- color: var(--blockquote-foreground);
- border-left: 0;
- overflow: visible;
- border-radius: var(--border-radius-medium);
- overflow: visible;
- position: relative;
-}
-
-blockquote::before, blockquote::after {
- font-weight: bold;
- font-family: serif;
- font-size: 360%;
- opacity: .15;
- position: absolute;
-}
-
-blockquote::before {
- content: "“";
- left: -10px;
- top: 4px;
-}
-
-blockquote::after {
- content: "”";
- right: -8px;
- bottom: -25px;
-}
-
-blockquote p {
- margin: var(--spacing-small) 0 var(--spacing-medium) 0;
-}
-.paramname {
- font-weight: 600;
- color: var(--primary-dark-color);
-}
-
-.paramname > code {
- border: 0;
-}
-
-table.params .paramname {
- font-weight: 600;
- font-family: var(--font-family-monospace);
- font-size: var(--code-font-size);
- padding-right: var(--spacing-small);
- line-height: var(--table-line-height);
-}
-
-h1.glow, h2.glow, h3.glow, h4.glow, h5.glow, h6.glow {
- text-shadow: 0 0 15px var(--primary-light-color);
-}
-
-.alphachar a {
- color: var(--page-foreground-color);
-}
-
-/*
- Table of Contents
- */
-
-div.contents .toc {
- max-height: var(--toc-max-height);
- min-width: var(--toc-width);
- border: 0;
- border-left: 1px solid var(--separator-color);
- border-radius: 0;
- background-color: transparent;
- box-shadow: none;
- position: sticky;
- top: var(--toc-sticky-top);
- padding: 0 var(--spacing-large);
- margin: var(--spacing-small) 0 var(--spacing-large) var(--spacing-large);
-}
-
-div.toc h3 {
- color: var(--toc-foreground);
- font-size: var(--navigation-font-size);
- margin: var(--spacing-large) 0 var(--spacing-medium) 0;
-}
-
-div.toc li {
- padding: 0;
- background: none;
- line-height: var(--toc-font-size);
- margin: var(--toc-font-size) 0 0 0;
-}
-
-div.toc li::before {
- display: none;
-}
-
-div.toc ul {
- margin-top: 0
-}
-
-div.toc li a {
- font-size: var(--toc-font-size);
- color: var(--page-foreground-color) !important;
- text-decoration: none;
-}
-
-div.toc li a:hover, div.toc li a.active {
- color: var(--primary-color) !important;
-}
-
-div.toc li a.aboveActive {
- color: var(--page-secondary-foreground-color) !important;
-}
-
-
-@media screen and (max-width: 999px) {
- div.contents .toc {
- max-height: 45vh;
- float: none;
- width: auto;
- margin: 0 0 var(--spacing-medium) 0;
- position: relative;
- top: 0;
- position: relative;
- border: 1px solid var(--separator-color);
- border-radius: var(--border-radius-medium);
- background-color: var(--toc-background);
- box-shadow: var(--box-shadow);
- }
-
- div.contents .toc.interactive {
- max-height: calc(var(--navigation-font-size) + 2 * var(--spacing-large));
- overflow: hidden;
- }
-
- div.contents .toc > h3 {
- -webkit-tap-highlight-color: transparent;
- cursor: pointer;
- position: sticky;
- top: 0;
- background-color: var(--toc-background);
- margin: 0;
- padding: var(--spacing-large) 0;
- display: block;
- }
-
- div.contents .toc.interactive > h3::before {
- content: "";
- width: 0;
- height: 0;
- border-left: 4px solid transparent;
- border-right: 4px solid transparent;
- border-top: 5px solid var(--primary-color);
- display: inline-block;
- margin-right: var(--spacing-small);
- margin-bottom: calc(var(--navigation-font-size) / 4);
- transform: rotate(-90deg);
- transition: transform 0.25s ease-out;
- }
-
- div.contents .toc.interactive.open > h3::before {
- transform: rotate(0deg);
- }
-
- div.contents .toc.interactive.open {
- max-height: 45vh;
- overflow: auto;
- transition: max-height 0.2s ease-in-out;
- }
-
- div.contents .toc a, div.contents .toc a.active {
- color: var(--primary-color) !important;
- }
-
- div.contents .toc a:hover {
- text-decoration: underline;
- }
-}
-
-/*
- Code & Fragments
- */
-
-code, div.fragment, pre.fragment {
- border-radius: var(--border-radius-small);
- border: 1px solid var(--separator-color);
- overflow: hidden;
-}
-
-code {
- display: inline;
- background: var(--code-background);
- color: var(--code-foreground);
- padding: 2px 6px;
-}
-
-div.fragment, pre.fragment {
- margin: var(--spacing-medium) 0;
- padding: calc(var(--spacing-large) - (var(--spacing-large) / 6)) var(--spacing-large);
- background: var(--fragment-background);
- color: var(--fragment-foreground);
- overflow-x: auto;
-}
-
-@media screen and (max-width: 767px) {
- div.fragment, pre.fragment {
- border-top-right-radius: 0;
- border-bottom-right-radius: 0;
- border-right: 0;
- }
-
- .contents > div.fragment,
- .textblock > div.fragment,
- .textblock > pre.fragment,
- .contents > .doxygen-awesome-fragment-wrapper > div.fragment,
- .textblock > .doxygen-awesome-fragment-wrapper > div.fragment,
- .textblock > .doxygen-awesome-fragment-wrapper > pre.fragment {
- margin: var(--spacing-medium) calc(0px - var(--spacing-large));
- border-radius: 0;
- border-left: 0;
- }
-
- .textblock li > .fragment,
- .textblock li > .doxygen-awesome-fragment-wrapper > .fragment {
- margin: var(--spacing-medium) calc(0px - var(--spacing-large));
- }
-
- .memdoc li > .fragment,
- .memdoc li > .doxygen-awesome-fragment-wrapper > .fragment {
- margin: var(--spacing-medium) calc(0px - var(--spacing-medium));
- }
-
- .textblock ul, .memdoc ul {
- overflow: initial;
- }
-
- .memdoc > div.fragment,
- .memdoc > pre.fragment,
- dl dd > div.fragment,
- dl dd pre.fragment,
- .memdoc > .doxygen-awesome-fragment-wrapper > div.fragment,
- .memdoc > .doxygen-awesome-fragment-wrapper > pre.fragment,
- dl dd > .doxygen-awesome-fragment-wrapper > div.fragment,
- dl dd .doxygen-awesome-fragment-wrapper > pre.fragment {
- margin: var(--spacing-medium) calc(0px - var(--spacing-medium));
- border-radius: 0;
- border-left: 0;
- }
-}
-
-code, code a, pre.fragment, div.fragment, div.fragment .line, div.fragment span, div.fragment .line a, div.fragment .line span {
- font-family: var(--font-family-monospace);
- font-size: var(--code-font-size) !important;
-}
-
-div.line:after {
- margin-right: var(--spacing-medium);
-}
-
-div.fragment .line, pre.fragment {
- white-space: pre;
- word-wrap: initial;
- line-height: var(--fragment-lineheight);
-}
-
-div.fragment span.keyword {
- color: var(--fragment-keyword);
-}
-
-div.fragment span.keywordtype {
- color: var(--fragment-keywordtype);
-}
-
-div.fragment span.keywordflow {
- color: var(--fragment-keywordflow);
-}
-
-div.fragment span.stringliteral {
- color: var(--fragment-token)
-}
-
-div.fragment span.comment {
- color: var(--fragment-comment);
-}
-
-div.fragment a.code {
- color: var(--fragment-link) !important;
-}
-
-div.fragment span.preprocessor {
- color: var(--fragment-preprocessor);
-}
-
-div.fragment span.lineno {
- display: inline-block;
- width: 27px;
- border-right: none;
- background: var(--fragment-linenumber-background);
- color: var(--fragment-linenumber-color);
-}
-
-div.fragment span.lineno a {
- background: none;
- color: var(--fragment-link) !important;
-}
-
-div.fragment .line:first-child .lineno {
- box-shadow: -999999px 0px 0 999999px var(--fragment-linenumber-background), -999998px 0px 0 999999px var(--fragment-linenumber-border);
-}
-
-div.line {
- border-radius: var(--border-radius-small);
-}
-
-div.line.glow {
- background-color: var(--primary-light-color);
- box-shadow: none;
-}
-
-/*
- dl warning, attention, note, deprecated, bug, ...
- */
-
-dl.bug dt a, dl.deprecated dt a, dl.todo dt a {
- font-weight: bold !important;
-}
-
-dl.warning, dl.attention, dl.note, dl.deprecated, dl.bug, dl.invariant, dl.pre, dl.todo, dl.remark {
- padding: var(--spacing-medium);
- margin: var(--spacing-medium) 0;
- color: var(--page-background-color);
- overflow: hidden;
- margin-left: 0;
- border-radius: var(--border-radius-small);
-}
-
-dl.section dd {
- margin-bottom: 2px;
-}
-
-dl.warning, dl.attention {
- background: var(--warning-color);
- border-left: 8px solid var(--warning-color-dark);
- color: var(--warning-color-darker);
-}
-
-dl.warning dt, dl.attention dt {
- color: var(--warning-color-dark);
-}
-
-dl.note, dl.remark {
- background: var(--note-color);
- border-left: 8px solid var(--note-color-dark);
- color: var(--note-color-darker);
-}
-
-dl.note dt, dl.remark dt {
- color: var(--note-color-dark);
-}
-
-dl.todo {
- background: var(--todo-color);
- border-left: 8px solid var(--todo-color-dark);
- color: var(--todo-color-darker);
-}
-
-dl.todo dt {
- color: var(--todo-color-dark);
-}
-
-dl.bug dt a {
- color: var(--todo-color-dark) !important;
-}
-
-dl.bug {
- background: var(--bug-color);
- border-left: 8px solid var(--bug-color-dark);
- color: var(--bug-color-darker);
-}
-
-dl.bug dt a {
- color: var(--bug-color-dark) !important;
-}
-
-dl.deprecated {
- background: var(--deprecated-color);
- border-left: 8px solid var(--deprecated-color-dark);
- color: var(--deprecated-color-darker);
-}
-
-dl.deprecated dt a {
- color: var(--deprecated-color-dark) !important;
-}
-
-dl.section dd, dl.bug dd, dl.deprecated dd, dl.todo dd {
- margin-inline-start: 0px;
-}
-
-dl.invariant, dl.pre {
- background: var(--invariant-color);
- border-left: 8px solid var(--invariant-color-dark);
- color: var(--invariant-color-darker);
-}
-
-dl.invariant dt, dl.pre dt {
- color: var(--invariant-color-dark);
-}
-
-/*
- memitem
- */
-
-div.memdoc, div.memproto, h2.memtitle {
- box-shadow: none;
- background-image: none;
- border: none;
-}
-
-div.memdoc {
- padding: 0 var(--spacing-medium);
- background: var(--page-background-color);
-}
-
-h2.memtitle, div.memitem {
- border: 1px solid var(--separator-color);
- box-shadow: var(--box-shadow);
-}
-
-h2.memtitle {
- box-shadow: 0px var(--spacing-medium) 0 -1px var(--fragment-background), var(--box-shadow);
-}
-
-div.memitem {
- transition: none;
-}
-
-div.memproto, h2.memtitle {
- background: var(--fragment-background);
-}
-
-h2.memtitle {
- font-weight: 500;
- font-size: var(--memtitle-font-size);
- font-family: var(--font-family-monospace);
- border-bottom: none;
- border-top-left-radius: var(--border-radius-medium);
- border-top-right-radius: var(--border-radius-medium);
- word-break: break-all;
- position: relative;
-}
-
-h2.memtitle:after {
- content: "";
- display: block;
- background: var(--fragment-background);
- height: var(--spacing-medium);
- bottom: calc(0px - var(--spacing-medium));
- left: 0;
- right: -14px;
- position: absolute;
- border-top-right-radius: var(--border-radius-medium);
-}
-
-h2.memtitle > span.permalink {
- font-size: inherit;
-}
-
-h2.memtitle > span.permalink > a {
- text-decoration: none;
- padding-left: 3px;
- margin-right: -4px;
- user-select: none;
- display: inline-block;
- margin-top: -6px;
-}
-
-h2.memtitle > span.permalink > a:hover {
- color: var(--primary-dark-color) !important;
-}
-
-a:target + h2.memtitle, a:target + h2.memtitle + div.memitem {
- border-color: var(--primary-light-color);
-}
-
-div.memitem {
- border-top-right-radius: var(--border-radius-medium);
- border-bottom-right-radius: var(--border-radius-medium);
- border-bottom-left-radius: var(--border-radius-medium);
- overflow: hidden;
- display: block !important;
-}
-
-div.memdoc {
- border-radius: 0;
-}
-
-div.memproto {
- border-radius: 0 var(--border-radius-small) 0 0;
- overflow: auto;
- border-bottom: 1px solid var(--separator-color);
- padding: var(--spacing-medium);
- margin-bottom: -1px;
-}
-
-div.memtitle {
- border-top-right-radius: var(--border-radius-medium);
- border-top-left-radius: var(--border-radius-medium);
-}
-
-div.memproto table.memname {
- font-family: var(--font-family-monospace);
- color: var(--page-foreground-color);
- font-size: var(--memname-font-size);
- text-shadow: none;
-}
-
-div.memproto div.memtemplate {
- font-family: var(--font-family-monospace);
- color: var(--primary-dark-color);
- font-size: var(--memname-font-size);
- margin-left: 2px;
- text-shadow: none;
-}
-
-table.mlabels, table.mlabels > tbody {
- display: block;
-}
-
-td.mlabels-left {
- width: auto;
-}
-
-td.mlabels-right {
- margin-top: 3px;
- position: sticky;
- left: 0;
-}
-
-table.mlabels > tbody > tr:first-child {
- display: flex;
- justify-content: space-between;
- flex-wrap: wrap;
-}
-
-.memname, .memitem span.mlabels {
- margin: 0
-}
-
-/*
- reflist
- */
-
-dl.reflist {
- box-shadow: var(--box-shadow);
- border-radius: var(--border-radius-medium);
- border: 1px solid var(--separator-color);
- overflow: hidden;
- padding: 0;
-}
-
-
-dl.reflist dt, dl.reflist dd {
- box-shadow: none;
- text-shadow: none;
- background-image: none;
- border: none;
- padding: 12px;
-}
-
-
-dl.reflist dt {
- font-weight: 500;
- border-radius: 0;
- background: var(--code-background);
- border-bottom: 1px solid var(--separator-color);
- color: var(--page-foreground-color)
-}
-
-
-dl.reflist dd {
- background: none;
-}
-
-/*
- Table
- */
-
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname),
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody {
- display: inline-block;
- max-width: 100%;
-}
-
-.contents > table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname):not(.classindex) {
- margin-left: calc(0px - var(--spacing-large));
- margin-right: calc(0px - var(--spacing-large));
- max-width: calc(100% + 2 * var(--spacing-large));
-}
-
-table.fieldtable,
-table.markdownTable tbody,
-table.doxtable tbody {
- border: none;
- margin: var(--spacing-medium) 0;
- box-shadow: 0 0 0 1px var(--separator-color);
- border-radius: var(--border-radius-small);
-}
-
-table.doxtable caption {
- display: block;
-}
-
-table.fieldtable {
- border-collapse: collapse;
- width: 100%;
-}
-
-th.markdownTableHeadLeft,
-th.markdownTableHeadRight,
-th.markdownTableHeadCenter,
-th.markdownTableHeadNone,
-table.doxtable th {
- background: var(--tablehead-background);
- color: var(--tablehead-foreground);
- font-weight: 600;
- font-size: var(--page-font-size);
-}
-
-th.markdownTableHeadLeft:first-child,
-th.markdownTableHeadRight:first-child,
-th.markdownTableHeadCenter:first-child,
-th.markdownTableHeadNone:first-child,
-table.doxtable tr th:first-child {
- border-top-left-radius: var(--border-radius-small);
-}
-
-th.markdownTableHeadLeft:last-child,
-th.markdownTableHeadRight:last-child,
-th.markdownTableHeadCenter:last-child,
-th.markdownTableHeadNone:last-child,
-table.doxtable tr th:last-child {
- border-top-right-radius: var(--border-radius-small);
-}
-
-table.markdownTable td,
-table.markdownTable th,
-table.fieldtable td,
-table.fieldtable th,
-table.doxtable td,
-table.doxtable th {
- border: 1px solid var(--separator-color);
- padding: var(--spacing-small) var(--spacing-medium);
-}
-
-table.markdownTable td:last-child,
-table.markdownTable th:last-child,
-table.fieldtable td:last-child,
-table.fieldtable th:last-child,
-table.doxtable td:last-child,
-table.doxtable th:last-child {
- border-right: none;
-}
-
-table.markdownTable td:first-child,
-table.markdownTable th:first-child,
-table.fieldtable td:first-child,
-table.fieldtable th:first-child,
-table.doxtable td:first-child,
-table.doxtable th:first-child {
- border-left: none;
-}
-
-table.markdownTable tr:first-child td,
-table.markdownTable tr:first-child th,
-table.fieldtable tr:first-child td,
-table.fieldtable tr:first-child th,
-table.doxtable tr:first-child td,
-table.doxtable tr:first-child th {
- border-top: none;
-}
-
-table.markdownTable tr:last-child td,
-table.markdownTable tr:last-child th,
-table.fieldtable tr:last-child td,
-table.fieldtable tr:last-child th,
-table.doxtable tr:last-child td,
-table.doxtable tr:last-child th {
- border-bottom: none;
-}
-
-table.markdownTable tr, table.doxtable tr {
- border-bottom: 1px solid var(--separator-color);
-}
-
-table.markdownTable tr:last-child, table.doxtable tr:last-child {
- border-bottom: none;
-}
-
-table.fieldtable th {
- font-size: var(--page-font-size);
- font-weight: 600;
- background-image: none;
- background-color: var(--tablehead-background);
- color: var(--tablehead-foreground);
-}
-
-table.fieldtable td.fieldtype, .fieldtable td.fieldname, .fieldtable td.fielddoc, .fieldtable th {
- border-bottom: 1px solid var(--separator-color);
- border-right: 1px solid var(--separator-color);
-}
-
-table.fieldtable tr:last-child td:first-child {
- border-bottom-left-radius: var(--border-radius-small);
-}
-
-table.fieldtable tr:last-child td:last-child {
- border-bottom-right-radius: var(--border-radius-small);
-}
-
-.memberdecls td.glow, .fieldtable tr.glow {
- background-color: var(--primary-light-color);
- box-shadow: none;
-}
-
-table.memberdecls {
- display: block;
- -webkit-tap-highlight-color: transparent;
-}
-
-table.memberdecls tr[class^='memitem'] {
- font-family: var(--font-family-monospace);
- font-size: var(--code-font-size);
-}
-
-table.memberdecls tr[class^='memitem'] .memTemplParams {
- font-family: var(--font-family-monospace);
- font-size: var(--code-font-size);
- color: var(--primary-dark-color);
- white-space: normal;
-}
-
-table.memberdecls .memItemLeft,
-table.memberdecls .memItemRight,
-table.memberdecls .memTemplItemLeft,
-table.memberdecls .memTemplItemRight,
-table.memberdecls .memTemplParams {
- transition: none;
- padding-top: var(--spacing-small);
- padding-bottom: var(--spacing-small);
- border-top: 1px solid var(--separator-color);
- border-bottom: 1px solid var(--separator-color);
- background-color: var(--fragment-background);
-}
-
-table.memberdecls .memTemplItemLeft,
-table.memberdecls .memTemplItemRight {
- padding-top: 2px;
-}
-
-table.memberdecls .memTemplParams {
- border-bottom: 0;
- border-left: 1px solid var(--separator-color);
- border-right: 1px solid var(--separator-color);
- border-radius: var(--border-radius-small) var(--border-radius-small) 0 0;
- padding-bottom: var(--spacing-small);
-}
-
-table.memberdecls .memTemplItemLeft {
- border-radius: 0 0 0 var(--border-radius-small);
- border-left: 1px solid var(--separator-color);
- border-top: 0;
-}
-
-table.memberdecls .memTemplItemRight {
- border-radius: 0 0 var(--border-radius-small) 0;
- border-right: 1px solid var(--separator-color);
- padding-left: 0;
- border-top: 0;
-}
-
-table.memberdecls .memItemLeft {
- border-radius: var(--border-radius-small) 0 0 var(--border-radius-small);
- border-left: 1px solid var(--separator-color);
- padding-left: var(--spacing-medium);
- padding-right: 0;
-}
-
-table.memberdecls .memItemRight {
- border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
- border-right: 1px solid var(--separator-color);
- padding-right: var(--spacing-medium);
- padding-left: 0;
-
-}
-
-table.memberdecls .mdescLeft, table.memberdecls .mdescRight {
- background: none;
- color: var(--page-foreground-color);
- padding: var(--spacing-small) 0;
-}
-
-table.memberdecls .memItemLeft,
-table.memberdecls .memTemplItemLeft {
- padding-right: var(--spacing-medium);
-}
-
-table.memberdecls .memSeparator {
- background: var(--page-background-color);
- height: var(--spacing-large);
- border: 0;
- transition: none;
-}
-
-table.memberdecls .groupheader {
- margin-bottom: var(--spacing-large);
-}
-
-table.memberdecls .inherit_header td {
- padding: 0 0 var(--spacing-medium) 0;
- text-indent: -12px;
- color: var(--page-secondary-foreground-color);
-}
-
-table.memberdecls img[src="closed.png"],
-table.memberdecls img[src="open.png"],
-div.dynheader img[src="open.png"],
-div.dynheader img[src="closed.png"] {
- width: 0;
- height: 0;
- border-left: 4px solid transparent;
- border-right: 4px solid transparent;
- border-top: 5px solid var(--primary-color);
- margin-top: 8px;
- display: block;
- float: left;
- margin-left: -10px;
- transition: transform 0.25s ease-out;
-}
-
-table.memberdecls img {
- margin-right: 10px;
-}
-
-table.memberdecls img[src="closed.png"],
-div.dynheader img[src="closed.png"] {
- transform: rotate(-90deg);
-
-}
-
-.compoundTemplParams {
- font-family: var(--font-family-monospace);
- color: var(--primary-dark-color);
- font-size: var(--code-font-size);
-}
-
-@media screen and (max-width: 767px) {
-
- table.memberdecls .memItemLeft,
- table.memberdecls .memItemRight,
- table.memberdecls .mdescLeft,
- table.memberdecls .mdescRight,
- table.memberdecls .memTemplItemLeft,
- table.memberdecls .memTemplItemRight,
- table.memberdecls .memTemplParams {
- display: block;
- text-align: left;
- padding-left: var(--spacing-large);
- margin: 0 calc(0px - var(--spacing-large)) 0 calc(0px - var(--spacing-large));
- border-right: none;
- border-left: none;
- border-radius: 0;
- white-space: normal;
- }
-
- table.memberdecls .memItemLeft,
- table.memberdecls .mdescLeft,
- table.memberdecls .memTemplItemLeft {
- border-bottom: 0;
- padding-bottom: 0;
- }
-
- table.memberdecls .memTemplItemLeft {
- padding-top: 0;
- }
-
- table.memberdecls .mdescLeft {
- margin-bottom: calc(0px - var(--page-font-size));
- }
-
- table.memberdecls .memItemRight,
- table.memberdecls .mdescRight,
- table.memberdecls .memTemplItemRight {
- border-top: 0;
- padding-top: 0;
- padding-right: var(--spacing-large);
- overflow-x: auto;
- }
-
- table.memberdecls tr[class^='memitem']:not(.inherit) {
- display: block;
- width: calc(100vw - 2 * var(--spacing-large));
- }
-
- table.memberdecls .mdescRight {
- color: var(--page-foreground-color);
- }
-
- table.memberdecls tr.inherit {
- visibility: hidden;
- }
-
- table.memberdecls tr[style="display: table-row;"] {
- display: block !important;
- visibility: visible;
- width: calc(100vw - 2 * var(--spacing-large));
- animation: fade .5s;
- }
-
- @keyframes fade {
- 0% {
- opacity: 0;
- max-height: 0;
- }
-
- 100% {
- opacity: 1;
- max-height: 200px;
- }
- }
-}
-
-
-/*
- Horizontal Rule
- */
-
-hr {
- margin-top: var(--spacing-large);
- margin-bottom: var(--spacing-large);
- height: 1px;
- background-color: var(--separator-color);
- border: 0;
-}
-
-.contents hr {
- box-shadow: 100px 0 0 var(--separator-color),
- -100px 0 0 var(--separator-color),
- 500px 0 0 var(--separator-color),
- -500px 0 0 var(--separator-color),
- 1500px 0 0 var(--separator-color),
- -1500px 0 0 var(--separator-color),
- 2000px 0 0 var(--separator-color),
- -2000px 0 0 var(--separator-color);
-}
-
-.contents img, .contents .center, .contents center, .contents div.image object {
- max-width: 100%;
- overflow: auto;
-}
-
-@media screen and (max-width: 767px) {
- .contents .dyncontent > .center, .contents > center {
- margin-left: calc(0px - var(--spacing-large));
- margin-right: calc(0px - var(--spacing-large));
- max-width: calc(100% + 2 * var(--spacing-large));
- }
-}
-
-/*
- Directories
- */
-div.directory {
- border-top: 1px solid var(--separator-color);
- border-bottom: 1px solid var(--separator-color);
- width: auto;
-}
-
-table.directory {
- font-family: var(--font-family);
- font-size: var(--page-font-size);
- font-weight: normal;
- width: 100%;
-}
-
-table.directory td.entry, table.directory td.desc {
- padding: calc(var(--spacing-small) / 2) var(--spacing-small);
- line-height: var(--table-line-height);
-}
-
-table.directory tr.even td:last-child {
- border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
-}
-
-table.directory tr.even td:first-child {
- border-radius: var(--border-radius-small) 0 0 var(--border-radius-small);
-}
-
-table.directory tr.even:last-child td:last-child {
- border-radius: 0 var(--border-radius-small) 0 0;
-}
-
-table.directory tr.even:last-child td:first-child {
- border-radius: var(--border-radius-small) 0 0 0;
-}
-
-table.directory td.desc {
- min-width: 250px;
-}
-
-table.directory tr.even {
- background-color: var(--odd-color);
-}
-
-table.directory tr.odd {
- background-color: transparent;
-}
-
-.icona {
- width: auto;
- height: auto;
- margin: 0 var(--spacing-small);
-}
-
-.icon {
- background: var(--primary-color);
- border-radius: var(--border-radius-small);
- font-size: var(--page-font-size);
- padding: calc(var(--page-font-size) / 5);
- line-height: var(--page-font-size);
- transform: scale(0.8);
- height: auto;
- width: var(--page-font-size);
- user-select: none;
-}
-
-.iconfopen, .icondoc, .iconfclosed {
- background-position: center;
- margin-bottom: 0;
- height: var(--table-line-height);
-}
-
-.icondoc {
- filter: saturate(0.2);
-}
-
-@media screen and (max-width: 767px) {
- div.directory {
- margin-left: calc(0px - var(--spacing-large));
- margin-right: calc(0px - var(--spacing-large));
- }
-}
-
-@media (prefers-color-scheme: dark) {
- html:not(.light-mode) .iconfopen, html:not(.light-mode) .iconfclosed {
- filter: hue-rotate(180deg) invert();
- }
-}
-
-html.dark-mode .iconfopen, html.dark-mode .iconfclosed {
- filter: hue-rotate(180deg) invert();
-}
-
-/*
- Class list
- */
-
-.classindex dl.odd {
- background: var(--odd-color);
- border-radius: var(--border-radius-small);
-}
-
-.classindex dl.even {
- background-color: transparent;
-}
-
-/*
- Class Index Doxygen 1.8
-*/
-
-table.classindex {
- margin-left: 0;
- margin-right: 0;
- width: 100%;
-}
-
-table.classindex table div.ah {
- background-image: none;
- background-color: initial;
- border-color: var(--separator-color);
- color: var(--page-foreground-color);
- box-shadow: var(--box-shadow);
- border-radius: var(--border-radius-large);
- padding: var(--spacing-small);
-}
-
-div.qindex {
- background-color: var(--odd-color);
- border-radius: var(--border-radius-small);
- border: 1px solid var(--separator-color);
- padding: var(--spacing-small) 0;
-}
-
-/*
- Footer and nav-path
- */
-
-#nav-path {
- width: 100%;
-}
-
-#nav-path ul {
- background-image: none;
- background: var(--page-background-color);
- border: none;
- border-top: 1px solid var(--separator-color);
- border-bottom: 1px solid var(--separator-color);
- border-bottom: 0;
- box-shadow: 0 0.75px 0 var(--separator-color);
- font-size: var(--navigation-font-size);
-}
-
-img.footer {
- width: 60px;
-}
-
-.navpath li.footer {
- color: var(--page-secondary-foreground-color);
-}
-
-address.footer {
- color: var(--page-secondary-foreground-color);
- margin-bottom: var(--spacing-large);
-}
-
-#nav-path li.navelem {
- background-image: none;
- display: flex;
- align-items: center;
-}
-
-.navpath li.navelem a {
- text-shadow: none;
- display: inline-block;
- color: var(--primary-color) !important;
-}
-
-.navpath li.navelem b {
- color: var(--primary-dark-color);
- font-weight: 500;
-}
-
-li.navelem {
- padding: 0;
- margin-left: -8px;
-}
-
-li.navelem:first-child {
- margin-left: var(--spacing-large);
-}
-
-li.navelem:first-child:before {
- display: none;
-}
-
-#nav-path li.navelem:after {
- content: '';
- border: 5px solid var(--page-background-color);
- border-bottom-color: transparent;
- border-right-color: transparent;
- border-top-color: transparent;
- transform: translateY(-1px) scaleY(4.2);
- z-index: 10;
- margin-left: 6px;
-}
-
-#nav-path li.navelem:before {
- content: '';
- border: 5px solid var(--separator-color);
- border-bottom-color: transparent;
- border-right-color: transparent;
- border-top-color: transparent;
- transform: translateY(-1px) scaleY(3.2);
- margin-right: var(--spacing-small);
-}
-
-.navpath li.navelem a:hover {
- color: var(--primary-color);
-}
-
-/*
- Scrollbars for Webkit
-*/
-
-#nav-tree::-webkit-scrollbar,
-div.fragment::-webkit-scrollbar,
-pre.fragment::-webkit-scrollbar,
-div.memproto::-webkit-scrollbar,
-.contents center::-webkit-scrollbar,
-.contents .center::-webkit-scrollbar,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar,
-div.contents .toc::-webkit-scrollbar {
- background: transparent;
- width: calc(var(--webkit-scrollbar-size) + var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
- height: calc(var(--webkit-scrollbar-size) + var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
-}
-
-#nav-tree::-webkit-scrollbar-thumb,
-div.fragment::-webkit-scrollbar-thumb,
-pre.fragment::-webkit-scrollbar-thumb,
-div.memproto::-webkit-scrollbar-thumb,
-.contents center::-webkit-scrollbar-thumb,
-.contents .center::-webkit-scrollbar-thumb,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar-thumb,
-div.contents .toc::-webkit-scrollbar-thumb {
- background-color: transparent;
- border: var(--webkit-scrollbar-padding) solid transparent;
- border-radius: calc(var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
- background-clip: padding-box;
-}
-
-#nav-tree:hover::-webkit-scrollbar-thumb,
-div.fragment:hover::-webkit-scrollbar-thumb,
-pre.fragment:hover::-webkit-scrollbar-thumb,
-div.memproto:hover::-webkit-scrollbar-thumb,
-.contents center:hover::-webkit-scrollbar-thumb,
-.contents .center:hover::-webkit-scrollbar-thumb,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody:hover::-webkit-scrollbar-thumb,
-div.contents .toc:hover::-webkit-scrollbar-thumb {
- background-color: var(--webkit-scrollbar-color);
-}
-
-#nav-tree::-webkit-scrollbar-track,
-div.fragment::-webkit-scrollbar-track,
-pre.fragment::-webkit-scrollbar-track,
-div.memproto::-webkit-scrollbar-track,
-.contents center::-webkit-scrollbar-track,
-.contents .center::-webkit-scrollbar-track,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar-track,
-div.contents .toc::-webkit-scrollbar-track {
- background: transparent;
-}
-
-#nav-tree::-webkit-scrollbar-corner {
- background-color: var(--side-nav-background);
-}
-
-#nav-tree,
-div.fragment,
-pre.fragment,
-div.memproto,
-.contents center,
-.contents .center,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody,
-div.contents .toc {
- overflow-x: auto;
- overflow-x: overlay;
-}
-
-#nav-tree {
- overflow-x: auto;
- overflow-y: auto;
- overflow-y: overlay;
-}
-
-/*
- Scrollbars for Firefox
-*/
-
-#nav-tree,
-div.fragment,
-pre.fragment,
-div.memproto,
-.contents center,
-.contents .center,
-.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody,
-div.contents .toc {
- scrollbar-width: thin;
-}
-
-/*
- Optional Dark mode toggle button
-*/
-
-doxygen-awesome-dark-mode-toggle {
- display: inline-block;
- margin: 0 0 0 var(--spacing-small);
- padding: 0;
- width: var(--searchbar-height);
- height: var(--searchbar-height);
- background: none;
- border: none;
- border-radius: var(--searchbar-height);
- vertical-align: middle;
- text-align: center;
- line-height: var(--searchbar-height);
- font-size: 22px;
- display: flex;
- align-items: center;
- justify-content: center;
- user-select: none;
- cursor: pointer;
-}
-
-doxygen-awesome-dark-mode-toggle > svg {
- transition: transform .1s ease-in-out;
-}
-
-doxygen-awesome-dark-mode-toggle:active > svg {
- transform: scale(.5);
-}
-
-doxygen-awesome-dark-mode-toggle:hover {
- background-color: rgba(0,0,0,.03);
-}
-
-html.dark-mode doxygen-awesome-dark-mode-toggle:hover {
- background-color: rgba(0,0,0,.18);
-}
-
-/*
- Optional fragment copy button
-*/
-.doxygen-awesome-fragment-wrapper {
- position: relative;
-}
-
-doxygen-awesome-fragment-copy-button {
- opacity: 0;
- background: var(--fragment-background);
- width: 28px;
- height: 28px;
- position: absolute;
- right: calc(var(--spacing-large) - (var(--spacing-large) / 2.5));
- top: calc(var(--spacing-large) - (var(--spacing-large) / 2.5));
- border: 1px solid var(--fragment-foreground);
- cursor: pointer;
- border-radius: var(--border-radius-small);
- display: flex;
- justify-content: center;
- align-items: center;
-}
-
-.doxygen-awesome-fragment-wrapper:hover doxygen-awesome-fragment-copy-button, doxygen-awesome-fragment-copy-button.success {
- opacity: .28;
-}
-
-doxygen-awesome-fragment-copy-button:hover, doxygen-awesome-fragment-copy-button.success {
- opacity: 1 !important;
-}
-
-doxygen-awesome-fragment-copy-button:active:not([class~=success]) svg {
- transform: scale(.91);
-}
-
-doxygen-awesome-fragment-copy-button svg {
- fill: var(--fragment-foreground);
- width: 18px;
- height: 18px;
-}
-
-doxygen-awesome-fragment-copy-button.success svg {
- fill: rgb(14, 168, 14);
-}
-
-doxygen-awesome-fragment-copy-button.success {
- border-color: rgb(14, 168, 14);
-}
-
-@media screen and (max-width: 767px) {
- .textblock > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
- .textblock li > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
- .memdoc li > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
- .memdoc > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
- dl dd > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button {
- right: 0;
- }
-}
-
-/*
- Optional paragraph link button
-*/
-
-a.anchorlink {
- font-size: 90%;
- margin-left: var(--spacing-small);
- color: var(--page-foreground-color) !important;
- text-decoration: none;
- opacity: .15;
- display: none;
- transition: opacity .1s ease-in-out, color .1s ease-in-out;
-}
-
-a.anchorlink svg {
- fill: var(--page-foreground-color);
-}
-
-h3 a.anchorlink svg, h4 a.anchorlink svg {
- margin-bottom: -3px;
- margin-top: -4px;
-}
-
-a.anchorlink:hover {
- opacity: .45;
-}
-
-h2:hover a.anchorlink, h1:hover a.anchorlink, h3:hover a.anchorlink, h4:hover a.anchorlink {
- display: inline-block;
-}
+/**
+
+Doxygen Awesome
+https://github.com/jothepro/doxygen-awesome-css
+
+MIT License
+
+Copyright (c) 2021 - 2022 jothepro
+
+Permission is hereby granted, free of charge, to any person obtaining a copy
+of this software and associated documentation files (the "Software"), to deal
+in the Software without restriction, including without limitation the rights
+to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+copies of the Software, and to permit persons to whom the Software is
+furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice shall be included in all
+copies or substantial portions of the Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
+AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
+SOFTWARE.
+
+*/
+
+html {
+ /* primary theme color. This will affect the entire websites color scheme: links, arrows, labels, ... */
+ --primary-color: #1779c4;
+ --primary-dark-color: #335c80;
+ --primary-light-color: #70b1e9;
+
+ /* page base colors */
+ --page-background-color: #ffffff;
+ --page-foreground-color: #2f4153;
+ --page-secondary-foreground-color: #6f7e8e;
+
+ /* color for all separators on the website: hr, borders, ... */
+ --separator-color: #dedede;
+
+ /* border radius for all rounded components. Will affect many components, like dropdowns, memitems, codeblocks, ... */
+ --border-radius-large: 8px;
+ --border-radius-small: 4px;
+ --border-radius-medium: 6px;
+
+ /* default spacings. Most components reference these values for spacing, to provide uniform spacing on the page. */
+ --spacing-small: 5px;
+ --spacing-medium: 10px;
+ --spacing-large: 16px;
+
+ /* default box shadow used for raising an element above the normal content. Used in dropdowns, search result, ... */
+ --box-shadow: 0 2px 8px 0 rgba(0,0,0,.075);
+
+ --odd-color: rgba(0,0,0,.028);
+
+ /* font-families. will affect all text on the website
+ * font-family: the normal font for text, headlines, menus
+ * font-family-monospace: used for preformatted text in memtitle, code, fragments
+ */
+ --font-family: -apple-system,BlinkMacSystemFont,Segoe UI,Roboto,Oxygen,Ubuntu,Cantarell,Fira Sans,Droid Sans,Helvetica Neue,sans-serif;
+ --font-family-monospace: ui-monospace,SFMono-Regular,SF Mono,Menlo,Consolas,Liberation Mono,monospace;
+
+ /* font sizes */
+ --page-font-size: 15.6px;
+ --navigation-font-size: 14.4px;
+ --toc-font-size: 13.4px;
+ --code-font-size: 14px; /* affects code, fragment */
+ --title-font-size: 22px;
+
+ /* content text properties. These only affect the page content, not the navigation or any other ui elements */
+ --content-line-height: 27px;
+ /* The content is centered and constraint in it's width. To make the content fill the whole page, set the variable to auto.*/
+ --content-maxwidth: 1050px;
+ --table-line-height: 24px;
+ --toc-sticky-top: var(--spacing-medium);
+ --toc-width: 200px;
+ --toc-max-height: calc(100vh - 2 * var(--spacing-medium) - 85px);
+
+ /* colors for various content boxes: @warning, @note, @deprecated @bug */
+ --warning-color: #f8d1cc;
+ --warning-color-dark: #b61825;
+ --warning-color-darker: #75070f;
+ --note-color: #faf3d8;
+ --note-color-dark: #f3a600;
+ --note-color-darker: #5f4204;
+ --todo-color: #e4f3ff;
+ --todo-color-dark: #1879C4;
+ --todo-color-darker: #274a5c;
+ --deprecated-color: #ecf0f3;
+ --deprecated-color-dark: #5b6269;
+ --deprecated-color-darker: #43454a;
+ --bug-color: #e4dafd;
+ --bug-color-dark: #5b2bdd;
+ --bug-color-darker: #2a0d72;
+ --invariant-color: #d8f1e3;
+ --invariant-color-dark: #44b86f;
+ --invariant-color-darker: #265532;
+
+ /* blockquote colors */
+ --blockquote-background: #f8f9fa;
+ --blockquote-foreground: #636568;
+
+ /* table colors */
+ --tablehead-background: #f1f1f1;
+ --tablehead-foreground: var(--page-foreground-color);
+
+ /* menu-display: block | none
+ * Visibility of the top navigation on screens >= 768px. On smaller screen the menu is always visible.
+ * `GENERATE_TREEVIEW` MUST be enabled!
+ */
+ --menu-display: block;
+
+ --menu-focus-foreground: var(--page-background-color);
+ --menu-focus-background: var(--primary-color);
+ --menu-selected-background: rgba(0,0,0,.05);
+
+
+ --header-background: var(--page-background-color);
+ --header-foreground: var(--page-foreground-color);
+
+ /* searchbar colors */
+ --searchbar-background: var(--side-nav-background);
+ --searchbar-foreground: var(--page-foreground-color);
+
+ /* searchbar size
+ * (`searchbar-width` is only applied on screens >= 768px.
+ * on smaller screens the searchbar will always fill the entire screen width) */
+ --searchbar-height: 33px;
+ --searchbar-width: 210px;
+ --searchbar-border-radius: var(--searchbar-height);
+
+ /* code block colors */
+ --code-background: #f5f5f5;
+ --code-foreground: var(--page-foreground-color);
+
+ /* fragment colors */
+ --fragment-background: #F8F9FA;
+ --fragment-foreground: #37474F;
+ --fragment-keyword: #bb6bb2;
+ --fragment-keywordtype: #8258b3;
+ --fragment-keywordflow: #d67c3b;
+ --fragment-token: #438a59;
+ --fragment-comment: #969696;
+ --fragment-link: #5383d6;
+ --fragment-preprocessor: #46aaa5;
+ --fragment-linenumber-color: #797979;
+ --fragment-linenumber-background: #f4f4f5;
+ --fragment-linenumber-border: #e3e5e7;
+ --fragment-lineheight: 20px;
+
+ /* sidebar navigation (treeview) colors */
+ --side-nav-background: #fbfbfb;
+ --side-nav-foreground: var(--page-foreground-color);
+ --side-nav-arrow-opacity: 0;
+ --side-nav-arrow-hover-opacity: 0.9;
+
+ --toc-background: var(--side-nav-background);
+ --toc-foreground: var(--side-nav-foreground);
+
+ /* height of an item in any tree / collapsable table */
+ --tree-item-height: 30px;
+
+ --memname-font-size: var(--code-font-size);
+ --memtitle-font-size: 18px;
+
+ --webkit-scrollbar-size: 7px;
+ --webkit-scrollbar-padding: 4px;
+ --webkit-scrollbar-color: var(--separator-color);
+}
+
+@media screen and (max-width: 767px) {
+ html {
+ --page-font-size: 16px;
+ --navigation-font-size: 16px;
+ --toc-font-size: 15px;
+ --code-font-size: 15px; /* affects code, fragment */
+ --title-font-size: 22px;
+ }
+}
+
+@media (prefers-color-scheme: dark) {
+ html:not(.light-mode) {
+ color-scheme: dark;
+
+ --primary-color: #1982d2;
+ --primary-dark-color: #86a9c4;
+ --primary-light-color: #4779ac;
+
+ --box-shadow: 0 2px 8px 0 rgba(0,0,0,.35);
+
+ --odd-color: rgba(100,100,100,.06);
+
+ --menu-selected-background: rgba(0,0,0,.4);
+
+ --page-background-color: #1C1D1F;
+ --page-foreground-color: #d2dbde;
+ --page-secondary-foreground-color: #859399;
+ --separator-color: #38393b;
+ --side-nav-background: #252628;
+
+ --code-background: #2a2c2f;
+
+ --tablehead-background: #2a2c2f;
+
+ --blockquote-background: #222325;
+ --blockquote-foreground: #7e8c92;
+
+ --warning-color: #2e1917;
+ --warning-color-dark: #ad2617;
+ --warning-color-darker: #f5b1aa;
+ --note-color: #3b2e04;
+ --note-color-dark: #f1b602;
+ --note-color-darker: #ceb670;
+ --todo-color: #163750;
+ --todo-color-dark: #1982D2;
+ --todo-color-darker: #dcf0fa;
+ --deprecated-color: #2e323b;
+ --deprecated-color-dark: #738396;
+ --deprecated-color-darker: #abb0bd;
+ --bug-color: #2a2536;
+ --bug-color-dark: #7661b3;
+ --bug-color-darker: #ae9ed6;
+ --invariant-color: #303a35;
+ --invariant-color-dark: #76ce96;
+ --invariant-color-darker: #cceed5;
+
+ --fragment-background: #282c34;
+ --fragment-foreground: #dbe4eb;
+ --fragment-keyword: #cc99cd;
+ --fragment-keywordtype: #ab99cd;
+ --fragment-keywordflow: #e08000;
+ --fragment-token: #7ec699;
+ --fragment-comment: #999999;
+ --fragment-link: #98c0e3;
+ --fragment-preprocessor: #65cabe;
+ --fragment-linenumber-color: #cccccc;
+ --fragment-linenumber-background: #35393c;
+ --fragment-linenumber-border: #1f1f1f;
+ }
+}
+
+/* dark mode variables are defined twice, to support both the dark-mode without and with doxygen-awesome-darkmode-toggle.js */
+html.dark-mode {
+ color-scheme: dark;
+
+ --primary-color: #1982d2;
+ --primary-dark-color: #86a9c4;
+ --primary-light-color: #4779ac;
+
+ --box-shadow: 0 2px 8px 0 rgba(0,0,0,.30);
+
+ --odd-color: rgba(100,100,100,.06);
+
+ --menu-selected-background: rgba(0,0,0,.4);
+
+ --page-background-color: #1C1D1F;
+ --page-foreground-color: #d2dbde;
+ --page-secondary-foreground-color: #859399;
+ --separator-color: #38393b;
+ --side-nav-background: #252628;
+
+ --code-background: #2a2c2f;
+
+ --tablehead-background: #2a2c2f;
+
+ --blockquote-background: #222325;
+ --blockquote-foreground: #7e8c92;
+
+ --warning-color: #2e1917;
+ --warning-color-dark: #ad2617;
+ --warning-color-darker: #f5b1aa;
+ --note-color: #3b2e04;
+ --note-color-dark: #f1b602;
+ --note-color-darker: #ceb670;
+ --todo-color: #163750;
+ --todo-color-dark: #1982D2;
+ --todo-color-darker: #dcf0fa;
+ --deprecated-color: #2e323b;
+ --deprecated-color-dark: #738396;
+ --deprecated-color-darker: #abb0bd;
+ --bug-color: #2a2536;
+ --bug-color-dark: #7661b3;
+ --bug-color-darker: #ae9ed6;
+ --invariant-color: #303a35;
+ --invariant-color-dark: #76ce96;
+ --invariant-color-darker: #cceed5;
+
+ --fragment-background: #282c34;
+ --fragment-foreground: #dbe4eb;
+ --fragment-keyword: #cc99cd;
+ --fragment-keywordtype: #ab99cd;
+ --fragment-keywordflow: #e08000;
+ --fragment-token: #7ec699;
+ --fragment-comment: #999999;
+ --fragment-link: #98c0e3;
+ --fragment-preprocessor: #65cabe;
+ --fragment-linenumber-color: #cccccc;
+ --fragment-linenumber-background: #35393c;
+ --fragment-linenumber-border: #1f1f1f;
+}
+
+body {
+ color: var(--page-foreground-color);
+ background-color: var(--page-background-color);
+ font-size: var(--page-font-size);
+}
+
+body, table, div, p, dl, #nav-tree .label, .title,
+.sm-dox a, .sm-dox a:hover, .sm-dox a:focus, #projectname,
+.SelectItem, #MSearchField, .navpath li.navelem a,
+.navpath li.navelem a:hover, p.reference, p.definition {
+ font-family: var(--font-family);
+}
+
+h1, h2, h3, h4, h5 {
+ margin-top: .9em;
+ font-weight: 600;
+ line-height: initial;
+}
+
+p, div, table, dl, p.reference, p.definition {
+ font-size: var(--page-font-size);
+}
+
+p.reference, p.definition {
+ color: var(--page-secondary-foreground-color);
+}
+
+a:link, a:visited, a:hover, a:focus, a:active {
+ color: var(--primary-color) !important;
+ font-weight: 500;
+}
+
+a.anchor {
+ scroll-margin-top: var(--spacing-large);
+ display: block;
+}
+
+/*
+ Title and top navigation
+ */
+
+#top {
+ background: var(--header-background);
+ border-bottom: 1px solid var(--separator-color);
+}
+
+@media screen and (min-width: 768px) {
+ #top {
+ display: flex;
+ flex-wrap: wrap;
+ justify-content: space-between;
+ align-items: center;
+ }
+}
+
+#main-nav {
+ flex-grow: 5;
+ padding: var(--spacing-small) var(--spacing-medium);
+}
+
+#titlearea {
+ width: auto;
+ padding: var(--spacing-medium) var(--spacing-large);
+ background: none;
+ color: var(--header-foreground);
+ border-bottom: none;
+}
+
+@media screen and (max-width: 767px) {
+ #titlearea {
+ padding-bottom: var(--spacing-small);
+ }
+}
+
+#titlearea table tbody tr {
+ height: auto !important;
+}
+
+#projectname {
+ font-size: var(--title-font-size);
+ font-weight: 600;
+}
+
+#projectnumber {
+ font-family: inherit;
+ font-size: 60%;
+}
+
+#projectbrief {
+ font-family: inherit;
+ font-size: 80%;
+}
+
+#projectlogo {
+ vertical-align: middle;
+}
+
+#projectlogo img {
+ max-height: calc(var(--title-font-size) * 2);
+ margin-right: var(--spacing-small);
+}
+
+.sm-dox, .tabs, .tabs2, .tabs3 {
+ background: none;
+ padding: 0;
+}
+
+.tabs, .tabs2, .tabs3 {
+ border-bottom: 1px solid var(--separator-color);
+ margin-bottom: -1px;
+}
+
+.main-menu-btn-icon, .main-menu-btn-icon:before, .main-menu-btn-icon:after {
+ background: var(--page-secondary-foreground-color);
+}
+
+@media screen and (max-width: 767px) {
+ .sm-dox a span.sub-arrow {
+ background: var(--code-background);
+ }
+
+ #main-menu a.has-submenu span.sub-arrow {
+ color: var(--page-secondary-foreground-color);
+ border-radius: var(--border-radius-medium);
+ }
+
+ #main-menu a.has-submenu:hover span.sub-arrow {
+ color: var(--page-foreground-color);
+ }
+}
+
+@media screen and (min-width: 768px) {
+ .sm-dox li, .tablist li {
+ display: var(--menu-display);
+ }
+
+ .sm-dox a span.sub-arrow {
+ border-color: var(--header-foreground) transparent transparent transparent;
+ }
+
+ .sm-dox a:hover span.sub-arrow {
+ border-color: var(--menu-focus-foreground) transparent transparent transparent;
+ }
+
+ .sm-dox ul a span.sub-arrow {
+ border-color: transparent transparent transparent var(--page-foreground-color);
+ }
+
+ .sm-dox ul a:hover span.sub-arrow {
+ border-color: transparent transparent transparent var(--menu-focus-foreground);
+ }
+}
+
+.sm-dox ul {
+ background: var(--page-background-color);
+ box-shadow: var(--box-shadow);
+ border: 1px solid var(--separator-color);
+ border-radius: var(--border-radius-medium) !important;
+ padding: var(--spacing-small);
+ animation: ease-out 150ms slideInMenu;
+}
+
+@keyframes slideInMenu {
+ from {
+ opacity: 0;
+ transform: translate(0px, -2px);
+ }
+
+ to {
+ opacity: 1;
+ transform: translate(0px, 0px);
+ }
+}
+
+.sm-dox ul a {
+ color: var(--page-foreground-color) !important;
+ background: var(--page-background-color);
+ font-size: var(--navigation-font-size);
+}
+
+.sm-dox>li>ul:after {
+ border-bottom-color: var(--page-background-color) !important;
+}
+
+.sm-dox>li>ul:before {
+ border-bottom-color: var(--separator-color) !important;
+}
+
+.sm-dox ul a:hover, .sm-dox ul a:active, .sm-dox ul a:focus {
+ font-size: var(--navigation-font-size) !important;
+ color: var(--menu-focus-foreground) !important;
+ text-shadow: none;
+ background-color: var(--menu-focus-background);
+ border-radius: var(--border-radius-small) !important;
+}
+
+.sm-dox a, .sm-dox a:focus, .tablist li, .tablist li a, .tablist li.current a {
+ text-shadow: none;
+ background: transparent;
+ background-image: none !important;
+ color: var(--header-foreground) !important;
+ font-weight: normal;
+ font-size: var(--navigation-font-size);
+ border-radius: var(--border-radius-small) !important;
+}
+
+.sm-dox a:focus {
+ outline: auto;
+}
+
+.sm-dox a:hover, .sm-dox a:active, .tablist li a:hover {
+ text-shadow: none;
+ font-weight: normal;
+ background: var(--menu-focus-background);
+ color: var(--menu-focus-foreground) !important;
+ border-radius: var(--border-radius-small) !important;
+ font-size: var(--navigation-font-size);
+}
+
+.tablist li.current {
+ border-radius: var(--border-radius-small);
+ background: var(--menu-selected-background);
+}
+
+.tablist li {
+ margin: var(--spacing-small) 0 var(--spacing-small) var(--spacing-small);
+}
+
+.tablist a {
+ padding: 0 var(--spacing-large);
+}
+
+
+/*
+ Search box
+ */
+
+#MSearchBox {
+ height: var(--searchbar-height);
+ background: var(--searchbar-background);
+ border-radius: var(--searchbar-border-radius);
+ border: 1px solid var(--separator-color);
+ overflow: hidden;
+ width: var(--searchbar-width);
+ position: relative;
+ box-shadow: none;
+ display: block;
+ margin-top: 0;
+}
+
+/* until Doxygen 1.9.4 */
+.left img#MSearchSelect {
+ left: 0;
+ user-select: none;
+ padding-left: 8px;
+}
+
+/* Doxygen 1.9.5 */
+.left span#MSearchSelect {
+ left: 0;
+ user-select: none;
+ margin-left: 8px;
+ padding: 0;
+}
+
+.left #MSearchSelect[src$=".png"] {
+ padding-left: 0
+}
+
+.SelectionMark {
+ user-select: none;
+}
+
+.tabs .left #MSearchSelect {
+ padding-left: 0;
+}
+
+.tabs #MSearchBox {
+ position: absolute;
+ right: var(--spacing-medium);
+}
+
+@media screen and (max-width: 767px) {
+ .tabs #MSearchBox {
+ position: relative;
+ right: 0;
+ margin-left: var(--spacing-medium);
+ margin-top: 0;
+ }
+}
+
+#MSearchSelectWindow, #MSearchResultsWindow {
+ z-index: 9999;
+}
+
+#MSearchBox.MSearchBoxActive {
+ border-color: var(--primary-color);
+ box-shadow: inset 0 0 0 1px var(--primary-color);
+}
+
+#main-menu > li:last-child {
+ margin-right: 0;
+}
+
+@media screen and (max-width: 767px) {
+ #main-menu > li:last-child {
+ height: 50px;
+ }
+}
+
+#MSearchField {
+ font-size: var(--navigation-font-size);
+ height: calc(var(--searchbar-height) - 2px);
+ background: transparent;
+ width: calc(var(--searchbar-width) - 64px);
+}
+
+.MSearchBoxActive #MSearchField {
+ color: var(--searchbar-foreground);
+}
+
+#MSearchSelect {
+ top: calc(calc(var(--searchbar-height) / 2) - 11px);
+}
+
+#MSearchBox span.left, #MSearchBox span.right {
+ background: none;
+ background-image: none;
+}
+
+#MSearchBox span.right {
+ padding-top: calc(calc(var(--searchbar-height) / 2) - 12px);
+ position: absolute;
+ right: var(--spacing-small);
+}
+
+.tabs #MSearchBox span.right {
+ top: calc(calc(var(--searchbar-height) / 2) - 12px);
+}
+
+@keyframes slideInSearchResults {
+ from {
+ opacity: 0;
+ transform: translate(0, 15px);
+ }
+
+ to {
+ opacity: 1;
+ transform: translate(0, 20px);
+ }
+}
+
+#MSearchResultsWindow {
+ left: auto !important;
+ right: var(--spacing-medium);
+ border-radius: var(--border-radius-large);
+ border: 1px solid var(--separator-color);
+ transform: translate(0, 20px);
+ box-shadow: var(--box-shadow);
+ animation: ease-out 280ms slideInSearchResults;
+ background: var(--page-background-color);
+}
+
+iframe#MSearchResults {
+ margin: 4px;
+}
+
+iframe {
+ color-scheme: normal;
+}
+
+@media (prefers-color-scheme: dark) {
+ html:not(.light-mode) iframe#MSearchResults {
+ filter: invert() hue-rotate(180deg);
+ }
+}
+
+html.dark-mode iframe#MSearchResults {
+ filter: invert() hue-rotate(180deg);
+}
+
+#MSearchResults .SRPage {
+ background-color: transparent;
+}
+
+#MSearchResults .SRPage .SREntry {
+ font-size: 10pt;
+ padding: var(--spacing-small) var(--spacing-medium);
+}
+
+#MSearchSelectWindow {
+ border: 1px solid var(--separator-color);
+ border-radius: var(--border-radius-medium);
+ box-shadow: var(--box-shadow);
+ background: var(--page-background-color);
+ padding-top: var(--spacing-small);
+ padding-bottom: var(--spacing-small);
+}
+
+#MSearchSelectWindow a.SelectItem {
+ font-size: var(--navigation-font-size);
+ line-height: var(--content-line-height);
+ margin: 0 var(--spacing-small);
+ border-radius: var(--border-radius-small);
+ color: var(--page-foreground-color) !important;
+ font-weight: normal;
+}
+
+#MSearchSelectWindow a.SelectItem:hover {
+ background: var(--menu-focus-background);
+ color: var(--menu-focus-foreground) !important;
+}
+
+@media screen and (max-width: 767px) {
+ #MSearchBox {
+ margin-top: var(--spacing-medium);
+ margin-bottom: var(--spacing-medium);
+ width: calc(100vw - 30px);
+ }
+
+ #main-menu > li:last-child {
+ float: none !important;
+ }
+
+ #MSearchField {
+ width: calc(100vw - 110px);
+ }
+
+ @keyframes slideInSearchResultsMobile {
+ from {
+ opacity: 0;
+ transform: translate(0, 15px);
+ }
+
+ to {
+ opacity: 1;
+ transform: translate(0, 20px);
+ }
+ }
+
+ #MSearchResultsWindow {
+ left: var(--spacing-medium) !important;
+ right: var(--spacing-medium);
+ overflow: auto;
+ transform: translate(0, 20px);
+ animation: ease-out 280ms slideInSearchResultsMobile;
+ width: auto !important;
+ }
+
+ /*
+ * Overwrites for fixing the searchbox on mobile in doxygen 1.9.2
+ */
+ label.main-menu-btn ~ #searchBoxPos1 {
+ top: 3px !important;
+ right: 6px !important;
+ left: 45px;
+ display: flex;
+ }
+
+ label.main-menu-btn ~ #searchBoxPos1 > #MSearchBox {
+ margin-top: 0;
+ margin-bottom: 0;
+ flex-grow: 2;
+ float: left;
+ }
+}
+
+/*
+ Tree view
+ */
+
+#side-nav {
+ padding: 0 !important;
+ background: var(--side-nav-background);
+}
+
+@media screen and (max-width: 767px) {
+ #side-nav {
+ display: none;
+ }
+
+ #doc-content {
+ margin-left: 0 !important;
+ }
+}
+
+#nav-tree {
+ background: transparent;
+}
+
+#nav-tree .label {
+ font-size: var(--navigation-font-size);
+}
+
+#nav-tree .item {
+ height: var(--tree-item-height);
+ line-height: var(--tree-item-height);
+}
+
+#nav-sync {
+ bottom: 12px;
+ right: 12px;
+ top: auto !important;
+ user-select: none;
+}
+
+#nav-tree .selected {
+ text-shadow: none;
+ background-image: none;
+ background-color: transparent;
+ position: relative;
+}
+
+#nav-tree .selected::after {
+ content: "";
+ position: absolute;
+ top: 1px;
+ bottom: 1px;
+ left: 0;
+ width: 4px;
+ border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
+ background: var(--primary-color);
+}
+
+
+#nav-tree a {
+ color: var(--side-nav-foreground) !important;
+ font-weight: normal;
+}
+
+#nav-tree a:focus {
+ outline-style: auto;
+}
+
+#nav-tree .arrow {
+ opacity: var(--side-nav-arrow-opacity);
+}
+
+.arrow {
+ color: inherit;
+ cursor: pointer;
+ font-size: 45%;
+ vertical-align: middle;
+ margin-right: 2px;
+ font-family: serif;
+ height: auto;
+ text-align: right;
+}
+
+#nav-tree div.item:hover .arrow, #nav-tree a:focus .arrow {
+ opacity: var(--side-nav-arrow-hover-opacity);
+}
+
+#nav-tree .selected a {
+ color: var(--primary-color) !important;
+ font-weight: bolder;
+ font-weight: 600;
+}
+
+.ui-resizable-e {
+ background: var(--separator-color);
+ width: 1px;
+}
+
+/*
+ Contents
+ */
+
+div.header {
+ border-bottom: 1px solid var(--separator-color);
+ background-color: var(--page-background-color);
+ background-image: none;
+}
+
+@media screen and (min-width: 1000px) {
+ #doc-content > div > div.contents,
+ .PageDoc > div.contents {
+ display: flex;
+ flex-direction: row-reverse;
+ flex-wrap: nowrap;
+ align-items: flex-start;
+ }
+
+ div.contents .textblock {
+ min-width: 200px;
+ flex-grow: 1;
+ }
+}
+
+div.contents, div.header .title, div.header .summary {
+ max-width: var(--content-maxwidth);
+}
+
+div.contents, div.header .title {
+ line-height: initial;
+ margin: calc(var(--spacing-medium) + .2em) auto var(--spacing-medium) auto;
+}
+
+div.header .summary {
+ margin: var(--spacing-medium) auto 0 auto;
+}
+
+div.headertitle {
+ padding: 0;
+}
+
+div.header .title {
+ font-weight: 600;
+ font-size: 225%;
+ padding: var(--spacing-medium) var(--spacing-large);
+ word-break: break-word;
+}
+
+div.header .summary {
+ width: auto;
+ display: block;
+ float: none;
+ padding: 0 var(--spacing-large);
+}
+
+td.memSeparator {
+ border-color: var(--separator-color);
+}
+
+span.mlabel {
+ background: var(--primary-color);
+ border: none;
+ padding: 4px 9px;
+ border-radius: 12px;
+ margin-right: var(--spacing-medium);
+}
+
+span.mlabel:last-of-type {
+ margin-right: 2px;
+}
+
+div.contents {
+ padding: 0 var(--spacing-large);
+}
+
+div.contents p, div.contents li {
+ line-height: var(--content-line-height);
+}
+
+div.contents div.dyncontent {
+ margin: var(--spacing-medium) 0;
+}
+
+@media (prefers-color-scheme: dark) {
+ html:not(.light-mode) div.contents div.dyncontent img,
+ html:not(.light-mode) div.contents center img,
+ html:not(.light-mode) div.contents > table img,
+ html:not(.light-mode) div.contents div.dyncontent iframe,
+ html:not(.light-mode) div.contents center iframe,
+ html:not(.light-mode) div.contents table iframe {
+ filter: hue-rotate(180deg) invert();
+ }
+}
+
+html.dark-mode div.contents div.dyncontent img,
+html.dark-mode div.contents center img,
+html.dark-mode div.contents > table img,
+html.dark-mode div.contents div.dyncontent iframe,
+html.dark-mode div.contents center iframe,
+html.dark-mode div.contents table iframe {
+ filter: hue-rotate(180deg) invert();
+}
+
+h2.groupheader {
+ border-bottom: 0px;
+ color: var(--page-foreground-color);
+ box-shadow:
+ 100px 0 var(--page-background-color),
+ -100px 0 var(--page-background-color),
+ 100px 0.75px var(--separator-color),
+ -100px 0.75px var(--separator-color),
+ 500px 0 var(--page-background-color),
+ -500px 0 var(--page-background-color),
+ 500px 0.75px var(--separator-color),
+ -500px 0.75px var(--separator-color),
+ 900px 0 var(--page-background-color),
+ -900px 0 var(--page-background-color),
+ 900px 0.75px var(--separator-color),
+ -900px 0.75px var(--separator-color),
+ 1400px 0 var(--page-background-color),
+ -1400px 0 var(--page-background-color),
+ 1400px 0.75px var(--separator-color),
+ -1400px 0.75px var(--separator-color),
+ 1900px 0 var(--page-background-color),
+ -1900px 0 var(--page-background-color),
+ 1900px 0.75px var(--separator-color),
+ -1900px 0.75px var(--separator-color);
+}
+
+blockquote {
+ margin: 0 var(--spacing-medium) 0 var(--spacing-medium);
+ padding: var(--spacing-small) var(--spacing-large);
+ background: var(--blockquote-background);
+ color: var(--blockquote-foreground);
+ border-left: 0;
+ overflow: visible;
+ border-radius: var(--border-radius-medium);
+ overflow: visible;
+ position: relative;
+}
+
+blockquote::before, blockquote::after {
+ font-weight: bold;
+ font-family: serif;
+ font-size: 360%;
+ opacity: .15;
+ position: absolute;
+}
+
+blockquote::before {
+ content: "“";
+ left: -10px;
+ top: 4px;
+}
+
+blockquote::after {
+ content: "”";
+ right: -8px;
+ bottom: -25px;
+}
+
+blockquote p {
+ margin: var(--spacing-small) 0 var(--spacing-medium) 0;
+}
+.paramname {
+ font-weight: 600;
+ color: var(--primary-dark-color);
+}
+
+.paramname > code {
+ border: 0;
+}
+
+table.params .paramname {
+ font-weight: 600;
+ font-family: var(--font-family-monospace);
+ font-size: var(--code-font-size);
+ padding-right: var(--spacing-small);
+ line-height: var(--table-line-height);
+}
+
+h1.glow, h2.glow, h3.glow, h4.glow, h5.glow, h6.glow {
+ text-shadow: 0 0 15px var(--primary-light-color);
+}
+
+.alphachar a {
+ color: var(--page-foreground-color);
+}
+
+/*
+ Table of Contents
+ */
+
+div.contents .toc {
+ max-height: var(--toc-max-height);
+ min-width: var(--toc-width);
+ border: 0;
+ border-left: 1px solid var(--separator-color);
+ border-radius: 0;
+ background-color: transparent;
+ box-shadow: none;
+ position: sticky;
+ top: var(--toc-sticky-top);
+ padding: 0 var(--spacing-large);
+ margin: var(--spacing-small) 0 var(--spacing-large) var(--spacing-large);
+}
+
+div.toc h3 {
+ color: var(--toc-foreground);
+ font-size: var(--navigation-font-size);
+ margin: var(--spacing-large) 0 var(--spacing-medium) 0;
+}
+
+div.toc li {
+ padding: 0;
+ background: none;
+ line-height: var(--toc-font-size);
+ margin: var(--toc-font-size) 0 0 0;
+}
+
+div.toc li::before {
+ display: none;
+}
+
+div.toc ul {
+ margin-top: 0
+}
+
+div.toc li a {
+ font-size: var(--toc-font-size);
+ color: var(--page-foreground-color) !important;
+ text-decoration: none;
+}
+
+div.toc li a:hover, div.toc li a.active {
+ color: var(--primary-color) !important;
+}
+
+div.toc li a.aboveActive {
+ color: var(--page-secondary-foreground-color) !important;
+}
+
+
+@media screen and (max-width: 999px) {
+ div.contents .toc {
+ max-height: 45vh;
+ float: none;
+ width: auto;
+ margin: 0 0 var(--spacing-medium) 0;
+ position: relative;
+ top: 0;
+ position: relative;
+ border: 1px solid var(--separator-color);
+ border-radius: var(--border-radius-medium);
+ background-color: var(--toc-background);
+ box-shadow: var(--box-shadow);
+ }
+
+ div.contents .toc.interactive {
+ max-height: calc(var(--navigation-font-size) + 2 * var(--spacing-large));
+ overflow: hidden;
+ }
+
+ div.contents .toc > h3 {
+ -webkit-tap-highlight-color: transparent;
+ cursor: pointer;
+ position: sticky;
+ top: 0;
+ background-color: var(--toc-background);
+ margin: 0;
+ padding: var(--spacing-large) 0;
+ display: block;
+ }
+
+ div.contents .toc.interactive > h3::before {
+ content: "";
+ width: 0;
+ height: 0;
+ border-left: 4px solid transparent;
+ border-right: 4px solid transparent;
+ border-top: 5px solid var(--primary-color);
+ display: inline-block;
+ margin-right: var(--spacing-small);
+ margin-bottom: calc(var(--navigation-font-size) / 4);
+ transform: rotate(-90deg);
+ transition: transform 0.25s ease-out;
+ }
+
+ div.contents .toc.interactive.open > h3::before {
+ transform: rotate(0deg);
+ }
+
+ div.contents .toc.interactive.open {
+ max-height: 45vh;
+ overflow: auto;
+ transition: max-height 0.2s ease-in-out;
+ }
+
+ div.contents .toc a, div.contents .toc a.active {
+ color: var(--primary-color) !important;
+ }
+
+ div.contents .toc a:hover {
+ text-decoration: underline;
+ }
+}
+
+/*
+ Code & Fragments
+ */
+
+code, div.fragment, pre.fragment {
+ border-radius: var(--border-radius-small);
+ border: 1px solid var(--separator-color);
+ overflow: hidden;
+}
+
+code {
+ display: inline;
+ background: var(--code-background);
+ color: var(--code-foreground);
+ padding: 2px 6px;
+}
+
+div.fragment, pre.fragment {
+ margin: var(--spacing-medium) 0;
+ padding: calc(var(--spacing-large) - (var(--spacing-large) / 6)) var(--spacing-large);
+ background: var(--fragment-background);
+ color: var(--fragment-foreground);
+ overflow-x: auto;
+}
+
+@media screen and (max-width: 767px) {
+ div.fragment, pre.fragment {
+ border-top-right-radius: 0;
+ border-bottom-right-radius: 0;
+ border-right: 0;
+ }
+
+ .contents > div.fragment,
+ .textblock > div.fragment,
+ .textblock > pre.fragment,
+ .contents > .doxygen-awesome-fragment-wrapper > div.fragment,
+ .textblock > .doxygen-awesome-fragment-wrapper > div.fragment,
+ .textblock > .doxygen-awesome-fragment-wrapper > pre.fragment {
+ margin: var(--spacing-medium) calc(0px - var(--spacing-large));
+ border-radius: 0;
+ border-left: 0;
+ }
+
+ .textblock li > .fragment,
+ .textblock li > .doxygen-awesome-fragment-wrapper > .fragment {
+ margin: var(--spacing-medium) calc(0px - var(--spacing-large));
+ }
+
+ .memdoc li > .fragment,
+ .memdoc li > .doxygen-awesome-fragment-wrapper > .fragment {
+ margin: var(--spacing-medium) calc(0px - var(--spacing-medium));
+ }
+
+ .textblock ul, .memdoc ul {
+ overflow: initial;
+ }
+
+ .memdoc > div.fragment,
+ .memdoc > pre.fragment,
+ dl dd > div.fragment,
+ dl dd pre.fragment,
+ .memdoc > .doxygen-awesome-fragment-wrapper > div.fragment,
+ .memdoc > .doxygen-awesome-fragment-wrapper > pre.fragment,
+ dl dd > .doxygen-awesome-fragment-wrapper > div.fragment,
+ dl dd .doxygen-awesome-fragment-wrapper > pre.fragment {
+ margin: var(--spacing-medium) calc(0px - var(--spacing-medium));
+ border-radius: 0;
+ border-left: 0;
+ }
+}
+
+code, code a, pre.fragment, div.fragment, div.fragment .line, div.fragment span, div.fragment .line a, div.fragment .line span {
+ font-family: var(--font-family-monospace);
+ font-size: var(--code-font-size) !important;
+}
+
+div.line:after {
+ margin-right: var(--spacing-medium);
+}
+
+div.fragment .line, pre.fragment {
+ white-space: pre;
+ word-wrap: initial;
+ line-height: var(--fragment-lineheight);
+}
+
+div.fragment span.keyword {
+ color: var(--fragment-keyword);
+}
+
+div.fragment span.keywordtype {
+ color: var(--fragment-keywordtype);
+}
+
+div.fragment span.keywordflow {
+ color: var(--fragment-keywordflow);
+}
+
+div.fragment span.stringliteral {
+ color: var(--fragment-token)
+}
+
+div.fragment span.comment {
+ color: var(--fragment-comment);
+}
+
+div.fragment a.code {
+ color: var(--fragment-link) !important;
+}
+
+div.fragment span.preprocessor {
+ color: var(--fragment-preprocessor);
+}
+
+div.fragment span.lineno {
+ display: inline-block;
+ width: 27px;
+ border-right: none;
+ background: var(--fragment-linenumber-background);
+ color: var(--fragment-linenumber-color);
+}
+
+div.fragment span.lineno a {
+ background: none;
+ color: var(--fragment-link) !important;
+}
+
+div.fragment .line:first-child .lineno {
+ box-shadow: -999999px 0px 0 999999px var(--fragment-linenumber-background), -999998px 0px 0 999999px var(--fragment-linenumber-border);
+}
+
+div.line {
+ border-radius: var(--border-radius-small);
+}
+
+div.line.glow {
+ background-color: var(--primary-light-color);
+ box-shadow: none;
+}
+
+/*
+ dl warning, attention, note, deprecated, bug, ...
+ */
+
+dl.bug dt a, dl.deprecated dt a, dl.todo dt a {
+ font-weight: bold !important;
+}
+
+dl.warning, dl.attention, dl.note, dl.deprecated, dl.bug, dl.invariant, dl.pre, dl.todo, dl.remark {
+ padding: var(--spacing-medium);
+ margin: var(--spacing-medium) 0;
+ color: var(--page-background-color);
+ overflow: hidden;
+ margin-left: 0;
+ border-radius: var(--border-radius-small);
+}
+
+dl.section dd {
+ margin-bottom: 2px;
+}
+
+dl.warning, dl.attention {
+ background: var(--warning-color);
+ border-left: 8px solid var(--warning-color-dark);
+ color: var(--warning-color-darker);
+}
+
+dl.warning dt, dl.attention dt {
+ color: var(--warning-color-dark);
+}
+
+dl.note, dl.remark {
+ background: var(--note-color);
+ border-left: 8px solid var(--note-color-dark);
+ color: var(--note-color-darker);
+}
+
+dl.note dt, dl.remark dt {
+ color: var(--note-color-dark);
+}
+
+dl.todo {
+ background: var(--todo-color);
+ border-left: 8px solid var(--todo-color-dark);
+ color: var(--todo-color-darker);
+}
+
+dl.todo dt {
+ color: var(--todo-color-dark);
+}
+
+dl.bug dt a {
+ color: var(--todo-color-dark) !important;
+}
+
+dl.bug {
+ background: var(--bug-color);
+ border-left: 8px solid var(--bug-color-dark);
+ color: var(--bug-color-darker);
+}
+
+dl.bug dt a {
+ color: var(--bug-color-dark) !important;
+}
+
+dl.deprecated {
+ background: var(--deprecated-color);
+ border-left: 8px solid var(--deprecated-color-dark);
+ color: var(--deprecated-color-darker);
+}
+
+dl.deprecated dt a {
+ color: var(--deprecated-color-dark) !important;
+}
+
+dl.section dd, dl.bug dd, dl.deprecated dd, dl.todo dd {
+ margin-inline-start: 0px;
+}
+
+dl.invariant, dl.pre {
+ background: var(--invariant-color);
+ border-left: 8px solid var(--invariant-color-dark);
+ color: var(--invariant-color-darker);
+}
+
+dl.invariant dt, dl.pre dt {
+ color: var(--invariant-color-dark);
+}
+
+/*
+ memitem
+ */
+
+div.memdoc, div.memproto, h2.memtitle {
+ box-shadow: none;
+ background-image: none;
+ border: none;
+}
+
+div.memdoc {
+ padding: 0 var(--spacing-medium);
+ background: var(--page-background-color);
+}
+
+h2.memtitle, div.memitem {
+ border: 1px solid var(--separator-color);
+ box-shadow: var(--box-shadow);
+}
+
+h2.memtitle {
+ box-shadow: 0px var(--spacing-medium) 0 -1px var(--fragment-background), var(--box-shadow);
+}
+
+div.memitem {
+ transition: none;
+}
+
+div.memproto, h2.memtitle {
+ background: var(--fragment-background);
+}
+
+h2.memtitle {
+ font-weight: 500;
+ font-size: var(--memtitle-font-size);
+ font-family: var(--font-family-monospace);
+ border-bottom: none;
+ border-top-left-radius: var(--border-radius-medium);
+ border-top-right-radius: var(--border-radius-medium);
+ word-break: break-all;
+ position: relative;
+}
+
+h2.memtitle:after {
+ content: "";
+ display: block;
+ background: var(--fragment-background);
+ height: var(--spacing-medium);
+ bottom: calc(0px - var(--spacing-medium));
+ left: 0;
+ right: -14px;
+ position: absolute;
+ border-top-right-radius: var(--border-radius-medium);
+}
+
+h2.memtitle > span.permalink {
+ font-size: inherit;
+}
+
+h2.memtitle > span.permalink > a {
+ text-decoration: none;
+ padding-left: 3px;
+ margin-right: -4px;
+ user-select: none;
+ display: inline-block;
+ margin-top: -6px;
+}
+
+h2.memtitle > span.permalink > a:hover {
+ color: var(--primary-dark-color) !important;
+}
+
+a:target + h2.memtitle, a:target + h2.memtitle + div.memitem {
+ border-color: var(--primary-light-color);
+}
+
+div.memitem {
+ border-top-right-radius: var(--border-radius-medium);
+ border-bottom-right-radius: var(--border-radius-medium);
+ border-bottom-left-radius: var(--border-radius-medium);
+ overflow: hidden;
+ display: block !important;
+}
+
+div.memdoc {
+ border-radius: 0;
+}
+
+div.memproto {
+ border-radius: 0 var(--border-radius-small) 0 0;
+ overflow: auto;
+ border-bottom: 1px solid var(--separator-color);
+ padding: var(--spacing-medium);
+ margin-bottom: -1px;
+}
+
+div.memtitle {
+ border-top-right-radius: var(--border-radius-medium);
+ border-top-left-radius: var(--border-radius-medium);
+}
+
+div.memproto table.memname {
+ font-family: var(--font-family-monospace);
+ color: var(--page-foreground-color);
+ font-size: var(--memname-font-size);
+ text-shadow: none;
+}
+
+div.memproto div.memtemplate {
+ font-family: var(--font-family-monospace);
+ color: var(--primary-dark-color);
+ font-size: var(--memname-font-size);
+ margin-left: 2px;
+ text-shadow: none;
+}
+
+table.mlabels, table.mlabels > tbody {
+ display: block;
+}
+
+td.mlabels-left {
+ width: auto;
+}
+
+td.mlabels-right {
+ margin-top: 3px;
+ position: sticky;
+ left: 0;
+}
+
+table.mlabels > tbody > tr:first-child {
+ display: flex;
+ justify-content: space-between;
+ flex-wrap: wrap;
+}
+
+.memname, .memitem span.mlabels {
+ margin: 0
+}
+
+/*
+ reflist
+ */
+
+dl.reflist {
+ box-shadow: var(--box-shadow);
+ border-radius: var(--border-radius-medium);
+ border: 1px solid var(--separator-color);
+ overflow: hidden;
+ padding: 0;
+}
+
+
+dl.reflist dt, dl.reflist dd {
+ box-shadow: none;
+ text-shadow: none;
+ background-image: none;
+ border: none;
+ padding: 12px;
+}
+
+
+dl.reflist dt {
+ font-weight: 500;
+ border-radius: 0;
+ background: var(--code-background);
+ border-bottom: 1px solid var(--separator-color);
+ color: var(--page-foreground-color)
+}
+
+
+dl.reflist dd {
+ background: none;
+}
+
+/*
+ Table
+ */
+
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname),
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody {
+ display: inline-block;
+ max-width: 100%;
+}
+
+.contents > table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname):not(.classindex) {
+ margin-left: calc(0px - var(--spacing-large));
+ margin-right: calc(0px - var(--spacing-large));
+ max-width: calc(100% + 2 * var(--spacing-large));
+}
+
+table.fieldtable,
+table.markdownTable tbody,
+table.doxtable tbody {
+ border: none;
+ margin: var(--spacing-medium) 0;
+ box-shadow: 0 0 0 1px var(--separator-color);
+ border-radius: var(--border-radius-small);
+}
+
+table.doxtable caption {
+ display: block;
+}
+
+table.fieldtable {
+ border-collapse: collapse;
+ width: 100%;
+}
+
+th.markdownTableHeadLeft,
+th.markdownTableHeadRight,
+th.markdownTableHeadCenter,
+th.markdownTableHeadNone,
+table.doxtable th {
+ background: var(--tablehead-background);
+ color: var(--tablehead-foreground);
+ font-weight: 600;
+ font-size: var(--page-font-size);
+}
+
+th.markdownTableHeadLeft:first-child,
+th.markdownTableHeadRight:first-child,
+th.markdownTableHeadCenter:first-child,
+th.markdownTableHeadNone:first-child,
+table.doxtable tr th:first-child {
+ border-top-left-radius: var(--border-radius-small);
+}
+
+th.markdownTableHeadLeft:last-child,
+th.markdownTableHeadRight:last-child,
+th.markdownTableHeadCenter:last-child,
+th.markdownTableHeadNone:last-child,
+table.doxtable tr th:last-child {
+ border-top-right-radius: var(--border-radius-small);
+}
+
+table.markdownTable td,
+table.markdownTable th,
+table.fieldtable td,
+table.fieldtable th,
+table.doxtable td,
+table.doxtable th {
+ border: 1px solid var(--separator-color);
+ padding: var(--spacing-small) var(--spacing-medium);
+}
+
+table.markdownTable td:last-child,
+table.markdownTable th:last-child,
+table.fieldtable td:last-child,
+table.fieldtable th:last-child,
+table.doxtable td:last-child,
+table.doxtable th:last-child {
+ border-right: none;
+}
+
+table.markdownTable td:first-child,
+table.markdownTable th:first-child,
+table.fieldtable td:first-child,
+table.fieldtable th:first-child,
+table.doxtable td:first-child,
+table.doxtable th:first-child {
+ border-left: none;
+}
+
+table.markdownTable tr:first-child td,
+table.markdownTable tr:first-child th,
+table.fieldtable tr:first-child td,
+table.fieldtable tr:first-child th,
+table.doxtable tr:first-child td,
+table.doxtable tr:first-child th {
+ border-top: none;
+}
+
+table.markdownTable tr:last-child td,
+table.markdownTable tr:last-child th,
+table.fieldtable tr:last-child td,
+table.fieldtable tr:last-child th,
+table.doxtable tr:last-child td,
+table.doxtable tr:last-child th {
+ border-bottom: none;
+}
+
+table.markdownTable tr, table.doxtable tr {
+ border-bottom: 1px solid var(--separator-color);
+}
+
+table.markdownTable tr:last-child, table.doxtable tr:last-child {
+ border-bottom: none;
+}
+
+table.fieldtable th {
+ font-size: var(--page-font-size);
+ font-weight: 600;
+ background-image: none;
+ background-color: var(--tablehead-background);
+ color: var(--tablehead-foreground);
+}
+
+table.fieldtable td.fieldtype, .fieldtable td.fieldname, .fieldtable td.fielddoc, .fieldtable th {
+ border-bottom: 1px solid var(--separator-color);
+ border-right: 1px solid var(--separator-color);
+}
+
+table.fieldtable tr:last-child td:first-child {
+ border-bottom-left-radius: var(--border-radius-small);
+}
+
+table.fieldtable tr:last-child td:last-child {
+ border-bottom-right-radius: var(--border-radius-small);
+}
+
+.memberdecls td.glow, .fieldtable tr.glow {
+ background-color: var(--primary-light-color);
+ box-shadow: none;
+}
+
+table.memberdecls {
+ display: block;
+ -webkit-tap-highlight-color: transparent;
+}
+
+table.memberdecls tr[class^='memitem'] {
+ font-family: var(--font-family-monospace);
+ font-size: var(--code-font-size);
+}
+
+table.memberdecls tr[class^='memitem'] .memTemplParams {
+ font-family: var(--font-family-monospace);
+ font-size: var(--code-font-size);
+ color: var(--primary-dark-color);
+ white-space: normal;
+}
+
+table.memberdecls .memItemLeft,
+table.memberdecls .memItemRight,
+table.memberdecls .memTemplItemLeft,
+table.memberdecls .memTemplItemRight,
+table.memberdecls .memTemplParams {
+ transition: none;
+ padding-top: var(--spacing-small);
+ padding-bottom: var(--spacing-small);
+ border-top: 1px solid var(--separator-color);
+ border-bottom: 1px solid var(--separator-color);
+ background-color: var(--fragment-background);
+}
+
+table.memberdecls .memTemplItemLeft,
+table.memberdecls .memTemplItemRight {
+ padding-top: 2px;
+}
+
+table.memberdecls .memTemplParams {
+ border-bottom: 0;
+ border-left: 1px solid var(--separator-color);
+ border-right: 1px solid var(--separator-color);
+ border-radius: var(--border-radius-small) var(--border-radius-small) 0 0;
+ padding-bottom: var(--spacing-small);
+}
+
+table.memberdecls .memTemplItemLeft {
+ border-radius: 0 0 0 var(--border-radius-small);
+ border-left: 1px solid var(--separator-color);
+ border-top: 0;
+}
+
+table.memberdecls .memTemplItemRight {
+ border-radius: 0 0 var(--border-radius-small) 0;
+ border-right: 1px solid var(--separator-color);
+ padding-left: 0;
+ border-top: 0;
+}
+
+table.memberdecls .memItemLeft {
+ border-radius: var(--border-radius-small) 0 0 var(--border-radius-small);
+ border-left: 1px solid var(--separator-color);
+ padding-left: var(--spacing-medium);
+ padding-right: 0;
+}
+
+table.memberdecls .memItemRight {
+ border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
+ border-right: 1px solid var(--separator-color);
+ padding-right: var(--spacing-medium);
+ padding-left: 0;
+
+}
+
+table.memberdecls .mdescLeft, table.memberdecls .mdescRight {
+ background: none;
+ color: var(--page-foreground-color);
+ padding: var(--spacing-small) 0;
+}
+
+table.memberdecls .memItemLeft,
+table.memberdecls .memTemplItemLeft {
+ padding-right: var(--spacing-medium);
+}
+
+table.memberdecls .memSeparator {
+ background: var(--page-background-color);
+ height: var(--spacing-large);
+ border: 0;
+ transition: none;
+}
+
+table.memberdecls .groupheader {
+ margin-bottom: var(--spacing-large);
+}
+
+table.memberdecls .inherit_header td {
+ padding: 0 0 var(--spacing-medium) 0;
+ text-indent: -12px;
+ color: var(--page-secondary-foreground-color);
+}
+
+table.memberdecls img[src="closed.png"],
+table.memberdecls img[src="open.png"],
+div.dynheader img[src="open.png"],
+div.dynheader img[src="closed.png"] {
+ width: 0;
+ height: 0;
+ border-left: 4px solid transparent;
+ border-right: 4px solid transparent;
+ border-top: 5px solid var(--primary-color);
+ margin-top: 8px;
+ display: block;
+ float: left;
+ margin-left: -10px;
+ transition: transform 0.25s ease-out;
+}
+
+table.memberdecls img {
+ margin-right: 10px;
+}
+
+table.memberdecls img[src="closed.png"],
+div.dynheader img[src="closed.png"] {
+ transform: rotate(-90deg);
+
+}
+
+.compoundTemplParams {
+ font-family: var(--font-family-monospace);
+ color: var(--primary-dark-color);
+ font-size: var(--code-font-size);
+}
+
+@media screen and (max-width: 767px) {
+
+ table.memberdecls .memItemLeft,
+ table.memberdecls .memItemRight,
+ table.memberdecls .mdescLeft,
+ table.memberdecls .mdescRight,
+ table.memberdecls .memTemplItemLeft,
+ table.memberdecls .memTemplItemRight,
+ table.memberdecls .memTemplParams {
+ display: block;
+ text-align: left;
+ padding-left: var(--spacing-large);
+ margin: 0 calc(0px - var(--spacing-large)) 0 calc(0px - var(--spacing-large));
+ border-right: none;
+ border-left: none;
+ border-radius: 0;
+ white-space: normal;
+ }
+
+ table.memberdecls .memItemLeft,
+ table.memberdecls .mdescLeft,
+ table.memberdecls .memTemplItemLeft {
+ border-bottom: 0;
+ padding-bottom: 0;
+ }
+
+ table.memberdecls .memTemplItemLeft {
+ padding-top: 0;
+ }
+
+ table.memberdecls .mdescLeft {
+ margin-bottom: calc(0px - var(--page-font-size));
+ }
+
+ table.memberdecls .memItemRight,
+ table.memberdecls .mdescRight,
+ table.memberdecls .memTemplItemRight {
+ border-top: 0;
+ padding-top: 0;
+ padding-right: var(--spacing-large);
+ overflow-x: auto;
+ }
+
+ table.memberdecls tr[class^='memitem']:not(.inherit) {
+ display: block;
+ width: calc(100vw - 2 * var(--spacing-large));
+ }
+
+ table.memberdecls .mdescRight {
+ color: var(--page-foreground-color);
+ }
+
+ table.memberdecls tr.inherit {
+ visibility: hidden;
+ }
+
+ table.memberdecls tr[style="display: table-row;"] {
+ display: block !important;
+ visibility: visible;
+ width: calc(100vw - 2 * var(--spacing-large));
+ animation: fade .5s;
+ }
+
+ @keyframes fade {
+ 0% {
+ opacity: 0;
+ max-height: 0;
+ }
+
+ 100% {
+ opacity: 1;
+ max-height: 200px;
+ }
+ }
+}
+
+
+/*
+ Horizontal Rule
+ */
+
+hr {
+ margin-top: var(--spacing-large);
+ margin-bottom: var(--spacing-large);
+ height: 1px;
+ background-color: var(--separator-color);
+ border: 0;
+}
+
+.contents hr {
+ box-shadow: 100px 0 0 var(--separator-color),
+ -100px 0 0 var(--separator-color),
+ 500px 0 0 var(--separator-color),
+ -500px 0 0 var(--separator-color),
+ 1500px 0 0 var(--separator-color),
+ -1500px 0 0 var(--separator-color),
+ 2000px 0 0 var(--separator-color),
+ -2000px 0 0 var(--separator-color);
+}
+
+.contents img, .contents .center, .contents center, .contents div.image object {
+ max-width: 100%;
+ overflow: auto;
+}
+
+@media screen and (max-width: 767px) {
+ .contents .dyncontent > .center, .contents > center {
+ margin-left: calc(0px - var(--spacing-large));
+ margin-right: calc(0px - var(--spacing-large));
+ max-width: calc(100% + 2 * var(--spacing-large));
+ }
+}
+
+/*
+ Directories
+ */
+div.directory {
+ border-top: 1px solid var(--separator-color);
+ border-bottom: 1px solid var(--separator-color);
+ width: auto;
+}
+
+table.directory {
+ font-family: var(--font-family);
+ font-size: var(--page-font-size);
+ font-weight: normal;
+ width: 100%;
+}
+
+table.directory td.entry, table.directory td.desc {
+ padding: calc(var(--spacing-small) / 2) var(--spacing-small);
+ line-height: var(--table-line-height);
+}
+
+table.directory tr.even td:last-child {
+ border-radius: 0 var(--border-radius-small) var(--border-radius-small) 0;
+}
+
+table.directory tr.even td:first-child {
+ border-radius: var(--border-radius-small) 0 0 var(--border-radius-small);
+}
+
+table.directory tr.even:last-child td:last-child {
+ border-radius: 0 var(--border-radius-small) 0 0;
+}
+
+table.directory tr.even:last-child td:first-child {
+ border-radius: var(--border-radius-small) 0 0 0;
+}
+
+table.directory td.desc {
+ min-width: 250px;
+}
+
+table.directory tr.even {
+ background-color: var(--odd-color);
+}
+
+table.directory tr.odd {
+ background-color: transparent;
+}
+
+.icona {
+ width: auto;
+ height: auto;
+ margin: 0 var(--spacing-small);
+}
+
+.icon {
+ background: var(--primary-color);
+ border-radius: var(--border-radius-small);
+ font-size: var(--page-font-size);
+ padding: calc(var(--page-font-size) / 5);
+ line-height: var(--page-font-size);
+ transform: scale(0.8);
+ height: auto;
+ width: var(--page-font-size);
+ user-select: none;
+}
+
+.iconfopen, .icondoc, .iconfclosed {
+ background-position: center;
+ margin-bottom: 0;
+ height: var(--table-line-height);
+}
+
+.icondoc {
+ filter: saturate(0.2);
+}
+
+@media screen and (max-width: 767px) {
+ div.directory {
+ margin-left: calc(0px - var(--spacing-large));
+ margin-right: calc(0px - var(--spacing-large));
+ }
+}
+
+@media (prefers-color-scheme: dark) {
+ html:not(.light-mode) .iconfopen, html:not(.light-mode) .iconfclosed {
+ filter: hue-rotate(180deg) invert();
+ }
+}
+
+html.dark-mode .iconfopen, html.dark-mode .iconfclosed {
+ filter: hue-rotate(180deg) invert();
+}
+
+/*
+ Class list
+ */
+
+.classindex dl.odd {
+ background: var(--odd-color);
+ border-radius: var(--border-radius-small);
+}
+
+.classindex dl.even {
+ background-color: transparent;
+}
+
+/*
+ Class Index Doxygen 1.8
+*/
+
+table.classindex {
+ margin-left: 0;
+ margin-right: 0;
+ width: 100%;
+}
+
+table.classindex table div.ah {
+ background-image: none;
+ background-color: initial;
+ border-color: var(--separator-color);
+ color: var(--page-foreground-color);
+ box-shadow: var(--box-shadow);
+ border-radius: var(--border-radius-large);
+ padding: var(--spacing-small);
+}
+
+div.qindex {
+ background-color: var(--odd-color);
+ border-radius: var(--border-radius-small);
+ border: 1px solid var(--separator-color);
+ padding: var(--spacing-small) 0;
+}
+
+/*
+ Footer and nav-path
+ */
+
+#nav-path {
+ width: 100%;
+}
+
+#nav-path ul {
+ background-image: none;
+ background: var(--page-background-color);
+ border: none;
+ border-top: 1px solid var(--separator-color);
+ border-bottom: 1px solid var(--separator-color);
+ border-bottom: 0;
+ box-shadow: 0 0.75px 0 var(--separator-color);
+ font-size: var(--navigation-font-size);
+}
+
+img.footer {
+ width: 60px;
+}
+
+.navpath li.footer {
+ color: var(--page-secondary-foreground-color);
+}
+
+address.footer {
+ color: var(--page-secondary-foreground-color);
+ margin-bottom: var(--spacing-large);
+}
+
+#nav-path li.navelem {
+ background-image: none;
+ display: flex;
+ align-items: center;
+}
+
+.navpath li.navelem a {
+ text-shadow: none;
+ display: inline-block;
+ color: var(--primary-color) !important;
+}
+
+.navpath li.navelem b {
+ color: var(--primary-dark-color);
+ font-weight: 500;
+}
+
+li.navelem {
+ padding: 0;
+ margin-left: -8px;
+}
+
+li.navelem:first-child {
+ margin-left: var(--spacing-large);
+}
+
+li.navelem:first-child:before {
+ display: none;
+}
+
+#nav-path li.navelem:after {
+ content: '';
+ border: 5px solid var(--page-background-color);
+ border-bottom-color: transparent;
+ border-right-color: transparent;
+ border-top-color: transparent;
+ transform: translateY(-1px) scaleY(4.2);
+ z-index: 10;
+ margin-left: 6px;
+}
+
+#nav-path li.navelem:before {
+ content: '';
+ border: 5px solid var(--separator-color);
+ border-bottom-color: transparent;
+ border-right-color: transparent;
+ border-top-color: transparent;
+ transform: translateY(-1px) scaleY(3.2);
+ margin-right: var(--spacing-small);
+}
+
+.navpath li.navelem a:hover {
+ color: var(--primary-color);
+}
+
+/*
+ Scrollbars for Webkit
+*/
+
+#nav-tree::-webkit-scrollbar,
+div.fragment::-webkit-scrollbar,
+pre.fragment::-webkit-scrollbar,
+div.memproto::-webkit-scrollbar,
+.contents center::-webkit-scrollbar,
+.contents .center::-webkit-scrollbar,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar,
+div.contents .toc::-webkit-scrollbar {
+ background: transparent;
+ width: calc(var(--webkit-scrollbar-size) + var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
+ height: calc(var(--webkit-scrollbar-size) + var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
+}
+
+#nav-tree::-webkit-scrollbar-thumb,
+div.fragment::-webkit-scrollbar-thumb,
+pre.fragment::-webkit-scrollbar-thumb,
+div.memproto::-webkit-scrollbar-thumb,
+.contents center::-webkit-scrollbar-thumb,
+.contents .center::-webkit-scrollbar-thumb,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar-thumb,
+div.contents .toc::-webkit-scrollbar-thumb {
+ background-color: transparent;
+ border: var(--webkit-scrollbar-padding) solid transparent;
+ border-radius: calc(var(--webkit-scrollbar-padding) + var(--webkit-scrollbar-padding));
+ background-clip: padding-box;
+}
+
+#nav-tree:hover::-webkit-scrollbar-thumb,
+div.fragment:hover::-webkit-scrollbar-thumb,
+pre.fragment:hover::-webkit-scrollbar-thumb,
+div.memproto:hover::-webkit-scrollbar-thumb,
+.contents center:hover::-webkit-scrollbar-thumb,
+.contents .center:hover::-webkit-scrollbar-thumb,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody:hover::-webkit-scrollbar-thumb,
+div.contents .toc:hover::-webkit-scrollbar-thumb {
+ background-color: var(--webkit-scrollbar-color);
+}
+
+#nav-tree::-webkit-scrollbar-track,
+div.fragment::-webkit-scrollbar-track,
+pre.fragment::-webkit-scrollbar-track,
+div.memproto::-webkit-scrollbar-track,
+.contents center::-webkit-scrollbar-track,
+.contents .center::-webkit-scrollbar-track,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody::-webkit-scrollbar-track,
+div.contents .toc::-webkit-scrollbar-track {
+ background: transparent;
+}
+
+#nav-tree::-webkit-scrollbar-corner {
+ background-color: var(--side-nav-background);
+}
+
+#nav-tree,
+div.fragment,
+pre.fragment,
+div.memproto,
+.contents center,
+.contents .center,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody,
+div.contents .toc {
+ overflow-x: auto;
+ overflow-x: overlay;
+}
+
+#nav-tree {
+ overflow-x: auto;
+ overflow-y: auto;
+ overflow-y: overlay;
+}
+
+/*
+ Scrollbars for Firefox
+*/
+
+#nav-tree,
+div.fragment,
+pre.fragment,
+div.memproto,
+.contents center,
+.contents .center,
+.contents table:not(.memberdecls):not(.mlabels):not(.fieldtable):not(.memname) tbody,
+div.contents .toc {
+ scrollbar-width: thin;
+}
+
+/*
+ Optional Dark mode toggle button
+*/
+
+doxygen-awesome-dark-mode-toggle {
+ display: inline-block;
+ margin: 0 0 0 var(--spacing-small);
+ padding: 0;
+ width: var(--searchbar-height);
+ height: var(--searchbar-height);
+ background: none;
+ border: none;
+ border-radius: var(--searchbar-height);
+ vertical-align: middle;
+ text-align: center;
+ line-height: var(--searchbar-height);
+ font-size: 22px;
+ display: flex;
+ align-items: center;
+ justify-content: center;
+ user-select: none;
+ cursor: pointer;
+}
+
+doxygen-awesome-dark-mode-toggle > svg {
+ transition: transform .1s ease-in-out;
+}
+
+doxygen-awesome-dark-mode-toggle:active > svg {
+ transform: scale(.5);
+}
+
+doxygen-awesome-dark-mode-toggle:hover {
+ background-color: rgba(0,0,0,.03);
+}
+
+html.dark-mode doxygen-awesome-dark-mode-toggle:hover {
+ background-color: rgba(0,0,0,.18);
+}
+
+/*
+ Optional fragment copy button
+*/
+.doxygen-awesome-fragment-wrapper {
+ position: relative;
+}
+
+doxygen-awesome-fragment-copy-button {
+ opacity: 0;
+ background: var(--fragment-background);
+ width: 28px;
+ height: 28px;
+ position: absolute;
+ right: calc(var(--spacing-large) - (var(--spacing-large) / 2.5));
+ top: calc(var(--spacing-large) - (var(--spacing-large) / 2.5));
+ border: 1px solid var(--fragment-foreground);
+ cursor: pointer;
+ border-radius: var(--border-radius-small);
+ display: flex;
+ justify-content: center;
+ align-items: center;
+}
+
+.doxygen-awesome-fragment-wrapper:hover doxygen-awesome-fragment-copy-button, doxygen-awesome-fragment-copy-button.success {
+ opacity: .28;
+}
+
+doxygen-awesome-fragment-copy-button:hover, doxygen-awesome-fragment-copy-button.success {
+ opacity: 1 !important;
+}
+
+doxygen-awesome-fragment-copy-button:active:not([class~=success]) svg {
+ transform: scale(.91);
+}
+
+doxygen-awesome-fragment-copy-button svg {
+ fill: var(--fragment-foreground);
+ width: 18px;
+ height: 18px;
+}
+
+doxygen-awesome-fragment-copy-button.success svg {
+ fill: rgb(14, 168, 14);
+}
+
+doxygen-awesome-fragment-copy-button.success {
+ border-color: rgb(14, 168, 14);
+}
+
+@media screen and (max-width: 767px) {
+ .textblock > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
+ .textblock li > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
+ .memdoc li > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
+ .memdoc > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button,
+ dl dd > .doxygen-awesome-fragment-wrapper > doxygen-awesome-fragment-copy-button {
+ right: 0;
+ }
+}
+
+/*
+ Optional paragraph link button
+*/
+
+a.anchorlink {
+ font-size: 90%;
+ margin-left: var(--spacing-small);
+ color: var(--page-foreground-color) !important;
+ text-decoration: none;
+ opacity: .15;
+ display: none;
+ transition: opacity .1s ease-in-out, color .1s ease-in-out;
+}
+
+a.anchorlink svg {
+ fill: var(--page-foreground-color);
+}
+
+h3 a.anchorlink svg, h4 a.anchorlink svg {
+ margin-bottom: -3px;
+ margin-top: -4px;
+}
+
+a.anchorlink:hover {
+ opacity: .45;
+}
+
+h2:hover a.anchorlink, h1:hover a.anchorlink, h3:hover a.anchorlink, h4:hover a.anchorlink {
+ display: inline-block;
+}
diff --git a/MaterialX/documents/Images/MaterialXGraphEditor_Marble.png b/MaterialX/documents/Images/MaterialXGraphEditor_Marble.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXLogo.png b/MaterialX/documents/Images/MaterialXLogo.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXLogo_200x155.png b/MaterialX/documents/Images/MaterialXLogo_200x155.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_Carpaint.png b/MaterialX/documents/Images/MaterialXView_Carpaint.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_Copper.png b/MaterialX/documents/Images/MaterialXView_Copper.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_Marble.png b/MaterialX/documents/Images/MaterialXView_Marble.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_Plastic.png b/MaterialX/documents/Images/MaterialXView_Plastic.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_TiledBrass.png b/MaterialX/documents/Images/MaterialXView_TiledBrass.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/MaterialXView_TiledWood.png b/MaterialX/documents/Images/MaterialXView_TiledWood.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/OpenChessSet_Arnold_01.png b/MaterialX/documents/Images/OpenChessSet_Arnold_01.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/OpenChessSet_Karma_01.png b/MaterialX/documents/Images/OpenChessSet_Karma_01.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Images/shadergen.png b/MaterialX/documents/Images/shadergen.png
old mode 100644
new mode 100755
diff --git a/MaterialX/documents/Specification/MaterialX.GeomExts.md b/MaterialX/documents/Specification/MaterialX.GeomExts.md
old mode 100644
new mode 100755
index e0fb3a8..7d1fe92
--- a/MaterialX/documents/Specification/MaterialX.GeomExts.md
+++ b/MaterialX/documents/Specification/MaterialX.GeomExts.md
@@ -1,525 +1,517 @@
-
-
-
-# MaterialX Geometry Extensions
-
-**Version 1.39**
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-October 21, 2022
-
-
-# Introduction
-
-The core [**MaterialX Specification**](./MaterialX.Specification.md) defines a number of element types and specific functional node definitions which can be used to describe the structure of shading networks and materials, including the definitions and functionality of custom shading operations.
-
-There are many formats that can be used to describe the associations between shading materials and renderable geometry as well as various data and metadata associated with geometry. For performance and other reasons it is often desirable to use native application mechanisms or something like Pixar's USD[^1] to describe these associations. However, there is significant value in being able to store a complete description of a CG object "look" within a single application-independent file format. This document describes extensions to the core MaterialX Specification that can be used to define collections of geometries, geometric properties and their values per geometry, and assignment of materials, variants, visibility and rendering properties to specific geometries in named looks, either directly or via geometry name expressions or named collections.
-
-
-## Table of Contents
-
-**[Introduction](#introduction)**
-
-**[Geometry Representation](#geometry-representation)**
- [Lights](#lights)
- [Geometry Name Expressions](#geometry-name-expressions)
- [Collections](#collections)
- [Geometry Prefixes](#geometry-prefixes)
-
-**[Additional MaterialX Data Types](#additional-materialx-data-types)**
-
-**[Additional Filename Substitutions](#additional-filename-substitutions)**
-
-**[Geometry Info Elements](#geometry-info-elements)**
- [GeomInfo Definition](#geominfo-definition)
- [GeomProp Elements](#geomprop-elements)
- [Geometry Token Elements](#geometry-token-elements)
- [TokenDefault Elements](#tokendefault-elements)
- [Reserved GeomProp Names](#reserved-geomprop-names)
-
-**[Look and Property Elements](#look-and-property-elements)**
- [Property Definition](#property-definition)
- [Look Definition](#look-definition)
- [Assignment Elements](#assignment-elements)
- [MaterialAssign Elements](#materialassign-elements)
- [VariantAssign Elements](#variantassign-elements)
- [Visibility Elements](#visibility-elements)
- [PropertyAssign Elements](#propertyassign-elements)
- [Look Examples](#look-examples)
-
-**[References](#references)**
-
-
-
-
-# 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 `geomfile` attributes within any element; that `geomfile` declaration will then apply to any geometry name referenced within the scope of that element, e.g. any `geom` attributes, including those defining the contents of collections (but not when referencing the contents of a collection via a `collection` attribute). If a geomfile is not defined for the scope of any particular `geom` attribute, 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/](http://www.alembic.io/)) and USD ([http://graphics.pixar.com/usd](http://graphics.pixar.com/usd)). "Geometry" can be any particular geometric object that a host application may support, including but not limited to polygons, meshes, subdivision surfaces, NURBS, implicit surfaces, particle sets, volumes, lights, 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/...
-```
-
-E.g. an initial "/" followed by one or more hierarchy level strings separated by "/"s, ending with a final string and no "/". The strings making up the path component for a level of hierarchy cannot contain spaces or "/"s or any of the characters reserved for geometry name expressions (see below). Individual implementations may have further restrictions on what characters may be used for hierarchy level names, so for ultimate compatibility it is recommended to use names comprised only of upper- or lower-case letters, digits 0-9, and underscores ("_").
-
-Geometry names (e.g. the full path name) must be unique within the entire set of geometries referenced in a setup. Note that _there is no implied transformation hierarchy in the specified geometry paths_: the paths are simply the names of the geometry. However, the path-like nature of geometry names can be used to benefit in geometry name expression pattern matching and assignments.
-
-Note: if a geometry mesh is divided into partitions, the syntax for the parent mesh would be:
-
-```
- /path/to/geom/meshname
-```
-
-and for the child partitions, the syntax would be:
-
-```
- /path/to/geom/meshname/partitionname
-```
-
-Assignments to non-leaf locations apply hierarchically to all geometries below the specified location, unless they are the target of another assignment. By extension, an assignment to "/" applies to _all _geometries within the MaterialX setup, unless they are the target of another assignment.
-
-
-## Lights
-
-Computer Graphics assets often include lights as part of the asset, such as the headlights of a car. MaterialX does not define "light" objects per se, but instead allows referencing externally-defined light objects in the same manner as geometry, via a UNIX-like path. MaterialX does not describe the position, view or shape of a light object: MaterialX presumes that these properties are stored within the external representation.
-
-Light object geometries can be turned off (muted) in looks by making the light geometry invisible, assignment of "light"-context shader materials can be done using a <materialassign> within a <look>, and illumination and shadowing assignments can be handled using <visibility> declarations for the light geometry. See the [**Look Definition**](#look-definition) section below for details.
-
-
-
-## Geometry Name Expressions
-
-Certain elements in MaterialX files support geometry specification via expressions. The syntax for geometry name expressions in MaterialX largely follows that of “glob” patterns for filenames in Unix environments, with a few extensions for the specific needs of geometry references.
-
-Within a single hierarchy level (e.g. between "/"s):
-
-* `*` matches 0 or more characters
-* `?` matches exactly one character
-* `[]` are used to match any individual character within the brackets, with "-" meaning match anything between the character preceding and the character following the "-"
-* `{}` are used to match any of the comma-separated strings or expressions within the braces
-
-Additionally, a `/` will match only exactly a single `/` in a geometry name, e.g. as a boundary for a hierarchy level, while a `//` will match a single `/`, or two `/`s any number of hierarchy levels apart; `//` can be used to specify a match at any hierarchy depth. If a geometry name ends with `//*`, the final `*` will only match leaf geometries in the hierarchy. A geometry name of `//*` by itself will match all leaf geometries in an entire scene, while the name `//*//` will match all geometries at any level, including nested geometries, and the name `/a/b/c//*//` will match all geometries at any level below `/a/b/c`. It should be noted that for a mesh with partitions, it is the partitions and not the mesh which are treated as leaf geometry by MaterialX geometry names using `//*`.
-
-
-
-## Collections
-
-Collections are recipes for building a list of geometries (which can be any path within the geometry hierarchy), which can be used as a shorthand for assignments to a (potentially large) number of geometries at once. Collections can be built up from lists of specific geometries, geometries matching defined geometry name expressions, other collections, or any combination of those.
-
-A **<collection>** element contains lists of geometry expressions and/or collections to be included, and an optional list of geometry expressions to be excluded:
-
-```xml
-
-```
-
-Either `includegeom` and/or `includecollection` must be specified. The `includegeom` and `includecollection` lists are applied first, followed by the `excludegeom` list. This can be used to build up the contents of a collection in pieces, or to add expression-matched geometry then remove specific unwanted matched geometries. The contents of a collection can itself be used to define a portion of another collection. The contents of each `includecollection` collection are effectively evaluated in whole before being added to the collection being built.
-
-If the containing file is capable of defining MaterialX-compliant collections (e.g. an Alembic or USD file), its collections can be referred to in any situation where a collection="name" reference is allowed.
-
-
-
-## Geometry Prefixes
-
-As a shorthand convenience, MaterialX allows the specification of a `geomprefix` attribute that will be prepended to data values of type "geomname" or "geomnamearray" (e.g. `geom` attributes in ``, ``, ``, and `` elements) specified within the scope of the element defining the `geomprefix`, similar to how MaterialX allows the specification of a `fileprefix` attribute which is prepended to input values of type "filename". For data values of type "geomnamearray", the `geomprefix` is prepended to each individual comma-separated geometry name. Since the values of the prefix and the geometry are string-concatenated, the value of a `geomprefix` should generally end with a "/". Geomprefix is commonly used to split off leading portions of geometry paths common to all geometry names, e.g. to define the "asset root" path.
-
-So the following MTLX file snippets are equivalent:
-
-
-```xml
-
-
-
-
-
-
-
-```
-
-
-
-
-# Additional MaterialX Data Types
-
-Systems supporting MaterialX Geometry Extensions support the following additional standard data types:
-
-**GeomName** and **GeomNameArray**: attributes of type "geomname" are just strings within quotes, but specifically mean the name of a single geometry using the conventions described in the [**Geometry Representation**](#geometry-representation) and [**Geometry Name Expressions**](#geometry-name-expressions) sections. A geomname is allowed to use a geometry name expression as long as it resolves to a single geometry. Attributes of type "geomnamearray" are strings within quotes containing a comma-separated list of one or more geomname values with or without expressions, and may resolve to any number of geometries.
-
-
-
-
-# Additional Filename Substitutions
-
-Filename input values for various nodes can include one or more special strings which will be replaced by the application with values derived from the current geometry, from the MaterialX state, or from the host application environment. Applications which support MaterialX Geometry Extensions also support the following filename substitution:
-
-
-| Token | Description |
-| ---- | ---- |
-| <geometry token> | The value of a specified token declared in a <geominfo> element or as a uniform primvar value (generally of type string or integer) for the current geometry. |
-
-
-Only applications fully supporting Geometry Extensions may allow using a <_geometry token_> as part of a larger filename string. All applications should allow the use of "<_geometry token_>" as the full filename string, in which case the string primvar value stored with the geometry is used as the filename unchanged; the string primvar value itself might be allowed to contain another token such as <UDIM> which the renderer may be able to parse and replace itself.
-
-
-
-
-# Geometry Info Elements
-
-Geometry Info ("geominfo") elements are used to define sets of named geometric properties with constant values, and to associate them with specific external geometries.
-
-The most common use for geominfo elements is to define the filenames (or portions of filenames) of texture map images mapped onto the geometry. Typically, there are several types of textures such as color, roughness, bump, opacity, etc. associated with each geometry: each texture name string would be a separate <token> within the <geominfo>. These images could contain texture data for multiple geometries, which would either be listed in the `geom` attribute of the <geominfo> element, or be assembled into a collection and the name of that collection would be specified in the `collection` attribute.
-
-
-## GeomInfo Definition
-
-A **<geominfo>** element contains one or more geometry property and/or token definitions, and associates them and their values with all geometries listed in the `geom` or `collection` attribute of the <geominfo>:
-
-```xml
-
- ...geometry property and token value definitions...
-
-```
-
-Note that no two <geominfo>s may define values for the same geometry property or token for the same geometry, whether the geometry is specified directly, matched via a geometry name expression, or contained within a specified collection.
-
-Attributes for GeomInfo elements:
-
-* `name` (string, required): the unique name of the GeomInfo element
-* `geom` (geomnamearray, optional): the list of geometries and/or geometry name expressions that the GeomInfo is to apply to
-* `collection` (string, optional): the name of a geometric collection
-
-Either a `geom` or a `collection` may be specified, but not both.
-
-
-
-### GeomProp Elements
-
-The core MaterialX Specification defines a Geometric Property, or "geomprop", as an intrinsic or user-defined surface coordinate property of geometries referenced in a specific space and/or index, and provides several nodes to retrieve the values of these properties within a shading network nodegraph, as well as a <geompropdef> element used to define the name and output type of custom geometric properties beyond the standard ones: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`.
-
-MaterialX Geometry Extensions expands upon this by allowing the use of <geomprop> elements to define specific uniform values of a geometric property with specific geometries, as opposed to relying on those values being defined externally. This could include application-specific metadata, attributes passed from a lighting package to a renderer, or other geometry-specific data. A geomprop may also specify a `unittype` and `unit` if appropriate to indicate that the geometric property's value is in that unit; see the [**Units** section of the main MaterialX Specification](./MaterialX.Specification.md#units), although typically the <geompropdef> would define the `unittype` and `unit`, and a geomprop would only provide an overriding `unit` if the unit for its value differed from the geompropdef's defined default unit.
-
-```xml
-
-```
-
-GeomProp elements have the following attributes:
-
-* `name` (string, required): the name of the geometric property to define
-* `type` (string, required): the data type of the given property
-* `value` (any MaterialX type, required): the value to assign to the given property.
-* `unittype` (attribute, string, optional): the type of unit for this property, e.g. "distance", which must be defined by a <unittypedef>. Default is to not specify a unittype.
-* `unit` (attribute, string, optional): the specific unit for this property. Default is to not specify a unit.
-
-Only float and vectorN geometric properties may specify a `unittype` and a `unit`.
-
-For example, one could specify a unique surface ID value associated with a geometry:
-
-```xml
-
-
-
-
-```
-
-GeomProp values can be accessed from a nodegraph using a `` node:
-
-```xml
-
-```
-
-A <geomprop> can also be used to define a default value for an intrinsic varying geometric property such as "geomcolor" for the geometry specified by the enclosing <geominfo>, which would be returned by the corresponding Geometric node (e.g. <geomcolor>) if the current geometry did not itself define values for that property.
-
-```xml
-
-
-
-```
-
-
-
-### Geometry Token Elements
-
-Token elements may be used within <geominfo> elements to define constant (typically string or integer) named values associated with specific geometries. These geometry token values can be substituted into filenames within image nodes; see the [**Additional Filename Substitutions**](#additional-filename-substitutions) section above for details:
-
-```xml
-
-```
-
-The "value" can be any MaterialX type, but since tokens are used in filename substitutions, string and integer values are recommended.
-
-Token elements have the following attributes:
-
-* `name` (string, required): the name of the geometry token to define
-* `type` (string, required): the geometry token's type
-* `value` (any MaterialX type, optional): the value to assign to that token name for this geometry.
-
-For example, one could specify a texture identifier value associated with a geometry:
-
-```xml
-
-
-
-```
-
-and then reference that token's value in a filename:
-
-```xml
-
-
-
-```
-
-The <txtid> in the file name would be replaced by whatever value the txtid token had for each geometry.
-
-
-### TokenDefault Elements
-
-TokenDefault elements define the default value for a specified geometry token name; this default value will be used in a filename string substitution if an explicit token value is not defined for the current geometry. Since TokenDefault does not apply to any geometry in particular, it must be used outside of a <geominfo> element.
-
-```xml
-
-```
-
-
-### Reserved GeomProp Names
-
-Workflows involving textures with implicitly-computed filenames based on u,v coordinates (such as <UDIM> and <UVTILE>) can be made more efficient by explicitly listing the set of values that they resolve to for any given geometry. The MaterialX specification reserves two geomprop names for this purpose, `udimset` and `uvtileset`, each of which is a stringarray containing a comma-separated list of UDIM or UVTILE values:
-
-```xml
-
-
-
-
-
-
-
-```
-
-
-
-
-# Look and Property Elements
-
-**Look** elements define the assignments of materials, visibility and other properties to geometries and geometry collections. In MaterialX, a number of geometries are associated with each stated material, visibility type or property in a look, as opposed to defining the particular material or properties for each geometry.
-
-**Property** elements define non-material properties that can be assigned to geometries or collections in Looks. There are a number of standard MaterialX property types that can be applied universally for any rendering target, as well as a mechanism to define target-specific properties for geometries or collections.
-
-A MaterialX document can contain multiple property and/or look elements.
-
-
-## Property Definition
-
-A **<property>** element defines the name, type and value of a look-specific non-material property of geometry; <**propertyset**> elements are used to group a number of <property>s into a single named object. The connection between properties or propertysets and specific geometries or collections is done in a <look> element, so that these properties can be reused across different geometries, and enabled in some looks but not others. <Property> elements may only be used within <propertyset>s; they may not be used independently, although a dedicated <propertyassign> element may be used within a <look> to declare a property name, type, value and assignment all at once.
-
-```xml
-
-
-
-
-```
-
-The following properties are considered standard in MaterialX, and should be respected on all platforms that support these concepts:
-
-
-| Property | Type | Default Value |
-| --- | --- | --- |
-| **`twosided`** | boolean | false |
-| **`matte`** | boolean | false |
-
-where `twosided` means the geometry should be rendered even if the surface normal faces away from camera, and `matte` means the geometry should hold out, or "matte" out anything behind it (including in the alpha channel).
-
-In the example above, the "trace_maxdiffusedepth" property is target-specific, having been restricted to the context of Renderman RIS by setting its `target` attribute to “rmanris”.
-
-
-
-## Look Definition
-
-A **<look>** element contains one or more material, variant, visibility and/or propertyset assignment declarations:
-
-```xml
-
- ...materialassign, variantassign, visibilityassign, property/propertysetassign declarations...
-
-```
-
-Looks can inherit the assignments from another look by including an `inherit` attribute. The look can then specify additional assignments that will apply on top of/in place of whatever came from the source look. This is useful for defining a base look and then one or more "variation" looks. It is permissible for an inherited-from look to itself inherit from another look, but a look can inherit from only one parent look.
-
-A number of looks can be grouped together into a **LookGroup**, e.g. to indicate which looks are defined for a particular asset:
-
-```xml
-
-```
-
-where `lookgroupname` is the name of the lookgroup being defined, `look1`/`look2`/etc. are the names of <look> or <lookgroup> elements to be contained in the lookgroup (a lookgroup name would resolve to the set of looks recursively contained in that lookgroup), and `default` (if specified) specifies the name of one of the looks defined in `looks` to be the default look to use. A look can be contained in any number of lookgroups.
-
-<Look> and <lookgroup> elements also support other attributes such as `xpos`, `ypos` and `uicolor` as described in the Standard UI Attributes section above.
-
-
-## Assignment Elements
-
-Various types of assignment elements are used within looks to assign materials, categorized visibility and properties to specific geometries, or variants to materials.
-
-For elements which make assignments to geometries, the pathed names within `geom` attributes or stored within collections do not need to resolve strictly to "leaf" path locations or actual renderable geometry names: assignments can also be made to intermediate "branch" geometry path locations, which will then apply to any geometry at a deeper level in the path hierarchy which does not have another "closer to the leaf" level assignment. E.g. an assignment to "/a/b/c" will effectively apply to "/a/b/c/d" and "/a/b/c/foo/bar" (and anything else whose full path name begins with "/a/b/c/") if no other assignment is made to "/a/b/c/d", "/a/b/c/foo", or "/a/b/c/foo/bar". If a look inherits from another look, the child look can replace assignments made to any specific path location (e.g. a child assignment to "/a/b/c" would take precedence over a parent look's assignment to "/a/b/c"), but an assignment by the parent look to a more "leaf"-level path location would take precedence over a child look assignment to a higher "branch"-level location.
-
-
-### MaterialAssign Elements
-
-MaterialAssign elements are used within a <look> to connect a specified material to one or more geometries or collections (either a `geom` or a `collection` may be specified, but not both).
-
-```xml
-
- ...optional variantassign elements...
-
-```
-
-Material assignments are generally assumed to be mutually-exclusive, that is, any individual geometry is assigned to only one material. Therefore, assign declarations should be processed in the order they appear in the file, and if any geometry appears in multiple <materialassign>s, the last <materialassign> wins. However, some applications allow multiple materials to be assigned to the same geometry as long as the shader node types don't overlap. If the `exclusive` attribute is set to false (default is true), then earlier material assigns will still take effect for all shader node types not defined in the materials of later assigns: for each shader node type, the shader within the last assigned material referencing a matching shader node type wins. If a particular application does not support multiple material assignments to the same geometry, the value of `exclusive` is ignored and only the last full material and its shaders are assigned to the geometry, and the parser should issue a warning.
-
-
-### VariantAssign Elements
-
-VariantAssign elements are used within a <materialassign> or a <look> to apply the values defined in one variant of a variantset to one assigned material, or to all applicable materials in a look.
-
-```xml
-
-
-
-
-
-
- ...
-
-```
-
-VariantAssign elements have the following attributes:
-
-* `name` (string, required): the unique name of the VariantAssign element
-* `variantset` (string, required): the name of the variantset to apply the variant from
-* `variant` (string, required): the name of the variant within `variantset` to use
-
-In the above example, the input/token values defined within variant "var1" will be applied to all identically-named inputs/tokens found in either "material1" or "material2" unless restricted by a `node` or `nodedef` attribute defined in the <variantset>, while values defined within variant "var2" will only be applied to matching-named bindings in "material1". VariantAssigns are applied in the order specified within a scope, with those within a <materialassign> taking precedence over those which are direct children of the <look>.
-
-
-### Visibility Elements
-
-Visibility elements are used within a <look> to define various types of generalized visibility between a "viewer" object and other geometries. A "viewer object" is simply a geometry that has the ability to "see" other geometries in some rendering context and thus may need to have the list of geometries that it "sees" in different contexts be specified; the most common examples are light sources and a primary rendering camera.
-
-```xml
-
-```
-
-Visibility elements have the following attributes:
-
-* `name` (string, required): the unique name of the Visibility element
-* `viewergeom` (geomnamearray, optional): the list of viewer geometry objects that the <visibility> assignment affects
-* `viewercollection` (string, optional): the name of a collection containing viewer geometry objects that the <visibility> assignment affects
-* `geom` (geomnamearray, optional): the list of geometries and/or geometry name expressions that the `viewergeom` object should (or shouldn't) "see"
-* `collection` (string, optional): the name of a defined collection of geometries that the `viewergeom` object should (or shouldn't) "see"
-* `vistype` (string, optional): the type of visibility being defined; see table below
-* `visible` (boolean, optional): if false, the geom/collection objects will be invisible to this particular type of visibility; defaults to "true".
-
-The `viewergeom` attribute (and/or the contents of a collection referred to by the `viewercollection` attribute) typically refers to the name of a light (or list of lights) or other "geometry viewing" object(s). If `viewergeom`/`viewercollection` are omitted, the visibility applies to all applicable viewers (camera, light, geometry) within the given render context; `viewergeom`/`viewercollection` are not typically specified for `vistype` "camera". Either `geom` or `collection` must be defined but not both; similarly, one cannot define both a `viewergeom` and a `viewercollection`.
-
-The `vistype` attribute refers to a specific type of visibility. If a particular `vistype` is not assigned within a <look>, then all geometry is visible by default to all `viewergeom`s for that `vistype`; this means that to have only a certain subset of geometries be visible (either overall or to a particular `vistype`), it is necessary to first assign <visibility> with `visible="false"` to all geometry. Additional <visibility> assignments to the same `vistype` within a <look> are applied on top of the current visibility state. The following `vistype`s are predefined by MaterialX; applications are free to define additional `vistype`s:
-
-
-| Vistype | Description |
-| --- | --- |
-| **`camera`** | camera or "primary" ray visibility |
-| **`illumination`** | geom or collection is illuminated by the viewergeom light(s) |
-| **`shadow`** | geom or collection casts shadows from the viewergeom light(s) |
-| **`secondary`** | indirect/bounce ray visibility of geom or collection to viewergeom geometry |
-
-
-If `vistype` is not specified, then the visibility assignment applies to _all_ visibility types, and in fact will take precedence over any specific `vistype` setting on the same geometry: geometry assigned a <`visibility>` with no `vistype` and `visible="false"` will not be visible to camera, shadows, secondary rays, or any other ray or render type. This mechanism can be used to cleanly hide geometry not needed in certain variations of an asset, e.g. different costume pieces or alternate damage shapes.
-
-If the <visibility> `geom` or `collection` refers to light geometry, then assigning `vistype="camera"` determines whether or not the light object itself is visible to the camera/viewer (e.g. "do you see the bulb"), while assigning `visible="false"` with no `vistype` will mute the light so it is neither visible to camera nor emitting any light.
-
-For the "secondary" vistype, `viewergeom` should be renderable geometry rather than a light, to declare that certain other geometry is or is not visible to indirect bounce illumination or raytraced reflections in that `viewergeom`. In this example, "/b" would not be seen in reflections nor contribute indirect bounce illumination to "/a", while geometry "/c" would not be visible to _any_ secondary rays:
-
-```xml
-
-
-```
-
-
-### PropertyAssign Elements
-
-PropertyAssign and PropertySetAssign elements are used within a <look> to connect a specified property value or propertyset to one or more geometries or collections.
-
-```xml
-
-
-```
-
-Either a `geom` or a `collection` may be specified, but not both. Multiple property/propertyset assignments can be made to the same geometry or collection, as long as no conflicting assignment is made. If there are any conflicting assignments, it is up to the host application to determine how such conflicts are to be resolved, but host applications should apply property assignments in the order they are listed in the look, so it should generally be safe to assume that if two property/propertyset assignments set different values for the same property to the same geometry, the later assignment will win.
-
-
-## Look Examples
-
-This example defines four collections, a light shader and material, and a propertyset, which are then used by two looks:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-
-
-
-# References
-
-[^1]:
-
+
+
+
+# MaterialX Geometry Extensions
+
+**Version 1.39**
+Doug Smythe - Industrial Light & Magic
+Jonathan Stone - Lucasfilm Advanced Development Group
+October 21, 2022
+
+
+# Introduction
+
+The core [**MaterialX Specification**](./MaterialX.Specification.md) defines a number of element types and specific functional node definitions which can be used to describe the structure of shading networks and materials, including the definitions and functionality of custom shading operations.
+
+There are many formats that can be used to describe the associations between shading materials and renderable geometry as well as various data and metadata associated with geometry. For performance and other reasons it is often desirable to use native application mechanisms or something like Pixar's USD[^1] to describe these associations. However, there is significant value in being able to store a complete description of a CG object "look" within a single application-independent file format. This document describes extensions to the core MaterialX Specification that can be used to define collections of geometries, geometric properties and their values per geometry, and assignment of materials, variants, visibility and rendering properties to specific geometries in named looks, either directly or via geometry name expressions or named collections.
+
+
+## Table of Contents
+
+**[Introduction](#introduction)**
+
+**[Geometry Representation](#geometry-representation)**
+ [Lights](#lights)
+ [Geometry Name Expressions](#geometry-name-expressions)
+ [Collections](#collections)
+ [Geometry Prefixes](#geometry-prefixes)
+
+**[Additional MaterialX Data Types](#additional-materialx-data-types)**
+
+**[Additional Filename Substitutions](#additional-filename-substitutions)**
+
+**[Geometry Info Elements](#geometry-info-elements)**
+ [GeomInfo Definition](#geominfo-definition)
+ [GeomProp Elements](#geomprop-elements)
+ [Geometry Token Elements](#geometry-token-elements)
+ [TokenDefault Elements](#tokendefault-elements)
+ [Reserved GeomProp Names](#reserved-geomprop-names)
+
+**[Look and Property Elements](#look-and-property-elements)**
+ [Property Definition](#property-definition)
+ [Look Definition](#look-definition)
+ [Assignment Elements](#assignment-elements)
+ [MaterialAssign Elements](#materialassign-elements)
+ [VariantAssign Elements](#variantassign-elements)
+ [Visibility Elements](#visibility-elements)
+ [PropertyAssign Elements](#propertyassign-elements)
+ [Look Examples](#look-examples)
+
+**[References](#references)**
+
+
+
+# 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 `geomfile` attributes within any element; that `geomfile` declaration will then apply to any geometry name referenced within the scope of that element, e.g. any `geom` attributes, including those defining the contents of collections (but not when referencing the contents of a collection via a `collection` attribute). If a geomfile is not defined for the scope of any particular `geom` attribute, 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/](http://www.alembic.io/)) and USD ([http://graphics.pixar.com/usd](http://graphics.pixar.com/usd)). "Geometry" can be any particular geometric object that a host application may support, including but not limited to polygons, meshes, subdivision surfaces, NURBS, implicit surfaces, particle sets, volumes, lights, 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/...
+```
+
+E.g. an initial "/" followed by one or more hierarchy level strings separated by "/"s, ending with a final string and no "/". The strings making up the path component for a level of hierarchy cannot contain spaces or "/"s or any of the characters reserved for geometry name expressions (see below). Individual implementations may have further restrictions on what characters may be used for hierarchy level names, so for ultimate compatibility it is recommended to use names comprised only of upper- or lower-case letters, digits 0-9, and underscores ("_").
+
+Geometry names (e.g. the full path name) must be unique within the entire set of geometries referenced in a setup. Note that _there is no implied transformation hierarchy in the specified geometry paths_: the paths are simply the names of the geometry. However, the path-like nature of geometry names can be used to benefit in geometry name expression pattern matching and assignments.
+
+Note: if a geometry mesh is divided into partitions, the syntax for the parent mesh would be:
+
+```
+ /path/to/geom/meshname
+```
+
+and for the child partitions, the syntax would be:
+
+```
+ /path/to/geom/meshname/partitionname
+```
+
+Assignments to non-leaf locations apply hierarchically to all geometries below the specified location, unless they are the target of another assignment. By extension, an assignment to "/" applies to _all _geometries within the MaterialX setup, unless they are the target of another assignment.
+
+
+## Lights
+
+Computer Graphics assets often include lights as part of the asset, such as the headlights of a car. MaterialX does not define "light" objects per se, but instead allows referencing externally-defined light objects in the same manner as geometry, via a UNIX-like path. MaterialX does not describe the position, view or shape of a light object: MaterialX presumes that these properties are stored within the external representation.
+
+Light object geometries can be turned off (muted) in looks by making the light geometry invisible, assignment of "light"-context shader materials can be done using a <materialassign> within a <look>, and illumination and shadowing assignments can be handled using <visibility> declarations for the light geometry. See the [**Look Definition**](#look-definition) section below for details.
+
+
+
+## Geometry Name Expressions
+
+Certain elements in MaterialX files support geometry specification via expressions. The syntax for geometry name expressions in MaterialX largely follows that of “glob” patterns for filenames in Unix environments, with a few extensions for the specific needs of geometry references.
+
+Within a single hierarchy level (e.g. between "/"s):
+
+* `*` matches 0 or more characters
+* `?` matches exactly one character
+* `[]` are used to match any individual character within the brackets, with "-" meaning match anything between the character preceding and the character following the "-"
+* `{}` are used to match any of the comma-separated strings or expressions within the braces
+
+Additionally, a `/` will match only exactly a single `/` in a geometry name, e.g. as a boundary for a hierarchy level, while a `//` will match a single `/`, or two `/`s any number of hierarchy levels apart; `//` can be used to specify a match at any hierarchy depth. If a geometry name ends with `//*`, the final `*` will only match leaf geometries in the hierarchy. A geometry name of `//*` by itself will match all leaf geometries in an entire scene, while the name `//*//` will match all geometries at any level, including nested geometries, and the name `/a/b/c//*//` will match all geometries at any level below `/a/b/c`. It should be noted that for a mesh with partitions, it is the partitions and not the mesh which are treated as leaf geometry by MaterialX geometry names using `//*`.
+
+
+
+## Collections
+
+Collections are recipes for building a list of geometries (which can be any path within the geometry hierarchy), which can be used as a shorthand for assignments to a (potentially large) number of geometries at once. Collections can be built up from lists of specific geometries, geometries matching defined geometry name expressions, other collections, or any combination of those.
+
+A **<collection>** element contains lists of geometry expressions and/or collections to be included, and an optional list of geometry expressions to be excluded:
+
+```xml
+
+```
+
+Either `includegeom` and/or `includecollection` must be specified. The `includegeom` and `includecollection` lists are applied first, followed by the `excludegeom` list. This can be used to build up the contents of a collection in pieces, or to add expression-matched geometry then remove specific unwanted matched geometries. The contents of a collection can itself be used to define a portion of another collection. The contents of each `includecollection` collection are effectively evaluated in whole before being added to the collection being built.
+
+If the containing file is capable of defining MaterialX-compliant collections (e.g. an Alembic or USD file), its collections can be referred to in any situation where a collection="name" reference is allowed.
+
+
+
+## Geometry Prefixes
+
+As a shorthand convenience, MaterialX allows the specification of a `geomprefix` attribute that will be prepended to data values of type "geomname" or "geomnamearray" (e.g. `geom` attributes in ``, ``, ``, and `` elements) specified within the scope of the element defining the `geomprefix`, similar to how MaterialX allows the specification of a `fileprefix` attribute which is prepended to input values of type "filename". For data values of type "geomnamearray", the `geomprefix` is prepended to each individual comma-separated geometry name. Since the values of the prefix and the geometry are string-concatenated, the value of a `geomprefix` should generally end with a "/". Geomprefix is commonly used to split off leading portions of geometry paths common to all geometry names, e.g. to define the "asset root" path.
+
+So the following MTLX file snippets are equivalent:
+
+
+```xml
+
+
+
+
+
+
+
+```
+
+
+
+# Additional MaterialX Data Types
+
+Systems supporting MaterialX Geometry Extensions support the following additional standard data types:
+
+**GeomName** and **GeomNameArray**: attributes of type "geomname" are just strings within quotes, but specifically mean the name of a single geometry using the conventions described in the [**Geometry Representation**](#geometry-representation) and [**Geometry Name Expressions**](#geometry-name-expressions) sections. A geomname is allowed to use a geometry name expression as long as it resolves to a single geometry. Attributes of type "geomnamearray" are strings within quotes containing a comma-separated list of one or more geomname values with or without expressions, and may resolve to any number of geometries.
+
+
+# Additional Filename Substitutions
+
+Filename input values for various nodes can include one or more special strings which will be replaced by the application with values derived from the current geometry, from the MaterialX state, or from the host application environment. Applications which support MaterialX Geometry Extensions also support the following filename substitution:
+
+
+| Token | Description |
+| ---- | ---- |
+| <geometry token> | The value of a specified token declared in a <geominfo> element or as a uniform primvar value (generally of type string or integer) for the current geometry. |
+
+
+Only applications fully supporting Geometry Extensions may allow using a <_geometry token_> as part of a larger filename string. All applications should allow the use of "<_geometry token_>" as the full filename string, in which case the string primvar value stored with the geometry is used as the filename unchanged; the string primvar value itself might be allowed to contain another token such as <UDIM> which the renderer may be able to parse and replace itself.
+
+
+
+# Geometry Info Elements
+
+Geometry Info ("geominfo") elements are used to define sets of named geometric properties with constant values, and to associate them with specific external geometries.
+
+The most common use for geominfo elements is to define the filenames (or portions of filenames) of texture map images mapped onto the geometry. Typically, there are several types of textures such as color, roughness, bump, opacity, etc. associated with each geometry: each texture name string would be a separate <token> within the <geominfo>. These images could contain texture data for multiple geometries, which would either be listed in the `geom` attribute of the <geominfo> element, or be assembled into a collection and the name of that collection would be specified in the `collection` attribute.
+
+
+## GeomInfo Definition
+
+A **<geominfo>** element contains one or more geometry property and/or token definitions, and associates them and their values with all geometries listed in the `geom` or `collection` attribute of the <geominfo>:
+
+```xml
+
+ ...geometry property and token value definitions...
+
+```
+
+Note that no two <geominfo>s may define values for the same geometry property or token for the same geometry, whether the geometry is specified directly, matched via a geometry name expression, or contained within a specified collection.
+
+Attributes for GeomInfo elements:
+
+* `name` (string, required): the unique name of the GeomInfo element
+* `geom` (geomnamearray, optional): the list of geometries and/or geometry name expressions that the GeomInfo is to apply to
+* `collection` (string, optional): the name of a geometric collection
+
+Either a `geom` or a `collection` may be specified, but not both.
+
+
+
+### GeomProp Elements
+
+The core MaterialX Specification defines a Geometric Property, or "geomprop", as an intrinsic or user-defined surface coordinate property of geometries referenced in a specific space and/or index, and provides several nodes to retrive the values of these properties within a shading network nodegraph, as well as a <geompropdef> element used to define the name and output type of custom geometric properties beyond the standard ones: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`.
+
+MaterialX Geometry Extensions expands upons this by allowing the use of <geomprop> elements to define specific uniform values of a geometric property with specific geometries, as opposed to relying on those values being defined externally. This could include application-specific metadata, attributes passed from a lighting package to a renderer, or other geometry-specific data. A geomprop may also specify a `unittype` and `unit` if appropriate to indicate that the geometric property's value is in that unit; see the [**Units** section of the main MaterialX Specification](./MaterialX.Specification.md#units), although typically the <geompropdef> would define the `unittype` and `unit`, and a geomprop would only provide an overriding `unit` if the unit for its value differed from the geompropdef's defined default unit.
+
+```xml
+
+```
+
+GeomProp elements have the following attributes:
+
+* `name` (string, required): the name of the geometric property to define
+* `type` (string, required): the data type of the given property
+* `value` (any MaterialX type, required): the value to assign to the given property.
+* `unittype` (attribute, string, optional): the type of unit for this property, e.g. "distance", which must be defined by a <unittypedef>. Default is to not specify a unittype.
+* `unit` (attribute, string, optional): the specific unit for this property. Default is to not specify a unit.
+
+Only float and vectorN geometric properties may specify a `unittype` and a `unit`.
+
+For example, one could specify a unique surface ID value associated with a geometry:
+
+```xml
+
+
+
+
+```
+
+GeomProp values can be accessed from a nodegraph using a `` node:
+
+```xml
+
+```
+
+A <geomprop> can also be used to define a default value for an intrinsic varying geometric property such as "geomcolor" for the geometry specified by the enclosing <geominfo>, which would be returned by the corresponding Geometric node (e.g. <geomcolor>) if the current geometry did not itself define values for that property.
+
+```xml
+
+
+
+```
+
+
+
+### Geometry Token Elements
+
+Token elements may be used within <geominfo> elements to define constant (typically string or integer) named values associated with specific geometries. These geometry token values can be substituted into filenames within image nodes; see the [**Additional Filename Substitutions**](#additional-filename-substitutions) section above for details:
+
+```xml
+
+```
+
+The "value" can be any MaterialX type, but since tokens are used in filename substitutions, string and integer values are recommended.
+
+Token elements have the following attributes:
+
+* `name` (string, required): the name of the geometry token to define
+* `type` (string, required): the geometry token's type
+* `value` (any MaterialX type, optional): the value to assign to that token name for this geometry.
+
+For example, one could specify a texture identifier value associated with a geometry:
+
+```xml
+
+
+
+```
+
+and then reference that token's value in a filename:
+
+```xml
+
+
+
+```
+
+The <txtid> in the file name would be replaced by whatever value the txtid token had for each geometry.
+
+
+### TokenDefault Elements
+
+TokenDefault elements define the default value for a specified geometry token name; this default value will be used in a filename string substitution if an explicit token value is not defined for the current geometry. Since TokenDefault does not apply to any geometry in particular, it must be used outside of a <geominfo> element.
+
+```xml
+
+```
+
+
+### Reserved GeomProp Names
+
+Workflows involving textures with implicitly-computed filenames based on u,v coordinates (such as <UDIM> and <UVTILE>) can be made more efficient by explicitly listing the set of values that they resolve to for any given geometry. The MaterialX specification reserves two geomprop names for this purpose, `udimset` and `uvtileset`, each of which is a stringarray containing a comma-separated list of UDIM or UVTILE values:
+
+```xml
+
+
+
+
+
+
+
+```
+
+
+
+# Look and Property Elements
+
+**Look** elements define the assignments of materials, visibility and other properties to geometries and geometry collections. In MaterialX, a number of geometries are associated with each stated material, visibility type or property in a look, as opposed to defining the particular material or properties for each geometry.
+
+**Property** elements define non-material properties that can be assigned to geometries or collections in Looks. There are a number of standard MaterialX property types that can be applied universally for any rendering target, as well as a mechanism to define target-specific properties for geometries or collections.
+
+A MaterialX document can contain multiple property and/or look elements.
+
+
+## Property Definition
+
+A **<property>** element defines the name, type and value of a look-specific non-material property of geometry; <**propertyset**> elements are used to group a number of <property>s into a single named object. The connection between properties or propertysets and specific geometries or collections is done in a <look> element, so that these properties can be reused across different geometries, and enabled in some looks but not others. <Property> elements may only be used within <propertyset>s; they may not be used independently, although a dedicated <propertyassign> element may be used within a <look> to declare a property name, type, value and assignment all at once.
+
+```xml
+
+
+
+
+```
+
+The following properties are considered standard in MaterialX, and should be respected on all platforms that support these concepts:
+
+
+| Property | Type | Default Value |
+| --- | --- | --- |
+| **`twosided`** | boolean | false |
+| **`matte`** | boolean | false |
+
+where `twosided` means the geometry should be rendered even if the surface normal faces away from camera, and `matte` means the geometry should hold out, or "matte" out anything behind it (including in the alpha channel).
+
+In the example above, the "trace_maxdiffusedepth" property is target-specific, having been restricted to the context of Renderman RIS by setting its `target` attribute to “rmanris”.
+
+
+
+## Look Definition
+
+A **<look>** element contains one or more material, variant, visibility and/or propertyset assignment declarations:
+
+```xml
+
+ ...materialassign, variantassign, visibilityassign, property/propertysetassign declarations...
+
+```
+
+Looks can inherit the assignments from another look by including an `inherit` attribute. The look can then specify additional assignments that will apply on top of/in place of whatever came from the source look. This is useful for defining a base look and then one or more "variation" looks. It is permissible for an inherited-from look to itself inherit from another look, but a look can inherit from only one parent look.
+
+A number of looks can be grouped together into a **LookGroup**, e.g. to indicate which looks are defined for a particular asset:
+
+```xml
+
+```
+
+where `lookgroupname` is the name of the lookgroup being defined, `look1`/`look2`/etc. are the names of <look> or <lookgroup> elements to be contained in the lookgroup (a lookgroup name would resolve to the set of looks recursively contained in that lookgroup), and `default` (if specified) specifies the name of one of the looks defined in `looks` to be the default look to use. A look can be contained in any number of lookgroups.
+
+<Look> and <lookgroup> elements also support other attributes such as `xpos`, `ypos` and `uicolor` as described in the Standard UI Attributes section above.
+
+
+## Assignment Elements
+
+Various types of assignment elements are used within looks to assign materials, categorized visibility and properties to specific geometries, or variants to materials.
+
+For elements which make assignments to geometries, the pathed names within `geom` attributes or stored within collections do not need to resolve strictly to "leaf" path locations or actual renderable geometry names: assignments can also be made to intermediate "branch" geometry path locations, which will then apply to any geometry at a deeper level in the path hierarchy which does not have another "closer to the leaf" level assignment. E.g. an assignment to "/a/b/c" will effectively apply to "/a/b/c/d" and "/a/b/c/foo/bar" (and anything else whose full path name begins with "/a/b/c/") if no other assignment is made to "/a/b/c/d", "/a/b/c/foo", or "/a/b/c/foo/bar". If a look inherits from another look, the child look can replace assignments made to any specific path location (e.g. a child assignment to "/a/b/c" would take precedence over a parent look's assignment to "/a/b/c"), but an assignment by the parent look to a more "leaf"-level path location would take precedence over a child look assignment to a higher "branch"-level location.
+
+
+### MaterialAssign Elements
+
+MaterialAssign elements are used within a <look> to connect a specified material to one or more geometries or collections (either a `geom` or a `collection` may be specified, but not both).
+
+```xml
+
+ ...optional variantassign elements...
+
+```
+
+Material assignments are generally assumed to be mutually-exclusive, that is, any individual geometry is assigned to only one material. Therefore, assign declarations should be processed in the order they appear in the file, and if any geometry appears in multiple <materialassign>s, the last <materialassign> wins. However, some applications allow multiple materials to be assigned to the same geometry as long as the shader node types don't overlap. If the `exclusive` attribute is set to false (default is true), then earlier material assigns will still take effect for all shader node types not defined in the materials of later assigns: for each shader node type, the shader within the last assigned material referencing a matching shader node type wins. If a particular application does not support multiple material assignments to the same geometry, the value of `exclusive` is ignored and only the last full material and its shaders are assigned to the geometry, and the parser should issue a warning.
+
+
+### VariantAssign Elements
+
+VariantAssign elements are used within a <materialassign> or a <look> to apply the values defined in one variant of a variantset to one assigned material, or to all applicable materials in a look.
+
+```xml
+
+
+
+
+
+
+ ...
+
+```
+
+VariantAssign elements have the following attributes:
+
+* `name` (string, required): the unique name of the VariantAssign element
+* `variantset` (string, required): the name of the variantset to apply the variant from
+* `variant` (string, required): the name of the variant within `variantset` to use
+
+In the above example, the input/token values defined within variant "var1" will be applied to and and all identically-named inputs/tokens found in either "material1" or "material2" unless restricted by a `node` or `nodedef` attribute defined in the <variantset>, while values defined within variant "var2" will only be applied to matching-named bindings in "material1". VariantAssigns are applied in the order specified within a scope, with those within a <materialassign> taking precedence over those which are direct children of the <look>.
+
+
+### Visibility Elements
+
+Visibility elements are used within a <look> to define various types of generalized visibility between a "viewer" object and other geometries. A "viewer object" is simply a geometry that has the ability to "see" other geometries in some rendering context and thus may need to have the list of geometries that it "sees" in different contexts be specified; the most common examples are light sources and a primary rendering camera.
+
+```xml
+
+```
+
+Visibility elements have the following attributes:
+
+* `name` (string, required): the unique name of the Visibility element
+* `viewergeom` (geomnamearray, optional): the list of viewer geometry objects that the <visibility> assignment affects
+* `viewercollection` (string, optional): the name of a collection containing viewer geometry objects that the <visibility> assignment affects
+* `geom` (geomnamearray, optional): the list of geometries and/or geometry name expressions that the `viewergeom` object should (or shouldn't) "see"
+* `collection` (string, optional): the name of a defined collection of geometries that the `viewergeom` object should (or shouldn't) "see"
+* `vistype` (string, optional): the type of visibility being defined; see table below
+* `visible` (boolean, optional): if false, the geom/collection objects will be invisible to this particular type of visibility; defaults to "true".
+
+The `viewergeom` attribute (and/or the contents of a collection referred to by the `viewercollection` attribute) typically refers to the name of a light (or list of lights) or other "geometry viewing" object(s). If `viewergeom`/`viewercollection` are omitted, the visibility applies to all applicable viewers (camera, light, geometry) within the given render context; `viewergeom`/`viewercollection` are not typically specified for `vistype` "camera". Either `geom` or `collection` must be defined but not both; similarly, one cannot define both a `viewergeom` and a `viewercollection`.
+
+The `vistype` attribute refers to a specific type of visibility. If a particular `vistype` is not assigned within a <look>, then all geometry is visible by default to all `viewergeom`s for that `vistype`; this means that to have only a certain subset of geometries be visible (either overall or to a particular `vistype`), it is necessary to first assign <visibility> with `visible="false"` to all geometry. Additional <visibility> assignments to the same `vistype` within a <look> are applied on top of the current visibility state. The following `vistype`s are predefined by MaterialX; applications are free to define additional `vistype`s:
+
+
+| Vistype | Description |
+| --- | --- |
+| **`camera`** | camera or "primary" ray visibility |
+| **`illumination`** | geom or collection is illuminated by the viewergeom light(s) |
+| **`shadow`** | geom or collection casts shadows from the viewergeom light(s) |
+| **`secondary`** | indirect/bounce ray visibility of geom or collection to viewergeom geometry |
+
+
+If `vistype` is not specified, then the visibility assignment applies to _all_ visibility types, and in fact will take precedence over any specific `vistype` setting on the same geometry: geometry assigned a <`visibility>` with no `vistype` and `visible="false"` will not be visible to camera, shadows, secondary rays, or any other ray or render type. This mechanism can be used to cleanly hide geometry not needed in certain variations of an asset, e.g. different costume pieces or alternate damage shapes.
+
+If the <visibility> `geom` or `collection` refers to light geometry, then assigning `vistype="camera"` determines whether or not the light object itself is visible to the camera/viewer (e.g. "do you see the bulb"), while assigning `visible="false"` with no `vistype` will mute the light so it is neither visible to camera nor emitting any light.
+
+For the "secondary" vistype, `viewergeom` should be renderable geometry rather than a light, to declare that certain other geometry is or is not visible to indirect bounce illumination or raytraced reflections in that `viewergeom`. In this example, "/b" would not be seen in reflections nor contribute indirect bounce illumination to "/a", while geometry "/c" would not be visible to _any_ secondary rays:
+
+```xml
+
+
+```
+
+
+### PropertyAssign Elements
+
+PropertyAssign and PropertySetAssign elements are used within a <look> to connect a specified property value or propertyset to one or more geometries or collections.
+
+```xml
+
+
+```
+
+Either a `geom` or a `collection` may be specified, but not both. Multiple property/propertyset assignments can be made to the same geometry or collection, as long as no conflicting assignment is made. If there are any conflicting assignments, it is up to the host application to determine how such conflicts are to be resolved, but host applications should apply property assignments in the order they are listed in the look, so it should generally be safe to assume that if two property/propertyset assignments set different values for the same property to the same geometry, the later assignment will win.
+
+
+## Look Examples
+
+This example defines four collections, a light shader and material, and a propertyset, which are then used by two looks:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+# References
+
+[^1]:
+
diff --git a/MaterialX/documents/Specification/MaterialX.NPRSpec.md b/MaterialX/documents/Specification/MaterialX.NPRSpec.md
old mode 100644
new mode 100755
index 180f97c..0506f29
--- a/MaterialX/documents/Specification/MaterialX.NPRSpec.md
+++ b/MaterialX/documents/Specification/MaterialX.NPRSpec.md
@@ -1,74 +1,71 @@
-
-
-
-# MaterialX NPR Shading Nodes
-
-**Version 1.39**
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-July 1, 2024
-
-# Introduction
-
-The [MaterialX Standard Nodes](./MaterialX.StandardNodes.md) and [MaterialX Physically Based Shading Nodes](./MaterialX.PBRSpec.md) documents describe a number of standard pattern and shading nodes that may be used to construct nodegraph-based shaders for physically based rendering in a variety of applications. However, there are certain operations that are desirable in non-photorealistic shading styles but which cannot be implemented within certain rendering constructs. It is also helpful conceptually to separate nodes primarily useful for photorealistic and non-photorealistic shading styles into separate libraries.
-
-This document describes a number of MaterialX nodes primarily applicable to non-photorealistic, or NPR, rendering. Rendering applications whose architecture cannot support these operations are not required to support these nodes.
-
-
-## Table of Contents
-
-**[MaterialX NPR Library](#materialx-npr-library)**
- [NPR Application Nodes](#npr-application-nodes)
- [NPR Utility Nodes](#npr-utility-nodes)
- [NPR Shading Nodes](#npr-shading-nodes)
-
-**[References](#references)**
-
-
-
-
-# MaterialX NPR Library
-
-
-## NPR Application Nodes
-
-
-
-* **`viewdirection`**: the current scene view direction (e.g. from the viewing/camera position to the current shading position). If `viewdirection` is used in a PBR shading context, it should be noted that this would be the same as the incident ray direction for primary ("camera") rays but **not** for secondary/reflection rays. This node must be of type vector3.
-
- * `space` (uniform string): the space in which to return the view vector direction, defaults to `world`.
-
-
-
-## NPR Utility Nodes
-
-
-
-* **`facingratio`**: returns the geometric facing ratio, computed as the dot product between the view direction and geometric normal. Output is a float between 0.0 and 1.0.
-
- * `viewdirection` (vector3): the viewing direction, defaults to the value of the "Vworld" (world space view direction) geometric property.
- * `normal` (vector3): the surface normal vector, defaults to the value of the "Nworld" (world space view direction) geometric property. This vector is expected to be prenormalized to length 1.0.
- * `faceforward` (boolean): description needed; default is false.
- * `invert` (boolean): description needed; default is false.
-
-
-
-## NPR Shading Nodes
-
-
-
-* **`gooch_shade`**: Computes the single-pass shading portion of the Gooch[^Gooch1998] lighting model. Output type `surfaceshader`.
- * `warm_color` (color3): the "warm" color for shading, defaults to (0.8, 0.8, 0.7) in the `lin_rec709` colorspace.
- * `cool_color` (color3): the "cool" color for shading, defaults to (0.3, 0.3, 0.8) in the `lin_rec709` colorspace.
- * `specular_intensity` (float): the intensity of the specular component. Defaults to 1.0.
- * `shininess` (float): the specular power typically ranging from 1 to 256, defaults to 64.
- * `light_direction` (vector3): the incoming predominant lighting direction in world space, defaults to (1.0, -0.5, -0.5).
-
-
-
-
-# References
-
-[^Gooch1998]: Gooch et al., **A Non-Photorealistic Lighting Model For Automatic Technical Illustration**, , 1998.
+
+
+
+# MaterialX NPR Shading Nodes
+
+**Version 1.39**
+Doug Smythe - Industrial Light & Magic
+Jonathan Stone - Lucasfilm Advanced Development Group
+July 1, 2024
+
+# Introduction
+
+The MaterialX Specification and MaterialX Physically Based Shading Nodes documents describe a number of standard pattern and shading nodes that may be used to construct nodegraph-based shaders for physically based rendering in a variety of applications. However, there are certain operations that are desirable in non-photorealistic shading styles but which cannot be implemented within certain rendering constructs. It is also helpful conceptually to separate nodes primarily useful for photorealistic and non-photorealistic shading styles into separate libraries.
+
+This document describes a number of MaterialX nodes primarily applicable to non-photorealistic, or NPR, rendering. Rendering applications whose architecture cannot support these operations are not required to support these nodes.
+
+
+## Table of Contents
+
+**[MaterialX NPR Library](#materialx-npr-library)**
+ [NPR Application Nodes](#npr-application-nodes)
+ [NPR Utility Nodes](#npr-utility-nodes)
+ [NPR Shading Nodes](#npr-shading-nodes)
+
+**[References](#references)**
+
+
+# MaterialX NPR Library
+
+
+## NPR Application Nodes
+
+
+
+* **`viewdirection`**: the current scene view direction (e.g. from the viewing/camera position to the current shading position). If `viewdirection` is used in a PBR shading context, it should be noted that this would be the same as the incident ray direction for primary ("camera") rays but **not** for secondary/reflection rays. This node must be of type vector3.
+
+ * `space` (uniform string): the space in which to return the view vector direction, defaults to `world`.
+
+
+
+## NPR Utility Nodes
+
+
+
+* **`facingratio`**: returns the geometric facing ratio, computed as the dot product between the view direction and geometric normal. Output is a float between 0.0 and 1.0.
+
+ * `viewdirection` (vector3): the viewing direction, defaults to the value of the "Vworld" (world space view direction) geometric property.
+ * `normal` (vector3): the surface normal vector, defaults to the value of the "Nworld" (world space view direction) geometric property. This vector is expected to be prenormalized to length 1.0.
+ * `faceforward` (boolean): description needed; default is false.
+ * `invert` (boolean): description needed; default is false.
+
+
+
+## NPR Shading Nodes
+
+
+
+* **`gooch_shade`**: Computes the single-pass shading portion of the Gooch[^Gooch1998] lighting model. Output type `surfaceshader`.
+ * `warm_color` (color3): the "warm" color for shading, defaults to (0.8, 0.8, 0.7) in the `lin_rec709` colorspace.
+ * `cool_color` (color3): the "cool" color for shading, defaults to (0.3, 0.3, 0.8) in the `lin_rec709` colorspace.
+ * `specular_intensity` (float): the intensity of the specular component. Defaults to 1.0.
+ * `shininess` (float): the specular power typically ranging from 1 to 256, defaults to 64.
+ * `light_direction` (vector3): the incoming predominant lighting direction in world space, defaults to (1.0, -0.5, -0.5).
+
+
+
+# References
+
+[^Gooch1998]: Gooch et al., **A Non-Photorealistic Lighting Model For Automatic Technical Illustration**, , 1998.
diff --git a/MaterialX/documents/Specification/MaterialX.PBRSpec.md b/MaterialX/documents/Specification/MaterialX.PBRSpec.md
old mode 100644
new mode 100755
index 6f19a10..afed6e7
--- a/MaterialX/documents/Specification/MaterialX.PBRSpec.md
+++ b/MaterialX/documents/Specification/MaterialX.PBRSpec.md
@@ -1,709 +1,451 @@
-
-
-
-# MaterialX Physically Based Shading Nodes
-
-**Version 1.39**
-Niklas Harrysson - Lumiere Software
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-December 22, 2025
-
-# Introduction
-
-The [MaterialX Specification](./MaterialX.Specification.md) describes a number of standard nodes that may be used to construct node graphs for the processing of images, procedurally-generated values, coordinates and other data. With the addition of user-defined custom nodes, it is possible to describe complete rendering shaders using node graphs. Up to this point, there has been no standardization of the specific shader-semantic nodes used in these node graph shaders, although with the widespread shift toward physically-based shading, it appears that the industry is settling upon a number of specific BSDF and other functions with standardized parameters and functionality.
-
-This document describes a number of shader-semantic nodes implementing widely-used surface scattering, emission and volume distribution functions and utility nodes useful in constructing complex layered rendering shaders using node graphs. These nodes in combination with other nodes may be used with the [MaterialX Shader Generation](../DeveloperGuide/ShaderGeneration.md) system.
-
-
-## Table of Contents
-
-**[Physical Material Model](#physical-material-model)**
- [Scope](#scope)
- [Physically Plausible Materials](#physically-plausible-materials)
- [Quantities and Units](#quantities-and-units)
- [Color Management](#color-management)
- [Surfaces](#surfaces)
- [Layering](#layering)
- [Bump and Normal Mapping](#bump-and-normal-mapping)
- [Surface Thickness](#surface-thickness)
- [Volumes](#volumes)
- [Lights](#lights)
-
-**[MaterialX PBS Library](#materialx-pbs-library)**
- [Data Types](#data-types)
- [BSDF Nodes](#bsdf-nodes)
- [EDF Nodes](#edf-nodes)
- [VDF Nodes](#vdf-nodes)
- [PBR Shader Nodes](#pbr-shader-nodes)
- [Utility Nodes](#utility-nodes)
-
-**[Shading Model Examples](#shading-model-examples)**
- [Autodesk Standard Surface](#autodesk-standard-surface)
- [UsdPreviewSurface](#usdpreviewsurface)
- [Khronos glTF PBR](#khronos-gltf-pbr)
- [OpenPBR Surface](#openpbr-surface)
-
-**[References](#references)**
-
-
-
-
-# Physical Material Model
-
-This section describes the material model used in the MaterialX Physically Based Shading (PBS) library and the rules we must follow to be physically plausible.
-
-
-## Scope
-
-A material describes the properties of a surface or medium that involves how it reacts to light. To be efficient, a material model is split into different parts, where each part handles a specific type of light interaction: light being scattered at the surface, light being emitted from a surface, light being scattered inside a medium, etc. The goal of our material model definition is to describe light-material interactions typical for physically plausible rendering systems, including those in feature film production, real-time preview, and game engines.
-
-Our model has support for surface materials, which includes scattering and emission of light from the surface of objects, and volume materials, which includes scattering and emission of light within a participating medium. For lighting, we support local lights and distant light from environments. Geometric modification is supported in the form of bump and normal mapping as well as displacement mapping.
-
-
-## Physically Plausible Materials
-
-The initial requirements for a physically-plausible material are that it 1) should be energy conserving and 2) support reciprocity. The energy conserving says that the sum of reflected and transmitted light leaving a surface must be less than or equal to the amount of light reaching it. The reciprocity requirement says that if the direction of the traveling light is reversed, the response from the material remains unchanged. That is, the response is identical if the incoming and outgoing directions are swapped. All materials implemented for ShaderGen should respect these requirements and only in rare cases deviate from it when it makes sense for the purpose of artistic freedom.
-
-
-## Quantities and Units
-
-Radiometric quantities are used by the material model for interactions with the renderer. The fundamental radiometric quantity is **radiance** (measured in _Wm−2sr−1_) and gives the intensity of light arriving at, or leaving from, a given point in a given direction. If incident radiance is integrated over all directions we get **irradiance** (measured in _Wm−2_), and if we integrate this over surface area we get **power** (measured in _W_). Input parameters for materials and lights specified in photometric units can be suitably converted to their radiometric counterparts before being submitted to the renderer.
-
-The interpretation of the data types returned by surface and volume shaders are unspecified, and left to the renderer and the shader generator for that renderer to decide. For an OpenGL-type renderer they will be tuples of floats containing radiance calculated directly by the shader node, but for an OSL-type renderer they may be closure primitives that are used by the renderer in the light transport simulation.
-
-In general, a color given as input to the renderer is considered to represent a linear RGB color space. However, there is nothing stopping a renderer from interpreting the color type differently, for instance to hold spectral values. In that case, the shader generator for that renderer needs to handle this in the implementation of the nodes involving the color type.
-
-
-## Color Management
-
-MaterialX supports the use of [color management systems](./MaterialX.Specification.md#color-spaces-and-color-management-systems) to associate colors with specific color spaces. A MaterialX document typically specifies the working color space that is to be used for the document as well as the color space in which input values and textures are given. If these color spaces are different from the working color space, it is the application's and shader generator's responsibility to transform them.
-
-The ShaderGen module has an interface that can be used to integrate support for different color management systems. A simplified implementation with some popular and commonly used color transformations is supplied and enabled by default. An integration with the relevant portions of OpenColorIO ([http://opencolorio.org](http://opencolorio.org)) is planned for the future.
-
-
-## Surfaces
-
-In our surface shading model the scattering and emission of light is controlled by distribution functions. Incident light can be reflected off, transmitted through, or absorbed by a surface. This is represented by a Bidirectional Scattering Distribution Function (BSDF). Light can also be emitted from a surface, for instance from a light source or glowing material. This is represented by an Emission Distribution Function (EDF). The PBS library introduces the [data types](#data-types) `BSDF` and `EDF` to represent the distribution functions, and there are nodes for constructing, combining and manipulating them.
-
-
-
-Another important property is the **index of refraction** (IOR), which describes how light is propagated through a medium. It controls how much a light ray is bent when crossing the interface between two media of different refractive indices. It also determines the amount of light that is reflected and transmitted when reaching the interface, as described by the Fresnel equations.
-
-A surface shader is represented with the data type `surfaceshader`. In the PBS library there is a [<surface>](#node-surface) node that constructs a surface shader from a BSDF and an EDF. Since there are nodes to combine and modify them, you can easily build surface shaders from different combinations of distribution functions. Inputs on the distribution function nodes can be connected, and nodes from the standard library can be combined into complex calculations, giving flexibility for the artist to author material variations over the surfaces.
-
-It is common for shading models to differentiate between closed surfaces and thin-walled surfaces. A closed surface represents a closed watertight interface with a solid interior. A typical example is a solid glass object. A thin-walled surface on the other hand has an infinitely thin volume, as with a sheet of paper or a soap bubble. For a closed surface there can be no backside visible if the material is opaque. In the case of a transparent closed surface a backside hit is treated as light exiting the closed interface. For a thin-walled surface both the front and back side are visible and it can either have the same material on both sides or different materials on each side. If the material is transparent in this case the thin wall makes the light transmit without refraction or scattering. By default the [<surface>](#node-surface) node constructs a surface shader for a closed surface, but there is a boolean switch to make it thin-walled.
-
-In order to assign different shaders to each side of a thin-walled object the [<surfacematerial>](./MaterialX.Specification.md#node-surfacematerial) node in the standard library has an input to connect an extra backside surface shader. If any of the sides of a <surfacematerial> has a thin-walled shader connected, both sides are considered to be thin-walled. Hence the thin-walled property takes precedence to avoid ambiguity between the sides. If only one side has a shader connected this is used for both sides. If both sides are connected but none of the shaders are thin-walled the front shader is used. The thin-walled property also takes precedence in the case of mixing surface shaders. If any of the shaders involved in the mix is thin-walled, both shaders are considered to be thin-walled.
-
-Note that in order to have surface shaders set for both sides the geometry has to be set as double-sided. Geometry sidedness is a property not handled by MaterialX and needs to be set elsewhere.
-
-
-### Layering
-
-In order to simplify authoring of complex materials, our model supports the notion of layering. Typical examples include: adding a layer of clear coat over a car paint material, or putting a layer of dirt or rust over a metal surface. Layering can be done in a number of different ways:
-
-
-
-* Horizontal Layering: A simple way of layering is using per-shading-point linear mixing of different BSDFs where a mix factor is given per BSDF controlling its contribution. Since the weight is calculated per shading point it can be used as a mask to hide contributions on different parts of a surface. The weight can also be calculated dependent on view angle to simulate approximate Fresnel behavior. This type of layering can be done both on a BSDF level and on a surface shader level. The latter is useful for mixing complete shaders which internally contain many BSDFs, e.g. to put dirt over a car paint, grease over a rusty metal or adding decals to a plastic surface. We refer to this type of layering as **horizontal layering** and the [<mix>](#node-mix) node in the PBS library can be used to achieve this (see below).
-* Vertical Layering: A more physically correct form of layering is also supported where a top BSDF layer is placed over another base BSDF layer, and the light not reflected by the top layer is assumed to be transmitted to the base layer; for example, adding a dielectric coating layer over a substrate. The refraction index and roughness of the coating will then affect the attenuation of light reaching the substrate. The substrate can be a transmissive BSDF to transmit the light further, or a reflective BSDF to reflect the light back up through the coating. The substrate can in turn be a reflective BSDF to simulate multiple specular lobes. We refer to this type of layering as **vertical layering** and it can be achieved using the [<layer>](#node-layer) node in the PBS library. See [<dielectric_bsdf>](#node-dielectric-bsdf) and [<sheen_bsdf>](#node-sheen-bsdf) below.
-* Shader Input Blending: Calculating and blending many BSDFs or separate surface shaders can be expensive. In some situations good results can be achieved by blending the texture/value inputs instead, before any illumination calculations. Typically one would use this with an über-shader that can simulate many different materials, and by masking or blending its inputs over the surface you get the appearance of having multiple layers, but with less expensive texture or value blending. Examples of this are given in the main [MaterialX Specification "Pre-Shader Compositing Example"](./MaterialX.Specification.md#example-pre-shader-compositing-material).
-
-
-### Bump and Normal Mapping
-
-The surface normal used for shading calculations is supplied as input to each BSDF that requires it. The normal can be perturbed by bump or normal mapping, before it is given to the BSDF. As a result, one can supply different normals for different BSDFs for the same shading point. When layering BSDFs, each layer can use different bump and normal maps.
-
-
-## Volumes
-
-In our volume shader model the scattering of light in a participating medium is controlled by a volume distribution function (VDF), with coefficients controlling the rate of absorption and scattering. The VDF represents what physicists call a _phase function, _describing how the light is distributed from its current direction when it is scattered in the medium. This is analogous to how a BSDF describes scattering at a surface, but with one important difference: a VDF is normalized, summing to 1.0 if all directions are considered. Additionally, the amount of absorption and scattering is controlled by coefficients that gives the rate (probability) per distance traveled in world space. The **absorption coefficient** sets the rate of absorption for light traveling through the medium, and the **scattering coefficient** sets the rate of which the light is scattered from its current direction. The unit for these are _m−1_.
-
-Light can also be emitted from a volume. This is represented by an EDF analog to emission from surfaces, but in this context the emission is given as radiance per distance traveled through the medium. The unit for this is _Wm−3sr−1_. The emission distribution is oriented along the current direction.
-
-The [<volume>](#node-volume) node in the PBS library constructs a volume shader from individual VDF and EDF components. There are also nodes to construct various VDFs, as well as nodes to combine them to build more complex ones.
-
-VDFs can also be used to describe the interior of a surface. A typical example would be to model how light is absorbed or scattered when transmitted through colored glass or turbid water. This is done by layering a BSDF for the surface transmission over the VDF using a [<layer>](#node-layer) node.
-
-
-## Lights
-
-Light sources can be divided into environment lights and local lights. Environment lights represent contributions coming from infinitely far away. All other lights are local lights and have a position and extent in space.
-
-Local lights are specified as light shaders assigned to a locator, modeling an explicit light source, or in the form of emissive geometry using an emissive surface shader. The [<light>](#node-light) node in the PBS library constructs a light shader from an EDF. There are also nodes to construct various EDFs as well as nodes to combine them to build more complex ones. Emissive properties of surface shaders are also modelled using EDFs; see the [**EDF Nodes**](#edf-nodes) section below for more information.
-
-Light contributions coming from far away are handled by environment lights. These are typically photographically-captured or procedurally-generated images that surround the whole scene. This category of lights also includes sources like the sun, where the long distance traveled makes the light essentially directional and without falloff. For all shading points, an environment is seen as being infinitely far away.
-
-
-
-
-# MaterialX PBS Library
-
-MaterialX includes a library of types and nodes for creating physically plausible materials and lights as described above. This section outlines the content of that library.
-
-
-## Data Types
-
-* `BSDF`: Data type representing a Bidirectional Scattering Distribution Function.
-* `EDF`: Data type representing an Emission Distribution Function.
-* `VDF`: Data type representing a Volume Distribution Function.
-
-The PBS nodes also make use of the following standard MaterialX types:
-
-* `surfaceshader`: Data type representing a surface shader.
-* `lightshader`: Data type representing a light shader.
-* `volumeshader`: Data type representing a volume shader.
-* `displacementshader`: Data type representing a displacement shader.
-
-
-## BSDF Nodes
-
-
-
-### `oren_nayar_diffuse_bsdf`
-Constructs a diffuse reflection BSDF based on the Oren-Nayar reflectance model.
-
-A `roughness` of 0.0 gives Lambertian reflectance.
-
-An `energy_compensation` boolean selects between the Qualitative Oren-Nayar[^Oren1994] and Energy-Preserving Oren-Nayar[^Portsmouth2025] models of diffuse reflectance.
-
-|Port |Description |Type |Default |Accepted Values|
-|---------------------|---------------------------------------|-------|----------------|---------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`color` |Diffuse reflectivity or albedo |color3 |0.18, 0.18, 0.18| |
-|`roughness` |Surface roughness |float |0.0 |[0, 1] |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`energy_compensation`|Enable energy compensation for the BSDF|boolean|false | |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `burley_diffuse_bsdf`
-Constructs a diffuse reflection BSDF based on the corresponding component of the Disney Principled model[^Burley2012].
-
-|Port |Description |Type |Default |Accepted Values|
-|-----------|-------------------------------|--------|----------------|---------------|
-|`weight` |Weight of the BSDF contribution|float |1.0 |[0, 1] |
-|`color` |Diffuse reflectivity or albedo |color3 |0.18, 0.18, 0.18| |
-|`roughness`|Surface roughness |float |0.0 |[0, 1] |
-|`normal` |Normal vector of the surface |vector3 |Nworld | |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `dielectric_bsdf`
-Constructs a reflection and/or transmission BSDF based on a microfacet reflectance model and a Fresnel curve for dielectrics[^Walter2007]. If reflection scattering is enabled the node may be layered vertically over a base BSDF for the surface beneath the dielectric layer. By chaining multiple <dielectric_bsdf> nodes you can describe a surface with multiple specular lobes. If transmission scattering is enabled the node may be layered over a VDF describing the surface interior to handle absorption and scattering inside the medium, useful for colored glass, turbid water, etc.
-
-Implementations are expected to preserve energy as the roughness of the surface increases, with multiple scattering compensation[^Turquin2019] being a popular implementation strategy.
-
-The `tint` input colors the reflected and transmitted light but should be left at white (1,1,1) for physically correct results. Setting the `ior` input to zero disables the Fresnel curve, allowing reflectivity to be controlled purely by weight and tint.
-
-The `scatter_mode` controls whether the surface reflects light (`R`), transmits light (`T`), or both (`RT`). In `RT` mode, reflection and transmission occur both when entering and leaving a surface, with their respective intensities controlled by the Fresnel curve. Depending on the IOR and incident angle, total internal reflection may occur even when transmission modes are selected.
-
-Thin-film iridescence effects[^Belcour2017] may be enabled by setting `thinfilm_thickness` to a non-zero value.
-
-|Port |Description |Type |Default |Accepted Values|
-|--------------------|---------------------------------------------------------------|-------|-------------|---------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`tint` |Color weight to tint the reflected and transmitted light |color3 |1.0, 1.0, 1.0| |
-|`ior` |Index of refraction of the surface |float |1.5 | |
-|`roughness` |Surface roughness along the tangent and bitangent |vector2|0.05, 0.05 |[0, 1] |
-|`thinfilm_thickness`|Thickness of the iridescent thin-film layer in nanometers |float |0.0 | |
-|`thinfilm_ior` |Index of refraction of the thin-film layer |float |1.5 | |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`tangent` |Tangent vector of the surface |vector3|Tworld | |
-|`distribution` |Microfacet distribution type |string |ggx |ggx |
-|`scatter_mode` |Surface Scatter mode, specifying reflection and/or transmission|string |R |R, T, RT |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `conductor_bsdf`
-Constructs a reflection BSDF based on a microfacet reflectance model[^Burley2012]. Uses a Fresnel curve with complex refraction index for conductors/metals. If an artistic parametrization[^Gulbrandsen2014] is needed the [<artistic_ior>](#node-artistic-ior) utility node can be connected to handle this.
-
-Implementations are expected to preserve energy as the roughness of the surface increases, with multiple scattering compensation[^Turquin2019] being a popular implementation strategy.
-
-The default values for `ior` and `extinction` represent approximate values for gold.
-
-Thin-film iridescence effects[^Belcour2017] may be enabled by setting `thinfilm_thickness` to a non-zero value.
-
-|Port |Description |Type |Default |Accepted Values|
-|--------------------|---------------------------------------------------------|-------|----------------------|---------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`ior` |Index of refraction |color3 |0.183, 0.421, 1.373 | |
-|`extinction` |Extinction coefficient |color3 |3.424, 2.346, 1.770 | |
-|`roughness` |Surface roughness |vector2|0.05, 0.05 |[0, 1] |
-|`thinfilm_thickness`|Thickness of the iridescent thin-film layer in nanometers|float |0.0 | |
-|`thinfilm_ior` |Index of refraction of the thin-film layer |float |1.5 | |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`tangent` |Tangent vector of the surface |vector3|Tworld | |
-|`distribution` |Microfacet distribution type |string |ggx |ggx |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `generalized_schlick_bsdf`
-Constructs a reflection and/or transmission BSDF based on a microfacet model and a generalized Schlick Fresnel curve[^Hoffman2023]. If reflection scattering is enabled the node may be layered vertically over a base BSDF for the surface beneath the dielectric layer. By chaining multiple <generalized_schlick_bsdf> nodes you can describe a surface with multiple specular lobes. If transmission scattering is enabled the node may be layered over a VDF describing the surface interior to handle absorption and scattering inside the medium, useful for colored glass, turbid water, etc.
-
-Implementations are expected to preserve energy as the roughness of the surface increases, with multiple scattering compensation[^Turquin2019] being a popular implementation strategy.
-
-The `color82` input provides a multiplier on reflectivity at 82 degrees, useful for capturing the characteristic "dip" in the reflectance curve of metallic surfaces. Setting it to (1,1,1) effectively disables this feature for backward compatibility.
-
-The `scatter_mode` behavior matches that of `dielectric_bsdf`: in `RT` mode, reflection and transmission occur both when entering and leaving a surface, with intensities controlled by the Fresnel curve. Total internal reflection may occur depending on the incident angle.
-
-Thin-film iridescence effects[^Belcour2017] may be enabled by setting `thinfilm_thickness` to a non-zero value.
-
-|Port |Description |Type |Default |Accepted Values|
-|--------------------|---------------------------------------------------------------|-------|-------------|---------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`color0` |Reflectivity per color component at facing angles |color3 |1.0, 1.0, 1.0| |
-|`color82` |Reflectivity multiplier at 82 degrees |color3 |1.0, 1.0, 1.0| |
-|`color90` |Reflectivity per color component at grazing angles |color3 |1.0, 1.0, 1.0| |
-|`exponent` |Exponent for Schlick blending between color0 and color90 |float |5.0 | |
-|`roughness` |Surface roughness along the tangent and bitangent |vector2|0.05, 0.05 |[0, 1] |
-|`thinfilm_thickness`|Thickness of the iridescent thin-film layer in nanometers |float |0.0 | |
-|`thinfilm_ior` |Index of refraction of the thin-film layer |float |1.5 | |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`tangent` |Tangent vector of the surface |vector3|Tworld | |
-|`distribution` |Microfacet distribution type |string |ggx |ggx |
-|`scatter_mode` |Surface Scatter mode, specifying reflection and/or transmission|string |R |R, T, RT |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `translucent_bsdf`
-Constructs a translucent (diffuse transmission) BSDF based on the Lambert reflectance model.
-
-|Port |Description |Type |Default |Accepted Values|
-|---------|-------------------------------|-------|-------------|---------------|
-|`weight` |Weight of the BSDF contribution|float |1.0 |[0, 1] |
-|`color` |Diffuse transmittance |color3 |1.0, 1.0, 1.0| |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `subsurface_bsdf`
-Constructs a subsurface scattering BSDF for subsurface scattering within a homogeneous medium. The parameterization is chosen to match random walk Monte Carlo methods as well as approximate empirical methods[^Christensen2015]. Note that this category of subsurface scattering can be defined more rigorously as a BSDF vertically layered over an [](#node-anisotropic-vdf), and we expect these two descriptions of the scattering-surface distribution function to be unified in future versions of MaterialX.
-
-The `radius` input sets the average distance (mean free path) that light propagates below the surface before scattering back out, and can be set independently for each color channel.
-
-The `anisotropy` input controls the scattering direction: negative values produce backwards scattering, positive values produce forward scattering, and zero produces uniform scattering.
-
-|Port |Description |Type |Default |Accepted Values|
-|------------|------------------------------------------|-------|----------------|---------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`color` |Diffuse reflectivity (albedo) |color3 |0.18, 0.18, 0.18| |
-|`radius` |Mean free path per color channel |color3 |1.0, 1.0, 1.0 | |
-|`anisotropy`|Anisotropy factor for scattering direction|float |0.0 |[-1, 1] |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `sheen_bsdf`
-Constructs a microfacet BSDF for the back-scattering properties of cloth-like materials. This node may be layered vertically over a base BSDF using a [<layer>](#node-layer) node. All energy that is not reflected will be transmitted to the base layer. A `mode` option selects between two available sheen models, Conty-Kulla[^Conty2017] and Zeltner[^Zeltner2022].
-
-|Port |Description |Type |Default |Accepted Values |
-|-----------|--------------------------------------------------------|-------|-------------|--------------------|
-|`weight` |Weight of the BSDF contribution |float |1.0 |[0, 1] |
-|`color` |Sheen reflectivity |color3 |1.0, 1.0, 1.0| |
-|`roughness`|Surface roughness |float |0.3 | |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`mode` |Selects between `conty_kulla` and `zeltner` sheen models|string |conty_kulla |conty_kulla, zeltner|
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-
-### `chiang_hair_bsdf`
-Constructs a hair BSDF based on the Chiang hair shading model[^Chiang2016]. This node does not support vertical layering.
-
-The roughness inputs control longitudinal (ν) and azimuthal (s) roughness for each lobe, with (0,0) specifying pure specular scattering. The default `ior` of 1.55 represents the index of refraction for keratin. The `cuticle_angle` is in radians, with 0.5 representing no tilt, and values above 0.5 tilting the scales toward the root of the fiber.
-
-|Port |Description |Type |Default |Accepted Values|
-|------------------------|--------------------------------------------------------|-------|-------------|---------------|
-|`tint_R` |Color multiplier for the first R-lobe |color3 |1.0, 1.0, 1.0| |
-|`tint_TT` |Color multiplier for the first TT-lobe |color3 |1.0, 1.0, 1.0| |
-|`tint_TRT` |Color multiplier for the first TRT-lobe |color3 |1.0, 1.0, 1.0| |
-|`ior` |Index of refraction |float |1.55 | |
-|`roughness_R` |Longitudinal and azimuthal roughness for R-lobe |vector2|0.1, 0.1 |[0, ∞) |
-|`roughness_TT` |Longitudinal and azimuthal roughness for TT-lobe |vector2|0.05, 0.05 |[0, ∞) |
-|`roughness_TRT` |Longitudinal and azimuthal roughness for TRT-lobe |vector2|0.2, 0.2 |[0, ∞) |
-|`cuticle_angle` |Cuticle angle in radians |float |0.5 |[0, 1] |
-|`absorption_coefficient`|Absorption coefficient normalized to hair fiber diameter|vector3|0.0, 0.0, 0.0| |
-|`normal` |Normal vector of the surface |vector3|Nworld | |
-|`curve_direction` |Direction of the hair geometry |vector3|Tworld | |
-|`out` |Output: the computed BSDF |BSDF | | |
-
-
-## EDF Nodes
-
-
-
-### `uniform_edf`
-Constructs an EDF emitting light uniformly in all directions.
-
-|Port |Description |Type |Default |
-|--------|----------------------------------------------|-------|-------------|
-|`color` |Radiant emittance of light leaving the surface|color3 |1.0, 1.0, 1.0|
-|`out` |Output: the computed EDF |EDF | |
-
-
-
-### `conical_edf`
-Constructs an EDF emitting light inside a cone around the normal direction.
-
-Light intensity begins to fall off at the `inner_angle` and reaches zero at the `outer_angle` (both specified in degrees). If the `outer_angle` is smaller than the `inner_angle`, no falloff occurs within the cone.
-
-|Port |Description |Type |Default |
-|-------------|--------------------------------------------------|-------|-------------|
-|`color` |Radiant emittance of light leaving the surface |color3 |1.0, 1.0, 1.0|
-|`normal` |Normal vector of the surface |vector3|Nworld |
-|`inner_angle`|Angle of inner cone where intensity falloff starts|float |60.0 |
-|`outer_angle`|Angle of outer cone where intensity goes to zero |float |0.0 |
-|`out` |Output: the computed EDF |EDF | |
-
-
-
-### `measured_edf`
-Constructs an EDF emitting light according to a measured IES light profile.
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|--------|-------------|
-|`color` |Radiant emittance of light leaving the surface |color3 |1.0, 1.0, 1.0|
-|`normal`|Normal vector of the surface |vector3 |Nworld |
-|`file` |Path to a file containing IES light profile data |filename|__empty__ |
-|`out` |Output: the computed EDF |EDF | |
-
-
-
-### `generalized_schlick_edf`
-Adds a directionally varying factor to an EDF. Scales the emission distribution of the base EDF according to a generalized Schlick Fresnel curve.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------|------|-------------|
-|`color0` |Scale factor for emittance at facing angles |color3|1.0, 1.0, 1.0|
-|`color90` |Scale factor for emittance at grazing angles |color3|1.0, 1.0, 1.0|
-|`exponent`|Exponent for the Schlick blending between color0 and color90 |float |5.0 |
-|`base` |The base EDF to be modified |EDF |__zero__ |
-|`out` |Output: the computed EDF |EDF | |
-
-
-## VDF Nodes
-
-
-
-### `absorption_vdf`
-Constructs a VDF for pure light absorption.
-
-The `absorption` input represents the absorption rate per distance traveled in the medium, stated in _m−1_, with independent control for each wavelength.
-
-|Port |Description |Type |Default |
-|------------|------------------------------|-------|-------------|
-|`absorption`|Absorption rate for the medium|vector3|0.0, 0.0, 0.0|
-|`out` |Output: the computed VDF |VDF | |
-
-
-
-### `anisotropic_vdf`
-Constructs a VDF scattering light for a participating medium, based on the Henyey-Greenstein phase function[^Pharr2023]. Forward, backward and uniform scattering is supported and controlled by the anisotropy input.
-
-The `absorption` input represents the absorption rate per distance traveled in the medium, stated in _m−1_, with independent control for each wavelength.
-
-The `anisotropy` input controls the scattering direction: negative values produce backwards scattering, positive values produce forward scattering, and 0.0 produces uniform scattering. Both absorption and scattering rates are specified per wavelength.
-
-|Port |Description |Type |Default |Accepted Values|
-|------------|------------------------------------------|-------|-------------|---------------|
-|`absorption`|Absorption rate for the medium |vector3|0.0, 0.0, 0.0| |
-|`scattering`|Scattering rate for the medium |vector3|0.0, 0.0, 0.0| |
-|`anisotropy`|Anisotropy factor for scattering direction|float |0.0 |[-1, 1] |
-|`out` |Output: the computed VDF |VDF | | |
-
-
-## PBR Shader Nodes
-
-
-
-### `surface`
-Constructs a surface shader describing light scattering and emission for surfaces. By default the node will construct a shader for a closed surface, representing an interface to a solid volume. In this mode refraction and scattering is enabled for any transmissive BSDFs connected to this surface. By setting thin_walled to "true" the node will instead construct a thin-walled surface, representing a surface with an infinitely thin volume. In thin-walled mode refraction and scattering will be disabled. Thin-walled mode must be enabled to construct a double-sided material with different surface shaders on the front and back side of geometry (using [<surfacematerial>](./MaterialX.Specification.md#node-surfacematerial) in the standard library).
-
-If the `edf` input is left unconnected, no emission will occur from the surface.
-
-|Port |Description |Type |Default |
-|-------------|----------------------------------------------|-------------|--------|
-|`bsdf` |Bidirectional scattering distribution function|BSDF |__zero__|
-|`edf` |Emission distribution function for the surface|EDF |__zero__|
-|`opacity` |Cutout opacity for the surface |float |1.0 |
-|`thin_walled`|Set to true to make the surface thin-walled |boolean |false |
-|`out` |Output: the computed surface shader |surfaceshader| |
-
-
-
-### `volume`
-Constructs a volume shader describing a participating medium.
-
-If the `edf` input is left unconnected, no emission will occur from the medium.
-
-|Port |Description |Type |Default |
-|------|---------------------------------------------|------------|--------|
-|`vdf` |Volume distribution function for the medium |VDF |__zero__|
-|`edf` |Emission distribution function for the medium|EDF |__zero__|
-|`out` |Output: the computed volume shader |volumeshader| |
-
-
-
-### `light`
-Constructs a light shader describing an explicit light source. The light shader will emit light according to the connected EDF. If the shader is attached to geometry both sides will be considered for light emission and the EDF controls if light is emitted from both sides or not.
-
-|Port |Description |Type |Default |
-|-----------|---------------------------------------------------|------------|--------|
-|`edf` |Emission distribution function for the light source|EDF |__zero__|
-|`intensity`|Intensity multiplier for the EDF's emittance |float |1.0 |
-|`exposure` |Exposure control for the EDF's emittance |float |0.0 |
-|`out` |Output: the computed light shader |lightshader | |
-
-Note that the standard library includes definitions for [**`displacement`**](./MaterialX.Specification.md#node-displacement) and [**`surface_unlit`**](./MaterialX.Specification.md#node-surfaceunlit) shader nodes.
-
-
-## Utility Nodes
-
-
-
-### `mix`
-Mix two same-type distribution functions according to a weight. Performs horizontal layering by linear interpolation between the two inputs, using the function "bg∗(1−mix) + fg∗mix".
-
-|Port |Description |Type |Default |Accepted Values|
-|------|-------------------------------------------|--------------------|--------|---------------|
-|`bg` |The first distribution function |BSDF, EDF, or VDF |__zero__| |
-|`fg` |The second distribution function |Same as `bg` |__zero__| |
-|`mix` |The mixing weight |float |0.0 |[0, 1] |
-|`out` |Output: the mixed distribution function |Same as `bg` | | |
-
-
-
-### `layer`
-Vertically layer a layerable BSDF such as [<dielectric_bsdf>](#node-dielectric-bsdf), [<generalized_schlick_bsdf>](#node-generalized-schlick-bsdf) or [<sheen_bsdf>](#node-sheen-bsdf) over a BSDF or VDF. The implementation is target specific, but a standard way of handling this is by albedo scaling, using the function "base*(1-reflectance(top)) + top", where the reflectance function calculates the directional albedo of a given BSDF.
-
-|Port |Description |Type |Default |
-|------|--------------------------------|-----------|--------|
-|`top` |The top BSDF |BSDF |__zero__|
-|`base`|The base BSDF or VDF |BSDF or VDF|__zero__|
-|`out` |Output: the layered distribution|BSDF | |
-
-
-
-### `add`
-Additively blend two distribution functions of the same type.
-
-|Port |Description |Type |Default |
-|------|-------------------------------------------|-----------------|--------|
-|`in1` |The first distribution function |BSDF, EDF, or VDF|__zero__|
-|`in2` |The second distribution function |Same as `in1` |__zero__|
-|`out` |Output: the added distribution functions |Same as `in1` | |
-
-
-
-### `multiply`
-Multiply the contribution of a distribution function by a scaling weight. The weight is either a float to attenuate the channels uniformly, or a color which can attenuate the channels separately. To be energy conserving the scaling weight should be no more than 1.0 in any channel.
-
-|Port |Description |Type |Default |
-|------|-----------------------------------------|--------------------|--------|
-|`in1` |The distribution function to scale |BSDF, EDF, or VDF |__zero__|
-|`in2` |The scaling weight |float or color3 |1.0 |
-|`out` |Output: the scaled distribution function |Same as `in1` | |
-
-
-
-### `roughness_anisotropy`
-Calculates anisotropic surface roughness from a scalar roughness and anisotropy parameterization. An anisotropy value above 0.0 stretches the roughness in the direction of the surface's "tangent" vector. An anisotropy value of 0.0 gives isotropic roughness. The roughness value is squared to achieve a more linear roughness look over the input range [0,1].
-
-|Port |Description |Type |Default |Accepted Values|
-|------------|----------------------------------|--------|--------|---------------|
-|`roughness` |Roughness value |float |0.0 |[0, 1] |
-|`anisotropy`|Amount of anisotropy |float |0.0 |[0, 1] |
-|`out` |Output: the computed roughness |vector2 |0.0, 0.0| |
-
-
-
-### `roughness_dual`
-Calculates anisotropic surface roughness from a dual surface roughness parameterization. The roughness is squared to achieve a more linear roughness look over the input range [0,1].
-
-|Port |Description |Type |Default |Accepted Values|
-|-----------|----------------------------------------|--------|--------|---------------|
-|`roughness`|Roughness in x and y directions |vector2 |0.0, 0.0|[0, 1] |
-|`out` |Output: the computed roughness |vector2 |0.0, 0.0| |
-
-
-
-### `glossiness_anisotropy`
-Calculates anisotropic surface roughness from a scalar glossiness and anisotropy parameterization. This node gives the same result as roughness anisotropy except that the glossiness value is an inverted roughness value. To be used as a convenience for shading models using the glossiness parameterization.
-
-|Port |Description |Type |Default|Accepted Values|
-|------------|----------------------------------|--------|-------|---------------|
-|`glossiness`|Glossiness value |float |0.0 |[0, 1] |
-|`anisotropy`|Amount of anisotropy |float |0.0 |[0, 1] |
-|`out` |Output: the computed roughness |vector2 | | |
-
-
-
-### `blackbody`
-Returns the radiant emittance of a blackbody radiator with the given temperature.
-
-|Port |Description |Type |Default|
-|-------------|-----------------------------|------|-------|
-|`temperature`|Temperature in Kelvin |float |5000.0 |
-|`out` |Output: the radiant emittance|color3| |
-
-
-
-### `artistic_ior`
-Converts the artistic parameterization reflectivity and edge_color to complex IOR values. To be used with the [<conductor_bsdf>](#node-conductor-bsdf) node.
-
-|Port |Description |Type |Default |
-|--------------|-----------------------------------------------------|------|-------------------|
-|`reflectivity`|Reflectivity per color component at facing angles |color3|0.947, 0.776, 0.371|
-|`edge_color` |Reflectivity per color component at grazing angles |color3|1.0, 0.982, 0.753 |
-|`ior` |Output: Computed index of refraction |color3| |
-|`extinction` |Output: Computed extinction coefficient |color3| |
-
-
-
-### `chiang_hair_roughness`
-Converts the artistic parameterization hair roughness to roughness for R, TT and TRT lobes, as described in [^Chiang2016].
-
-|Port |Description |Type |Default|Accepted Values|
-|----------------|--------------------------------------------------------|--------|-------|---------------|
-|`longitudinal` |Longitudinal roughness |float |0.1 |[0, 1] |
-|`azimuthal` |Azimuthal roughness |float |0.2 |[0, 1] |
-|`scale_TT` |Roughness scale for TT lobe[^Marschner2003] |float |0.5 | |
-|`scale_TRT` |Roughness scale for TRT lobe[^Marschner2003] |float |2.0 | |
-|`roughness_R` |Output: Roughness for R lobe |vector2 | | |
-|`roughness_TT` |Output: Roughness for TT lobe |vector2 | | |
-|`roughness_TRT` |Output: Roughness for TRT lobe |vector2 | | |
-
-
-
-### `deon_hair_absorption_from_melanin`
-Converts the hair melanin parameterization to absorption coefficient based on pigments eumelanin and pheomelanin using the mapping method described in [^d'Eon2011]. The default of `eumelanin_color` and `pheomelanin_color` are `lin_rec709` color converted from the constants[^d'Eon2011] via `exp(-c)`. They may be transformed to scene-linear rendering color space.
-
-|Port |Description |Type |Default |Accepted Values|
-|-----------------------|----------------------------------------------------|-------|----------------------------|---------------|
-|`melanin_concentration`|Amount of melanin affected to the output |float |0.25 |[0, 1] |
-|`melanin_redness` |Amount of redness affected to the output |float |0.5 |[0, 1] |
-|`eumelanin_color` |Eumelanin color |color3 |0.657704, 0.498077, 0.254107| |
-|`pheomelanin_color` |Pheomelanin color |color3 |0.829444, 0.67032, 0.349938 | |
-|`absorption` |Output: the computed absorption coefficient |vector3| | |
-
-
-
-### `chiang_hair_absorption_from_color`
-Converts the hair scattering color to absorption coefficient using the mapping method described in [^Chiang2016].
-
-|Port |Description |Type |Default |Accepted Values|
-|---------------------|------------------------------------------------|-------|-------------|---------------|
-|`color` |Scattering color |color3 |1.0, 1.0, 1.0| |
-|`azimuthal_roughness`|Azimuthal roughness |float |0.2 |[0, 1] |
-|`absorption` |Output: the computed absorption coefficient |vector3| | |
-
-
-
-
-# Shading Model Examples
-
-This section contains examples of shading model implementations using the MaterialX PBS library. For all examples, the shading model is defined via a <nodedef> interface plus a nodegraph implementation. The resulting nodes can be used as shaders by a MaterialX material definition.
-
-
-## Disney Principled BSDF
-
-This shading model was presented by Brent Burley from Walt Disney Animation Studios in 2012[^Burley2012], with additional refinements presented in 2015[^Burley2015].
-
-A MaterialX definition and nodegraph implementation of the Disney Principled BSDF can be found here:
-[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/disney_principled.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/disney_principled.mtlx)
-
-
-## Autodesk Standard Surface
-
-This is a surface shading model used in Autodesk products created by the Solid Angle team for the Arnold renderer. It is an über shader built from ten different BSDF layers[^Georgiev2019].
-
-A MaterialX definition and nodegraph implementation of Autodesk Standard Surface can be found here:
-[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/standard_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/standard_surface.mtlx)
-
-
-## UsdPreviewSurface
-
-This is a shading model proposed by Pixar for USD[^Pixar2019]. It is meant to model a physically based surface that strikes a balance between expressiveness and reliable interchange between current day DCC’s and game engines and other real-time rendering clients.
-
-A MaterialX definition and nodegraph implementation of UsdPreviewSurface can be found here:
-[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/usd_preview_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/usd_preview_surface.mtlx)
-
-
-## Khronos glTF PBR
-
-This is a shading model using the PBR material extensions in Khronos glTF specification.
-
-A MaterialX definition and nodegraph implementation of glTF PBR can be found here:
-[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/gltf_pbr.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/gltf_pbr.mtlx)
-
-
-## OpenPBR Surface
-
-This is an open surface shading model that was designed as a collaboration between Adobe, Autodesk, and other companies in the industry, and is currently maintained as a subproject of MaterialX within the Academy Software Foundation[^Andersson2024].
-
-A MaterialX definition and nodegraph implementation of OpenPBR Surface can be found here:
-[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx)
-
-
-
-
-# Shading Translation Graphs
-
-The MaterialX PBS Library includes a number of nodegraphs that can be used to approximately translate the input parameters for one shading model into values to drive the inputs of a different shading model, to produce the same visual results to the degree the differences between the shading models allow. Currently, the library includes translation graphs for:
-
-* Autodesk Standard Surface to UsdPreviewSurface
-* Autodesk Standard Surface to glTF
-
-
-
-
-# References
-
-[^Andersson2024]: Andersson et al., **OpenPBR Surface Specification**, , 2024.
-
-[^Belcour2017]: Laurent Belcour, Pascal Barla, **A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence**, , 2017
-
-[^Burley2012]: Brent Burley, **Physically-Based Shading at Disney**, , 2012
-
-[^Burley2015]: Brent Burley, **Extending the Disney BRDF to a BSDF with Integrated Subsurface Scattering**, , 2015
-
-[^Chiang2016]: Matt Jen-Yuan Chiang et al., **A Practical and Controllable Hair and Fur Model for Production
-Path Tracing**, , 2016
-
-[^Christensen2015]: Per H. Christensen, Brent Burley, **Approximate Reflectance Profiles for Efficient Subsurface Scattering**, 2015
-
-[^Conty2017]: Alejandro Conty, Christopher Kulla, **Production Friendly Microfacet Sheen BRDF**, , 2017
-
-[^d'Eon2011]: Eugene d'Eon et al., **An Energy-Conserving Hair Reflectance Model**, , 2011
-
-[^Georgiev2019]: Iliyan Georgiev et al., **Autodesk Standard Surface**, , 2019.
-
-[^Gulbrandsen2014]: Ole Gulbrandsen, **Artist Friendly Metallic Fresnel**, , 2014
-
-[^Hoffman2023]: Naty Hoffman, **Generalization of Adobe's Fresnel Model**, 2023
-
-[^Marschner2003]: Stephen R. Marschner et al., **Light Scattering from Human Hair Fibers**, , 2003
-
-[^Oren1994]: Michael Oren, Shree K. Nayar, **Generalization of Lambert’s Reflectance Model**, , 1994
-
-[^Pharr2023]: Matt Pharr et al., **Physically Based Rendering: From Theory To Implementation**, , 2023
-
-[^Pixar2019]: Pixar Animation Studios, **UsdPreviewSurface Specification**, , 2019.
-
-[^Portsmouth2025]: Portsmouth et al., **EON: A practical energy-preserving rough diffuse BRDF**, , 2025.
-
-[^Turquin2019]: Emmanuel Turquin, **Practical multiple scattering compensation for microfacet models**, , 2019.
-
-[^Walter2007]: Bruce Walter et al., **Microfacet Models for Refraction through Rough Surfaces**, , 2007
-
-[^Zeltner2022]: Tizian Zeltner et al., **Practical Multiple-Scattering Sheen Using Linearly Transformed Cosines**, , 2022
+
+
+
+# MaterialX Physically Based Shading Nodes
+
+**Version 1.39**
+Niklas Harrysson - Lumiere Software
+Doug Smythe - Industrial Light & Magic
+Jonathan Stone - Lucasfilm Advanced Development Group
+June 29, 2024
+
+# Introduction
+
+The [MaterialX Specification](./MaterialX.Specification.md) describes a number of standard nodes that may be used to construct node graphs for the processing of images, procedurally-generated values, coordinates and other data. With the addition of user-defined custom nodes, it is possible to describe complete rendering shaders using node graphs. Up to this point, there has been no standardization of the specific shader-semantic nodes used in these node graph shaders, although with the widespread shift toward physically-based shading, it appears that the industry is settling upon a number of specific BSDF and other functions with standardized parameters and functionality.
+
+This document describes a number of shader-semantic nodes implementing widely-used surface scattering, emission and volume distribution functions and utility nodes useful in constructing complex layered rendering shaders using node graphs. These nodes in combination with other nodes may be used with the [MaterialX Shader Generation](../DeveloperGuide/ShaderGeneration.md) system.
+
+
+## Table of Contents
+
+**[Physical Material Model](#physical-material-model)**
+ [Scope](#scope)
+ [Physically Plausible Materials](#physically-plausible-materials)
+ [Quantities and Units](#quantities-and-units)
+ [Color Management](#color-management)
+ [Surfaces](#surfaces)
+ [Layering](#layering)
+ [Bump and Normal Mapping](#bump-and-normal-mapping)
+ [Surface Thickness](#surface-thickness)
+ [Volumes](#volumes)
+ [Lights](#lights)
+
+**[MaterialX PBS Library](#materialx-pbs-library)**
+ [Data Types](#data-types)
+ [BSDF Nodes](#bsdf-nodes)
+ [EDF Nodes](#edf-nodes)
+ [VDF Nodes](#vdf-nodes)
+ [PBR Shader Nodes](#pbr-shader-nodes)
+ [Utility Nodes](#utility-nodes)
+
+**[Shading Model Examples](#shading-model-examples)**
+ [Autodesk Standard Surface](#autodesk-standard-surface)
+ [UsdPreviewSurface](#usdpreviewsurface)
+ [Khronos glTF PBR](#khronos-gltf-pbr)
+ [OpenPBR Surface](#openpbr-surface)
+
+**[References](#references)**
+
+
+
+# Physical Material Model
+
+This section describes the material model used in the MaterialX Physically Based Shading (PBS) library and the rules we must follow to be physically plausible.
+
+
+## Scope
+
+A material describes the properties of a surface or medium that involves how it reacts to light. To be efficient, a material model is split into different parts, where each part handles a specific type of light interaction: light being scattered at the surface, light being emitted from a surface, light being scattered inside a medium, etc. The goal of our material model definition is to describe light-material interactions typical for physically plausible rendering systems, including those in feature film production, real-time preview, and game engines.
+
+Our model has support for surface materials, which includes scattering and emission of light from the surface of objects, and volume materials, which includes scattering and emission of light within a participating medium. For lighting, we support local lights and distant light from environments. Geometric modification is supported in the form of bump and normal mapping as well as displacement mapping.
+
+
+## Physically Plausible Materials
+
+The initial requirements for a physically-plausible material are that it 1) should be energy conserving and 2) support reciprocity. The energy conserving says that the sum of reflected and transmitted light leaving a surface must be less than or equal to the amount of light reaching it. The reciprocity requirement says that if the direction of the traveling light is reversed, the response from the material remains unchanged. That is, the response is identical if the incoming and outgoing directions are swapped. All materials implemented for ShaderGen should respect these requirements and only in rare cases deviate from it when it makes sense for the purpose of artistic freedom.
+
+
+## Quantities and Units
+
+Radiometric quantities are used by the material model for interactions with the renderer. The fundamental radiometric quantity is **radiance** (measured in _Wm−2sr−1_) and gives the intensity of light arriving at, or leaving from, a given point in a given direction. If incident radiance is integrated over all directions we get **irradiance** (measured in _Wm−2_), and if we integrate this over surface area we get **power** (measured in _W_). Input parameters for materials and lights specified in photometric units can be suitably converted to their radiometric counterparts before being submitted to the renderer.
+
+The interpretation of the data types returned by surface and volume shaders are unspecified, and left to the renderer and the shader generator for that renderer to decide. For an OpenGL-type renderer they will be tuples of floats containing radiance calculated directly by the shader node, but for an OSL-type renderer they may be closure primitives that are used by the renderer in the light transport simulation.
+
+In general, a color given as input to the renderer is considered to represent a linear RGB color space. However, there is nothing stopping a renderer from interpreting the color type differently, for instance to hold spectral values. In that case, the shader generator for that renderer needs to handle this in the implementation of the nodes involving the color type.
+
+
+## Color Management
+
+MaterialX supports the use of [color management systems](./MaterialX.Specification.md#color-spaces-and-color-management-systems) to associate colors with specific color spaces. A MaterialX document typically specifies the working color space that is to be used for the document as well as the color space in which input values and textures are given. If these color spaces are different from the working color space, it is the application's and shader generator's responsibility to transform them.
+
+The ShaderGen module has an interface that can be used to integrate support for different color management systems. A simplified implementation with some popular and commonly used color transformations is supplied and enabled by default. A full integration of OpenColorIO ([http://opencolorio.org](http://opencolorio.org)) is planned for the future.
+
+
+## Surfaces
+
+In our surface shading model the scattering and emission of light is controlled by distribution functions. Incident light can be reflected off, transmitted through, or absorbed by a surface. This is represented by a Bidirectional Scattering Distribution Function (BSDF). Light can also be emitted from a surface, for instance from a light source or glowing material. This is represented by an Emission Distribution Function (EDF). The PBS library introduces the [data types](#data-types) `BSDF` and `EDF` to represent the distribution functions, and there are nodes for constructing, combining and manipulating them.
+
+
+
+Another important property is the **index of refraction** (IOR), which describes how light is propagated through a medium. It controls how much a light ray is bent when crossing the interface between two media of different refractive indices. It also determines the amount of light that is reflected and transmitted when reaching the interface, as described by the Fresnel equations.
+
+A surface shader is represented with the data type `surfaceshader`. In the PBS library there is a [<surface>](#node-surface) node that constructs a surface shader from a BSDF and an EDF. Since there are nodes to combine and modify them, you can easily build surface shaders from different combinations of distribution functions. Inputs on the distribution function nodes can be connected, and nodes from the standard library can be combined into complex calculations, giving flexibility for the artist to author material variations over the surfaces.
+
+It is common for shading models to differentiate between closed surfaces and thin-walled surfaces. A closed surface represents a closed watertight interface with a solid interior. A typical example is a solid glass object. A thin-walled surface on the other hand has an infinitely thin volume, as with a sheet of paper or a soap bubble. For a closed surface there can be no backside visible if the material is opaque. In the case of a transparent closed surface a backside hit is treated as light exiting the closed interface. For a thin-walled surface both the front and back side are visible and it can either have the same material on both sides or different materials on each side. If the material is transparent in this case the thin wall makes the light transmit without refraction or scattering. By default the [<surface>](#node-surface) node constructs a surface shader for a closed surface, but there is a boolean switch to make it thin-walled.
+
+In order to assign different shaders to each side of a thin-walled object the [<surfacematerial>](./MaterialX.Specification.md#node-surfacematerial) node in the standard library has an input to connect an extra backside surface shader. If any of the sides of a <surfacematerial> has a thin-walled shader connected, both sides are considered to be thin-walled. Hence the thin-walled property takes precedence to avoid ambiguity between the sides. If only one side has a shader connected this is used for both sides. If both sides are connected but none of the shaders are thin-walled the front shader is used. The thin-walled property also takes precedence in the case of mixing surface shaders. If any of the shaders involved in the mix is thin-walled, both shaders are considered to be thin-walled.
+
+Note that in order to have surface shaders set for both sides the geometry has to be set as double-sided. Geometry sidedness is a property not handled by MaterialX and needs to be set elsewhere.
+
+
+### Layering
+
+In order to simplify authoring of complex materials, our model supports the notion of layering. Typical examples include: adding a layer of clear coat over a car paint material, or putting a layer of dirt or rust over a metal surface. Layering can be done in a number of different ways:
+
+
+
+* Horizontal Layering: A simple way of layering is using per-shading-point linear mixing of different BSDFs where a mix factor is given per BSDF controlling its contribution. Since the weight is calculated per shading point it can be used as a mask to hide contributions on different parts of a surface. The weight can also be calculated dependent on view angle to simulate approximate Fresnel behavior. This type of layering can be done both on a BSDF level and on a surface shader level. The latter is useful for mixing complete shaders which internally contain many BSDFs, e.g. to put dirt over a car paint, grease over a rusty metal or adding decals to a plastic surface. We refer to this type of layering as **horizontal layering** and the [<mix>](#node-mix) node in the PBS library can be used to achieve this (see below).
+* Vertical Layering: A more physically correct form of layering is also supported where a top BSDF layer is placed over another base BSDF layer, and the light not reflected by the top layer is assumed to be transmitted to the base layer; for example, adding a dielectric coating layer over a substrate. The refraction index and roughness of the coating will then affect the attenuation of light reaching the substrate. The substrate can be a transmissive BSDF to transmit the light further, or a reflective BSDF to reflect the light back up through the coating. The substrate can in turn be a reflective BSDF to simulate multiple specular lobes. We refer to this type of layering as **vertical layering** and it can be achieved using the [<layer>](#node-layer) node in the PBS library. See [<dielectric_bsdf>](#node-dielectric-bsdf) and [<sheen_bsdf>](#node-sheen-bsdf) below.
+* Shader Input Blending: Calculating and blending many BSDFs or separate surface shaders can be expensive. In some situations good results can be achieved by blending the texture/value inputs instead, before any illumination calculations. Typically one would use this with an über-shader that can simulate many different materials, and by masking or blending its inputs over the surface you get the appearance of having multiple layers, but with less expensive texture or value blending. Examples of this are given in the main [MaterialX Specification "Pre-Shader Compositing Example"](./MaterialX.Specification.md#example-pre-shader-compositing-material).
+
+
+### Bump and Normal Mapping
+
+The surface normal used for shading calculations is supplied as input to each BSDF that requires it. The normal can be perturbed by bump or normal mapping, before it is given to the BSDF. As a result, one can supply different normals for different BSDFs for the same shading point. When layering BSDFs, each layer can use different bump and normal maps.
+
+
+## Volumes
+
+In our volume shader model the scattering of light in a participating medium is controlled by a volume distribution function (VDF), with coefficients controlling the rate of absorption and scattering. The VDF represents what physicists call a _phase function, _describing how the light is distributed from its current direction when it is scattered in the medium. This is analogous to how a BSDF describes scattering at a surface, but with one important difference: a VDF is normalized, summing to 1.0 if all directions are considered. Additionally, the amount of absorption and scattering is controlled by coefficients that gives the rate (probability) per distance traveled in world space. The **absorption coefficient** sets the rate of absorption for light traveling through the medium, and the **scattering coefficient** sets the rate of which the light is scattered from its current direction. The unit for these are _m−1_.
+
+Light can also be emitted from a volume. This is represented by an EDF analog to emission from surfaces, but in this context the emission is given as radiance per distance traveled through the medium. The unit for this is _Wm−3sr−1_. The emission distribution is oriented along the current direction.
+
+The [<volume>](#node-volume) node in the PBS library constructs a volume shader from individual VDF and EDF components. There are also nodes to construct various VDFs, as well as nodes to combine them to build more complex ones.
+
+VDFs can also be used to describe the interior of a surface. A typical example would be to model how light is absorbed or scattered when transmitted through colored glass or turbid water. This is done by layering a BSDF for the surface transmission over the VDF using a [<layer>](#node-layer) node.
+
+
+## Lights
+
+Light sources can be divided into environment lights and local lights. Environment lights represent contributions coming from infinitely far away. All other lights are local lights and have a position and extent in space.
+
+Local lights are specified as light shaders assigned to a locator, modeling an explicit light source, or in the form of emissive geometry using an emissive surface shader. The [<light>](#node-light) node in the PBS library constructs a light shader from an EDF. There are also nodes to construct various EDFs as well as nodes to combine them to build more complex ones. Emissive properties of surface shaders are also modelled using EDFs; see the [**EDF Nodes**](#edf-nodes) section below for more information.
+
+Light contributions coming from far away are handled by environment lights. These are typically photographically-captured or procedurally-generated images that surround the whole scene. This category of lights also includes sources like the sun, where the long distance traveled makes the light essentially directional and without falloff. For all shading points, an environment is seen as being infinitely far away.
+
+
+
+# MaterialX PBS Library
+
+MaterialX includes a library of types and nodes for creating physically plausible materials and lights as described above. This section outlines the content of that library.
+
+
+## Data Types
+
+* `BSDF`: Data type representing a Bidirectional Scattering Distribution Function.
+* `EDF`: Data type representing an Emission Distribution Function.
+* `VDF`: Data type representing a Volume Distribution Function.
+
+The PBS nodes also make use of the following standard MaterialX types:
+
+* `surfaceshader`: Data type representing a surface shader.
+* `lightshader`: Data type representing a light shader.
+* `volumeshader`: Data type representing a volume shader.
+* `displacementshader`: Data type representing a displacement shader.
+
+
+## BSDF Nodes
+
+
+
+* **`oren_nayar_diffuse_bsdf`**: Constructs a diffuse reflection BSDF based on the Oren-Nayar reflectance model. A `roughness` of 0.0 gives Lambertian reflectance. An `energy_compensation` boolean selects between classic Oren-Nayar behavior[^Oren1994] and the energy-compensated Oren-Nayar in OpenPBR[^Andersson2024].
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color` (color3): Diffuse reflectivity (albedo). Defaults to (0.18, 0.18, 0.18).
+ * `roughness `(float): Surface roughness, range [0.0, 1.0]. Defaults to 0.0.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `energy_compensation` (uniform boolean): Set to `true` to enable energy compensation. Defaults to `false`.
+
+
+
+* **`burley_diffuse_bsdf`**: Constructs a diffuse reflection BSDF based on the corresponding component of the Disney Principled model[^Burley2012].
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color` (color3): Diffuse reflectivity (albedo). Defaults to (0.18, 0.18, 0.18).
+ * `roughness` (float): Surface roughness, range [0.0, 1.0]. Defaults to 0.0.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+
+
+
+* **`dielectric_bsdf`**: Constructs a reflection and/or transmission BSDF based on a microfacet reflectance model and a Fresnel curve for dielectrics[^Walter2007]. If reflection scattering is enabled the node may be layered vertically over a base BSDF for the surface beneath the dielectric layer. By chaining multiple <dielectric_bsdf> nodes you can describe a surface with multiple specular lobes. If transmission scattering is enabled the node may be layered over a VDF describing the surface interior to handle absorption and scattering inside the medium, useful for colored glass, turbid water, etc.
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `tint` (color3): Color weight to tint the reflected and transmitted light. Defaults to (1.0, 1.0, 1.0). Note that changing the tint gives non-physical results and should only be done when needed for artistic purposes.
+ * `ior` (float): Index of refraction of the surface. Defaults to 1.5. If set to 0.0 the Fresnel curve is disabled and reflectivity is controlled only by weight and tint.
+ * `roughness` (vector2): Surface roughness. Defaults to (0.05, 0.05).
+ * `thinfilm_thickness` (float): The thickness of an iridescent thin film layer[^Belcour2017] applied over the base bsdf, expressed in nanometers. Defaults to 0.0, for no thin film.
+ * `thinfilm_ior` (float): The index of refraction of the thin film layer. Defaults to 1.5.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `tangent` (vector3): Tangent vector of the surface. Defaults to world space tangent.
+ * `distribution` (uniform string): Microfacet distribution type. Defaults to `ggx`.
+ * `scatter_mode` (uniform string): Scattering mode, specifying whether the BSDF supports reflection `R`, transmission `T` or both reflection and transmission `RT`. With `RT`, reflection and transmission occur both when entering and leaving a surface, with their respective intensities controlled by the Fresnel curve. Depending on the IOR and incident angle, it is possible for total internal reflection to occur, generating no transmission even if `T` or `RT` is selected. Defaults to `R`.
+
+
+
+* **`conductor_bsdf`**: Constructs a reflection BSDF based on a microfacet reflectance model[^Burley2012]. Uses a Fresnel curve with complex refraction index for conductors/metals. If an artistic parametrization[^Gulbrandsen2014] is needed the [<artistic_ior>](#node-artistic-ior) utility node can be connected to handle this.
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `ior `(color3): Index of refraction. Defaults to (0.18, 0.42, 1.37) (approximate IOR for gold).
+ * `extinction` (color3): Extinction coefficient. Defaults to (3.42, 2.35, 1.77) (approximate extinction coefficients for gold).
+ * `roughness` (vector2): Surface roughness. Defaults to (0.05, 0.05).
+ * `thinfilm_thickness` (float): The thickness of an iridescent thin film layer[^Belcour2017] applied over the base bsdf, expressed in nanometers. Defaults to 0.0, for no thin film.
+ * `thinfilm_ior` (float): The index of refraction of the thin film layer. Defaults to 1.5.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `tangent` (vector3): Tangent vector of the surface. Defaults to world space tangent.
+ * `distribution` (uniform string): Microfacet distribution type. Defaults to `ggx`.
+
+
+
+* **`generalized_schlick_bsdf`**: Constructs a reflection and/or transmission BSDF based on a microfacet model and a generalized Schlick Fresnel curve[^Hoffman2023]. If reflection scattering is enabled the node may be layered vertically over a base BSDF for the surface beneath the dielectric layer. By chaining multiple <generalized_schlick_bsdf> nodes you can describe a surface with multiple specular lobes. If transmission scattering is enabled the node may be layered over a VDF describing the surface interior to handle absorption and scattering inside the medium, useful for colored glass, turbid water, etc.
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color0` (color3): Reflectivity per color component at facing angles. Defaults to (1.0, 1.0, 1.0).
+ * `color82` (color3): A multiplier on the reflectivity per color component at 82 degrees, useful for capturing the "dip" in the reflectance curve of metallic surfaces. Defaults to (1.0, 1.0, 1.0), which effectively disables "color82" for backward compatibility.
+ * `color90` (color3): Reflectivity per color component at grazing angles. Defaults to (1.0, 1.0, 1.0).
+ * `exponent` (float): Exponent for the Schlick blending between `color0` and `color90`. Defaults to 5.0.
+ * `roughness` (vector2): Surface roughness. Defaults to (0.05, 0.05).
+ * `thinfilm_thickness` (float): The thickness of an iridescent thin film layer[^Belcour2017] applied over the base bsdf, expressed in nanometers. Defaults to 0.0, for no thin film.
+ * `thinfilm_ior` (float): The index of refraction of the thin film layer. Defaults to 1.5.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `tangent` (vector3): Tangent vector of the surface. Defaults to world space tangent.
+ * `distribution` (uniform string): Microfacet distribution type. Defaults to `ggx`.
+ * `scatter_mode` (uniform string): Scattering mode, specifying whether the BSDF supports reflection `R`, transmission `T` or both reflection and transmission `RT`. With `RT`, reflection and transmission occur both when entering and leaving a surface, with their respective intensities controlled by the Fresnel curve. Depending on the IOR and incident angle, it is possible for total internal reflection to occur, generating no transmission even if `T` or `RT` is selected. Defaults to `R`.
+
+
+
+* **`translucent_bsdf`**: Constructs a translucent (diffuse transmission) BSDF based on the Lambert reflectance model.
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color` (color3): Diffuse transmittance. Defaults to (1.0, 1.0, 1.0).
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+
+
+
+* **`subsurface_bsdf`**: Constructs a subsurface scattering BSDF for subsurface scattering within a homogeneous medium. The parameterization is chosen to match random walk Monte Carlo methods as well as approximate empirical methods[^Christensen2015]. Note that this category of subsurface scattering can be defined more rigorously as a BSDF vertically layered over an [](#node-anisotropic-vdf), and we expect these two descriptions of the scattering-surface distribution function to be unified in future versions of MaterialX.
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color` (color3): Diffuse reflectivity (albedo). Defaults to (0.18, 0.18, 0.18).
+ * `radius` (color3): Sets the average distance that light might propagate below the surface before scattering back out. This is also known as the mean free path of the material. The radius can be set for each color component separately. Defaults to (1, 1, 1).
+ * `anisotropy` (float): Anisotropy factor, controlling the scattering direction, range [-1.0, 1.0]. Negative values give backwards scattering, positive values give forward scattering, and a value of zero gives uniform scattering. Defaults to 0.0.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+
+
+
+* **`sheen_bsdf`**: Constructs a microfacet BSDF for the back-scattering properties of cloth-like materials. This node may be layered vertically over a base BSDF using a [<layer>](#node-layer) node. All energy that is not reflected will be transmitted to the base layer. A `mode` option selects between two available sheen models, Conty-Kulla[^Conty2017] and Zeltner[^Zeltner2022].
+ * `weight` (float): Weight for this BSDF’s contribution, range [0.0, 1.0]. Defaults to 1.0.
+ * `color` (color3): Sheen reflectivity. Defaults to (1.0, 1.0, 1.0).
+ * `roughness` (float): Surface roughness, range [0.0, 1.0]. Defaults to 0.3.
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `mode` (uniform string): Selects between `conty_kulla` and `zeltner` sheen models. Defaults to `conty_kulla`.
+
+
+## EDF Nodes
+
+
+
+* **`uniform_edf`**: Constructs an EDF emitting light uniformly in all directions.
+ * `color` (color3): Radiant emittance of light leaving the surface. Defaults to (1, 1, 1).
+
+
+
+* **`conical_edf`**: Constructs an EDF emitting light inside a cone around the normal direction.
+ * `color` (color3): Radiant emittance of light leaving the surface. Defaults to (1, 1, 1).
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `inner_angle` (uniform float): Angle of inner cone where intensity falloff starts (given in degrees). Defaults to 60.
+ * `outer_angle` (uniform float): Angle of outer cone where intensity goes to zero (given in degrees). If set to a smaller value than inner angle no falloff will occur within the cone. Defaults to 0.
+
+
+
+* **`measured_edf`**: Constructs an EDF emitting light according to a measured IES light profile.
+ * `color` (color3): Radiant emittance of light leaving the surface. Defaults to (1, 1, 1).
+ * `normal` (vector3): Normal vector of the surface. Defaults to world space normal.
+ * `file` (uniform filename): Path to a file containing IES light profile data. Defaults to "".
+
+
+
+* **`generalized_schlick_edf`**: Adds a directionally varying factor to an EDF. Scales the emission distribution of the base EDF according to a generalized Schlick Fresnel curve.
+ * `color0` (color3): Scale factor for emittance at facing angles. Defaults to (1, 1, 1).
+ * `color90` (color3): Scale factor for emittance at grazing angles. Defaults to (1, 1, 1).
+ * `exponent` (float): Exponent for the Schlick blending between `color0` and `color90`. Defaults to 5.0.
+ * `base` (EDF): The base EDF to be modified. Defaults to "".
+
+
+## VDF Nodes
+
+
+
+* **`absorption_vdf`**: Constructs a VDF for pure light absorption.
+ * `absorption` (color3): Absorption rate for the medium (rate per distance traveled in the medium, given in _m−1_). Set for each color component/wavelength separately. Defaults to (0, 0, 0).
+
+
+
+* **`anisotropic_vdf`**: Constructs a VDF scattering light for a participating medium, based on the Henyey-Greenstein phase function[^Pharr2023]. Forward, backward and uniform scattering is supported and controlled by the anisotropy input.
+ * `absorption` (color3): Absorption rate for the medium (rate per distance traveled in the medium, given in _m−1_). Set for each color component/wavelength separately. Defaults to (0, 0, 0).
+ * `scattering` (color3): Scattering rate for the medium (rate per distance traveled in the medium, given in _m−1_). Set for each color component/wavelength separately. Defaults to (0, 0, 0).
+ * `anisotropy` (float): Anisotropy factor, controlling the scattering direction, range [-1.0, 1.0]. Negative values give backwards scattering, positive values give forward scattering, and a value of 0.0 (the default) gives uniform scattering.
+
+
+## PBR Shader Nodes
+
+
+
+* **`surface`**: Constructs a surface shader describing light scattering and emission for surfaces. By default the node will construct a shader for a closed surface, representing an interface to a solid volume. In this mode refraction and scattering is enabled for any transmissive BSDFs connected to this surface. By setting thin_walled to "true" the node will instead construct a thin-walled surface, representing a surface with an infinitely thin volume. In thin-walled mode refraction and scattering will be disabled. Thin-walled mode must be enabled to construct a double-sided material with different surface shaders on the front and back side of geometry (using [<surfacematerial>](./MaterialX.Specification.md#node-surfacematerial) in the standard library). Output type "surfaceshader".
+ * `bsdf` (BSDF): Bidirectional scattering distribution function for the surface. Defaults to "".
+ * `edf` (EDF): Emission distribution function for the surface. If unconnected, then no emission will occur.
+ * `opacity` (float): Cutout opacity for the surface. Defaults to 1.0.
+ * `thin_walled` (boolean): Set to `true` to make the surface thin-walled. Defaults to `false`.
+
+
+
+* **`volume`**: Constructs a volume shader describing a participating medium. Output type "volumeshader".
+ * `vdf` (VDF): Volume distribution function for the medium. Defaults to "".
+ * `edf` (EDF): Emission distribution function for the medium. If unconnected, then no emission will occur.
+
+
+
+* **`light`**: Constructs a light shader describing an explicit light source. The light shader will emit light according to the connected EDF. If the shader is attached to geometry both sides will be considered for light emission and the EDF controls if light is emitted from both sides or not. Output type "lightshader".
+ * `edf` (EDF): Emission distribution function for the light source. Defaults to no emission.
+ * `intensity` (color3): Intensity multiplier for the EDF’s emittance. Defaults to (1.0, 1.0, 1.0).
+ * `exposure` (float): Exposure control for the EDF’s emittance. Defaults to 0.0.
+
+Note that the standard library includes definitions for [**`displacement`**](./MaterialX.Specification.md#node-displacement) and [**`surface_unlit`**](./MaterialX.Specification.md#node-surfaceunlit) shader nodes.
+
+
+
+## Utility Nodes
+
+
+
+* **`mix`**: Mix two same-type distribution functions according to a weight. Performs horizontal layering by linear interpolation between the two inputs, using the function "bg∗(1−mix) + fg∗mix".
+ * `bg` (BSDF or EDF or VDF): The first distribution function. Defaults to "".
+ * `fg` (same type as `bg`): The second distribution function. Defaults to "".
+ * `mix` (float): The mixing weight, range [0.0, 1.0]. Defaults to 0.
+
+
+
+* **`layer`**: Vertically layer a layerable BSDF such as [<dielectric_bsdf>](#node-dielectric-bsdf), [<generalized_schlick_bsdf>](#node-generalized-schlick-bsdf) or [<sheen_bsdf>](#node-sheen-bsdf) over a BSDF or VDF. The implementation is target specific, but a standard way of handling this is by albedo scaling, using the function "base*(1-reflectance(top)) + top", where the reflectance function calculates the directional albedo of a given BSDF.
+ * `top` (BSDF): The top BSDF. Defaults to "".
+ * `base` (BSDF or VDF): The base BSDF or VDF. Defaults to "".
+
+
+
+* **`add`**: Additively blend two distribution functions of the same type.
+ * `in1` (BSDF or EDF or VDF): The first distribution function. Defaults to "".
+ * `in2` (same type as `in1`): The second distribution function. Defaults to "".
+
+
+
+* **`multiply`**: Multiply the contribution of a distribution function by a scaling weight. The weight is either a float to attenuate the channels uniformly, or a color which can attenuate the channels separately. To be energy conserving the scaling weight should be no more than 1.0 in any channel.
+ * `in1` (BSDF or EDF or VDF): The distribution function to scale. Defaults to "".
+ * `in2` (float or color3): The scaling weight. Defaults to 1.0.
+
+
+
+* **`roughness_anisotropy`**: Calculates anisotropic surface roughness from a scalar roughness and anisotropy parameterization. An anisotropy value above 0.0 stretches the roughness in the direction of the surface's "tangent" vector. An anisotropy value of 0.0 gives isotropic roughness. The roughness value is squared to achieve a more linear roughness look over the input range [0,1]. Output type `vector2`.
+ * `roughness` (float): Roughness value, range [0.0, 1.0]. Defaults to 0.0.
+ * `anisotropy` (float): Amount of anisotropy, range [0.0, 1.0]. Defaults to 0.0.
+
+
+
+* **`roughness_dual`**: Calculates anisotropic surface roughness from a dual surface roughness parameterization. The roughness is squared to achieve a more linear roughness look over the input range [0,1]. Output type `vector2`.
+ * `roughness` (vector2): Roughness in x and y directions, range [0.0, 1.0]. Defaults to (0.0, 0.0).
+
+
+
+* **`glossiness_anisotropy`**: Calculates anisotropic surface roughness from a scalar glossiness and anisotropy parameterization. This node gives the same result as roughness anisotropy except that the glossiness value is an inverted roughness value. To be used as a convenience for shading models using the glossiness parameterization. Output type `vector2`.
+ * `glossiness` (float): Roughness value, range [0.0, 1.0]. Defaults to 0.0.
+ * `anisotropy` (float): Amount of anisotropy, range [0.0, 1.0]. Defaults to 0.0.
+
+
+
+* **`blackbody`**: Returns the radiant emittance of a blackbody radiator with the given temperature. Output type `color3`.
+ * `temperature` (float): Temperature in Kelvin. Defaults to 5000.
+
+
+
+* **`artistic_ior`**: Converts the artistic parameterization reflectivity and edge_color to complex IOR values. To be used with the [<conductor_bsdf>](#node-conductor-bsdf) node.
+ * `reflectivity` (color3): Reflectivity per color component at facing angles. Defaults to (0.947, 0.776, 0.371).
+ * `edge_color` (color3): Reflectivity per color component at grazing angles. Defaults to (1.0, 0.982, 0.753).
+ * `ior` (**output**, vector3): Computed index of refraction.
+ * `extinction` (**output**, vector3): Computed extinction coefficient.
+
+
+
+# Shading Model Examples
+
+This section contains examples of shading model implementations using the MaterialX PBS library. For all examples, the shading model is defined via a <nodedef> interface plus a nodegraph implementation. The resulting nodes can be used as shaders by a MaterialX material definition.
+
+
+## Autodesk Standard Surface
+
+This is a surface shading model used in Autodesk products created by the Solid Angle team for the Arnold renderer. It is an über shader built from ten different BSDF layers[^Georgiev2019].
+
+A MaterialX definition and nodegraph implementation of Autodesk Standard Surface can be found here:
+[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/standard_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/standard_surface.mtlx)
+
+
+## UsdPreviewSurface
+
+This is a shading model proposed by Pixar for USD[^Pixar2019]. It is meant to model a physically based surface that strikes a balance between expressiveness and reliable interchange between current day DCC’s and game engines and other real-time rendering clients.
+
+A MaterialX definition and nodegraph implementation of UsdPreviewSurface can be found here:
+[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/usd_preview_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/usd_preview_surface.mtlx)
+
+
+## Khronos glTF PBR
+
+This is a shading model using the PBR material extensions in Khronos glTF specification.
+
+A MaterialX definition and nodegraph implementation of glTF PBR can be found here:
+[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/gltf_pbr.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/gltf_pbr.mtlx)
+
+
+## OpenPBR Surface
+
+This is an open surface shading model that was designed as a collaboration between Adobe, Autodesk, and other companies in the industry, and is currently maintained as a subproject of MaterialX within the Academy Software Foundation[^Andersson2024].
+
+A MaterialX definition and nodegraph implementation of OpenPBR Surface can be found here:
+[https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx](https://github.com/AcademySoftwareFoundation/MaterialX/blob/main/libraries/bxdf/open_pbr_surface.mtlx)
+
+
+
+# Shading Translation Graphs
+
+The MaterialX PBS Library includes a number of nodegraphs that can be used to approximately translate the input parameters for one shading model into values to drive the inputs of a different shading model, to produce the same visual results to the degree the differences between the shading models allow. Currently, the library includes translation graphs for:
+
+* Autodesk Standard Surface to UsdPreviewSurface
+* Autodesk Standard Surface to glTF
+
+
+# References
+
+[^Andersson2024]: Andersson et al., **OpenPBR Surface Specification**, , 2024.
+
+[^Belcour2017]: Laurent Belcour, Pascal Barla, **A Practical Extension to Microfacet Theory for the Modeling of Varying Iridescence**, , 2017
+
+[^Burley2012]: Brent Burley, **Physically-Based Shading at Disney**, , 2012
+
+[^Christensen2015]: Per H. Christensen, Brent Burley, **Approximate Reflectance Profiles for Efficient Subsurface Scattering**, 2015
+
+[^Conty2017]: Alejandro Conty, Christopher Kulla, **Production Friendly Microfacet Sheen BRDF**, , 2017
+
+[^Georgiev2019]: Iliyan Georgiev et al., **Autodesk Standard Surface**, , 2019.
+
+[^Gulbrandsen2014]: Ole Gulbrandsen, **Artist Friendly Metallic Fresnel**, , 2014
+
+[^Hoffman2023]: Naty Hoffman, **Generalization of Adobe's Fresnel Model**, 2023
+
+[^Oren1994]: Michael Oren, Shree K. Nayar, **Generalization of Lambert’s Reflectance Model**, , 1994
+
+[^Pharr2023]: Matt Pharr et al., **Physically Based Rendering: From Theory To Implementation**, , 2023
+
+[^Pixar2019]: Pixar Animation Studios, **UsdPreviewSurface Specification**, , 2019.
+
+[^Walter2007]: Bruce Walter et al., **Microfacet Models for Refraction through Rough Surfaces**, , 2007
+
+[^Zeltner2022]: Tizian Zeltner et al., **Practical Multiple-Scattering Sheen Using Linearly Transformed Cosines**, , 2022
diff --git a/MaterialX/documents/Specification/MaterialX.Proposals.md b/MaterialX/documents/Specification/MaterialX.Proposals.md
old mode 100644
new mode 100755
index 4548bda..56e159a
--- a/MaterialX/documents/Specification/MaterialX.Proposals.md
+++ b/MaterialX/documents/Specification/MaterialX.Proposals.md
@@ -1,337 +1,331 @@
-
-
-
-# MaterialX: Proposed Additions and Changes
-
-**Proposals for Version 1.39**
-September 15, 2024
-
-
-# Introduction
-
-The [MaterialX Specification](./MaterialX.Specification.md) has historically included descriptions of not just current functionality, but also forward-looking proposed functionality intended for eventual implementation. We believe it will be beneficial to provide clarity on which functionality is currently supported in the library, and which sections document proposed additions.
-
-As such, those forward-looking proposals have been moved from the formal Specification documents into this Proposed Additions and Changes document to be discussed and debated. These descriptions can then be migrated into the appropriate formal Specification document once actually implemented in the code base. New proposals for changes and additions to MaterialX may be added to this document once a generally favorable consensus from the community is reached.
-
-
-
-## Table of Contents
-
-**[Introduction](#introduction)**
-
-**[Proposals: General](#propose-general)**
-
-**[Proposals: Elements](#propose-elements)**
-
-**[Proposals: Stdlib Nodes](#propose-stdlib-nodes)**
-
-**[Proposals: PBR Nodes](#propose-pbr-nodes)**
-
-**[Proposals: NPR Nodes](#propose-npr-nodes)**
-
-
-
-
-# Proposals: General
-
-
-## Color Spaces
-
-When the OCIO NanoColor library (provide link) becomes available, MaterialX should support the official colorspace names in that spec, with the current MaterialX colorspace names supported as aliases.
-
-MaterialX should also support the following color spaces:
-* `lin_rec2020`
-* `g22_rec2020`
-
-
-
-
-
-# Proposals: Elements
-
-
-### AOV Output Elements
-
-(Summary for README.md: **New Support for Shader AOVs**
-
-Previously, MaterialX used custom types with a structure of output variables to define shader AOVs. But this approach was not very flexible and in fact had not been implemented. In v1.39, nodegraph-based shader implementations can include new [<aovoutput> elements](./MaterialX.Specification.md#aov-output-elements) to define AOVs which renderers can use to output additional channels of information in addition to the final shading result, while file-based <implementation>s can similarly define AOVs using [<aov> elements](./MaterialX.Specification.md#implementation-aov-elements).
-)
-
-A functional nodegraph with either a "shader" or "material"-semantic output type may contain a number of <aovoutput> elements to declare arbitrary output variables ("AOVs") which the renderer can see and output as additional streams of information. AOVoutputs must be of type float, color3 or vector3 for pre-shading "pattern" values, or BSDF or EDF for shader-node output values; the renderer is expected to extract the appropriate color-like information from BSDF and EDF types. AOVs defined within a shader-semantic node instantiated within this functional nodegraph may be "passed along" and potentially renamed (but may not be modified or operated on in any way) by providing a sourceaov attribute in the <aovoutput>.
-
-```xml
-
-```
-
-The attributes for <aovoutput> elements are:
-
-* name (string, required): a user-chosen name for this aov output definition element.
-* type (string, required): the type of the AOV, which must be one of the supported types listed above.
-* aovname (string, required): the name that the renderer should use for the AOV.
-* nodename (string, required): the name of the node whose output defines the AOV value.
-* sourceaov (string, optional): If nodename is a surfaceshader type, the name of the output AOV defined within nodename to pass along as the output AOV. The type of the sourceaov defined within nodename must match the <aovoutput> type.
-
-Examples:
-
-```xml
-
-
- nodename="diffuse_bsdf"/>
-```
-
-#### AovOutput Example
-
-Example of using <aovoutput> with sourceaov to forward AOVs from within an instantiation of a shader-semantic node; this assumes that <standard_surface> has itself defined <aovoutput>s for "diffuse" and "specular" AOVs:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-Layered shaders or materials must internally handle blending of AOV-like values from source layers before outputting them as AOVs: there is currently no facility for blending AOVs defined within post-shading blended surfaceshaders.
-
-Note: while it is syntactically possible to create <aovoutput>s for geometric primitive values such as shading surface point and normal accessed within a nodegraph, it is preferred that renderers derive such information directly from their internal shading state or geometric primvars.
-
-
-
-#### Implementation AOV Elements
-
-An <implementation> element with a file attribute defining an external compiled implementation of a surface shader may contain one or more <aov> elements to declare the names and types of arbitrary output variables ("AOVs") which the shader can output to the renderer. AOVs must be of type float, color3, vector3, BSDF or EDF. Note that in MaterialX, AOVs for pre-shading "pattern" colors are normally of type color3, while post-shaded color-like values are normally of type BSDF and emissive color-like values are normally of type EDF. An <implementation> with a `nodegraph` attribute may not contain <aov> elements; instead, <aovoutput> elements within the nodegraph should be used.
-
-```xml
-
- ......
-
-
-
-```
-
-
-
-### Material Inheritance
-
-Materials can inherit from other materials, to add or change shaders connected to different inputs; in this example, a displacement shader is added to the above "Mgold" material to create a new "Mgolddsp" material:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-```
-
-Inheritance of material-type custom nodes is also allowed, so that new or changed input values can be applied on top of those specified in the inherited material.
-
-
-
-
-# Proposals: Stdlib Nodes
-
-
-### Procedural Nodes
-
-
-
-* **`tokenvalue`**: a constant "interface token" value, may only be connected to <token>s in nodes, not to <input>s.
- * `value` (any uniform non-shader-semantic type): the token value to output; "enum" and "enumvalues" attributes may be provided to define a specific set of allowed token values.
-
-
-
-### Noise Nodes
-
-
-
-1D Cell noise was proposed an an alternative approach to random value generation.
-
-* **`cellnoise1d`**: 1D cellular noise, 1 or 3 channels (type float or vector3).
- * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for input coordinate repeated at that step. Default is 0, meaning the noise is not periodic.
- * `in` (float): the 1D coordinate at which the noise is evaluated.
-
-
-
-Expanded 2D Worley noise to support different distance metrics and periodicity.
-
-* **`worleynoise2d`**: 2D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features).
- * `metric` (uniform string): the distance metric to return, one of "distance" (Euclidean distance to feature), "distance2" (Euclidean distance squared), "manhattan" or "chebyshev". Default is "distance".
- * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for texture coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
-
-
-
-Expanded 3D Worley noise to support different distance metrics and periodicity.
-
-* **`worleynoise3d`**: 3D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features).
- * `metric` (uniform string): the distance metric to return, one of "distance" (Euclidean distance to feature), "distance2" (Euclidean distance squared), "manhattan" or "chebyshev". Default is "distance".
- * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for position coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
-
-#### Periodic Noises
-
-In #1201 it was decided that separate periodic versions of all of the noises is preferred to adding it to the existing noises.
-
-### Shape Nodes
-
-
-
-
-### Geometric Nodes
-
-
-
-* **`bump`**: Existing node, proposal to add a vector3 `bitangent` input
-
-Note: when <geompropvalueuniform> is added, the text in the first paragraph of the Specification about Node Inputs should be revised to include "<geompropvalueuniform>" as an example of "or any other node whose output is explicitly declared to be uniform".
-
-
-### Global Nodes
-
-
-
-* **`ambientocclusion`**: Compute the ambient occlusion at the current surface point, returning a scalar value between 0 and 1. Ambient occlusion represents the accessibility of each surface point to ambient lighting, with larger values representing greater accessibility to light. This node must be of type float.
- * `coneangle` (float): the half-angle of a cone about the surface normal, within which geometric surface features are considered as potential occluders. The unit for this input is degrees, and its default value is 90.0 (full hemisphere).
- * `maxdistance` (float): the maximum distance from the surface point at which geometric surface features are considered as potential occluders. Defaults to 1e38, e.g. "unlimited".
-
-
-
-### Application Nodes
-
-
-
-* **`updirection`**: the current scene "up vector" direction, as defined by the shading environment. This node must be of type vector3.
- * `space` (uniform string): the space in which to return the up vector direction, defaults to "world".
-
-
-
-### Math Nodes
-
-
-
-* **`transformcolor`**: transform the incoming color from one specified colorspace to another, ignoring any colorspace declarations that may have been provided upstream. For color4 types, the alpha channel value is unaffected.
- * `in` (color3 or color4): the input color.
- * `fromspace` (uniform string): the name of a standard colorspace or a colorspace understood by the application to transform the `in` color from; may be empty (the default) to specify the document's working colorspace.
- * `tospace` (uniform string): the name of a standard colorspace or a colorspace understood by the application to transform the `in` color to; may be empty (the default) to specify the document's working colorspace.
-
-
-
-* **`triplanarblend`** (NG): samples data from three inputs, and projects a tiled representation of the images along each of the three respective coordinate axes, computing a weighted blend of the three samples using the geometric normal.
- * `inx` (float or colorN): the image to be projected in the direction from the +X axis back toward the origin. Default is 0 in all channels.
- * `iny` (float or colorN): the image to be projected in the direction from the +Y axis back toward the origin with the +X axis to the right. Default is 0 in all channels.
- * `inz` (float or colorN): the image to be projected in the direction from the +Z axis back toward the origin. Default is 0 in all channels.
- * `position` (vector3): a spatially-varying input specifying the 3D position at which the projection is evaluated. Default is to use the current 3D object-space coordinate.
- * `normal` (vector3): a spatially-varying input specifying the 3D normal vector used for blending. Default is to use the current object-space surface normal.
- * `blend` (float): a 0-1 weighting factor for blending the three axis samples using the geometric normal, with higher values giving softer blending. Default is 1.0.
- * `filtertype` (uniform string): the type of texture filtering to use; standard values include "closest" (nearest-neighbor single-sample), "linear", and "cubic". If not specified, an application may use its own default texture filtering method.
-
-
-
-### Adjustment Nodes
-
-
-
-* **`curveinversecubic`**: remap a 0-1 input float value using an inverse Catmull-Rom spline lookup on the input `knots` values. Outputs a 0-1 float interpolant value.
- * `in` (float): the input value or nodename
- * `knots` (uniform floatarray): the list of non-uniformly distributed input values defining the curve for the remapping. At least 2 values must be provided, and the first and last knot have multiplicity 2.
-
-
-
-* **`curveuniformlinear`**: output a float, colorN or vectorN value linearly interpolated between a number of `knotvalues` values, using the value of `in` as the interpolant.
- * `in` (float): the input interpolant value or nodename
- * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the array of at least 2 values to interpolate between.
-
-
-
-* **`curveuniformcubic`**: output a float, colorN or vectorN value smoothly interpolated between a number of `knotvalues` values using a Catmull-Rom spline with the value of `in` as the interpolant.
- * `in` (float): the input interpolant value or nodename
- * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the array of at least 2 values to interpolate between.
-
-
-
-* **`curveadjust`** (NG): output a smooth remapping of input values using the centripetal Catmull-Rom cubic spline curve defined by specified knot values, using an inverse spline lookup on input knot values and a forward spline through output knot values. All channels of the input will be remapped using the same curve.
- * `in` (float or colorN or vectorN): the input value or nodename
- * `numknots` (uniform integer): the number of values in the knots and knotvalues arrays
- * `knots` (uniform floatarray): the list of input values defining the curve for the remapping. At least 2 and at most 16 values must be provided.
- * `knotvalues` (uniform floatarray): the list of output values defining the curve for the remapping. Must be the same length as knots.
-
-
-
-* **`curvelookup`** (NG): output a float, colorN or vectorN value smoothly interpolated between a number of knotvalue values, using the position of in within knots as the knotvalues interpolant.
- * `in` (float): the input interpolant value or nodename
- * `numknots` (uniform integer): the number of values in the knots and knotvalues arrays
- * `knots` (uniform floatarray): the list of knot values to interpolate in within. At least 2 and at most 16 values must be provided.
- * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the values at each knot position to interpolate between. Must be the same length as knots.
-
-
-
-### Compositing Nodes
-
-
-
-### Conditional Nodes
-
-
-
-* **`ifelse`**: output the value of one of two input streams, according to whether the value of a boolean selector input is true or false
- * `infalse`, `intrue` (float or colorN or vectorN): the values or nodenames to select from based on the value of the `which` input. The types of the various `inN` inputs must match the type of the `switch` node itself. The default value of all `inN` inputs is 0.0 in all channels.
- * `which` (boolean): a selector to choose which input to take values from; default is "false".
-
-
-
-### Channel Nodes
-
-
-
-* **`extractrowvector`**: extract the specified row vector number from a matrixN stream.
- * `in` (matrixN): the input value or nodename
- * `index` (integer): the row number to extract, should be 0-2 for matrix33 streams, or 0-3 for matrix44 streams.
-
-
-
-* **`separatecolor4`** (NG): output the RGB and alpha channels of a color4 as separate outputs.
- * `in` (color4): the input value or nodename
- * `outcolor` (output, color3): the RGB channel values.
- * `outa` (output, float): the value of the alpha channel.
-
-
-
-
-
-# Proposals: PBR Nodes
-
-
-
-
-
-# Proposals: NPR Nodes
-
+
+
+
+# MaterialX: Proposed Additions and Changes
+
+**Proposals for Version 1.39**
+July 26, 2024
+
+
+# Introduction
+
+The [MaterialX Specification](./MaterialX.Specification.md) has historically included descriptions of not just current functionality, but also forward-looking proposed functionality intended for eventual implementation. We believe it will be beneficial to provide clarity on which functionality is currently supported in the library, and which sections document proposed additions.
+
+As such, those forward-looking proposals have been moved from the formal Specification documents into this Proposed Additions and Changes document to be discussed and debated. These descriptions can then be migrated into the appropriate formal Specification document once actually implemented in the code base. New proposals for changes and additions to MaterialX may be added to this document once a generally favorable consensus from the community is reached.
+
+
+
+## Table of Contents
+
+**[Introduction](#introduction)**
+
+**[Proposals: General](#propose-general)**
+
+**[Proposals: Elements](#propose-elements)**
+
+**[Proposals: Stdlib Nodes](#propose-stdlib-nodes)**
+
+**[Proposals: PBR Nodes](#propose-pbr-nodes)**
+
+**[Proposals: NPR Nodes](#propose-npr-nodes)**
+
+
+
+
+# Proposals: General
+
+
+## Color Spaces
+
+When the OCIO NanoColor library (provide link) becomes available, MaterialX should support the official colorspace names in that spec, with the current MaterialX colorspace names supported as aliases.
+
+MaterialX should also support the following color spaces:
+* `lin_rec2020`
+* `g22_rec2020`
+
+
+
+
+
+# Proposals: Elements
+
+
+### AOV Output Elements
+
+A functional nodegraph with either a "shader" or "material"-semantic output type may contain a number of <aovoutput> elements to declare arbitrary output variables ("AOVs") which the renderer can see and output as additional streams of information. AOVoutputs must be of type float, color3 or vector3 for pre-shading "pattern" values, or BSDF or EDF for shader-node output values; the renderer is expected to extract the appropriate color-like information from BSDF and EDF types. AOVs defined within a shader-semantic node instantiated within this functional nodegraph may be "passed along" and potentially renamed (but may not be modified or operated on in any way) by providing a sourceaov attribute in the <aovoutput>.
+
+```xml
+
+```
+
+The attributes for <aovoutput> elements are:
+
+* name (string, required): a user-chosen name for this aov output definition element.
+* type (string, required): the type of the AOV, which must be one of the supported types listed above.
+* aovname (string, required): the name that the renderer should use for the AOV.
+* nodename (string, required): the name of the node whose output defines the AOV value.
+* sourceaov (string, optional): If nodename is a surfaceshader type, the name of the output AOV defined within nodename to pass along as the output AOV. The type of the sourceaov defined within nodename must match the <aovoutput> type.
+
+Examples:
+
+```xml
+
+
+ nodename="diffuse_bsdf"/>
+```
+
+#### AovOutput Example
+
+Example of using <aovoutput> with sourceaov to forward AOVs from within an instantiation of a shader-semantic node; this assumes that <standard_surface> has itself defined <aovoutput>s for "diffuse" and "specular" AOVs:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Layered shaders or materials must internally handle blending of AOV-like values from source layers before outputting them as AOVs: there is currently no facility for blending AOVs defined within post-shading blended surfaceshaders.
+
+Note: while it is syntactically possible to create <aovoutput>s for geometric primitive values such as shading surface point and normal accessed within a nodegraph, it is preferred that renderers derive such information directly from their internal shading state or geometric primvars.
+
+
+
+#### Implementation AOV Elements
+
+An <implementation> element with a file attribute defining an external compiled implementation of a surface shader may contain one or more <aov> elements to declare the names and types of arbitrary output variables ("AOVs") which the shader can output to the renderer. AOVs must be of type float, color3, vector3, BSDF or EDF. Note that in MaterialX, AOVs for pre-shading "pattern" colors are normally of type color3, while post-shaded color-like values are normally of type BSDF and emissive color-like values are normally of type EDF. An <implementation> with a `nodegraph` attribute may not contain <aov> elements; instead, <aovoutput> elements within the nodegraph should be used.
+
+```xml
+
+ ......
+
+
+
+```
+
+
+
+### Material Inheritance
+
+Materials can inherit from other materials, to add or change shaders connected to different inputs; in this example, a displacement shader is added to the above "Mgold" material to create a new "Mgolddsp" material:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Inheritance of material-type custom nodes is also allowed, so that new or changed input values can be applied on top of those specified in the inherited material.
+
+
+
+
+# Proposals: Stdlib Nodes
+
+
+### Procedural Nodes
+
+
+
+* **`tokenvalue`**: a constant "interface token" value, may only be connected to <token>s in nodes, not to <input>s.
+ * `value` (any uniform non-shader-semantic type): the token value to output; "enum" and "enumvalues" attributes may be provided to define a specific set of allowed token values.
+
+
+
+### Noise Nodes
+
+
+
+We have a standard 3d fractal noise, but a 2d variant would be useful as well.
+
+* **`fractal2d`**: Zero-centered 2D Fractal noise in 1, 2, 3 or 4 channels, created by summing several octaves of 2D Perlin noise, increasing the frequency and decreasing the amplitude at each octave.
+ * `amplitude` (float or vectorN): the center-to-peak amplitude of the noise (peak-to-peak amplitude is 2x this value). Default is 1.0.
+ * `octaves` (integer): the number of octaves of noise to be summed. Default is 3.
+ * `lacunarity` (float or vectorN): the exponential scale between successive octaves of noise; must be an integer value if period is non-zero so the result is properly tileable. VectorN-output types can provide either a float (isotropic) or vectorN (anisotropic) values for lacunarity and diminish. Default is 2.0.
+ * `diminish` (float or vectorN): the rate at which noise amplitude is diminished for each octave. Should be between 0.0 and 1.0; default is 0.5. VectorN-output types can provide either a float (isotropic) or vectorN (anisotropic) values for lacunarity and diminish.
+ * `period` (float or vectorN): the positive integer distance at which the noise function returns the same value for texture coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `texcoord` (vector2): the 2D texture coordinate at which the noise is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+1D Cell noise was proposed an an alternative approach to random value generation.
+
+* **`cellnoise1d`**: 1D cellular noise, 1 or 3 channels (type float or vector3).
+ * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for input coordinate repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `in` (float): the 1D coordinate at which the noise is evaluated.
+
+
+
+### Shape Nodes
+
+
+
+
+### Geometric Nodes
+
+
+
+* **`bump`**: Existing node, proposal to add a vector3 `bitangent` input
+
+
+
+* **`geompropvalueuniform`**: the value of the specified uniform geometric property (defined using <geompropdef>) of the currently-bound geometry. This node's type must match that of the referenced geomprop.
+ * `geomprop` (uniform string): the geometric property to be referenced.
+ * `default` (same type as the geomprop's value): a value to return if the specified `geomprop` is not defined on the current geometry.
+
+
+
+### Global Nodes
+
+
+
+* **`ambientocclusion`**: Compute the ambient occlusion at the current surface point, returning a scalar value between 0 and 1. Ambient occlusion represents the accessibility of each surface point to ambient lighting, with larger values representing greater accessibility to light. This node must be of type float.
+ * `coneangle` (float): the half-angle of a cone about the surface normal, within which geometric surface features are considered as potential occluders. The unit for this input is degrees, and its default value is 90.0 (full hemisphere).
+ * `maxdistance` (float): the maximum distance from the surface point at which geometric surface features are considered as potential occluders. Defaults to 1e38, e.g. "unlimited".
+
+
+
+### Application Nodes
+
+
+
+* **`updirection`**: the current scene "up vector" direction, as defined by the shading environment. This node must be of type vector3.
+ * `space` (uniform string): the space in which to return the up vector direction, defaults to "world".
+
+
+
+### Math Nodes
+
+
+
+* **`transformcolor`**: transform the incoming color from one specified colorspace to another, ignoring any colorspace declarations that may have been provided upstream. For color4 types, the alpha channel value is unaffected.
+ * `in` (color3 or color4): the input color.
+ * `fromspace` (uniform string): the name of a standard colorspace or a colorspace understood by the application to transform the `in` color from; may be empty (the default) to specify the document's working colorspace.
+ * `tospace` (uniform string): the name of a standard colorspace or a colorspace understood by the application to transform the `in` color to; may be empty (the default) to specify the document's working colorspace.
+
+
+
+* **`triplanarblend`** (NG): samples data from three inputs, and projects a tiled representation of the images along each of the three respective coordinate axes, computing a weighted blend of the three samples using the geometric normal.
+ * `inx` (float or colorN): the image to be projected in the direction from the +X axis back toward the origin. Default is 0 in all channels.
+ * `iny` (float or colorN): the image to be projected in the direction from the +Y axis back toward the origin with the +X axis to the right. Default is 0 in all channels.
+ * `inz` (float or colorN): the image to be projected in the direction from the +Z axis back toward the origin. Default is 0 in all channels.
+ * `position` (vector3): a spatially-varying input specifying the 3D position at which the projection is evaluated. Default is to use the current 3D object-space coordinate.
+ * `normal` (vector3): a spatially-varying input specifying the 3D normal vector used for blending. Default is to use the current object-space surface normal.
+ * `blend` (float): a 0-1 weighting factor for blending the three axis samples using the geometric normal, with higher values giving softer blending. Default is 1.0.
+ * `filtertype` (uniform string): the type of texture filtering to use; standard values include "closest" (nearest-neighbor single-sample), "linear", and "cubic". If not specified, an application may use its own default texture filtering method.
+
+
+
+### Adjustment Nodes
+
+
+
+* **`curveinversecubic`**: remap a 0-1 input float value using an inverse Catmull-Rom spline lookup on the input `knots` values. Outputs a 0-1 float interpolant value.
+ * `in` (float): the input value or nodename
+ * `knots` (uniform floatarray): the list of non-uniformly distributed input values defining the curve for the remapping. At least 2 values must be provided, and the first and last knot have multiplicity 2.
+
+
+
+* **`curveuniformlinear`**: output a float, colorN or vectorN value linearly interpolated between a number of `knotvalues` values, using the value of `in` as the interpolant.
+ * `in` (float): the input interpolant value or nodename
+ * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the array of at least 2 values to interpolate between.
+
+
+
+* **`curveuniformcubic`**: output a float, colorN or vectorN value smoothly interpolated between a number of `knotvalues` values using a Catmull-Rom spline with the value of `in` as the interpolant.
+ * `in` (float): the input interpolant value or nodename
+ * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the array of at least 2 values to interpolate between.
+
+
+
+* **`curveadjust`** (NG): output a smooth remapping of input values using the centripetal Catmull-Rom cubic spline curve defined by specified knot values, using an inverse spline lookup on input knot values and a forward spline through output knot values. All channels of the input will be remapped using the same curve.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `numknots` (uniform integer): the number of values in the knots and knotvalues arrays
+ * `knots` (uniform floatarray): the list of input values defining the curve for the remapping. At least 2 and at most 16 values must be provided.
+ * `knotvalues` (uniform floatarray): the list of output values defining the curve for the remapping. Must be the same length as knots.
+
+
+
+* **`curvelookup`** (NG): output a float, colorN or vectorN value smoothly interpolated between a number of knotvalue values, using the position of in within knots as the knotvalues interpolant.
+ * `in` (float): the input interpolant value or nodename
+ * `numknots` (uniform integer): the number of values in the knots and knotvalues arrays
+ * `knots` (uniform floatarray): the list of knot values to interpolate in within. At least 2 and at most 16 values must be provided.
+ * `knotvalues` (uniform floatarray or colorNarray or vectorNarray): the values at each knot position to interpolate between. Must be the same length as knots.
+
+
+
+### Compositing Nodes
+
+
+
+### Conditional Nodes
+
+
+
+* **`ifelse`**: output the value of one of two input streams, according to whether the value of a boolean selector input is true or false
+ * `infalse`, `intrue` (float or colorN or vectorN): the values or nodenames to select from based on the value of the `which` input. The types of the various `inN` inputs must match the type of the `switch` node itself. The default value of all `inN` inputs is 0.0 in all channels.
+ * `which` (boolean): a selector to choose which input to take values from; default is "false".
+
+
+
+### Channel Nodes
+
+
+
+* **`extractrowvector`**: extract the specified row vector number from a matrixN stream.
+ * `in` (matrixN): the input value or nodename
+ * `index` (integer): the row number to extract, should be 0-2 for matrix33 streams, or 0-3 for matrix44 streams.
+
+
+
+* **`separatecolor4`** (NG): output the RGB and alpha channels of a color4 as separate outputs.
+ * `in` (color4): the input value or nodename
+ * `outcolor` (output, color3): the RGB channel values.
+ * `outa` (output, float): the value of the alpha channel.
+
+
+
+
+
+# Proposals: PBR Nodes
+
+
+
+
+
+# Proposals: NPR Nodes
+
diff --git a/MaterialX/documents/Specification/MaterialX.Specification.md b/MaterialX/documents/Specification/MaterialX.Specification.md
old mode 100644
new mode 100755
index 2904920..c8e1f88
--- a/MaterialX/documents/Specification/MaterialX.Specification.md
+++ b/MaterialX/documents/Specification/MaterialX.Specification.md
@@ -1,1582 +1,2722 @@
-
-
-
-# MaterialX: An Open Standard for Network-Based CG Object Looks
-
-**Version 1.39**
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-March 15, 2025
-
-
-# Introduction
-
-Computer graphics production studios commonly 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 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 now using more flexible node-based shader networks built up by connecting images and procedurals to shader inputs through a graph of image processing and blending operators.
-
-At least four distinct interrelated data relationships are required to specify the complete "look" of a CG object:
-
-1. _Image processing networks_ of sources, operators, connections and input values, outputting a number of spatially-varying data streams.
-2. _Geometry-specific information_ such as associated texture filenames or IDs for various map types.
-3. Associations between spatially-varying data streams and/or uniform values and the inputs of surface, volume, or other shaders, defining a number of _materials_.
-4. Associations between materials and specific geometries to create a number of _looks_.
-
-**MaterialX** addresses the need for an open, platform-independent, well-defined standard for specifying the "look" of computer graphics objects built using node networks by defining a material content schema along with a corresponding XML-based file format to read and write MaterialX content. The MaterialX schema defines a number of primary element types plus several supplemental and sub-element types, as well as a set of **standard nodes** with specific functionality for defining data-processing graphs, shaders and materials.
-
-This document describes the core MaterialX specification. Companion documents [**MaterialX Standard Nodes**](./MaterialX.StandardNodes.md), [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md) and [**MaterialX NPR Shading Nodes**](./MaterialX.NPRSpec.md) describe the standard mathematical, pattern and shading nodes of MaterialX, while companion documents [**MaterialX Geometry Extensions**](./MaterialX.GeomExts.md) and [**MaterialX Supplemental Notes**](./MaterialX.Supplement.md) describe additional element types and other information about the library, while [**MaterialX: Proposed Additions and Changes**](./MaterialX.Proposals.md) describes forward-looking proposed functionality for MaterialX.
-
-
-
-## Table of Contents
-
-**[Introduction](#introduction)**
-
-**[MaterialX Overview](#materialx-overview)**
- [Definitions](#definitions)
- [MaterialX Names](#materialx-names)
- [MaterialX Data Types](#materialx-data-types)
- [Custom Data Types](#custom-data-types)
- [MTLX File Format Definition](#mtlx-file-format-definition)
- [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems)
- [Units](#units)
- [MaterialX Namespaces](#materialx-namespaces)
- [Geometric Properties](#geometric-properties)
- [Geometric Spaces](#geometric-spaces)
- [File Prefixes](#file-prefixes)
- [Filename Substitutions](#filename-substitutions)
-
-**[Nodes](#nodes)**
- [Inputs](#inputs)
- [Node Graph Elements](#node-graph-elements)
- [Output Elements](#output-elements)
- [Standard Nodes](#standard-nodes)
- [Standard Node Inputs](#standard-node-inputs)
- [Standard UI Attributes](#standard-ui-attributes)
- [Backdrop Elements](#backdrop-elements)
- [Node Graph Examples](#node-graph-examples)
-
-**[Customization, Targeting and Shading](#customization-targeting-and-shading)**
- [Target Definition](#target-definition)
- [Custom Attributes and Inputs](#custom-attributes-and-inputs)
-
- [Custom Nodes](#custom-nodes)
- [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements)
- [NodeDef Parameter Interface](#nodedef-parameter-interface)
- [NodeDef Input Elements](#nodedef-input-elements)
- [NodeDef Token Elements](#nodedef-token-elements)
- [NodeDef Output Elements](#nodedef-output-elements)
- [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements)
- [Example Custom Nodes Defined by External File Implementations](#example-custom-nodes-defined-by-external-file-implementations)
- [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs)
- [Functional Nodegraphs](#functional-nodegraphs)
- [Compound Nodegraphs](#compound-nodegraphs)
- [Example Custom Node Defined by a Nodegraph](#example-custom-node-defined-by-a-nodegraph)
- [Custom Node Use](#custom-node-use)
- [Shader Nodes](#shader-nodes)
- [Material Nodes](#material-nodes)
- [Example Pre-Shader Compositing Material](#example-pre-shader-compositing-material)
- [Material Variants](#material-variants)
-
-**[References](#references)**
-
-
-
-
-# MaterialX Overview
-
-The diagram below gives a high-level overview of a typical MaterialX look definition. A directed acyclic graph of pattern generation and processing nodes is connected to inputs of a surface Shader which defines a layered BSDF response. One or more shaders can be connected to form a Material, which is ultimately associated with specific scene geometry via a MaterialAssign, a number of which comprise a Look. The assignments of Materials to geometries can be defined within a MaterialX document in applications supporting MaterialX Geometry Extensions, or using an alternative mechanism such as USD[^1] or a native application's toolset. Each of the pattern nodes and even the Shaders may in turn be implemented using a graph of nodes: these NodeGraphs are given a parameter interface using NodeDefs, and these implementations may be reused with different input values just like any other Standard node defined by MaterialX.
-
-
-
-MaterialX also allows the specification of additional information not shown in this diagram, such as geometry-specific properties, material variations, arbitrary custom inputs and attributes for nodes, rendering-target-specific versions of shaders, nodes and implementations, external compiled or generated shader implementations, and much more.
-
-
-
-## Definitions
-
-Because the same word can be used to mean slightly different things in different contexts, and because each studio and package has its own vocabulary, it's important to define exactly what we mean by any particular term in this proposal and use each term consistently.
-
-An **Element** is a named object within a MaterialX document, which may possess any number of child elements and attributes. An **Attribute** is a named property of a MaterialX element.
-
-A **Node** is a function that generates or operates upon spatially-varying data. This specification provides a set of standard nodes with precise definitions, and also supports the creation of custom nodes for application-specific uses. The interface for a node’s incoming data is declared through **Inputs**, which may be spatially-varying or uniform, and **Tokens**, which are string values that can be substituted into filenames declared in node inputs. The interface for a node's outgoing data is declared through one or more **Outputs**; a node's Inputs, Tokens and Outputs are collectively referred to as the node's **Ports**.
-
-A **Pattern** is a node that generates or processes simple scalar, vector, and color data, and has access to local properties of any geometry that has been bound.
-
-A **Shader** is a node that can generate or process arbitrary lighting or BSDF data, and has access to global properties of the scene in which it is evaluated.
-
-A **Material** is a node which internally or externally references one or more shaders with specific data streams or uniform values bound to their inputs.
-
-A **Node Graph** is a directed acyclic graph of nodes, which may be used to define arbitrarily complex generation or processing networks. Common uses of Node Graphs are to describe a network of pattern nodes flowing into shader inputs, or to define a complex or layered node in terms of simpler nodes.
-
-A **Stream** refers to a flow of spatially-varying data from one node to another. A Stream most commonly consists of color, vector, or scalar data, but can transport data of any standard or custom type.
-
-A **Layer** is a named 1-, 2-, 3- or 4-channel color "plane" within an image file. Image file formats that do not support multiple or named layers within a file should be treated as if the (single) layer was named "rgba".
-
-A **Channel** is a single float value within a color or vector value, e.g. each layer of an image might have a red Channel, a green Channel, a blue Channel and an alpha Channel.
-
-A **Geometry** is any renderable object, while a **Partition** refers to a specific named renderable subset of a piece of geometry, such as a face set.
-
-A **Collection** is a recipe for building a list of geometries, which can be used as a shorthand for assigning e.g. a Material to a number of geometries in a Look.
-
-A **Target** is a software environment that interprets MaterialX content to generate images, with common examples being digital content creation tools and 3D renderers.
-
-
-
-## MaterialX Names
-
-All elements in MaterialX (nodes, materials, shaders, etc.) are required to have a `name` attribute of type "string". The `name` attribute of a MaterialX element is its unique identifier, and no two elements within the same scope (i.e. elements with the same parent) may share a name.
-
-Element names are restricted to upper- and lower-case letters, numbers, and underscores (“_”) from the ASCII character set; all other characters and symbols are disallowed. MaterialX names are case-sensitive and are not allowed to begin with a digit.
-
-
-
-## MaterialX Data Types
-
-All values, input and output ports, and streams in MaterialX are strongly typed, and are explicitly associated with a specific data type. The following standard data types are defined by MaterialX:
-
-**Base Types**:
-
-```
- integer, boolean, float,
- color3, color4,
- vector2, vector3, vector4,
- matrix33, matrix44, string, filename
-```
-
-**Array Types**:
-
-```
- integerarray, floatarray,
- color3array, color4array,
- vector2array, vector3array, vector4array,
- stringarray
-```
-
-
-The following examples show the appropriate syntax for MaterialX attributes in MTLX files:
-
-**Integer**, **Float**: just a value inside quotes:
-
-```
- integervalue = "1"
- floatvalue = "1.0"
-```
-
-**Boolean**: the lower-case word "true" or "false" inside quotes:
-
-```
- booleanvalue = "true"
-```
-
-**Color** types: MaterialX supports two different color types:
-
-* color3 (red, green, blue)
-* color4 (red, green, blue, alpha)
-
-Color channel values should be separated by commas (with or without whitespace), within quotes:
-
-```
- color3value = "0.1,0.2,0.3"
- color4value = "0.1,0.2,0.3,1.0"
-```
-
-Note: all color3 values and the RGB components of a color4 value are presumed to be specified in the "working color space" defined in the enclosing <materialx> element, although any element within a document may provide a `colorspace` attribute that explicitly states the space in which color values within its scope should be interpreted; implementations are expected to translate those color values into the working color space before performing computations with those values. See the [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems) section below.
-
-**Vector** types: similar to colors, MaterialX supports three different vector types:
-
-* vector2 (x, y)
-* vector3 (x, y, z)
-* vector4 (x, y, z, w)
-
-Coordinate values should be separated by commas (with or without whitespace), within quotes:
-
-```
- vector2value = "0.234,0.885"
- vector3value = "-0.13,12.883,91.7"
- vector4value = "-0.13,12.883,91.7,1.0"
-```
-
-While colorN and vectorN types both describe vectors of floating-point values, they differ in a number of significant ways. First, the final channel of a color4 value is interpreted as an alpha channel by compositing operators, and is only meaningful within the [0, 1] range, while the fourth channel of a vector4 value _could be_ (but is not necessarily) interpreted as the "w" value of a homogeneous 3D vector. Additionally, values of type color3 and color4 are always associated with a particular color space and are affected by color transformations, while values of type vector3 and vector4 are not. More detailed rules for colorN and vectorN operations may be found in the [Standard Operator Nodes](./MaterialX.StandardNodes.md#standard-operator-nodes) section of the specification.
-
-**Matrix** types: MaterialX supports two matrix types that may be used to represent geometric and color transforms. The `matrix33` and `matrix44` types, respectively, represent 3x3 and 4x4 matrices and are written as nine or sixteen float values separated by commas, in row-major order:
-
-```
- matrix33value = "1,0,0, 0,1,0, 0,0,1"
- matrix44value = "1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,1"
-```
-
-**String**: literal text within quotes. See the [MTLX File Format Definition](#mtlx-file-format-definition) section for details on representing special characters within string data.
-
-```
- stringvalue = "some text"
-```
-
-**Filename**: attributes of type "filename" are just strings within quotes, but specifically mean a Uniform Resource Identifier ([https://en.wikipedia.org/wiki/Uniform_Resource_Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier)) optionally containing one or more Filename Substitution strings (see below) that represents a reference to an external asset, such as a file on disk or a query into a content management system.
-
-```
- filevalue = "diffuse/color01.tif"
- filevalue = "/s/myshow/assets/myasset/v102.1/wetdrips/drips.{frame}.tif"
- filevalue = "https://github.com/organization/project/tree/master/src/node.osl"
- filevalue = "cmsscheme:myassetdiffuse..tif?ver=current"
-```
-
-**IntegerArray**, **FloatArray**, **Color3Array**, **Color4Array**, **Vector2Array**, **Vector3Array**, **Vector4Array**, **StringArray**: any number of values (including zero) of the same base type, separated by commas (with or without whitespace), within quotes; arrays of color3’s, color4’s, vector2's, vector3's or vector4's are simply a 1D list of channel values in order, e.g. "r0, g0, b0, r1, g1, b1, r2, g2, b2". Individual string values within stringarrays may not contain commas or semicolons, and any leading and trailing whitespace characters in them is ignored. MaterialX does not support multi-dimensional or nested arrays. Array-typed inputs to nodes must be static uniform values of a length specified by another uniform input value of the node, or implicitly by the node's implementation requirements. Nodes cannot output an Array type.
-
-```
- integerarrayvalue = "1,2,3,4,5"
- floatarrayvalue = "1.0, 2.2, 3.3, 4.4, 5.5"
- color3arrayvalue = ".1,.2,.3, .2,.3,.4, .3,.4,.5"
- color4arrayvalue = ".1,.2,.3,1, .2,.3,.4,.98, .3,.4,.5,.9"
- vector2arrayvalue = "0,.1, .4,.5, .9,1.0"
- vector3arrayvalue = "-0.2,0.11,0.74, 5.1,-0.31,4.62"
- vector4arrayvalue = "-0.2,0.11,0.74,1, 5.1,-0.31,4.62,1"
- stringarrayvalue = "hello, there, world"
-```
-
-
-
-## Custom Data Types
-
-In addition to the standard data types, MaterialX supports the specification of custom data types for the inputs and outputs of shaders and custom nodes. This allows documents to describe data streams of any complex type an application may require; examples might include spectral color samples or compound geometric data. The structure of a custom type's contents may be described using a number of elements, though it is also permissible to only declare the custom type's name and treat the type as "blind data".
-
-Types can be declared to have a specific semantic, which can be used to determine how values of that type should be interpreted, and how nodes outputting that type can be connected. Currently, MaterialX defines three semantics:
-
-* "`color`": the type is interpreted to represent or contain a color, and thus should be color-managed as described in the [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems) section.
-* "`shader`": the type is interpreted as a shader output type; nodes or nodegraphs which output a type with a "shader" semantic can be used to define a shader-type node, which can be connected to inputs of "material"-type nodes.
-* "`material`": the type is interpreted as a material output type; nodes or nodegraphs which output a type with a "material" semantic can be referenced by a <materialassign> in a <look>.
-
-Types not defined with a specific semantic are assumed to have semantic="default".
-
-Custom types are defined using the <typedef> element:
-
-```xml
-
-
-
-
-
-```
-
-Attributes for <typedef> elements:
-
-* `name` (string, required): the name of this type. Cannot be the same as a built-in MaterialX type. To reduce the possible symbol conflict between custom type names and possible variable names created by code generation, we suggest the convention of using `_struct` as a suffix to the type name.
-* `semantic` (string, optional): the semantic for this type (see above); the default semantic is "default".
-* `context` (string, optional): a semantic-specific context in which this type should be applied. For "shader" semantic types, `context` defines the rendering context in which the shader output is interpreted; please see the [Shader Nodes](#shader-nodes) section for details.
-* `inherit` (string, optional): the name of another type that this type inherits from, which can be either a built-in type or a custom type. Applications that do not have a definition for this type can use the inherited type as a "fallback" type.
-* `hint` (string, optional): A hint to help those creating code generators understand how the type might be defined. The following hints for typedefs are currently defined:
- * "halfprecision": the values within this type are half-precision
- * "doubleprecision: the values within this type are double-precision
-
-Attributes for <member> elements:
-
-* `name` (string, required): the name of the member variable. Must be unique within the list of other member names for this custom type.
-* `type` (string, required): the type of the member variable; can be any built-in MaterialX type, or any previously defined custom type; recursive inclusion for <member> types is not supported.
-* `value` (string, required): the default value of the member variable.
-
-If a number of elements are provided, then a MaterialX file can specify a value for that type any place it is used, as a brace surrounded, semicolon-separated list of numbers and strings, with the expectation that the numbers and strings between semicolons exactly line up with the expected types in order. The use of the braces allows for custom struct types initializers to be nested. For example, if the following was declared:
-
-```xml
-
-
-
-
-
-
-
-```
-
-Then a permissible input declaration in a custom node using that type could be:
-
-```xml
-
-```
-
-If child elements are not provided, e.g. if the contents of the custom type cannot be represented as a list of MaterialX types, then a value cannot be provided, and this type can only be used to pass blind data from one custom node's output to another custom node or shader input.
-
-Once a custom type is defined by a <typedef>, it can then be used in any MaterialX element that allows "any MaterialX type"; the list of MaterialX types is effectively expanded to include the new custom type. It should be noted however that the <typedef> is only declaring the existence of the type and perhaps some hints about its intended definition, but it is up to each application and code generator to provide its own precise definition for any type.
-
-The standard MaterialX distribution includes definitions for four "shader"-semantic data types: **surfaceshader**, **displacementshader**, **volumeshader**, and **lightshader**. These types are discussed in more detail in the [Shader Nodes](#shader-nodes) section below.
-
-
-
-## MTLX File Format Definition
-
-An MTLX file (with file extension ".mtlx") has the following general form:
-
-```xml
-
-
-
-
-```
-
-That is, a standard XML declaration line followed by a root <materialx> element, which contains any number of MaterialX elements and sub-elements. The default character encoding for MTLX files is UTF-8, and this encoding is expected for the in-memory representation of string values in MaterialX implementations.
-
-Standard XML XIncludes are supported ([http://en/wikipedia.org/wiki/XInclude](http://en/wikipedia.org/wiki/Xinclude)), as well as standard XML comments and the XML character entities `"`, `&`, `'`, `<` and `>`:
-
-```xml
-
-
-
-```
-
-To support stringarray types, MaterialX supports a non-standard XML convention where a comma (and any following whitespace) is a separator for strings within a stringarray, a comma or semicolon preceded by a backslash is interpreted as a regular comma or semicolon rather than as a separator, and two backslashes are interpreted as a single backslash.
-
-Each XIncluded document must itself be a valid MTLX file, containing an XML header and its own root `` element, the children of which are added to the root element of the including document. Hierarchical root-level attributes such as `colorspace` and `namespace` are distributed to the included children to maintain correct semantics within the including MaterialX document.
-
-Attributes for a <materialx> element:
-
-* `version` (string, required): a string containing the version number of the MaterialX specification that this document conforms to, specified as a major and minor number separated by a dot. The MaterialX library automatically upgrades older-versioned documents to the current MaterialX version at load time.
-* `colorspace` (string, optional): the name of the "working color space" for this element and all of its descendants. This is the default color space for all image inputs and color values, and the color space in which all color computations will be performed. The default is "none", for no color management.
-* `namespace` (string, optional): defines the namespace for all elements defined within this <materialx> scope. Please see the [MaterialX Namespaces](#materialx-namespaces) section below for details.
-
-
-
-## Color Spaces and Color Management Systems
-
-MaterialX supports the use of color management systems to associate RGB colors and images with specific color spaces. MaterialX documents typically specify the working color space of the application that created them, and any input color or image described in the document can specify the name of its color space if different from the working color space. This allows applications using MaterialX to transform color values within input colors and images from their original color space into a desired working color space upon ingest. MaterialX does not specify _how_ or _when_ color values should be transformed: that is up to the host application, which can use any appropriate method including code generation, conversion when loading images into memory, maintaining cached or pre-converted image textures, etc. It is generally presumed that the working color space of a MaterialX document will be linear (as opposed to log, a display-referred space such as sRGB, or some other non-linear encoding), although this is not a firm requirement.
-
-By default, MaterialX supports the following color spaces as defined in ACES 1.2 ([http://www.oscars.org/science-technology/sci-tech-projects/aces)](http://www.oscars.org/science-technology/sci-tech-projects/aces), and applications rendering MaterialX documents are expected to transform input colors and images from these spaces to the color space of their renderer. One straightforward option for providing this support is to leverage MaterialX code generators, which support these transforms automatically, but applications may use any appropriate means to handle the transforms on their own.
-
-* `srgb_texture`
-* `lin_rec709`
-* `g22_rec709`
-* `g18_rec709`
-* `acescg`
-* `lin_ap1 (alias for "acescg")`
-* `g22_ap1`
-* `g18_ap1`
-* `lin_srgb`
-* `adobergb`
-* `lin_adobergb`
-* `srgb_displayp3`
-* `lin_displayp3`
-
-The working color space of a MaterialX document is defined by the `colorspace` attribute of its root <materialx> element, and it is strongly recommended that all <materialx> elements define a specific `colorspace` if they wish to use a color-managed workflow rather than relying on a default color space setting from an external configuration file. If a MaterialX document is xi:included into another MaterialX document, it will inherit the working color space setting of the parent document, unless it itself declares a specific working color space.
-
-The color space of individual color image files and values may be defined via a `colorspace` attribute in an input which defines a filename or value. Other elements, such as <nodegraph> or a node instance, are allowed to define a `colorspace` attribute that will apply to elements within their scope; color values in inputs and files that do not explicitly provide a `colorspace` attribute will be treated as if they are in the color space of the nearest enclosing scope which does define a `colorspace` attribute. Color images and values in spaces other than the working color space are expected to be transformed by the application into the working space before computations are performed. In the example below, an image file has been defined in the “srgb_texture” color space, while its default value has been defined in “lin_rec709”; both should be transformed to the application’s working color space before being applied to any computations.
-
-```xml
-
-
-
-
-```
-
-MaterialX reserves the color space name "none" to mean no color space conversion should be applied to the images and color values within their scope, regardless of any differences between stated color spaces at the local scope and document or application working color space settings.
-
-
-
-## Units
-
-MaterialX allows floating-point and vector values to be defined in terms of a specific unit and unit type, and can automatically convert values from their specified unit into a scene unit of the same type specified by the application. This allows images and the quantities they represent such as displacement amount to be specified at an absolute real-world size, and then be converted automatically to the expected scene units of the application.
-
-Unit types are defined using a <unittypedef> element, and a set of units of that type is defined using a <unitdef> element with one or more child <unit> elements. The following unittypes and units are pre-defined by MaterialX:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-The <unittypedef> defines the name of a unittype, while the <unitdef> defines any number of units for a unittype along with the multiplicative conversion `scale` values relative to the other units. Additional unit definitions for any unit type may be done by providing another <unitdef> with the same `unittype` attribute value.
-
-Any input or other floating-point value may specify a `unit` and/or `unittype` attribute subject to guidelines clarified throughout this document. Units and unittypes may also be provided for floatarray, vectorN and vectorNarray quantities, with all components of the vector or all values in the array using the same unit, and for "filename"-type input, in which case the `unit` and/or `unittype` attribute applies to the float or vectorN values read from those files. It is not expected that all inputs will have defined units or unittypes; in fact, it is expected that the vast majority of inputs will have neither. Units and unittypes should only be specified where specific units are important and it is reasonably expected that unit conversion may need to take place.
-
-Please refer to the [Inputs](#inputs), [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements), [Geometric Properties](#geometric-properties) and [Geometric Nodes](./MaterialX.StandardNodes.md#geometric-nodes) sections below and in the MaterialX Standard Nodes and MaterialX Geometry Extensions documents for additional specific requirements for the use of units.
-
-
-
-## MaterialX Namespaces
-
-MaterialX supports the specification of “namespaces”, which qualify the MaterialX names of all elements within their scope. Namespaces are specified via a `namespace` attribute in a <materialx> element, and other MaterialX files which <xi:include> this .mtlx file can refer to its content without worrying about element or object naming conflicts, similar to the way namespaces are used in various programming languages. It is permissible for multiple <materialx> elements to specify the same namespace; the elements from each will simply be merged into the same namespace. <materialx> elements which do not specify a namespace will define elements into the (unnamed) global namespace. MaterialX namespaces are most commonly used to define families of custom nodes (nodedefs), material libraries, or commonly-used network shaders or nodegraphs.
-
-References to elements in a different namespace are qualified using the syntax "_namespace_:_elementname_", where _namespace_ is the namespace at the scope of the referenced element and _elementname_ is the name of the referenced element. References to elements in the same namespace, or to elements in the global namespace, should not be qualified.
-
-#### Namespace Examples
-
-Mtllib.mtlx contains the following (assuming that "..." contains any necessary material input connections and other element definitions):
-
-```xml
-
-
- ...
-
- ...
-
-
- ...
-
-
-```
-
-Then another MaterialX file could reference these materials like this:
-
-```xml
-
- ...
-
-
-
-
-```
-
-Similarly, if a .mtlx file defining the "site_ops" namespace defined a custom color3-typed node "mynoise" with a single float input "f", it could be used in a node graph like this:
-
-```xml
-
-
-
-```
-
-A `namespace` attribute may also be added to individual <nodedef>s or <nodegraph>s, in which case the `name` and `node` of a <nodedef>, or just the `name` of a <nodegraph> will be assigned to the specified `namespace`. In a <nodegraph>, the `nodedef` must include a namespace reference if the <nodedef> to which it refers is defined in a specific namespace, even if it's the same namespace as the <nodegraph>: this is because the `namespace` only applies to the content that is created by or contained within an element, not to anything external referenced by that element.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-```
-
-
-
-## Geometric Properties
-
-Geometric Properties, or "geomprops", are intrinsic or user-defined surface coordinate properties of geometries referenced in a specific space and/or index, and are functionally equivalent to USD's concept of "primvars". A number of geometric properties are predefined in MaterialX: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`, the values of which can be accessed in nodegraphs using elements of those same names; see the [Geometric Nodes](./MaterialX.StandardNodes.md#geometric-nodes) section of the MaterialX Standard Nodes document for details. The value of a varying geometric property can also be used as the default value for a node input using a `defaultgeomprop` attribute.
-
-The following geometric properties are pre-defined by MaterialX:
-
-| GeomProp Name | Type | Description |
-| ---- | ---- | ---- |
-| Pobject | vector3 | Object space position |
-| Nobject | vector3 | Object space surface normal |
-| Tobject | vector3 | Object space tangent vector (index 0) |
-| Bobject | vector3 | Object space bitangent vector (index 0) |
-| Pworld | vector3 | World space position |
-| Nworld | vector3 | World space surface normal |
-| Tworld | vector3 | World space tangent vector (index 0) |
-| Bworld | vector3 | World space bitangent vector (index 0) |
-| UV0 | vector2 | Index "0" UV texture coordinate |
-
-One may also define custom geometric properties using a <geompropdef> element:
-
-```xml
-
-```
-
-e.g.
-
-```xml
-
-
-```
-
-The `type` of the geomprop may be any non-array MaterialX type, although `string`- or `filename`-type geomprops must be declared with uniform="true". The "geomprop", "space" and "index" attributes are optional; if "geomprop" is specified, it must be one of the standard geometric properties noted above, and if it is not specified, the new geomprop is a blind geometric property, e.g. one that can be referenced but which MaterialX knows no details about. The "space" and "index" attributes may only be specified if a "geomprop" attribute is specified and the standard geomproperty supports it. "Geomprop", "space" and "index" attributes may not be specified for `uniform="true"` geomprops.
-
-Once defined, a custom geomprop name may be used any place that a standard geomprop can:
-
-```xml
-
-```
-
-A geompropdef may also specify a `unittype` and a `unit` to indicate that the geometric property is defined in terms of a specific unit. If a geomprop with a defined unit is accessed in a nodegraph using <geompropvalue>, the geometric property value will be converted from the unit specified by the geompropdef to the application-specified scene unit.
-
-```xml
-
-```
-
-
-## Geometric Spaces
-
-Various operator nodes may need to specify which 3D space a position or vector is in. The following values are supported by the `space` inputs of Geometric nodes and when transforming from one space to another:
-
-* "model": The local coordinate space of the geometry, before any local deformations or global transforms have been applied.
-* "object": The local coordinate space of the geometry, after local deformations have been applied, but before any global transforms.
-* "world": The global coordinate space of the geometry, after local deformations and global transforms have been applied.
-
-
-
-## File Prefixes
-
-As a shorthand convenience, MaterialX allows the specification of a `fileprefix` attribute which will be prepended to input values of type "filename" (e.g. `file` inputs in `` nodes, or any shader input of type "filename") specified within the scope of the element defining the `fileprefix`. Note that `fileprefix` values are only prepended to input with a `type` attribute that explicitly states its data type as “filename”. Since the values of the prefix and the filename are string-concatenated, the value of a `fileprefix` should generally end with a "/". Fileprefixes are frequently used to split off common path components for asset directories, e.g. to define an asset's "texture root" directory.
-
-So the following snippets are equivalent:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-Note in the second example that `` "in2" redefined `fileprefix` for itself, and that any other nodes in the same nodegraph would use the fileprefix value ("textures/color/") defined in the parent/enclosing scope.
-
-Note: Application implementations have access to both the raw input values and attributes (e.g. the "file" name and the current "fileprefix") and to fully-resolved filenames at the scope of any given element.
-
-
-
-## Filename Substitutions
-
-Filename input values for various nodes can include one or more special strings, which will be replaced as described in the following table. Substitution strings within <>'s come from the current geometry, strings within []'s come from the MaterialX state, and strings within {}'s come from the host application environment.
-
-| Token | Description |
-| ---- | ---- |
-| <UDIM> | A special geometry token that will be replaced with the computed four digit Mari-style "udim" value at render or evaluation time based on the current point’s uv value, using the formula UDIM = 1001 + U + V*10, where U is the integer portion of the u coordinate, and V is the integer portion of the v coordinate. |
-| <UVTILE> | A special geometry token that will be replaced with the computed Mudbox-style "uU_vV" string, where U is 1+ the integer portion of the u coordinate, and V is 1+ the integer portion of the v coordinate. |
-| [interface token] | The value of a specified token declared in the containing nodegraph's <nodedef> interface; the value for the token may be set in the shader node in a material referencing the node or within a <variant>; it is an error if the same token is defined in more than one of those places for the current geometry. |
-| {hostattr} | The host application may define other variables which can be resolved within filenames. |
-| {frame} | A special string that will be replaced by the current frame number, as defined by the host environment. |
-| {0Nframe} | A special string that will be replaced by the current frame number padded with zeros to be N digits total (replace N with a number): e.g. {04frame} will be replaced by a 4-digit zero-padded frame number such as "0010". |
-
-
-Note: Implementations are expected to retain substitution strings within filenames upon export rather than "baking them out" into fully-evaluated filenames. Applications using USD for geometry and assignments may additionally use a <_geometry token_> (a.k.a. "<_primvarname_>") as the entire filename string to access an entire string primvar value unchanged (though that string value may contain the USD-supported <UDIM> token).
-
-
-
-
-# Nodes
-
-Nodes are individual data generation or processing "blocks". Node functionality can range from simple operations such as returning a constant color value or adding two input values, to more complex image processing operations, 3D spatial data operations, or even complete shader BxDFs. Nodes are connected together into a network or "node graph", and pass typed data streams between them.
-
-Individual node elements have the form:
-
-```xml
-
-
- ...additional input or token elements...
-
-```
-
-where _nodecategory_ is the general "category" of the node (e.g. "image", "add" or "mix"), `name` (string, required) defines the name of this instance of the node, which must be unique within the scope it appears in, and `type` (string, required) specifies the MaterialX type (typically float, colorN, or vectorN) of the output of that node. If the application uses a different name for this instance of the node in the user interface, a `uiname` attribute may be added to the <_nodecategory_> element to indicate the name of the node as it appears to the user.
-
-Node elements may optionally specify a `version` string attribute in "_major_[._minor_]" format, requesting that a specific version of that node's definition be used instead of the default version. Normally, the types of a node's inputs and outputs are sufficient to disambiguate which signature of the applicable version of a node is intended, but if necessary, a node instantiation may also declare a specific nodedef name to precisely define exactly which node signature is desired. Please refer to the [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements) section below for further details.
-
-MaterialX defines a number of [Standard Nodes](#standard-nodes) which all implementations should support as described to the degree their architecture and capabilities allow. One can define new nodes by declaring their parameter interfaces and providing portable nodegraph or target-specific shading language implementations. Please see the [Custom Nodes](#custom-nodes) section for notes and implementation details.
-
-
-
-## Inputs
-
-Node elements contain zero or more <input> elements defining the name, type, and value or connection for each node input. Input elements can assign an explicit uniform value by providing a `value` attribute, make a connection to the output of another node by providing a `nodename` attribute, or make a connection to the output of a nodegraph by providing a `nodegraph` attribute. An optional `output` attribute may also be provided for <input> elements, allowing the input to connect to a specific, named output of the referenced upstream node or nodegraph. If the referenced node/nodegraph has multiple outputs, `output` is required; if it has only one output, the `output` attribute of the <input> is ignored. Input elements may be defined to only accept uniform values, in which case the input may provide a `value` or a `nodename` connection to the output of a [<constant> node](./MaterialX.StandardNodes.md#node-constant) (possibly through one or more no-op [<dot> nodes](./MaterialX.StandardNodes.md#node-dot)) or any other node whose output is explicitly declared to be "uniform", but may not provide a `nodename` or `nodegraph` connection to any arbitrary node output or to any nodegraph output. String- and filename-type inputs are required to be "uniform", as are any array-typed inputs. Input elements may be connected to an external parameter interface in the node definition, allowing them to be assigned values from materials or node instantiations; this includes "uniform" and string/filename-type inputs, however, the same connectability restrictions listed above apply to the inputs of the material or node instance. Inputs may only be connected to node/nodegraph outputs or nodedef interface inputs of the same type, though it is permissible for a `string`-type output to be connected to a `filename`-type input (but not the other way around).
-
-A float/vectorN input of a node, or a "filename"-type input referring to an image file containing float or vectorN values, may specify a unit for its value by providing a `unit` attribute, and that unit must be one associated with the `unittype` for that input in the nodedef, if specified; please see the [Units](#units) section above for details on declaring units and unittypes. If the nodedef for a node (see the [Custom Nodes](#custom-nodes) section below) does not declare a `unittype` for an input, the node may do so; it is not permissible to provide a `unit` for a node input without a compatible `unittype` being defined on either the node or applicable nodedef.
-
-```xml
-
-
-
-```
-
-Unless specified otherwise, all inputs default to a value of 0 in all channels for integer, float, color and vector types, "" for string and filename types, "false" for boolean types, the identity matrix for matrix types, and for array types, an appropriate-length array consisting of the default value for the array's base type.
-
-Standard MaterialX nodes have exactly one output, while custom nodes may have any number of outputs; please see the [Custom Nodes](#custom-nodes) section for details.
-
-
-
-## Node Graph Elements
-
-A graph containing any number of nodes and output declarations forms a Node Graph, which may be enclosed within a <nodegraph> element to group them together into a single functional unit. Please see the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section below for details on how nodegraphs can be used to describe the functionality of new nodes.
-
-```xml
-
- ...node element(s)...
- ...output element(s)...
-
-```
-
-
-
-## Output Elements
-
-Output data streams are defined using **<output>** elements, and may be used to declare which output streams are connectable to other MaterialX elements. Within a node graph, an <output> element declares an output stream that may be connected to a shader input or to the input of a referencing node in another graph when the nodegraph is the implementation of a custom node. See the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section for details on the use of node graphs as node implementations.
-
-```xml
-
-
-```
-
-Attributes for Output elements:
-
-* `name` (string, required): the name of the output
-* `type` (string, required): the MaterialX type of the output
-* `nodename` (string, optional): the name of a node at the same scope within the document, whose result value will be output. This attribute is required for <output> elements within a node graph, but is not allowed in <output> elements within a <nodedef>.
-* `output` (string, optional): if the node specified by `nodename` has multiple outputs, the name of the specific output to connect this <output> to.
-* `uniform` (boolean, optional): If set to "true", then the output of this node is treated as a uniform value, and this output may be connected to a uniform input of the same (or compatible) type. It is up to the application creating the nodegraph to ensure that the value actually is uniform. Default is "false".
-
-MaterialX also supports the following additional attributes for Output elements in applications which process node graphs in 2D space and save or cache outputs as images for efficiency, such as texture baking or image caching. These attributes do **not** affect values from this <output> connected to other nodes, e.g. they would remain in the working colorspace and retain full resolution and bitdepth precision.
-
-* `colorspace` (string, optional): the name of the color space for the output image. Applications that support color space management are expected to perform the required transformations of output colors into this space.
-* `width` (integer, optional): the expected width in pixels of the output image.
-* `height` (integer, optional): the expected height in pixels of the output image.
-* `bitdepth` (integer, optional): the expected per-channel bit depth of the output image, which may be used to capture expected color quantization effects. Common values for `bitdepth` are 8, 16, 32, and 64. It is up to the application to determine what the internal representation of any declared bit depth is (e.g. scaling factor, signed or unsigned, etc.).
-
-
-
-## Standard Nodes
-
-A core part of MaterialX is its set of Standard Nodes, divided into five categories: Source nodes, Operator nodes, Standard Shader nodes, Physically-Based Shading nodes, and NPR (non-photorealistic) Shading nodes.
-
-[**Source nodes**](./MaterialX.StandardNodes.md#standard-source-nodes) use external data and/or procedural functions to form an output; they do not have any required inputs. Standard Source Nodes are grouped into the following classifications: [Texture Nodes](./MaterialX.StandardNodes.md#texture-nodes), [Procedural Nodes](./MaterialX.StandardNodes.md#procedural-nodes), [Noise Nodes](./MaterialX.StandardNodes.md#noise-nodes), [Shape Nodes](./MaterialX.StandardNodes.md#shape-nodes), [Geometric Nodes](./MaterialX.StandardNodes.md#geometric-nodes) and [Application Nodes](./MaterialX.StandardNodes.md#application-nodes).
-
-[**Operator nodes**](./MaterialX.StandardNodes.md#standard-operator-nodes) process one or more input streams to form an output. Standard Operator Nodes are grouped into the following classifications: [Math Nodes](./MaterialX.StandardNodes.md#math-nodes), [Logical Operator Nodes](./MaterialX.StandardNodes.md#logical-operator-nodes), [Adjustment Nodes](./MaterialX.StandardNodes.md#adjustment-nodes), [Compositing Nodes](./MaterialX.StandardNodes.md#compositing-nodes), [Conditional Nodes](./MaterialX.StandardNodes.md#conditional-nodes), [Channel Nodes](./MaterialX.StandardNodes.md#channel-nodes) and [Convolution Nodes](./MaterialX.StandardNodes.md#convolution-nodes).
-
-[**Standard Shader nodes**](./MaterialX.StandardNodes.md#standard-shader-nodes) comprise non-shading shaders such as for displacement, and shaders which do not respond to external illumination.
-
-[**Physically-Based Shading nodes**](./MaterialX.PBRSpec.md) are shader-semantic nodes implementing a number of widely-used [BSDF/BSSRDF](./MaterialX.PBRSpec.md#bsdf-nodes), [emission](./MaterialX.PBRSpec.md#edf-nodes) and [volume](./MaterialX.PBRSpec.md#vdf-nodes) distribution functions and [utility nodes](./MaterialX.PBRSpec.md#utility-nodes) useful in constructing complex layered rendering shaders using node graphs, as well as a set of complete [PBR Shader Nodes](./MaterialX.PBRSpec.md#pbr-shader-nodes) implementing open standard shading models.
-
-[**NPR Shading nodes**](./MaterialX.NPRSpec.md) are operations that are desirable in non-photorealistic shading styles but which cannot be implemented within certain rendering constructs. These include [NPR Application Nodes](./MaterialX.NPRSpec.md#npr-application-nodes), [NPR Utility Nodes](./MaterialX.NPRSpec.md#npr-utility-nodes) and [NPR Shading Nodes](./MaterialX.NPRSpec.md#npr-shading-nodes).
-
-
-
-## Standard Node Inputs
-
-All standard nodes which define a `defaultinput` or `default` value support the following input:
-
-
-
-* `disable` (uniform boolean): if set to true, the node will pass its default input or value to its output, effectively disabling the node; default is false. Applications may choose to implement the `disable` input by skipping over the disabled node during traversal and instead passing through a connection to the defaultinput node or outputting the node's default value, rather than using an actual `disable` input in the node implementation.
-
-
-## Standard UI Attributes
-
-All elements support the following additional UI-related attributes:
-
-
-
-* `doc` (string attribute): a description of the function or purpose of this element; may include standard HTML formatting strings such as <b>, <ul>, <p>, etc. but no complex formatting such as CSS or external references (e.g. no hyperlinks or images). May be used for functional documentation, or for UI pop-up "tool tip" strings.
-
-
-All node types (sources, operators, shader nodes and material nodes) as well as <look> elements support the following UI-related attributes:
-
-
-
-* `xpos` (float attribute): X-position of the upper-left corner of the node when drawn in a UI.
-
-
-
-* `ypos` (float attribute): Y-position of the upper-left corner of the node when drawn in a UI.
-
-
-
-* `width` (float attribute): the relative width of the node when drawn in a UI; default is 1.0.
-
-
-
-* `height` (float attribute): the relative height of the node when drawn in a UI; default is 1.0.
-
-
-
-* `uicolor` (color3 attribute): the display-referred color of the node as drawn in the UI, normalized to 0.0-1.0 range; default is to not specify a particular color so the application's default node color would be used. `uicolor` values are expressed as color3 values in "none" colorspace, and thus are not affected by the current `colorspace`.
-
-All positioning and sizing attribute values are specified relative to an application's default size for drawing a node including any minimal-length connection edges and arrows. So a node drawn at position (xpos, ypos) will "look good" if connected to nodes drawn at position (xpos+width, ypos) and at position (xpos, ypos+height), and a node specifying `width="2"` would be drawn twice as wide (including outside whitespace for a minimal connecting arrow) as a node with the default width. It is not necessary that nodes be placed exactly on integer grid boundaries; this merely states the scale of nodes. It is also not assumed that the pixel scaling factors for X and Y are the same: the actual UI unit "grid" does not have to be square. If xpos and ypos are not both specified, placement of the node when drawn in a UI is undefined, and it is up to the application to figure out placement (which could mean "all piled up in the center in a tangled mess").
-
-MaterialX defines xpos values to be increasing left to right, ypos values to be increasing top to bottom, and the general flow is generally downward. E.g. node inputs are on the top and outputs on the bottom, and a node at (10, 10) could connect naturally to a node at (10, 11). Content creation applications using left-to-right flow can simply exchange X and Y coordinates in their internal representations when reading or writing MaterialX data, and applications that internally use Y coordinates increasing upward rather than downward can invert the Y coordinates between MTLX files and their internal representations.
-
-The <input> and <token> elements within <nodedef>s and node instantiations (but not within <implementation>s or <nodegraph> parameter interfaces) support the following UI-related attributes:
-
-
-
-* `uivisible` (boolean attribute): whether or not the input is visible in the UI. If `uivisible` is specified on an input/token in a <nodedef> that defines the default visibility of that input/token, while a `uivisible` specified on a input/token in a node instantiation affects just the visibility of the input/token within that particular instantiation. Default is "true".
-
-
-
-* `uiadvanced` (boolean attribute): whether or not the input is considered to be an "advanced" parameter which an application may choose to hide in a more "basic" mode. Should normally be declared only within a <nodedef>. Default is "false", meaning the input should be displayed if `uivisible` is true, while "true" means the input would be displayed if `uivisible` is true and the application UI is set to show "advanced" parameters.
-
-
-
-## Backdrop Elements
-
-Backdrop elements are used to contain, group, and document nodes within a node graph, and they have no impact on the functionality of the graph. The following attributes are supported by <backdrop> elements:
-
-* `contains` (stringarray attribute): a comma-separated list of node names that the backdrop "contains"; default is to contain no nodes.
-* `minimized` (boolean attribute): whether or not this backdrop is collapsed to a single node-sized box in the application's UI or not; default is false.
-
-Backdrop elements also support the standard `width`, `height`, `xpos`, `ypos` and `doc` attributes.
-
-
-
-
-## Node Graph Examples
-
-The following examples demonstrate how a MaterialX Document might encode graphs of nodes.
-
-
-#### Nodegraph Example 1
-
-A simple merge of two single-layer images with a separate mask image, followed by a simple color operation.
-
-
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-
-#### Nodegraph Example 2
-
-A more complex nodegraph using geometry properties to define two diffuse albedo colors and two masks, then color-correcting one albedo less red and more blue and increasing the contrast of the other, blending the two through an area mask, and adding a small amount of scaled 2D Perlin noise within a second mask. The graph outputs the area mask layer separately from the composited diffuse albedo color.
-
-
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-
-
-
-# Customization, Targeting and Shading
-
-While the Standard Nodes are considered universal across all MaterialX applications, there are many circumstances in which one would like to extend this with new custom functionality, or define functionality or underlying implementations specific to different applications or renderers. This includes the definition of nodes for shading and materials.
-
-
-## Target Definition
-
-MaterialX supports the definition of nodes, attributes and inputs that are specific to particular rendering "targets". This allows a single implementation to restrict certain values or nodes to only the targets for which they are valid, or to allow separate definitions of the same node functionality for different renderers.
-
-Targets are declared using a <targetdef> element:
-
-```xml
-
-
-
-```
-
-A target may inherit from another target, so that any reference to a parent target will automatically include any definitions specific to the inherited child target that do not have a definition for the parent target itself:
-
-```xml
-
-
-
-```
-
-In the above example, any renderer that requests nodes/inputs/attributes for the "osl" target will also see any node/input/attribute that is defined with `target="oslpattern"`. A renderer may also declare that it will accept implementations for multiple targets, e.g. Vray might declare it will accept either "vrayosl", "mdl" or "vrayglsl", with "vrayosl" preferred.
-
-A targetdef element may also specify additional custom attributes for that target, such as configuration or code generation options.
-
-
-## Custom Attributes and Inputs
-
-#### Custom Attributes
-
-While the MaterialX specification describes the attributes and elements that are meaningful to MaterialX-compliant applications, it is permissible to add custom attributes and inputs to standard MaterialX elements. These custom attributes and child elements are ignored by applications that do not understand them, although applications should preserve and re-output them with their values and connections even if they do not understand their meaning.
-
-If an application requires additional information related to any MaterialX element, it may define and utilize additional attributes with non-standard names. Custom attributes are defined using <attributedef> elements:
-
-
-```xml
-
-```
-
-where _name_ is a unique name for the attributedef, _attrname_ is the name of the custom attribute to define, _type_ is the type of the attribute (typically string, stringarray, integer or boolean, although any MaterialX type is allowed), _defaultvalue_ is the default value for the attribute, _target_ is an optional list of targets to which this attribute applies, and _elements_ is an optional list of element names or elementname/inputname in which the attribute may be used. It is also permissible to provide enum and enumvalues attributes for an attributedef, to define specific labels and values that the custom attribute is allowed to take, using the same syntax and limitations as enum/enumvalues on nodedef inputs and tokens (see below). By default, a custom attribute is not emitted as metadata in generated shaders, but can be exported if the `exportable` attribute is set to "true". Examples:
-
-```xml
-
-
-
-```
-
-The first example above defines a 3ds Max-specific name attribute for surface materials, which may be given a value in addition to its MaterialX-compliant name in order to preserve the original package-specific name; it is assumed here that `maxmtlname` is the attribute name used by that particular implementation for this purpose. The second example defines a "mystudio"-specific boolean attribute "vflip", which could be used in the "file" input of <image> nodes.
-
-Once defined, custom attributes may be used in exactly the same manner as standard attributes:
-
-```xml
-
-
-
-
-
- ...
-
-```
-
-
-#### Custom Inputs
-
-If an application requires additional custom inputs within a standard MaterialX node, it may define a target application-specific <nodedef> for that node inheriting the base input definitions from the standard node's <nodedef>, then add inputs specific to that target application.
-
-```xml
-
-
-
-```
-
-In the above example, a Maya-specific version of the color4-type <image> node has been declared, inheriting from the standard declaration then adding a maya-specific "preFilter" input.
-
-When using a node, the definition appropriate for the current target will automatically be used, and other targets will ignore any inputs that are not part of the nodedef for that target. However, one may specify a documentational `target` attribute on an input to hint what target it is intended for if desired. In this example, the "preFilter" input has indicated that it is specific to the "maya" target.
-
-```xml
-
-
-
-
-```
-
-
-## Custom Nodes
-
-Specific applications will commonly support sources and operators that do not map directly to standard MaterialX nodes. Individual implementations may provide their own custom nodes, with <nodedef> elements to declare their parameter interfaces, and <implementation> and/or <nodegraph> elements to define their behaviors.
-
-
-### Custom Node Declaration NodeDef Elements
-
-Each custom node must be explicitly declared with a <nodedef> element, with child <input>, <token> and <output> elements specifying the expected names and types of the node’s ports.
-
-Attributes for <nodedef> elements:
-
-* `name` (string, required): a unique name for this <nodedef>
-* `node` (string, required): the name of the custom node being defined
-* `inherit` (string, optional): the `name` of a <nodedef> to inherit node definitions from; the output types of this nodedef and the inherited one must match, and the input/output definitions of this nodedef will be applied on top of those in the inherited-from one.
-* `nodegroup` (string, optional): an optional group to which this node declaration belongs. Standard MaterialX nodes have `nodegroup` values matching the titles of the section headings in which they are described, e.g. "texture2d", "procedural", "geometric", "application", "math", "adjustment", "compositing", "conditional", "channel", "convolution", or "organization".
-* `version` (string, optional): a version string for this nodedef, allowing usage of a node to reference a specific version of a node. Version strings should be of the format "_major_[._minor_]", i.e. one or two integer numbers separated by a dot (the minor version is assumed to be "0" if not provided). If there are multiple nodedefs for the same `node` and `target` with the same combination of input and output types, they must each specify a `version`.
-* `isdefaultversion` (boolean, optional): If true, then this nodedef should be used for node instances which do not request a specific version. Specifying `isdefaultversion` "true" is only required if there are multiple nodedefs for a node declaring a `version`, and it is not permissible for multiple nodedefs for the same `node` and `target` with the same combination of input and output types to set `isdefaultversion` "true". Defaults to "false".
-* `target` (stringarray, optional): the set of targets to which this nodedef is restricted. By default, a nodedef is considered universal, not restricted to any specific targets, but it is possible that certain targets may have different parameter names or usage for the same node.
-* `uiname` (string, optional): an alternative "node" value for this nodedef to be displayed in the UI. If `uiname` is not provided, then `node` is the presumed UI node value for the nodedef. This is most useful when the <nodedef> defines a namespace, so the user doesn't need to see a full namespaced path for the node.
-* `internalgeomprops` (stringarray, optional): a list of MaterialX geometric properties (e.g. "position", "normal", "texcoord", etc. or any name defined by a <geompropdef> element) that the node expects to be able to access internally. This metadata hint allows code generators to ensure this data is available and can be used for error checking. `Internalgeomprops` is most useful for nodes whose implementation is defined by external code; it is not necessary for nodegraph-defined nodes, as the list of geometric properties accessed can be determined by examining the nodegraph.
-
-Custom nodes are allowed to overload a single `node` name by providing multiple <nodedef> elements with different combinations of input and output types. This overloading is permitted both for custom `node` names and for the standard MaterialX node set. Within the scope of a single MaterialX document and its included content, no two <nodedef> elements with an identical combination of input and output types for the same target and version may be provided for a single `node` name. It is recommended that all <nodedef> variations for a `node` use exactly the same set of input names differing only in their types, with no variation adding or removing any inputs. It is also recommended that newer versions of nodes be fully backward-compatible with earlier versions (including default values of input) so that a change in default version of a node does not break functionality; if this is not possible, using a different `node` name is recommended.
-
-The `inherit` attribute may be provided to allow one <nodedef> to inherit from another: this is most useful for defining additional inputs in a target- or version-specific <nodedef>, inheriting from a generic, canonical definition of a node or shader. NodeDefs which inherit from another nodedef may not re-declare <output>s from the parent nodedef, only add additional new <output>s.
-
-NodeDefs must define one or more child <output> elements within the <nodedef> to state the name and type of each output; for nodes defined using a nodegraph, the names and types of the outputs must agree with the <output> elements in the nodegraph. The output name for a single-output <nodedef> is less important, as any connection made to the output of a single-output node will succeed regardless of the actual `name` referenced, although by convention, the name "out" is preferred for single-output nodes. See the [**NodeDef Output Elements**](#nodedef-output-elements) section below for details.
-
-
-#### NodeDef Parameter Interface
-
-The parameter interface of a custom node is specified via a set of child <input> and <token> elements of the <nodedef>, while documentation of the folder structure of a node may be defined using a number of <uifolder> elements, each of which may provide a doc attribute to provide documentation for that folder layer. A <uifolder> element may not contain any other elements; in particular, the <input>s and <token>s of the nodedef interface must be direct children of the <nodedef>. Nested folders may be indicated using a full path for the folder, with a "/" separator between folder levels.
-
-```xml
-
-
-
-
- ...input and token definitions...
-
-```
-
-
-#### NodeDef Input Elements
-
-**Input** elements are used within a <nodedef> to declare the spatially-varying and uniform inputs for a node:
-
-```xml
-
-```
-
-Attributes for NodeDef Input elements:
-
-* `name` (string, required): the name of the shader input
-* `type` (string, required): the MaterialX type of the shader input
-* `value` (same type as `type`, optional): a default value for this input, to be used if the input remains unconnected and is not otherwise assigned a value
-* `uniform` (boolean, optional): if set to "true", then this input can only take uniform values and may only be connected to the outputs of <constant> nodes or any other node whose output is explicitly declared to be "uniform" (optionally through a number of <dot> nodes), but not to the outputs of other (non-"uniform") nodes. `uniform` must be set to true for string and filename-type inputs.
-* `defaultgeomprop` (string, optional): for vector2 or vector3 inputs, the name of an intrinsic geometric property that provides the default value for this input, must be one of "position", "normal", "tangent", "bitangent" or "texcoord" or vector3-type custom geometric property for vector3 inputs, or "texcoord" or vector2-type custom geometric property for vector2 inputs. For standard geometric properties, this is effectively the same as declaring a default connection of the input to a Geometric Node with default input values. May not be specified on uniform inputs.
-* `enum` (stringarray, optional): a comma-separated non-exclusive list of string value descriptors that the input couldmayis allowed to take: for string- and stringarray-type inputs, these are the actual values (or values per array index for stringarrays); for other types, these are the "enum" labels e.g. as shown in the application user interface for each of the actual underlying values specified by `enumvalues`. The enum list can be thought of as a list of commonly used values or UI labels for the input rather than a strict list, and MaterialX itself does not enforce that a specified input enum value is actually in this list, with the exception that if the input is a "string" (or "stringarray") type and an enum list is provided, then the value(s) must in fact be one of the enum stringarray values.
-* `enumvalues` (typearray, optional): for non-string/stringarray types, a comma-separated list of values of the same base type as the <input>, representing the values that would be used if the corresponding `enum` string was chosen in the UI. MaterialX itself does not enforce that a specified input value is actually in this list. Note that implementations are allowed to redefine `enumvalues` (but not `enum`) for specific targets: see the [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements) section below.
-* `colorspace` (string, optional): for color3- or color4-type inputs, the colorspace of the default value for this input.
-* `unittype` (string, optional): the type of unit for this input, e.g. "distance", which must be defined by a <unittypedef>. Default is to not specify a unittype. Only float-, vectorN- and filename-type inputs may specify a `unittype`.
-* `unit` (string, optional): the specific unit for this input. Nodedef inputs do not typically specify a unit; if it does, that would indicate that the implementation of that node expects values to be specified in that unit, and that any invocation of that node using a different unit should be converted to the nodedef-specified unit for that input rather than to the application's scene unit. The most common instance of this is for angular values, where a nodedef might specify that it expects values to be given in degrees.
-* `uiname` (string, optional): an alternative name for this input as it appears in the UI. If `uiname` is not provided, then `name` is the presumed UI name for the input.
-* `uifolder` (attribute, string, optional): the pathed name of the folder in which this input appears in the UI, using a "/" character as a separator for nested UI folders.
-* `uimin` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the minimum value that the UI allows for this particular value. MaterialX itself does not enforce this as an actual minimum value.
-* `uimax` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the maximum value that the UI allows for this particular value. MaterialX itself does not enforce this as an actual maximum value.
-* `uisoftmin` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, a suggested minimum UI slider value for this input, should be >= `uimin`. MaterialX itself does not enforce this as an actual minimum value.
-* `uisoftmax` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, a suggested maximum UI slider value for this inputs, should be <= `uimax`. MaterialX itself does not enforce this as an actual maximum value.
-* `uistep` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the increment size that the UI would increment or decrement a component of the input value.
-* `hint` (string): A hint to help code generators understand how the input may be used. The following hints for nodedef inputs are currently defined:
- * "transparency": the input is indicating a level of shading transparency.
- * "opacity": the input is indicating a level of shading opacity (inverse of transparency).
- * "anisotropy": the presence of this hint on an input indicates that anisotropic reflections _may_ (but not necessarily) be taking place; if no input on a shading node(def) defines an "anisotropic" hint, then some implementations may use this as an optimization to allow only isotropic reflections.
-
-It is permissible to define a `value` or a `defaultgeomprop` for an input but not both. If neither `value` or `defaultgeomprop` are defined, then the input becomes required, and any invocation of the custom node without providing a value or connection for this input would be in error.
-
-
-#### NodeDef Token Elements
-
-**Token** elements are used within a <nodedef> to declare uniform "interface token" string-substitution values to be referenced and substituted within filenames used in a node's nodegraph implementation:
-
-```xml
-
-```
-
-Attributes for NodeDef Token elements:
-
-* `name` (string, required): the name of the token
-* `type` (string, required): the MaterialX type of the token; when the token's value is substituted into a filename, the token value will be cast to a string, so string or integer types are recommended for tokens, although any MaterialX type is permitted.
-* `value` (same type as `type`, optional): a default value for this token, to be used if the node is invoked without a value defined for this token. If a default value is not defined, then the token becomes required, so any invocation of the custom node without a value assigned to that token would be in error.
-* `enum` (stringarray, optional): a comma-separated non-exclusive list of string value descriptors that the token could take: for string-type tokens, these are the actual values; for other types, these are the "enum" labels e.g. as shown in the application user interface for each of the actual underlying values specified by enumvalues. The enum list can be thought of as a list of commonly used values or UI labels for the input rather than a strict list, and MaterialX itself does not enforce that a specified token enum value is actually in this list, with the exception that if the input is a "string" (or "stringarray") type and an enum list is provided, then the value(s) must in fact be one of the enum stringarray values.
-* `enumvalues` (typearray, optional): for non-string types, a comma-separated list of values of the same base type as the <token>, representing the values that would be used if the corresponding enum string was chosen in the UI. MaterialX itself does not enforce that a specified token value is actually in this list. Note that implementations are allowed to redefine enumvalues (but not enum) for specific targets: see the [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements) section below.
-* `uiname` (string, optional): an alternative name for this token as it appears in the UI. If `uiname` is not provided, then `name` is the presumed UI name for the token.
-* `uifolder` (string, optional): the pathed name of the folder in which this token appears in the UI, using a "/" character as a separator for nested UI folders.
-
-Please see the [Example Pre-Shader Compositing Material](#example-pre-shader-compositing-material) in the [Material Nodes](#material-nodes) section below for an example of how Tokens are used.
-
-
-#### NodeDef Output Elements
-
-**Output** elements are used within a <nodedef> to declare an output for node definitions, including the output's name, type, and default value or "defaultinput" connection:
-
-```xml
-
-```
-
-Attributes for NodeDef Output elements:
-
-* `name` (string, required): the name of the output. For nodes with a single output, the name "out" is preferred.
-* `type` (string, required): the MaterialX type of the output.
-* `defaultinput` (string, optional): the name of an <input> element within the <nodedef>, which must be the same type as `type`, that will be passed through unmodified by applications that don’t have an implementation for this node.
-* `default` (same type as `type`, optional): a constant value which will be output by applications that don’t have an implementation for this node, or if a `defaultinput` input is specified but that input is not connected.
-
-The <output> elements for NodeDefs are similar to those for NodeGraph outputs, except that they may define default output values for the node but may not define a connection to another node (except for the `defaultinput` pass-through connection declaration) or any output file-related attributes such as width, height, colorspace or bitdepth.
-
-
-
-### Custom Node Definition Using Implementation Elements
-
-Once the parameter interface of a custom node has been declared through a <nodedef>, MaterialX provides two methods for precisely defining its functionality: via an <implementation> element that references external source code, or via a <nodegraph> element that composes the required functionality from existing nodes. Providing a definition for a custom node is optional in MaterialX, but is recommended for maximum clarity and portability.
-
-**Implementation** elements are used to associate external function source code with a specific nodedef. Implementation elements support the following attributes:
-
-* `name` (string, required): a unique name for this <implementation>
-* `nodedef` (string, required): the name of the <nodedef> for which this <implementation> applies
-* `nodegraph` (string, optional): the name of the <nodegraph> which is the implementation for the specified nodedef; see the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section below.
-* `implname` (string, optional): an alternative name for this node for the specified target; this allows one to say that for this particular target, the node/shader is called something else but is functionally equivalent to the node described by the nodedef. Note that node graphs in MaterialX documents should always use the node names defined in the nodedefs, never implementation-specific names.
-* `file` (filename, optional): the URI of an external file containing the source code for the entry point of this particular node template. This file may contain source code for other templates of the same custom node, and/or for other custom nodes.
-* `sourcecode` (string, optional): a string containing the actual source code for the node.
-* `function` (string, optional): the name of a function within the given source code that contains the implementation of this node. If this attribute is not given it is assumed the source code is an inline expression for a shader code generator like ShaderGen. Please refer to appropriate language specifications and developer guides (such as the ShaderGeneration.md file in the GitHub documents/DeveloperGuide directory) for valid syntax for using inline code.
-* `target` (stringarray, optional): the set of targets to which this implementation is restricted. By default, an implementation is considered applicable to all targets that the referenced nodedef applies to. If the referenced <nodedef> also specifies a target, then this `target` must be a subset of the nodedef's target list.
-* `format` (string, optional): the format used by the given source code, typically "shader" if the source code is a complete shader that can be compiled and executed as is by a target renderer, or "fragment" if the source code is a code fragment that requires processing of a code generator before it can be compiled and executed. Default is "shader".
-
-An <implementation> may define a `file` or `sourcecode` attribute, or neither, but not both. If an <implementation> element specifies a `target` with no `file` or `sourcecode`, then it is interpreted purely as documentation that a private definition exists for the given target. Because the definition in an <implementation> may be restricted to specific targets, a <nodedef> that is defined with such restrictions may not be available in all applications; for this reason, a <nodedef> that is defined through an <implementation> is expected to provide a value for `default` and/or `defaultinput` when possible, specifying the expected behavior when no definition for the given node can be found. It should be noted that specifying `target` is intended to help applications differentiate between different implementations of nodes and implies compatibility for specific situations, but does not necessarily guarantee compatibility: they are intended to be hints about the particular implementation, and it is up to the host application to determine which <implementation>, if any, is appropriate for any particular use.
-
-Because the names used for node inputs (such as "normal" or "default") may conflict with the reserved words in various shading languages, or may simply be different for specific targets, <implementation> elements may contain a number of <input> elements to remap the `name`s of <input>s as specified in the <nodedef> to different `implname`s to indicate what the input name is actually called in the implementation's code. Only the inputs that need to be remapped to new `implname`s need to be listed; for each, it is recommended that the `type` of that input be listed for clarity, but if specified, it must match the type specified in the <nodedef>: <implementation>s are not allowed to change the type or any other attribute defined in the <nodedef>. In this example, the <implementation> declares that the "default" input defined in the "ND_image_color3" nodedef is actually called "default_value" in the "mx_image_color" function:
-
-```xml
-
-
-
-```
-
-For uniform inputs and tokens whose nodedef description includes an enum list of allowable values, individual implementations may associate different target-specific resolved values for them potentially of a different type; these may be described by providing an `enumvalues` attribute on the uniform input or token within an <implementation> and if appropriate, an `impltype` to declare the target-specific type of these enumvalues. Note that if the type of an enum input in the nodedef is an array type, then the `impltype` (if specified) must also be an array type, while `enumvalues` is a list of values of the base (non-array) type. The following <implementation> states that for the "mystudio" target, the uaddressmode and vaddressmode inputs of the "image" node are actually called "extrapolate_u" and "extrapolate_v", are integers rather than strings, and take different values (e.g. "clamp" is 2):
-
-```xml
-
-
-
-
-
-```
-
-
-#### Example Custom Nodes Defined by External File Implementations
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-This example defines two templates for a custom operator node called "mariBlend" (one operating on color3 values, and one operating on floats), and one template for a custom source node called "mariCustomNoise". Implementations of these functions have been defined in both OSL and GLSL. There is also in this example an alternate implementation of the "mariCustomNoise" function specifically for VRay, as if the author had determined that the generic OSL version was not appropriate for that renderer.
-
-Here is an example of a two-output node definition and external implementation declaration.
-
-```xml
-
-
-
-
-
-
-
-```
-
-
-
-### Custom Node Definition Using Node Graphs
-
-Alternatively, a custom node's implementation may be described using a Node Graph. A <nodegraph> element wraps a graph of standard or custom nodes, taking the inputs and producing the output(s) described in the specified <nodedef>.
-
-A **<nodegraph>** element consists of at least one node element and at least one <output> element contained within a <nodegraph> element. Nodegraph elements may be one of two types: a **functional nodegraph**, which is the implementation of a node defined by a separate <nodedef>, or a **compound nodegraph**, which is a set of nodes grouped together into a nodegraph container. A functional nodegraph must either itself specify a `nodedef` attribute or be referenced by an <implementation> element with a "nodegraph" attribute, while a compound nodegraph may do neither but may optionally specify one or more <input> and/or <token> elements.
-
-
-#### Functional Nodegraphs
-
-A **functional nodegraph** is a nodegraph-based implementation for a specified <nodedef>, with the <nodedef> declaring the set of inputs that the nodegraph accepts: a functional nodegraph may not itself specify any direct child input elements.
-
-```xml
-
- ...node element(s)...
- ...output element(s)...
-
-```
-
-or
-
-```xml
-
- ...node element(s)...
- ...output element(s)...
-
-
-```
-
-The type(s) of the <output>(s) of the <nodedef> and the type(s) of the nodegraph <output>(s) must agree, and if there are multiple outputs, then the `name`s of the <output>s in the <nodegraph> and <nodedef> must also agree. The inputs and tokens of the <nodedef> can be referenced within <input> and <token> elements of nodes within the nodegraph implementation using `interfacename` attributes in place of `value` or `nodename` attributes, e.g. a nodedef input "i2" and interface token "diffmap" could be referenced as follows:
-
-```xml
-
-
-```
-
-Note that a uniform <input> of a node within the nodegraph may use `interfacename` to reference a uniform input in the nodedef, but it may not reference a non-uniform nodedef input.
-
-
-#### Compound Nodegraphs
-
-A **compound <nodegraph>** element may specify one or more child <input> and/or <token> elements. In this case, the <nodegraph> functions as a collapsible "wrapper" for the contained nodes.
-
-```xml
-
- [...input and/or token element(s)...]
- ...node and/or (compound) nodegraph element(s)...
- ...output element(s)...
-
-```
-
-A compound nodegraph provides a set of named input and output connection ports which may be referenced by its contained nodes using `interfacename` attributes, and interface token names whose values may be substituted into filenames used within the nodegraph; nodes within this <nodegraph> adopt the context of that nodegraph. The <input>s and <token>s of a compound nodegraph may also be connected to other nodes outside the <nodegraph> at the same scope as the <nodegraph> itself using `nodename` attributes; inputs of nodes within a compound nodegraph may only be connected to the outputs of other nodes within the same compound nodegraph, or to the input connection ports using interfacename. This is in contrast to a <backdrop> node whose contained nodes connect directly to nodes outside the backdrop at the same level of context without going through an intermediate named <input>. A <nodegraph> element of this form may specify the same float `width` and `height` and boolean `minimized` attributes as <backdrop> nodes. Inputs of other nodes, or the inputs of a compound nodegraph, can connect to an output of a (different) compound nodegraph using a `nodegraph` attribute (and for multiple-output compound nodegraphs, an `output` attribute as well) on a node's <input>.
-
-It is permissible to define multiple nodegraph- and/or file-based implementations for a custom node for the same combination of input and output types, as long as the specified `version`/`target`/`format` combinations are unique, e.g. one implementation for target "oslpattern" and another for "glsl", or one "osl" target with `format="shader"` and another with `format="fragment"`. It is allowable for there to be both a <nodegraph> and an <implementation> for the same nodedef target/version, with the <implementation> generally prevailing in order to allow for optimized native-code node implementations, although ultimately it would be up to the host application to determine which implementation to actually use.
-
-
-#### Example Custom Node Defined by a Nodegraph
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-The inputs of the nodegraph are declared by the <nodedef>, and the nodes within the nodegraph reference those inputs using `interfacename` attributes. The "fg" and "bg" inputs provide default values which are used if an input is left unconnected when the custom node is used, and the "amount" input defines a default value which will be used if invocations of the node do not explicitly provide a value for "amount".
-
-
-### Custom Node Use
-
-Once defined with a <nodedef>, using a custom node within a node graph follows the same syntax as any other standard node: the name of the element is the name of the custom node, and the MaterialX type of the node's output is required; the custom node's child elements define connections of inputs to other node outputs as well as any input values for the custom node.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-```
-
-When invoking nodes with multiple outputs, the `type` of the node should be declared as "multioutput", and other node inputs connecting to an output of the node must include an `output` attribute to specify which output of the node to connect to:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-
-
-## Shader Nodes
-
-Custom nodes that output data types with a "shader" semantic are referred to in MaterialX as "Shader Nodes". Shaders, along with their inputs, are declared using the same <nodedef>, <implementation> and <nodegraph> elements described above:
-
-```xml
-
- ...input declarations...
-
-
-```
-
-The attributes for <nodedef> elements as they pertain to the declaration of shaders are:
-
-* `name` (string, required): a user-chosen name for this shader node definition element.
-* `node` (string, required): the name of the shader node being defined, which typically matches the name of an associated shader function such as “blinn_phong”, “disney_principled”, “volumecloud_vol”. Just as for custom nodes, this shading program may be defined precisely through an <implementation> or <nodegraph>, or left to the application to locate by name using any shader definition method that it chooses.
-
-The child <output> element within the <nodedef> defines the "data type" of the output for this shader, which must have been defined with a "shader" semantic; see the [Custom Data Types](#custom-data-types) section above and discussion below for details.
-
-NodeDef elements defining shader nodes do not typically include `default` or `defaultinput` attributes, though they are permitted using the syntax described in the [Custom Data Types](#custom-data-types) section if the output type of the shader node is not a blind data type.
-
-As mentioned in the [Custom Data Types](#custom-data-types) section earlier, the standard MaterialX distribution includes the following standard data types for shaders:
-
-```xml
-
-
-
-
-```
-
-These types all declare that they have "shader" semantic, but define different contexts in which a rendering target should interpret the output of the shader node. For a shading language based on deferred lighting computations (e.g. OSL), a shader-semantic data type is equivalent to a radiance closure. For a shading language based on in-line lighting computations (e.g. GLSL), a shader-semantic data type is equivalent to the final output values of the shader.
-
-Instantiation of shader nodes to give them specific values is done the same way as instantiating any other node type:
-
-```xml
-
-
-
-
-
-```
-
-Instantiated shader nodes can also inherit from other shader nodes of the same class:
-
-```xml
-
-
-
-```
-
-Declarations of shader node source implementations are accomplished using either <implementation> elements for external source file declarations, or functional nodegraphs for nodegraph-based definitions.
-
-As with non-shader custom nodes, **Input** elements are used within a <nodedef> to declare the input ports for a shader node.
-
-An input with a shader-semantic type may be given a value of "" to indicate no shader node is connected to this input; this is typically the default for shader-semantic inputs of operator nodes. It is up to applications to decide what to do with unconnected shader-semantic inputs.
-
-Please refer to [**Standard Shader Nodes**](./MaterialX.StandardNodes.md#standard-shader-nodes), [**Physically-Based Shading Nodes**](./MaterialX.PBRSpec.md) and [**NPR Shading Nodes**](./MaterialX.NPRSpec.md) for descriptions of Shader Nodes defined by MaterialX.
-
-
-
-## Material Nodes
-
-Custom nodes that output data types with a "material" semantic are referred to in MaterialX as "Material Nodes". Material nodes typically have one or more "shader" semantic inputs which establish what shaders the material references; previous versions of MaterialX used <shaderref> elements to establish these shader-to-material connections. Material Nodes are declared using the same <nodedef> elements as described above:
-
-```xml
-
-
- ...additional shader or input declarations...
-
-
-```
-
-The attributes for <nodedef> elements as they pertain to the declaration of materials are:
-
-* `name` (string, required): a user-chosen name for this material node definition element.
-* `node` (string, required): the name of the material node class being defined.
-
-The standard MaterialX distribution includes a single material type definition used as the output type for all material nodes:
-
-```xml
-
-```
-
-as well as definitions for three standard material nodes, all outputting type "material":
-
-
-
-* **`surfacematerial`**: a surface shading material.
- * `surfaceshader` (surfaceshader): the name of the surfaceshader node.
- * `backsurfaceshader` (surfaceshader): the name of the surfaceshader node to be used for the back surface of an object, if the geometry is two-sided. Default is "", meaning the `surfaceshader` shader will be used for both sides of a surface if the geometry is two-sided.
- * `displacementshader` (displacementshader): the name of the displacementshader node to use; default is "" for no displacement.
-
-
-
-* **`volumematerial`**: a volume shading material.
- * `volumeshader` (volumeshader): the name of the volumeshader node.
-
-
-
-* **`lightmaterial`**: a light shader material.
- * `lightshader` (lightshader): the name of the lightshader node.
-
-Material nodes supporting multiple shaders of the same type for different rendering targets can be defined:
-
-```xml
-
-
-
-
-
-
-
-
-```
-
-Creating materials with specific values bound to shader inputs involves instantiating a Shader Node for each desired shader type and setting values on those shader nodes, and connecting the shader node(s) to the inputs of a Material Node:
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-```
-
-Alternatively, and perhaps more usefully, a complete network of multiple shader nodes of different types or for different targets along with a material node to collect them all can be packaged within a nodegraph, and the various inputs of the shader nodes and any other nodes connected to their inputs can be connected to a single material nodedef interface to provide parameter values for the entire multi-shader network. Because nodedef inputs can be referenced by more than one node, a single unified interface could be created for several shaders for different targets, and the networks for those targets could contain input value conversion nodes as needed to handle differences in parametrization or shading methodologies.
-
-
-#### Example Pre-Shader Compositing Material
-
-A material to blend between three different surface layers using mask textures. This example also demonstrates the use of the "target" attribute of a shader implementation element to define multiple renderer-specific shaders of the same type referenced within a single material, and the use of interface tokens to define texture filenames.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-
-## Material Variants
-
-A Variant is a container for any number of uniform values for material inputs and interface tokens. One or more mutually-exclusive variants are defined as part of a <variantset>; variants may not be defined outside of a <variantset>.
-
-```xml
-
-
-
-
-
-
- ...additional declarations for this variantset...
-
-```
-
-<Input> elements within a <variant> may only define a `value`, not a connection to a node or <output>.
-
-Example uses for variants include defining a number of allowable colors and texture tokens for different costume variations, and defining values for progressively increasing levels of damage to a model.
-
-Variants and variantsets are not intrinsically associated with any particular material; they merely state a number of values for a number of named inputs/tokens. However, variantsets may state that they are associated with specific shader-semantic nodes and/or <nodedef> declarations by providing stringarray-type `node` and/or `nodedef` attributes:
-
-```xml
-
- ...
-```
-
-Variants and variantsets can be defined in any MaterialX implementation, but because variants are applied to materials within a <look>, they can only be applied in applications supporting MaterialX Geometry Extensions; please see the [**VariantAssign Elements**](./MaterialX.GeomExts.md#variantassign-elements) section in that document for information on using material variants.
-
-
-
-
-# References
-
-[^1]:
-
+
+
+
+# MaterialX: An Open Standard for Network-Based CG Object Looks
+
+**Version 1.39**
+Doug Smythe - Industrial Light & Magic
+Jonathan Stone - Lucasfilm Advanced Development Group
+July 26, 2024
+
+
+# Introduction
+
+Computer graphics production studios commonly 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 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 now using more flexible node-based shader networks built up by connecting images and procedurals to shader inputs through a graph of image processing and blending operators.
+
+At least four distinct interrelated data relationships are required to specify the complete "look" of a CG object:
+
+1. _Image processing networks_ of sources, operators, connections and input values, outputting a number of spatially-varying data streams.
+2. _Geometry-specific information_ such as associated texture filenames or IDs for various map types.
+3. Associations between spatially-varying data streams and/or uniform values and the inputs of surface, volume, or other shaders, defining a number of _materials_.
+4. Associations between materials and specific geometries to create a number of _looks_.
+
+**MaterialX** addresses the need for an open, platform-independent, well-defined standard for specifying the "look" of computer graphics objects built using node networks by defining a material content schema along with a corresponding XML-based file format to read and write MaterialX content. The MaterialX schema defines a number of primary element types plus several supplemental and sub-element types, as well as a set of **standard nodes** with specific functionality for defining data-processing graphs, shaders and materials.
+
+This document describes the core MaterialX specification. Companion documents [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md), [**MaterialX Geometry Extensions**](./MaterialX.GeomExts.md) and [**MaterialX Supplemental Notes**](./MaterialX.Supplement.md) describe additional node and element types and other information about the library, while [**MaterialX: Proposed Additions and Changes**](./MaterialX.Proposals.md) describes forward-looking proposed funnctionality for MaterialX.
+
+
+
+## Table of Contents
+
+**[Introduction](#introduction)**
+
+**[MaterialX Overview](#materialx-overview)**
+ [Definitions](#definitions)
+ [MaterialX Names](#materialx-names)
+ [MaterialX Data Types](#materialx-data-types)
+ [Custom Data Types](#custom-data-types)
+ [MTLX File Format Definition](#mtlx-file-format-definition)
+ [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems)
+ [Units](#units)
+ [MaterialX Namespaces](#materialx-namespaces)
+ [Geometric Properties](#geometric-properties)
+ [File Prefixes](#file-prefixes)
+ [Filename Substitutions](#filename-substitutions)
+
+**[Nodes](#nodes)**
+ [Inputs](#inputs)
+ [Node Graph Elements](#node-graph-elements)
+ [Output Elements](#output-elements)
+
+ [Standard Source Nodes](#standard-source-nodes)
+ [Texture Nodes](#texture-nodes)
+ [Procedural Nodes](#procedural-nodes)
+ [Noise Nodes](#noise-nodes)
+ [Shape Nodes](#shape-nodes)
+ [Geometric Nodes](#geometric-nodes)
+ [Application Nodes](#application-nodes)
+
+ [Standard Operator Nodes](#standard-operator-nodes)
+ [Math Nodes](#math-nodes)
+ [Logical Operator Nodes](#logical-operator-nodes)
+ [Adjustment Nodes](#adjustment-nodes)
+ [Compositing Nodes](#compositing-nodes)
+ [Conditional Nodes](#conditional-nodes)
+ [Channel Nodes](#channel-nodes)
+ [Convolution Nodes](#convolution-nodes)
+
+ [Standard Node Inputs](#standard-node-inputs)
+ [Standard UI Attributes](#standard-ui-attributes)
+ [Backdrop Elements](#backdrop-elements)
+ [Node Graph Examples](#node-graph-examples)
+
+**[Customization, Targeting and Shading](#customization-targeting-and-shading)**
+ [Target Definition](#target-definition)
+ [Custom Attributes and Inputs](#custom-attributes-and-inputs)
+
+ [Custom Nodes](#custom-nodes)
+ [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements)
+ [NodeDef Parameter Interface](#nodedef-parameter-interface)
+ [NodeDef Input Elements](#nodedef-input-elements)
+ [NodeDef Token Elements](#nodedef-token-elements)
+ [NodeDef Output Elements](#nodedef-output-elements)
+ [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements)
+ [Example Custom Nodes Defined by External File Implementations](#example-custom-nodes-defined-by-external-file-implementations)
+ [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs)
+ [Functional Nodegraphs](#functional-nodegraphs)
+ [Compound Nodegraphs](#compound-nodegraphs)
+ [Example Custom Node Defined by a Nodegraph](#example-custom-node-defined-by-a-nodegraph)
+ [Custom Node Use](#custom-node-use)
+ [Shader Nodes](#shader-nodes)
+ [Standard Library Shader Nodes](#standard-library-shader-nodes)
+ [Material Nodes](#material-nodes)
+ [Example Pre-Shader Compositing Material](#example-pre-shader-compositing-material)
+ [Material Variants](#material-variants)
+
+**[References](#references)**
+
+
+# MaterialX Overview
+
+The diagram below gives a high-level overview of a typical MaterialX look definition. A directed acyclic graph of pattern generation and processing nodes is connected to inputs of a surface Shader which defines a layered BSDF response. One or more shaders can be connected to form a Material, which is ultimately associated with specific scene geometry via a MaterialAssign, a number of which comprise a Look. The assignments of Materials to geometries can be defined within a MaterialX document in applications supporting MaterialX Geometry Extensions, or using an alternative mechanism such as USD[^1] or a native application's toolset. Each of the pattern nodes and even the Shaders may in turn be implemented using a graph of nodes: these NodeGraphs are given a parameter interface using NodeDefs, and these implementations may be reused with different input values just like any other Standard node defined by MaterialX.
+
+
+
+MaterialX also allows the specification of additional information not shown in this diagram, such as geometry-specific properties, material variations, arbitrary custom inputs and attributes for nodes, rendering-target-specific versions of shaders, nodes and implementations, external compiled or generated shader implementations, and much more.
+
+
+
+## Definitions
+
+Because the same word can be used to mean slightly different things in different contexts, and because each studio and package has its own vocabulary, it's important to define exactly what we mean by any particular term in this proposal and use each term consistently.
+
+An **Element** is a named object within a MaterialX document, which may possess any number of child elements and attributes. An **Attribute** is a named property of a MaterialX element.
+
+A **Node** is a function that generates or operates upon spatially-varying data. This specification provides a set of standard nodes with precise definitions, and also supports the creation of custom nodes for application-specific uses. The interface for a node’s incoming data is declared through **Inputs**, which may be spatially-varying or uniform, and **Tokens**, which are string values that can be substituted into filenames declared in node inputs.
+
+A **Pattern** is a node that generates or processes simple scalar, vector, and color data, and has access to local properties of any geometry that has been bound.
+
+A **Shader** is a node that can generate or process arbitrary lighting or BSDF data, and has access to global properties of the scene in which it is evaluated.
+
+A **Material** is a node which internally or externally references one or more shaders with specific data streams or uniform values bound to their inputs.
+
+A **Node Graph** is a directed acyclic graph of nodes, which may be used to define arbitrarily complex generation or processing networks. Common uses of Node Graphs are to describe a network of pattern nodes flowing into shader inputs, or to define a complex or layered node in terms of simpler nodes.
+
+A **Stream** refers to a flow of spatially-varying data from one node to another. A Stream most commonly consists of color, vector, or scalar data, but can transport data of any standard or custom type.
+
+A **Layer** is a named 1-, 2-, 3- or 4-channel color "plane" within an image file. Image file formats that do not support multiple or named layers within a file should be treated as if the (single) layer was named "rgba".
+
+A **Channel** is a single float value within a color or vector value, e.g. each layer of an image might have a red Channel, a green Channel, a blue Channel and an alpha Channel.
+
+A **Geometry** is any renderable object, while a **Partition** refers to a specific named renderable subset of a piece of geometry, such as a face set.
+
+A **Collection** is a recipe for building a list of geometries, which can be used as a shorthand for assigning e.g. a Material to a number of geometries in a Look.
+
+A **Target** is a software environment that interprets MaterialX content to generate images, with common examples being digital content creation tools and 3D renderers.
+
+
+
+## MaterialX Names
+
+All elements in MaterialX (nodes, materials, shaders, etc.) are required to have a `name` attribute of type "string". The `name` attribute of a MaterialX element is its unique identifier, and no two elements within the same scope (i.e. elements with the same parent) may share a name.
+
+Element names are restricted to upper- and lower-case letters, numbers, and underscores (“_”) from the ASCII character set; all other characters and symbols are disallowed. MaterialX names are case-sensitive and are not allowed to begin with a digit.
+
+
+
+## MaterialX Data Types
+
+All values, input and output ports, and streams in MaterialX are strongly typed, and are explicitly associated with a specific data type. The following standard data types are defined by MaterialX:
+
+**Base Types**:
+
+```
+ integer, boolean, float,
+ color3, color4,
+ vector2, vector3, vector4,
+ matrix33, matrix44, string, filename
+```
+
+**Array Types**:
+
+```
+ integerarray, floatarray,
+ color3array, color4array,
+ vector2array, vector3array, vector4array,
+ stringarray
+```
+
+
+The following examples show the appropriate syntax for MaterialX attributes in MTLX files:
+
+**Integer**, **Float**: just a value inside quotes:
+
+```
+ integervalue = "1"
+ floatvalue = "1.0"
+```
+
+**Boolean**: the lower-case word "true" or "false" inside quotes:
+
+```
+ booleanvalue = "true"
+```
+
+**Color** types: MaterialX supports two different color types:
+
+* color3 (red, green, blue)
+* color4 (red, green, blue, alpha)
+
+Color channel values should be separated by commas (with or without whitespace), within quotes:
+
+```
+ color3value = "0.1,0.2,0.3"
+ color4value = "0.1,0.2,0.3,1.0"
+```
+
+Note: all color3 values and the RGB components of a color4 value are presumed to be specified in the "working color space" defined in the enclosing <materialx> element, although any element within a document may provide a `colorspace` attribute that explicitly states the space in which color values within its scope should be interpreted; implementations are expected to translate those color values into the working color space before performing computations with those values. See the [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems) section below.
+
+**Vector** types: similar to colors, MaterialX supports three different vector types:
+
+* vector2 (x, y)
+* vector3 (x, y, z)
+* vector4 (x, y, z, w)
+
+Coordinate values should be separated by commas (with or without whitespace), within quotes:
+
+```
+ vector2value = "0.234,0.885"
+ vector3value = "-0.13,12.883,91.7"
+ vector4value = "-0.13,12.883,91.7,1.0"
+```
+
+While colorN and vectorN types both describe vectors of floating-point values, they differ in a number of significant ways. First, the final channel of a color4 value is interpreted as an alpha channel by compositing operators, and is only meaningful within the [0, 1] range, while the fourth channel of a vector4 value _could be_ (but is not necessarily) interpreted as the "w" value of a homogeneous 3D vector. Additionally, values of type color3 and color4 are always associated with a particular color space and are affected by color transformations, while values of type vector3 and vector4 are not. More detailed rules for colorN and vectorN operations may be found in the [Standard Operator Nodes](#standard-operator-nodes) section of the specification.
+
+**Matrix** types: MaterialX supports two matrix types that may be used to represent geometric and color transforms. The `matrix33` and `matrix44` types, respectively, represent 3x3 and 4x4 matrices and are written as nine or sixteen float values separated by commas, in row-major order:
+
+```
+ matrix33value = "1,0,0, 0,1,0, 0,0,1"
+ matrix44value = "1,0,0,0, 0,1,0,0, 0,0,1,0, 0,0,0,1"
+```
+
+**String**: literal text within quotes. See the [MTLX File Format Definition](#mtlx-file-format-definition) section for details on representing special characters within string data.
+
+```
+ stringvalue = "some text"
+```
+
+**Filename**: attributes of type "filename" are just strings within quotes, but specifically mean a Uniform Resource Identifier ([https://en.wikipedia.org/wiki/Uniform_Resource_Identifier](https://en.wikipedia.org/wiki/Uniform_Resource_Identifier)) optionally containing one or more Filename Substitution strings (see below) that represents a reference to an external asset, such as a file on disk or a query into a content management system.
+
+```
+ filevalue = "diffuse/color01.tif"
+ filevalue = "/s/myshow/assets/myasset/v102.1/wetdrips/drips.{frame}.tif"
+ filevalue = "https://github.com/organization/project/tree/master/src/node.osl"
+ filevalue = "cmsscheme:myassetdiffuse..tif?ver=current"
+```
+
+**IntegerArray**, **FloatArray**, **Color3Array**, **Color4Array**, **Vector2Array**, **Vector3Array**, **Vector4Array**, **StringArray**: any number of values (including zero) of the same base type, separated by commas (with or without whitespace), within quotes; arrays of color3’s, color4’s, vector2's, vector3's or vector4's are simply a 1D list of channel values in order, e.g. "r0, g0, b0, r1, g1, b1, r2, g2, b2". Individual string values within stringarrays may not contain commas or semicolons, and any leading and trailing whitespace characters in them is ignored. MaterialX does not support multi-dimensional or nested arrays. Array-typed inputs to nodes must be static uniform values of a length specified by another uniform input value of the node, or implicitly by the node's implementation requirements. Nodes cannot output an Array type.
+
+```
+ integerarrayvalue = "1,2,3,4,5"
+ floatarrayvalue = "1.0, 2.2, 3.3, 4.4, 5.5"
+ color3arrayvalue = ".1,.2,.3, .2,.3,.4, .3,.4,.5"
+ color4arrayvalue = ".1,.2,.3,1, .2,.3,.4,.98, .3,.4,.5,.9"
+ vector2arrayvalue = "0,.1, .4,.5, .9,1.0"
+ vector3arrayvalue = "-0.2,0.11,0.74, 5.1,-0.31,4.62"
+ vector4arrayvalue = "-0.2,0.11,0.74,1, 5.1,-0.31,4.62,1"
+ stringarrayvalue = "hello, there, world"
+```
+
+
+
+## Custom Data Types
+
+In addition to the standard data types, MaterialX supports the specification of custom data types for the inputs and outputs of shaders and custom nodes. This allows documents to describe data streams of any complex type an application may require; examples might include spectral color samples or compound geometric data. The structure of a custom type's contents may be described using a number of elements, though it is also permissible to only declare the custom type's name and treat the type as "blind data".
+
+Types can be declared to have a specific semantic, which can be used to determine how values of that type should be interpreted, and how nodes outputting that type can be connected. Currently, MaterialX defines three semantics:
+
+* "`color`": the type is interpreted to represent or contain a color, and thus should be color-managed as described in the [Color Spaces and Color Management Systems](#color-spaces-and-color-management-systems) section.
+* "`shader`": the type is interpreted as a shader output type; nodes or nodegraphs which output a type with a "shader" semantic can be used to define a shader-type node, which can be connected to inputs of "material"-type nodes.
+* "`material`": the type is interpreted as a material output type; nodes or nodegraphs which output a type with a "material" semantic can be referenced by a <materialassign> in a <look>.
+
+Types not defined with a specific semantic are assumed to have semantic="default".
+
+Custom types are defined using the <typedef> element:
+
+```xml
+
+
+
+
+
+```
+
+Attributes for <typedef> elements:
+
+* `name` (string, required): the name of this type. Cannot be the same as a built-in MaterialX type. To reduce the possible symbol conflict between custom type names and possible variable names created by code generation, we suggest the convention of using `_struct` as a suffix to the type name.
+* `semantic` (string, optional): the semantic for this type (see above); the default semantic is "default".
+* `context` (string, optional): a semantic-specific context in which this type should be applied. For "shader" semantic types, `context` defines the rendering context in which the shader output is interpreted; please see the [Shader Nodes](#shader-nodes) section for details.
+* `inherit` (string, optional): the name of another type that this type inherits from, which can be either a built-in type or a custom type. Applications that do not have a definition for this type can use the inherited type as a "fallback" type.
+* `hint` (string, optional): A hint to help those creating code generators understand how the type might be defined. The following hints for typedefs are currently defined:
+ * "halfprecision": the values within this type are half-precision
+ * "doubleprecision: the values within this type are double-precision
+
+Attributes for <member> elements:
+
+* `name` (string, required): the name of the member variable. Must be unique within the list of other member names for this custom type.
+* `type` (string, required): the type of the member variable; can be any built-in MaterialX type, or any previously defined custom type; recursive inclusion for <member> types is not supported.
+* `value` (string, required): the default value of the member variable.
+
+If a number of elements are provided, then a MaterialX file can specify a value for that type any place it is used, as a brace surrounded, semicolon-separated list of numbers and strings, with the expectation that the numbers and strings between semicolons exactly line up with the expected types in order. The use of the braces allows for custom struct types initializers to be nested. For example, if the following was declared:
+
+```xml
+
+
+
+
+
+
+
+```
+
+Then a permissible input declaration in a custom node using that type could be:
+
+```xml
+
+```
+
+If child elements are not provided, e.g. if the contents of the custom type cannot be represented as a list of MaterialX types, then a value cannot be provided, and this type can only be used to pass blind data from one custom node's output to another custom node or shader input.
+
+Once a custom type is defined by a <typedef>, it can then be used in any MaterialX element that allows "any MaterialX type"; the list of MaterialX types is effectively expanded to include the new custom type. It should be noted however that the <typedef> is only declaring the existence of the type and perhaps some hints about its intended definition, but it is up to each application and code generator to provide its own precise definition for any type.
+
+The standard MaterialX distribution includes definitions for four "shader"-semantic data types: **surfaceshader**, **displacementshader**, **volumeshader**, and **lightshader**. These types are discussed in more detail in the [Shader Nodes](#shader-nodes) section below.
+
+
+
+## MTLX File Format Definition
+
+An MTLX file (with file extension ".mtlx") has the following general form:
+
+```xml
+
+
+
+
+```
+
+That is, a standard XML declaration line followed by a root <materialx> element, which contains any number of MaterialX elements and sub-elements. The default character encoding for MTLX files is UTF-8, and this encoding is expected for the in-memory representation of string values in MaterialX implementations.
+
+Standard XML XIncludes are supported ([http://en/wikipedia.org/wiki/XInclude](http://en/wikipedia.org/wiki/Xinclude)), as well as standard XML comments and the XML character entities `"`, `&`, `'`, `<` and `>`:
+
+```xml
+
+
+
+```
+
+To support stringarray types, MaterialX supports a non-standard XML convention where a comma (and any following whitespace) is a separator for strings within a stringarray, a comma or semicolon preceded by a backslash is interpreted as a regular comma or semicolon rather than as a separator, and two backslashes are interpreted as a single backslash.
+
+Each XIncluded document must itself be a valid MTLX file, containing an XML header and its own root `` element, the children of which are added to the root element of the including document. Hierarchical root-level attributes such as `colorspace` and `namespace` are distributed to the included children to maintain correct semantics within the including MaterialX document.
+
+Attributes for a <materialx> element:
+
+* `version` (string, required): a string containing the version number of the MaterialX specification that this document conforms to, specified as a major and minor number separated by a dot. The MaterialX library automatically upgrades older-versioned documents to the current MaterialX version at load time.
+* `colorspace` (string, optional): the name of the "working color space" for this element and all of its descendants. This is the default color space for all image inputs and color values, and the color space in which all color computations will be performed. The default is "none", for no color management.
+* `namespace` (string, optional): defines the namespace for all elements defined within this <materialx> scope. Please see the [MaterialX Namespaces](#materialx-namespaces) section below for details.
+
+
+
+## Color Spaces and Color Management Systems
+
+MaterialX supports the use of color management systems to associate RGB colors and images with specific color spaces. MaterialX documents typically specify the working color space of the application that created them, and any input color or image described in the document can specify the name of its color space if different from the working color space. This allows applications using MaterialX to transform color values within input colors and images from their original color space into a desired working color space upon ingest. MaterialX does not specify _how_ or _when_ color values should be transformed: that is up to the host application, which can use any appropriate method including code generation, conversion when loading images into memory, maintaining cached or pre-converted image textures, etc. It is generally presumed that the working color space of a MaterialX document will be linear (as opposed to log, a display-referred space such as sRGB, or some other non-linear encoding), although this is not a firm requirement.
+
+By default, MaterialX supports the following color spaces as defined in ACES 1.2 ([http://www.oscars.org/science-technology/sci-tech-projects/aces)](http://www.oscars.org/science-technology/sci-tech-projects/aces), and applications rendering MaterialX documents are expected to transform input colors and images from these spaces to the color space of their renderer. One straightforward option for providing this support is to leverage MaterialX code generators, which support these transforms automatically, but applications may use any appropriate means to handle the transforms on their own.
+
+* `srgb_texture`
+* `lin_rec709`
+* `g22_rec709`
+* `g18_rec709`
+* `acescg`
+* `lin_ap1 (alias for "acescg")`
+* `g22_ap1`
+* `g18_ap1`
+* `lin_srgb`
+* `adobergb`
+* `lin_adobergb`
+* `srgb_displayp3`
+* `lin_displayp3`
+
+The working color space of a MaterialX document is defined by the `colorspace` attribute of its root <materialx> element, and it is strongly recommended that all <materialx> elements define a specific `colorspace` if they wish to use a color-managed workflow rather than relying on a default colorspace setting from an external configuration file.
+
+The color space of individual color image files and values may be defined via a `colorspace` attribute in an input which defines a filename or value. Color images and values in spaces other than the working color space are expected to be transformed by the application into the working space before computations are performed. In the example below, an image file has been defined in the “srgb_texture” color space, while its default value has been defined in “lin_rec709”; both should be transformed to the application’s working color space before being applied to any computations.
+
+```xml
+
+
+
+
+```
+
+MaterialX reserves the color space name "none" to mean no color space conversion should be applied to the images and color values within their scope.
+
+
+
+## Units
+
+MaterialX allows floating-point and vector values to be defined in terms of a specific unit and unit type, and can automatically convert values from their specified unit into a scene unit of the same type specified by the application. This allows images and the quantities they represent such as displacement amount to be specified at an absolute real-world size, and then be converted automatically to the expected scene units of the application.
+
+Unit types are defined using a <unittypedef> element, and a set of units of that type is defined using a <unitdef> element with one or more child <unit> elements. The following unittypes and units are pre-defined by MaterialX:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+The <unittypedef> defines the name of a unittype, while the <unitdef> defines any number of units for a unittype along with the multiplicative conversion `scale` values relative to the other units. Additional unit definitions for any unit type may be done by providing another <unitdef> with the same `unittype` attribute value.
+
+Any input or other floating-point value may specify a `unit` and/or `unittype` attribute subject to guidelines clarified throughout this document. Units and unittypes may also be provided for floatarray, vectorN and vectorNarray quantities, with all components of the vector or all values in the array using the same unit, and for "filename"-type input, in which case the `unit` and/or `unittype` attribute applies to the float or vectorN values read from those files. It is not expected that all inputs will have defined units or unittypes; in fact, it is expected that the vast majority of inputs will have neither. Units and unittypes should only be specified where specific units are important and it is reasonably expected that unit conversion may need to take place.
+
+Please refer to the [Inputs](#inputs), [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements), [Geometric Properties](#geometric-properties) and [Geometric Nodes](#geometric-nodes) sections below and in the MaterialX Geometry Extensions document for additional specific requirements for the use of units.
+
+
+
+## MaterialX Namespaces
+
+MaterialX supports the specification of “namespaces”, which qualify the MaterialX names of all elements within their scope. Namespaces are specified via a `namespace` attribute in a <materialx> element, and other MaterialX files which <xi:include> this .mtlx file can refer to its content without worrying about element or object naming conflicts, similar to the way namespaces are used in various programming languages. It is permissible for multiple <materialx> elements to specify the same namespace; the elements from each will simply be merged into the same namespace. <materialx> elements which do not specify a namespace will define elements into the (unnamed) global namespace. MaterialX namespaces are most commonly used to define families of custom nodes (nodedefs), material libraries, or commonly-used network shaders or nodegraphs.
+
+References to elements in a different namespace are qualified using the syntax "_namespace_:_elementname_", where _namespace_ is the namespace at the scope of the referenced element and _elementname_ is the name of the referenced element. References to elements in the same namespace, or to elements in the global namespace, should not be qualified.
+
+#### Namespace Examples
+
+Mtllib.mtlx contains the following (assuming that "..." contains any necessary material input connections and other element definitions):
+
+```xml
+
+
+ ...
+
+ ...
+
+
+ ...
+
+
+```
+
+Then another MaterialX file could reference these materials like this:
+
+```xml
+
+ ...
+
+
+
+
+```
+
+Similarly, if a .mtlx file defining the "site_ops" namespace defined a custom color3-typed node "mynoise" with a single float input "f", it could be used in a node graph like this:
+
+```xml
+
+
+
+```
+
+A `namespace` attribute may also be added to individual <nodedef>s or <nodegraph>s, in which case the `name` and `node` of a <nodedef>, or just the `name` of a <nodegraph> will be assigned to the specified `namespace`. In a <nodegraph>, the `nodedef` must include a namespace reference if the <nodedef> to which it refers is defined in a specific namespace, even if it's the same namespace as the <nodegraph>: this is because the `namespace` only applies to the content that is created by or contained within an element, not to anything external referenced by that element.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+## Geometric Properties
+
+Geometric Properties, or "geomprops", are intrinsic or user-defined surface coordinate properties of geometries referenced in a specific space and/or index, and are functionally equivalent to USD's concept of "primvars". A number of geometric properties are predefined in MaterialX: `position`, `normal`, `tangent`, `bitangent`, `texcoord` and `geomcolor`, the values of which can be accessed in nodegraphs using elements of those same names; see the [Geometric Nodes](#geometric-nodes) section below for details. The value of a varying geometric property can also be used as the default value for a node input using a `defaultgeomprop` attribute.
+
+The following geometric properties are pre-defined by MaterialX:
+
+| GeomProp Name | Type | Description |
+| ---- | ---- | ---- |
+| Pobject | vector3 | Object space position |
+| Nobject | vector3 | Object space surface normal |
+| Tobject | vector3 | Object space tangent vector (index 0) |
+| Bobject | vector3 | Object space bitangent vector (index 0) |
+| Pworld | vector3 | World space position |
+| Nworld | vector3 | World space surface normal |
+| Tworld | vector3 | World space tangent vector (index 0) |
+| Bworld | vector3 | World space bitangent vector (index 0) |
+| UV0 | vector2 | Index "0" UV texture coordinate |
+
+One may also define custom geometric properties using a <geompropdef> element:
+
+```xml
+
+```
+
+e.g.
+
+```xml
+
+
+```
+
+The `type` of the geomprop may be any non-array MaterialX type, although `string`- or `filename`-type geomprops must be declared with uniform="true". The "geomprop", "space" and "index" attributes are optional; if "geomprop" is specified, it must be one of the standard geometric properties noted above, and if it is not specified, the new geomprop is a blind geometric property, e.g. one that can be referenced but which MaterialX knows no details about. The "space" and "index" attributes may only be specified if a "geomprop" attribute is specified and the standard geomproperty supports it. "Geomprop", "space" and "index" attributes may not be specified for `uniform="true"` geomprops.
+
+Once defined, a custom geomprop name may be used any place that a standard geomprop can:
+
+```xml
+
+```
+
+A geompropdef may also specify a `unittype` and a `unit` to indicate that the geometric property is defined in terms of a specific unit. If a geomprop with a defined unit is accessed in a nodegraph using <geompropvalue>, the geometric property value will be converted from the unit specified by the geompropdef to the application-specified scene unit.
+
+```xml
+
+```
+
+
+
+## File Prefixes
+
+As a shorthand convenience, MaterialX allows the specification of a `fileprefix` attribute which will be prepended to input values of type "filename" (e.g. `file` inputs in `` nodes, or any shader input of type "filename") specified within the scope of the element defining the `fileprefix`. Note that `fileprefix` values are only prepended to input with a `type` attribute that explicitly states its data type as “filename”. Since the values of the prefix and the filename are string-concatenated, the value of a `fileprefix` should generally end with a "/". Fileprefixes are frequently used to split off common path components for asset directories, e.g. to define an asset's "texture root" directory.
+
+So the following snippets are equivalent:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Note in the second example that `` "in2" redefined `fileprefix` for itself, and that any other nodes in the same nodegraph would use the fileprefix value ("textures/color/") defined in the parent/enclosing scope.
+
+Note: Application implementations have access to both the raw input values and attributes (e.g. the "file" name and the current "fileprefix") and to fully-resolved filenames at the scope of any given element.
+
+
+
+## Filename Substitutions
+
+Filename input values for various nodes can include one or more special strings, which will be replaced as described in the following table. Substitution strings within <>'s come from the current geometry, strings within []'s come from the MaterialX state, and strings within {}'s come from the host application environment.
+
+| Token | Description |
+| ---- | ---- |
+| <UDIM> | A special geometry token that will be replaced with the computed four digit Mari-style "udim" value at render or evaluation time based on the current point’s uv value, using the formula UDIM = 1001 + U + V*10, where U is the integer portion of the u coordinate, and V is the integer portion of the v coordinate. |
+| <UVTILE> | A special geometry token that will be replaced with the computed Mudbox-style "uU_vV" string, where U is 1+ the integer portion of the u coordinate, and V is 1+ the integer portion of the v coordinate. |
+| [interface token] | The value of a specified token declared in the containing nodegraph's <nodedef> interface; the value for the token may be set in the shader node in a material referencing the node or within a <variant>; it is an error if the same token is defined in more than one of those places for the current geometry. |
+| {hostattr} | The host application may define other variables which can be resolved within filenames. |
+| {frame} | A special string that will be replaced by the current frame number, as defined by the host environment. |
+| {0Nframe} | A special string that will be replaced by the current frame number padded with zeros to be N digits total (replace N with a number): e.g. {04frame} will be replaced by a 4-digit zero-padded frame number such as "0010". |
+
+
+Note: Implementations are expected to retain substitution strings within filenames upon export rather than "baking them out" into fully-evaluated filenames. Applications using USD for geometry and assignments may additionally use a <_geometry token_> (a.k.a. "<_primvarname_>") as the entire filename string to access an entire string primvar value unchanged (though that string value may contain the USD-supported <UDIM> token).
+
+
+
+# Nodes
+
+Nodes are individual data generation or processing "blocks". Node functionality can range from simple operations such as returning a constant color value or adding two input values, to more complex image processing operations, 3D spatial data operations, or even complete shader BxDFs. Nodes are connected together into a network or "node graph", and pass typed data streams between them.
+
+Individual node elements have the form:
+
+```xml
+
+
+ ...additional input or token elements...
+
+```
+
+where _nodecategory_ is the general "category" of the node (e.g. "image", "add" or "mix"), `name` (string, required) defines the name of this instance of the node, which must be unique within the scope it appears in, and `type` (string, required) specifies the MaterialX type (typically float, colorN, or vectorN) of the output of that node. If the application uses a different name for this instance of the node in the user interface, a `uiname` attribute may be added to the <_nodecategory_> element to indicate the name of the node as it appears to the user.
+
+Node elements may optionally specify a `version` string attribute in "_major_[._minor_]" format, requesting that a specific version of that node's definition be used instead of the default version. Normally, the types of a node's inputs and outputs are sufficient to disambiguate which signature of the applicable version of a node is intended, but if necessary, a node instantiation may also declare a specific nodedef name to precisely define exactly which node signature is desired. Please refer to the [Custom Node Declaration NodeDef Elements](#custom-node-declaration-nodedef-elements) section below for further details.
+
+MaterialX defines a number of Standard Nodes which all implementations should support as described to the degree their architecture and capabilities allow. These standard nodes are grouped into [Standard Source Nodes](#standard-source-nodes) and [Standard Operator Nodes](#standard-operator-nodes); these groups are further divided into additional subcategories of nodes. In the descriptions below, a node with an "(NG)" annotation indicates a node that is implemented using a nodegraph in the MaterialX distribution, while unannotated nodes are implemented natively in the various renderer shading languages. One can define new nodes by declaring their parameter interfaces and providing portable nodegraph or target-specific shading language implementations. Please see the [Custom Nodes](#custom-nodes) section for notes and implementation details.
+
+
+
+## Inputs
+
+Node elements contain zero or more <input> elements defining the name, type, and value or connection for each node input. Input elements can assign an explicit uniform value by providing a `value` attribute, make a connection to the output of another node by providing a `nodename` attribute, or make a connection to the output of a nodegraph by providing a `nodegraph` attribute. An optional `output` attribute may also be provided for <input> elements, allowing the input to connect to a specific, named output of the referenced upstream node or nodegraph. If the referenced node/nodegraph has multiple outputs, `output` is required; if it has only one output, the `output` attribute of the <input> is ignored. Input elements may be defined to only accept uniform values, in which case the input may provide a `value` or a `nodename` connection to the output of a [<constant> node](#node-constant) (possibly through one or more no-op [<dot> nodes](#node-dot)) or any other node whose output is explicitly declared to be "uniform" (such as [<geompropvalueuniform>](#node-geompropvalueuniform)), but may not provide a `nodename` or `nodegraph` connection to any arbitrary node output or to any nodegraph output. String- and filename-type inputs are required to be "uniform", as are any array-typed inputs. Input elements may be connected to an external parameter interface in the node definition, allowing them to be assigned values from materials or node instantiations; this includes "uniform" and string/filename-type inputs, however, the same connectability restrictions listed above apply to the inputs of the material or node instance. Inputs may only be connected to node/nodegraph outputs or nodedef interface inputs of the same type, though it is permissible for a `string`-type output to be connected to a `filename`-type input (but not the other way around).
+
+A float/vectorN input of a node, or a "filename"-type input referring to an image file containing float or vectorN values, may specify a unit for its value by providing a `unit` attribute, and that unit must be one associated with the `unittype` for that input in the nodedef, if specified; please see the [Units](#units) section above for details on declaring units and unittypes. If the nodedef for a node (see the [Custom Nodes](#custom-nodes) section below) does not declare a `unittype` for an input, the node may do so; it is not permissible to provide a `unit` for a node input without a compatible `unittype` being defined on either the node or applicable nodedef.
+
+```xml
+
+
+
+```
+
+Unless specified otherwise, all inputs default to a value of 0 in all channels for integer, float, color and vector types, "" for string and filename types, "false" for boolean types, the identity matrix for matrix types, and for array types, an appropriate-length array consisting of the default value for the array's base type.
+
+Standard MaterialX nodes have exactly one output, while custom nodes may have any number of outputs; please see the [Custom Nodes](#custom-nodes) section for details.
+
+
+
+## Node Graph Elements
+
+A graph containing any number of nodes and output declarations forms a Node Graph, which may be enclosed within a <nodegraph> element to group them together into a single functional unit. Please see the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section below for details on how nodegraphs can be used to describe the functionality of new nodes.
+
+```xml
+
+ ...node element(s)...
+ ...output element(s)...
+
+```
+
+
+
+## Output Elements
+
+Output data streams are defined using **<output>** elements, and may be used to declare which output streams are connectable to other MaterialX elements. Within a node graph, an <output> element declares an output stream that may be connected to a shader input or to the input of a referencing node in another graph when the nodegraph is the implementation of a custom node. See the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section for details on the use of node graphs as node implementations.
+
+```xml
+
+
+```
+
+Attributes for Output elements:
+
+* `name` (string, required): the name of the output
+* `type` (string, required): the MaterialX type of the output
+* `nodename` (string, optional): the name of a node at the same scope within the document, whose result value will be output. This attribute is required for <output> elements within a node graph, but is not allowed in <output> elements within a <nodedef>.
+* `output` (string, optional): if the node specified by `nodename` has multiple outputs, the name of the specific output to connect this <output> to.
+* `uniform` (boolean, optional): If set to "true", then the output of this node is treated as a uniform value, and this output may be connected to a uniform input of the same (or compatible) type. It is up to the application creating the nodegraph to ensure that the value actually is uniform. Default is "false".
+
+MaterialX also supports the following additional attributes for Output elements in applications which process node graphs in 2D space and save or cache outputs as images for efficiency, such as texture baking or image caching. These attributes do **not** affect values from this <output> connected to other nodes, e.g. they would remain in the working colorspace and retain full resolution and bitdepth precision.
+
+* `colorspace` (string, optional): the name of the color space for the output image. Applications that support color space management are expected to perform the required transformations of output colors into this space.
+* `width` (integer, optional): the expected width in pixels of the output image.
+* `height` (integer, optional): the expected height in pixels of the output image.
+* `bitdepth` (integer, optional): the expected per-channel bit depth of the output image, which may be used to capture expected color quantization effects. Common values for `bitdepth` are 8, 16, 32, and 64. It is up to the application to determine what the internal representation of any declared bit depth is (e.g. scaling factor, signed or unsigned, etc.).
+
+
+
+## Standard Source Nodes
+
+Source nodes use external data and/or procedural functions to form an output; they do not have any required inputs. Each source node must define its output type.
+
+This section defines the Source Nodes that all MaterialX implementations are expected to support. Standard Source Nodes are grouped into the following classifications: [Texture Nodes](#texture-nodes), [Procedural Nodes](#procedural-nodes), [Noise Nodes](#noise-nodes), [Shape Nodes](#shape-nodes), [Geometric Nodes](#geometric-nodes) and [Application Nodes](#application-nodes).
+
+
+### Texture Nodes
+
+Texture nodes are used to read filtered image data from image or texture map files for processing within a node graph.
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+Standard Texture nodes:
+
+
+
+* **`image`**: samples data from a single image, or from a layer within a multi-layer image. When used in the context of rendering a geometry, the image is mapped onto the geometry based on geometry UV coordinates, with the lower-left corner of an image mapping to the (0,0) UV coordinate (or to the fractional (0,0) UV coordinate for tiled images).
+The type of the <image> node determines the number of channels output, which may be less than the number of channels in the image file, outputting the first N channels from the image file. So a `float` <image> would return the Red channel of an RGB image, and a `color3` <image> would return the RGB channels of an RGBA image. If the type of the <image> node has more channels than the referenced image file, then the output will contain zero values in all channels beyond the N channels of the image file.
+ * `file` (uniform filename): the URI of an image file. The filename can include one or more substitutions to change the file name (including frame number) that is accessed, as described in the [Filename Substitutions](#filename-substitutions) section above.
+ * `layer` (uniform string): the name of the layer to extract from a multi-layer input file. If no value for `layer` is provided and the input file has multiple layers, then the "default" layer will be used, or "rgba" if there is no "default" layer. Note: the number of channels defined by the `type` of the `` must match the number of channels in the named layer.
+ * `default` (float or colorN or vectorN): a default value to use if the `file` reference can not be resolved (e.g. if a <_geometry token_>, [_interface token_] or {_hostattr_} is included in the filename but no substitution value or default is defined, or if the resolved `file` URI cannot be read), or if the specified `layer` does not exist in the file. The `default` value must be the same type as the `` element itself. If `default` is not defined, the default color value will be 0.0 in all channels.
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the image data is read. Default is to use the current u,v coordinate.
+ * `uaddressmode` (uniform string): determines how U coordinates outside the 0-1 range are processed before sampling the image; see below. Default is "periodic".
+ * `vaddressmode` (uniform string): determines how V coordinates outside the 0-1 range are processed before sampling the image; see below. Default is "periodic".
+ * `filtertype` (uniform string): the type of texture filtering to use; standard values include "closest" (nearest-neighbor single-sample), "linear", and "cubic". If not specified, an application may use its own default texture filtering method.
+
+
+
+* **`tiledimage`** (NG): samples data from a single image, with provisions for tiling and offsetting the image across uv space.
+ * `file` (uniform filename): the URI of an image file. The filename can include one or more substitutions to change the file name (including frame number) that is accessed, as described in the [Filename Substitutions](#filename-substitutions) section.
+ * `default` (float or colorN or vectorN): a default value to use if the `file` reference can not be resolved (e.g. if a <geomtoken>, [interfacetoken] or {hostattr} is included in the filename but no substitution value or default is defined, or if the resolved file URI cannot be read), or if the specified `layer` does not exist in the file. The `default` value must be the same type as the `` element itself. If `default` is not defined, the default color value will be 0.0 in all channels.
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the image data is read. Default is to use the current u,v coordinate.
+ * `uvtiling` (vector2): the tiling rate for the given image along the U and V axes. Mathematically equivalent to multiplying the incoming texture coordinates by the given vector value. Default value is (1.0, 1.0).
+ * `uvoffset` (vector2): the offset for the given image along the U and V axes. Mathematically equivalent to subtracting the given vector value from the incoming texture coordinates. Default value is (0.0, 0.0).
+ * `realworldimagesize` (vector2): the real-world size represented by the `file` image, with unittype "distance". A `unit` attribute may be provided to indicate the units that `realworldimagesize` is expressed in.
+ * `realworldtilesize` (vector2): the real-world size of a single square 0-1 UV tile, with unittype "distance". A `unit` attribute may be provided to indicate the units that `realworldtilesize` is expressed in.
+ * `filtertype` (uniform string): the type of texture filtering to use; standard values include "closest" (nearest-neighbor single-sample), "linear", and "cubic". If not specified, an application may use its own default texture filtering method.
+
+
+
+* **`triplanarprojection`** (NG): samples data from three images (or layers within multi-layer images), and projects a tiled representation of the images along each of the three respective coordinate axes, computing a weighted blend of the three samples using the geometric normal.
+ * `filex` (uniform filename): the URI of an image file to be projected in the direction from the +X axis back toward the origin.
+ * `filey` (uniform filename): the URI of an image file to be projected in the direction from the +Y axis back toward the origin with the +X axis to the right.
+ * `filez` (uniform filename): the URI of an image file to be projected in the direction from the +Z axis back toward the origin.
+ * `layerx` (uniform string): the name of the layer to extract from a multi-layer input file for the x-axis projection. If no value for `layerx` is provided and the input file has multiple layers, then the "default" layer will be used, or "rgba" if there is no "default" layer. Note: the number of channels defined by the `type` of the `` must match the number of channels in the named layer.
+ * `layery` (uniform string): the name of the layer to extract from a multi-layer input file for the y-axis projection.
+ * `layerz` (uniform string): the name of the layer to extract from a multi-layer input file for the z-axis projection.
+ * `default` (float or colorN or vectorN): a default value to use if any `fileX` reference can not be resolved (e.g. if a <geomtoken>, [interfacetoken] or {hostattr} is included in the filename but no substitution value or default is defined, or if the resolved file URI cannot be read) The `default` value must be the same type as the `` element itself. If `default` is not defined, the default color value will be 0.0 in all channels.
+ * `position` (vector3): a spatially-varying input specifying the 3D position at which the projection is evaluated. Default is to use the current 3D object-space coordinate.
+ * `normal` (vector3): a spatially-varying input specifying the 3D normal vector used for blending. Default is to use the current object-space surface normal.
+ * `upaxis` (integer enum): which axis is considered to be "up", either 0 for X, 1 for Y, or 2 for Z. Default is Y (1).
+ * `blend` (float): a 0-1 weighting factor for blending the three axis samples using the geometric normal, with higher values giving softer blending. Default is 1.0.
+ * `filtertype` (uniform string): the type of texture filtering to use; standard values include "closest" (nearest-neighbor single-sample), "linear", and "cubic". If not specified, an application may use its own default texture filtering method.
+
+
+
+
+The following values are supported by `uaddressmode` and `vaddressmode` inputs of [image](#node-image) nodes:
+
+* “constant”: Texture coordinates outside the 0-1 range return the value of the node's `default` input.
+* “clamp”: Texture coordinates are clamped to the 0-1 range before sampling the image.
+* “periodic”: Texture coordinates outside the 0-1 range "wrap around", effectively being processed by a modulo 1 operation before sampling the image.
+* "mirror": Texture coordinates outside the 0-1 range will be mirrored back into the 0-1 range, e.g. u=-0.01 will return the u=0.01 texture coordinate value, and u=1.01 will return the u=0.99 texture coordinate value.
+
+
+Texture nodes using `file*` inputs also support the following inputs to handle boundary conditions for image file frame ranges for all `file*` inputs:
+
+* `framerange` (uniform string): a string "_minframe_-_maxframe_", e.g. "10-99", to specify the range of frames that the image file is allowed to have, usually the range of image files on disk. Default is unbounded.
+* `frameoffset` (integer): a number that is added to the current frame number to get the image file frame number. E.g. if `frameoffset` is 25, then processing frame 100 will result in reading frame 125 from the imagefile sequence. Default is no frame offset.
+* `frameendaction` (uniform string): what to do when the resolved image frame number is outside the `framerange` range:
+ * "constant": Return the value of the node's `default` input (default action)
+ * "clamp": Hold the minframe image for all frames before _minframe_ and hold the maxframe image for all frames after _maxframe_
+ * "periodic": Frame numbers "wrap around", so after the _maxframe_ it will start again at _minframe_ (and similar before _minframe_ wrapping back around to _maxframe_)
+ * "mirror": Frame numbers "mirror" or "ping-pong" at the endpoints of framerange, so a read of the frame after _maxframe_ will return the image from frame _maxframe_-1, and a read of the frame before _minframe_ will return the image from frame _minframe_+1.
+
+Arbitrary frame number expressions and speed changes are not supported.
+
+
+
+### Procedural Nodes
+
+Procedural nodes are used to generate value data programmatically.
+
+```xml
+
+
+
+
+
+
+
+```
+
+Standard Procedural nodes:
+
+
+
+* **`constant`**: a constant value.
+ * `value` (any non-shader-semantic type): the value to output
+
+
+
+* **`ramplr`**: a left-to-right linear value ramp.
+ * `valuel` (float or colorN or vectorN): the value at the left (U=0) edge
+ * `valuer` (float or colorN or vectorN): the value at the right (U=1) edge
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the ramp interpolation is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`ramptb`**: a top-to-bottom linear value ramp.
+ * `valuet` (float or colorN or vectorN): the value at the top (V=1) edge
+ * `valueb` (float or colorN or vectorN): the value at the bottom (V=0) edge
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the ramp interpolation is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`ramp4`** (NG): a 4-corner bilinear value ramp.
+ * `valuetl` (float or colorN or vectorN): the value at the top-left (U0V1) corner
+ * `valuetr` (float or colorN or vectorN): the value at the top-right (U1V1) corner
+ * `valuebl` (float or colorN or vectorN): the value at the bottom-left (U0V0) corner
+ * `valuebr` (float or colorN or vectorN): the value at the bottom-right (U1V0) corner
+ * `texcoord` (vector2, optional): the name of a vector2-type node specifying the 2D texture coordinate at which the ramp interpolation is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`splitlr`**: a left-right split matte, split at a specified U value.
+ * `valuel` (float or colorN or vectorN): the value at the left (U=0) edge
+ * `valuer` (float or colorN or vectorN): the value at the right (U=1) edge
+ * `center` (float): a value representing the U-coordinate of the split; all pixels to the left of "center" will be `valuel`, all pixels to the right of "center" will be `valuer`. Default is 0.5.
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the split position is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`splittb`**: a top-bottom split matte, split at a specified V value.
+ * `valuet` (float or colorN or vectorN): the value at the top (V=1) edge
+ * `valueb` (float or colorN or vectorN): the value at the bottom (V=0) edge
+ * `center` (float): a value representing the V-coordinate of the split; all pixels above "center" will be `valuet`, all pixels below "center" will be `valueb`. Default is 0.5.
+ * `texcoord` (vector2): the name of a vector2-type node specifying the 2D texture coordinate at which the split position is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`randomfloat`**: Produces a stable randomized float value between 'min' and 'max', based on an 'input' signal and 'seed' value. Uses a 2d cellnoise function to produce the output.
+ * `in` (float or integer): Initial randomization seed, default is 0.
+ * `min` (float): The minimum output value, default is 0.0.
+ * `max` (float): The maximum output value, default is 1.0.
+ * `seed` (integer): Additional randomization seed, default is 0.
+
+
+
+* **`randomcolor`**: Produces a randomized RGB color within a randomized hue, saturation and brightness range, based on an 'input' signal and 'seed' value. Output type color3.
+ * `in` (float or integer): Initial randomization seed, default is 0.
+ * `huelow` (float): The minimum hue value, default is 0.0.
+ * `huehigh` (float): The maximum hue value, default is 1.0.
+ * `saturationlow` (float): The minimum saturation value, default is 0.0.
+ * `saturationhigh` (float): The maximum saturation value, default is 1.0.
+ * `brightnesslow` (float): The minimum brightness value, default is 0.0.
+ * `brightnesshigh` (float): The maximum brightness value, default is 1.0.
+ * `seed` (integer): Additional randomization seed, default is 0.
+
+
+To scale or offset `rampX` or `splitX` input coordinates, use a <texcoord> or similar Geometric node processed by vector2 <multiply>, <rotate> and/or <add> nodes, and connect to the node's `texcoord` input.
+
+
+
+### Noise Nodes
+
+Noise nodes are used to generate value data using one of several procedural noise functions.
+
+```xml
+
+
+
+
+```
+
+Standard Noise nodes:
+
+
+
+* **`noise2d`**: 2D Perlin noise in 1, 2, 3 or 4 channels.
+ * `amplitude` (float or vectorN): the center-to-peak amplitude of the noise (peak-to-peak amplitude is 2x this value). Default is 1.0.
+ * `pivot` (float): the center value of the output noise; effectively, this value is added to the result after the Perlin noise is multiplied by `amplitude`. Default is 0.0.
+ * `period` (float or vectorN): the positive integer distance at which the noise function returns the same value for texture coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `texcoord` (vector2): the 2D texture coordinate at which the noise is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`noise3d`**: 3D Perlin noise in 1, 2, 3 or 4 channels.
+ * `amplitude` (float or vectorN): the center-to-peak amplitude of the noise (peak-to-peak amplitude is 2x this value). Default is 1.0.
+ * `pivot` (float): the center value of the output noise; effectively, this value is added to the result after the Perlin noise is multiplied by `amplitude`. Default is 0.0.
+ * `period` (float or vectorN): the positive integer distance at which the noise function returns the same value for position coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `position` (vector3): the 3D position at which the noise is evaluated. Default is to use the current 3D object-space coordinate.
+
+
+
+* **`fractal3d`**: Zero-centered 3D Fractal noise in 1, 2, 3 or 4 channels, created by summing several octaves of 3D Perlin noise, increasing the frequency and decreasing the amplitude at each octave.
+ * `amplitude` (float or vectorN): the center-to-peak amplitude of the noise (peak-to-peak amplitude is 2x this value). Default is 1.0.
+ * `octaves` (integer): the number of octaves of noise to be summed. Default is 3.
+ * `lacunarity` (float or vectorN): the exponential scale between successive octaves of noise; must be an integer value if period is non-zero so the result is properly tileable. Default is 2.0. VectorN-output types can provide either a float (isotropic) or vectorN (anisotropic) values for `lacunarity` and `diminish`.
+ * `diminish` (float or vectorN): the rate at which noise amplitude is diminished for each octave. Should be between 0.0 and 1.0; default is 0.5. VectorN-output types can provide either a float (isotropic) or vectorN (anisotropic) values for `lacunarity` and `diminish`.
+ * `period` (float or vectorN): the positive integer distance at which the noise function returns the same value for position coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `position` (vector3): the 3D position at which the noise is evaluated. Default is to use the current 3D object-space coordinate.
+
+
+
+* **`cellnoise2d`**: 2D cellular noise, 1 or 3 channels (type float or vector3).
+ * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for texture coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `texcoord` (vector2): the 2D position at which the noise is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`cellnoise3d`**: 3D cellular noise, 1 or 3 channels (type float or vector3).
+ * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for position coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `position` (vector3): the 3D position at which the noise is evaluated. Default is to use the current 3D object-space coordinate.
+
+
+
+* **`worleynoise2d`**: 2D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features).
+ * `metric` (uniform string): the distance metric to return, one of "distance" (Euclidean distance to feature), "distance2" (Euclidean distance squared), "manhattan" or "chebyshev". Default is "distance".
+ * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for texture coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `jitter` (float): amount to jitter the cell center position, with smaller values creating a more regular pattern. Default is 1.0.
+ * `texcoord` (vector2): the 2D position at which the noise is evaluated. Default is to use the first set of texture coordinates.
+
+
+
+* **`worleynoise3d`**: 3D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features).
+ * `metric` (uniform string): the distance metric to return, one of "distance" (Euclidean distance to feature), "distance2" (Euclidean distance squared), "manhattan" or "chebyshev". Default is "distance".
+ * `period` (float or vector3): the positive integer distance at which the noise function returns the same value for position coordinates repeated at that step. Default is 0, meaning the noise is not periodic.
+ * `jitter` (float): amount to jitter the cell center position, with smaller values creating a more regular pattern. Default is 1.0.
+ * `position` (vector3): the 3D position at which the noise is evaluated. Default is to use the current 3D object-space coordinate.
+
+
+
+* **`unifiednoise2d`** (NG): a single node supporting 2D Perlin, Cell, Worley or Fractal noise in a unified interface.
+ * `type` (integer): The type of noise function to use. One of 0 (Perlin), 1 (Cell), 2 (Worley), or 3 (Fractal); default is Perlin.
+ * `texcoord` (vector2): the input 2d space. Default is the first texture coordinates.
+ * `freq` (vector2): Adjusts the noise frequency, with higher values producing smaller noise shapes. Default is (1,1).
+ * `offset` (vector2): Shift the noise in 2d space. Default is (0,0).
+ * `jitter` (float): Adjust uniformity of Worley noise; for other noise types jitters the results.
+ * `outmin` (float): The lowest values fit to the noise. Default is 0.0.
+ * `outmax` (float): The highest values fit to the noise. Default is 1.0.
+ * `clampoutput` (boolean): Clamp the output to the min and max output values.
+ * `octaves` (integer): The number of octaves of Fractal noise to be generated. Default is 3.
+ * `lacunarity` (float): The exponential scale between successive octaves of Fractal noise. Default is 2.0.
+ * `diminish` (float): The rate at which noise amplitude is diminished for each octave of Fractal noise. Default is 0.5.
+
+
+
+* **`unifiednoise3d`** (NG): a single node supporting 3D Perlin, Cell, Worley or Fractal noise in a unified interface.
+ * `type` (integer): The type of noise function to use. One of 0 (Perlin), 1 (Cell), 2 (Worley), or 3 (Fractal); default is Perlin.
+ * `position` (vector3): the input 3d space. Default is position in object-space.
+ * `freq` (vector3): Adjusts the noise frequency, with higher values producing smaller noise shapes. Default is (1,1,1).
+ * `offset` (vector3): Shift the noise in 3d space. Default is (0,0,0).
+ * `jitter` (float): Adjust uniformity of Worley noise; for other noise types jitters the results.
+ * `outmin` (float): The lowest values fit to the noise. Default is 0.0.
+ * `outmax` (float): The highest values fit to the noise. Default is 1.0.
+ * `clampoutput` (boolean): Clamp the output to the min and max output values.
+ * `octaves` (integer): The number of octaves of Fractal noise to be generated. Default is 3.
+ * `lacunarity` (float): The exponential scale between successive octaves of Fractal noise. Default is 2.0.
+ * `diminish` (float): The rate at which noise amplitude is diminished for each octave of Fractal noise. Default is 0.5.
+
+
+To scale or offset the noise pattern generated by a 3D noise node such as `noise3d`, `fractal3d` or `cellnoise3d`, use a <position> or other [Geometric Node](#geometric-nodes) (see below) connected to vector3 <multiply> and/or <add> nodes, in turn connected to the noise node's `position` input. To scale or offset the noise pattern generated by a 2D noise node such as `noise2d` or `cellnoise2d`, use a <texcoord> or similar Geometric node processed by vector2 <multiply>, <rotate> and/or <add> nodes, and connect to the node's `texcoord` input.
+
+
+
+### Shape Nodes
+
+Shape nodes are used to generate shapes or patterns in UV space.
+
+```xml
+
+
+
+
+
+```
+
+Standard Shape nodes:
+
+
+
+* **`checkerboard`** (NG): a 2D checkerboard pattern. Output type color3.
+ * `color1` (color3): The first color used in the checkerboard pattern.
+ * `color2` (color3): The second color used in the checkerboard pattern.
+ * `uvtiling` (vector2): The tiling of the checkerboard pattern along each axis, with higher values producing smaller squares. Default is (8, 8).
+ * `uvoffset` (vector2): The offset of the checkerboard pattern along each axis. Default is (0, 0).
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+
+
+
+* **`line`** (NG): Returns 1 if texcoord is at less than radius distance from a line segment defined by point1 and point2; otherwise returns 0. Output type float.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `center` (vector2): An offset value added to both the point1 and point2 coordinates, default is (0, 0).
+ * `radius` (float): The radius or "half thickness" of the line, default is 0.1.
+ * `point1` (vector2): The UV coordinate of the first endpoint, default is (0.25, 0.25).
+ * `point2` (vector2): The UV coordinate of the second endpoint, default is (0.75, 0.75).
+
+
+
+* **`circle`** (NG): Returns 1 if texcoord is inside a circle defined by center and radius; otherwise returns 0. Output type float.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `center` (vector2): The center coordinate of the circle, default is (0, 0).
+ * `radius` (float): The radius of the circle, default is 0.5.
+
+
+
+* **`cloverleaf`** (NG): Returns 1 if texcoord is inside a cloverleaf shape described by four semicircles on the edges of a square defined by center and radius; otherwise returns 0. Output type float.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `center` (vector2): 2x the coordinate of the center of the cloverleaf pattern, default is (0, 0); a value of (1,1) will center the cloverleaf in the 0-1 UV space.
+ * `radius` (float): The radius of the complete cloverleaf pattern, default is 0.5 resulting in a cloverleaf pattern filling the 0-1 UV boundary.
+
+
+
+* **`hexagon`** (NG): Returns 1 if texcoord is inside a hexagon shape inscribed by a circle defined by center and radius; otherwise returns 0. Output type float.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `center` (vector2): The center coordinate of the hexagon, default is (0, 0).
+ * `radius` (float): The inner (edge center to opposite edge center) radius of the hexagon, default is 0.5.
+
+
+
+* **`grid`** (NG): Creates a grid pattern of (1, 1, 1) white lines on a (0, 0, 0) black background with the given tiling, offset, and line thickness. Pattern can be regular or staggered. Output type color3.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `uvtiling` (vector2): Tiling factor, with higher values producing a denser grid. Default is (1, 1).
+ * `uvoffset` (vector2): UV Offset, default is (0, 0).
+ * `thickness` (float): The thickness of the grid lines, default is 0.05.
+ * `staggered` (boolean): If true, every other row will be offset 50% to produce a "brick wall" pattern. Default is false.
+
+
+
+* **`crosshatch`** (NG): Creates a crosshatch pattern with the given tiling, offset, and line thickness. Pattern can be regular or staggered. Output type color3.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `uvtiling` (vector2): Tiling factor, with higher values producing a denser grid. Default is (1, 1).
+ * `uvoffset` (vector2): UV Offset, default is (0, 0).
+ * `thickness` (float): The thickness of the grid lines, default is 0.05.
+ * `staggered` (boolean): If true, every other row will be offset 50% to produce an "alternating diamond" pattern. Default is false.
+
+
+
+* **`tiledcircles`** (NG): Creates a black and white pattern of circles with a defined tiling and size (diameter). Pattern can be regular or staggered. Output type color3.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `uvtiling` (vector2): Tiling factor, with higher values producing a denser grid. Default is (1, 1).
+ * `uvoffset` (vector2): UV Offset, default is (0, 0).
+ * `size` (float): The diameter of the circles in the tiled pattern, default is 0.5; if `size` is 1.0, the edges of adjacent circles in the tiling will exactly touch.
+ * `staggered` (boolean): If true, every other row will be offset 50%, and the spacing of the tiling will be adjusted in the V direction to center the circles on the vertices of an equilateral triangle grid. Default is false.
+
+
+
+* **`tiledcloverleafs`** (NG): Creates a black and white pattern of cloverleafs with a defined tiling and size (diameter of the circles circumscribing the shape). Pattern can be regular or staggered. Output type color3.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `uvtiling` (vector2): Tiling factor, with higher values producing a denser grid. Default is (1, 1).
+ * `uvoffset` (vector2): UV Offset, default is (0, 0).
+ * `size` (float): The outer diameter of the cloverleafs in the tiled pattern, default is 0.5; if `size` is 1.0, the edges of adjacent cloverleafs in the tiling will exactly touch.
+ * `staggered` (boolean): If true, an additional pattern of cloverleafs will be generated in between the originals offset by 50% in both U and V. Default is false.
+
+
+
+* **`tiledhexagons`** (NG): Creates a black and white pattern of hexagons with a defined tiling and size (diameter of the circles circumscribing the shape). Pattern can be regular or staggered. Output type color3.
+ * `texcoord` (vector2): The input 2d space. Default is the first texture coordinates.
+ * `uvtiling` (vector2): Tiling factor, with higher values producing a denser grid. Default is (1, 1).
+ * `uvoffset` (vector2): UV Offset, default is (0, 0).
+ * `size` (float): The inner diameter of the hexagons in the tiled pattern, default is 0.5; if `size` is 1.0, the edges of adjacent hexagons in the U-direcction tiling will exactly touch.
+ * `staggered` (boolean): If true, every other row will be offset 50%, and the spacing of the tiling will be adjusted in the V direction to center the hexagons on the vertices of an equilateral triangle grid. Default is false.
+
+
+
+
+### Geometric Nodes
+
+Geometric nodes are used to reference local geometric properties from within a node graph:
+
+```xml
+
+
+
+
+```
+
+Standard Geometric nodes:
+
+
+
+* **`position`**: the coordinates associated with the currently-processed data, as defined in a specific coordinate space. This node must be of type vector3.
+ * `space` (uniform string): the name of the coordinate space in which the position is defined. Default is "object", see below for details.
+
+
+
+* **`normal`**: the geometric normal associated with the currently-processed data, as defined in a specific coordinate space. This node must be of type vector3.
+ * `space` (uniform string): the name of the coordinate space in which the normal vector is defined. Default is "object", see below for details.
+
+
+
+* **`tangent`**: the geometric tangent vector associated with the currently-processed data, as defined in a specific coordinate space. This node must be of type vector3.
+ * `space` (uniform string): the name of the coordinate space in which the tangent vector is defined. Default is "object", see below for details.
+ * `index` (uniform integer): the index of the texture coordinates against which the tangent is computed. The default index is 0.
+
+
+
+* **`bitangent`**: the geometric bitangent vector associated with the currently-processed data, as defined in a specific coordinate space. This node must be of type vector3.
+ * `space` (uniform string): the name of the coordinate space in which the bitangent vector is defined. Default is "object", see below for details.
+ * `index` (uniform integer): the index of the texture coordinates against which the tangent is computed. The default index is 0.
+
+
+
+* **`bump`**: offset the surface normal by a scalar value. This node must be of type type vector3, and is generally connected to a shader node's "normal" input.
+ * `height` (float): Amount to offset the surface normal.
+ * `scale` (float): Scalar to adjust the height amount.
+ * `normal` (vector3): Surface normal; defaults to the current world-space normal.
+ * `tangent` (vector3): Surface tangent vector, defaults to the current world-space tangent vector.
+
+
+
+* **`texcoord`**: the 2D or 3D texture coordinates associated with the currently-processed data. This node must be of type vector2 or vector3.
+ * `index` (uniform integer): the index of the texture coordinates to be referenced. The default index is 0.
+
+
+
+* **`geomcolor`**: the color associated with the current geometry at the current `position`, generally bound via per-vertex color values. Can be of type float, color3 or color4, and must match the type of the "color" bound to the geometry.
+ * `index` (uniform integer): the index of the color to be referenced, default is 0.
+
+
+
+* **`geompropvalue`**: the value of the specified varying geometric property (defined using <geompropdef>) of the currently-bound geometry. This node's type must match that of the referenced geomprop.
+ * `geomprop` (uniform string): the geometric property to be referenced.
+ * `default` (same type as the geomprop's value): a value to return if the specified `geomprop` is not defined on the current geometry.
+
+
+
+* **`geompropvalueuniform`**: the value of the specified uniform geometric property (defined using <geompropdef>) of the currently-bound geometry. This node's type must match that of the referenced geomprop.
+ * `geomprop` (uniform string): the geometric property to be referenced.
+ * `default` (same type as the geomprop's value): a value to return if the specified `geomprop` is not defined on the current geometry.
+
+Additionally, the `geomcolor`, `geompropvalue` and `geompropvalueuniform` nodes for color3/color4-type properties can take a `colorspace` attribute to declare what colorspace the color property value is in; the default is "none" for no colorspace declaration (and hence no colorspace conversion).
+
+
+
+
+The following values are supported by the `space` inputs of Geometric nodes and when transforming from one space to another:
+
+
+* "model": The local coordinate space of the geometry, before any local deformations or global transforms have been applied.
+* "object": The local coordinate space of the geometry, after local deformations have been applied, but before any global transforms.
+* "world": The global coordinate space of the geometry, after local deformations and global transforms have been applied.
+* "tangent": A coordinate space defined by the tangent, bitangent and normal vectors of the geometry.
+
+Applications may also reference other renderer-specific named spaces, at the expense of portability.
+
+
+
+### Application Nodes
+
+Application nodes are used to reference application-defined properties within a node graph, and have no inputs:
+
+```xml
+
+
+```
+
+Standard Application nodes:
+
+
+
+* **`frame`**: the current frame number as defined by the host environment. This node must be of type float. Applications may use whatever method is appropriate to communicate the current frame number to the <frame> node's implementation, whether via an internal state variable, a custom input, or other method.
+
+
+
+* **`time`**: the current time in seconds, as defined by the host environment. This node must be of type float. Applications may use whatever method is appropriate to communicate the current time to the <time> node's implementation, whether via an internal state variable, a custom input, dividing the current frame number by a local "frames per second" value, or other method; real-time applications may return some variation of wall-clock time.
+
+
+
+## Standard Operator Nodes
+
+Operator nodes process one or more required input streams to form an output. Like other nodes, each operator must define its output type, which in most cases also determines the type(s) of the required input streams.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+The inputs of compositing operators are called "fg" and "bg" (plus "alpha" for float and color3 variants, and "mix" for all variants of the `mix` operator), while the inputs of other operators are called "in" if there is exactly one input, or "in1", "in2" etc. if there are more than one input. If an implementation does not support a particular operator, it should pass through the "bg", "in" or "in1" input unchanged.
+
+This section defines the Operator Nodes that all MaterialX implementations are expected to support. Standard Operator Nodes are grouped into the following classifications: [Math Nodes](#math-nodes), [Adjustment Nodes](#adjustment-nodes), [Compositing Nodes](#compositing-nodes), [Conditional Nodes](#conditional-nodes), [Channel Nodes](#channel-nodes) and [Convolution Nodes](#convolution-nodes).
+
+
+
+### Math Nodes
+
+Math nodes have one or two spatially-varying inputs, and are used to perform a math operation on values in one spatially-varying input stream, or to combine two spatially-varying input streams using a specified math operation. The given math operation is performed for each channel of the input stream(s), and the data type of each input must either match that of the input stream(s), or be a float value that will be applied to each channel separately.
+
+
+
+
+* **`add`**: add a value to the incoming float/color/vector/matrix, or, add one integer value to another.
+ * `in1` (float or colorN or vectorN or matrixNN, or integer): the value or nodename for the primary input; for matrix types, the default is the zero matrix.
+ * `in2` (same type as `in1` or float, or integer): the value or nodename to add; for matrix types, the default is the zero matrix.
+
+
+
+* **`subtract`**: subtract a value from the incoming float/color/vector/matrix, or subtract one integer value from another; in either case, outputting "in1-in2".
+ * `in1` (float or colorN or vectorN or matrixNN, or integer): the value or nodename for the primary input; for matrix types, the default is the zero matrix.
+ * `in2` (same type as `in1` or float, or integer): the value or nodename to subtract; for matrix types, the default is the zero matrix
+
+
+
+* **`multiply`**: multiply an incoming float/color/vector/matrix by a value. Multiplication of two vectors is interpreted as a component-wise vector multiplication, while multiplication of two matrices is interpreted as a standard matrix product. To multiply a vector and a matrix, use one of the `transform*` nodes.
+ * `in1` (float or colorN or vectorN or matrixNN): the value or nodename for the primary input
+ * `in2` (same type as `in1` or float): the value or nodename to multiply by; default is 1.0 in all channels for float/color/vector types, or the identity matrix for matrix types.
+
+
+
+* **`divide`**: divide an incoming float/color/vector/matrix by a value; dividing a channel value by 0 results in floating-point "NaN". Division of two vectors is interpreted as a component-wise division of the first vector by the second, while division of two matrices is interpreted as a standard matrix product of the `in1` matrix and the inverse of the `in2` matrix.
+ * `in1` (float or colorN or vectorN or matrixNN): the value or nodename for the primary input
+ * `in2` (same type as `in1` or float): the value or nodename to divide by; default is 1.0 in all channels for float/color/vector types, or the identity matrix for matrix types.
+
+
+
+* **`modulo`**: the remaining fraction after dividing an incoming float/color/vector by a value and subtracting the integer portion. Modulo always returns a non-negative result, matching the interpretation of the GLSL and OSL `mod()` function (not `fmod()`).
+ * `in1` (float or colorN or vectorN): the value or nodename for the primary input
+ * `in2` (same type as `in1` or float): the modulo value or nodename to divide by, cannot be 0 in any channel; default is 1.0 in all channels, which effectively returns the fractional part of a float value
+
+
+
+* **`invert`**: subtract the incoming float/color/vector from "amount" in all channels, outputting: `amount - in`.
+ * `in` (float or colorN or vectorN): the value or nodename for the primary input
+ * `amount` (same type as `in` or float): the value or nodename to subtract from; default is 1.0 in all channels
+
+
+
+* **`absval`**: the per-channel absolute value of the incoming float/color/vector.
+ * `in` (float or colorN or vectorN): the input value or nodename
+
+
+
+* **`sign`**: the per-channel sign of the incoming float/color/vector value: -1 for negative, +1 for positive, or 0 for zero.
+ * `in` (float or colorN or vectorN): the input value or nodename
+
+
+
+* **`floor`**: the per-channel nearest integer value less than or equal to the incoming float/color/vector. The output remains in floating point per-channel, i.e. the same type as the input, except that the floor(float) also has a variant outputting an integer type.
+ * `in` (float or colorN or vectorN): the input value or nodename
+
+
+
+* **`ceil`**: the per-channel nearest integer value greater than or equal to the incoming float/color/vector. The output remains in floating point per-channel, i.e. the same type as the input, except that the ceil(float) also has a variant outputting an integer type.
+ * `in` (float or colorN or vectorN): the input value or nodename
+
+
+
+* **`round`**: round each channel of the incoming float/color/vector values to the nearest integer value, e.g "floor(in+0.5)"; the round(float) also has a variant outputting an integer type.
+ * `in` (float or colorN or vectorN): the input value or nodename
+
+
+
+* **`power`**: raise incoming float/color values to the specified exponent, commonly used for "gamma" adjustment.
+ * `in1` (float or colorN or vectorN): the value or nodename for the primary input
+ * `in2` (same type as `in1` or float): exponent value or nodename; output = pow(in1, in2); default is 1.0 in all channels
+
+
+
+* **`safepower`** (NG): raise incoming float/color values to the specified exponent. Unlike the standard [<power>](#node-power) node, negative `in1` values for <safepower> will result in negative output values, e.g. `out = sign(in1)*pow(abs(in1),in2)`.
+ * `in1` (float or colorN or vectorN): the value or nodename for the primary input
+ * `in2` (same type as `in1` or float): exponent value or nodename; default is 1.0 in all channels
+
+
+
+* **`sin`**: the sine of the incoming value, which is expected to be expressed in radians.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`cos`**: the cosine of the incoming value, which is expected to be expressed in radians.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`tan`**: the tangent of the incoming value, which is expected to be expressed in radians.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`asin`**: the arcsine of the incoming value; the output will be expressed in radians.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`acos`**: the arccosine of the incoming value; the output will be expressed in radians.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`atan2`**: the arctangent of the expression (iny/inx); the output will be expressed in radians. If both `iny` and `inx` are provided, they must be the same type.
+ * `iny` (float or vectorN): the value or nodename for the "y" input; default is 0.0.
+ * `inx` (float or vectorN): the value or nodename for the "x" input; default is 1.0.
+
+
+
+* **`sqrt`**: the square root of the incoming value.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`ln`**: the natural log of the incoming value.
+ * `in` (float or vectorN): the input value or nodename; default is 1.0.
+
+
+
+* **`exp`**: "e" to the power of the incoming value.
+ * `in` (float or vectorN): the input value or nodename
+
+
+
+* **`clamp`**: clamp incoming values per-channel to a specified range of float/color/vector values.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `low` (same type as `in` or float): clamp low value; any value lower than this will be set to "low". Default is 0 in all channels.
+ * `high` (same type as `in` or float): clamp high value; any value higher than this will be set to "high". Default is 1 in all channels.
+
+
+
+* **`trianglewave`**: Generate a triangle wave from the given scalar input. The generated wave ranges from zero to one and repeats on integer boundaries.
+ * `in` (float): the scalar value or nodename
+
+
+
+* **`min`**: select the minimum of the two incoming values
+ * `in1` (float or colorN or vectorN): the first value or nodename
+ * `in2` (same type as `in1` or float): the second value or nodename
+
+
+
+* **`max`**: select the maximum of the two incoming values
+ * `in1` (float or colorN or vectorN): the first value or nodename
+ * `in2` (same type as `in1` or float): the second value or nodename
+
+
+
+* **`normalize`**: output the normalized vectorN from the incoming vectorN stream; cannot be used on float or colorN streams. Note: the fourth channel in vector4 streams is not treated any differently, e.g. not as a homogeneous "w" value.
+ * `in` (vectorN): the input value or nodename
+
+
+
+* **`magnitude`**: output the float magnitude (vector length) of the incoming vectorN stream; cannot be used on float or colorN streams. Note: the fourth channel in vector4 streams is not treated any differently, e.g. not as a homogeneous "w" value.
+ * `in` (vectorN): the input value or nodename
+
+
+
+
+* **`distance`**: Measures the distance between two points in 2D, 3D, or 4D.
+ * `in1` (vectorN): the first input value or nodename
+ * `in2` (same type as `in1`): the second input value or nodename
+
+
+
+* **`dotproduct`**: output the (float) dot product of two incoming vectorN streams; cannot be used on float or colorN streams.
+ * `in1` (vectorN): the input value or nodename for the primary input.
+ * `in2` (same type as `in1`): the secondary value or nodename
+
+
+
+* **`crossproduct`**: output the (vector3) cross product of two incoming vector3 streams; cannot be used on any other stream type. A disabled `crossproduct` node passes through the value of `in1` unchanged.
+ * `in1` (vector3): the input value or nodename for the primary input.
+ * `in2` (vector3): the secondary value or nodename
+
+
+
+* **`transformpoint`**: transform the incoming vector3 coordinate from one specified space to another; cannot be used on any other stream type.
+ * `in` (vector3): the input coordinate vector.
+ * `fromspace` (uniform string): the name of a vector space understood by the rendering target to transform the `in` point from; may be empty to specify the renderer's working or "common" space.
+ * `tospace` (uniform string): the name of a vector space understood by the rendering target for the space to transform the `in` point to.
+
+
+
+* **`transformvector`**: transform the incoming vector3 vector from one specified space to another; cannot be used on any other stream type.
+ * `in` (vector3): the input vector.
+ * `fromspace` (uniform string): the name of a vector space understood by the rendering target to transform the `in` point from; may be empty to specify the renderer's working or "common" space.
+ * `tospace` (uniform string): the name of a vector space understood by the rendering target for the space to transform the `in` point to.
+
+
+
+* **`transformnormal`**: transform the incoming vector3 normal from one specified space to another; cannot be used on any other stream type.
+ * `in` (vector3): the input normal vector; default is (0,0,1).
+ * `fromspace` (uniform string): the name of a vector space understood by the rendering target to transform the `in` point from; may be empty to specify the renderer's working or "common" space.
+ * `tospace` (uniform string): the name of a vector space understood by the rendering target for the space to transform the `in` point to.
+
+
+
+* **`transformmatrix`**: transform the incoming vectorN coordinate by the specified matrix.
+ * `in` (vectorN): the input vector. If needed, an additional 1.0 component will be temporarily appended to the `in` vector to make it match the dimension of the transforming `mat` matrix, then removed after transformation.
+ * `mat` matrix33/44): the matrix used to transform the vector; a vector2 `in` can be transformed by a matrix33, a vector3 by a matrix33 or a matrix44, and a vector4 by a matrix44. Default is the identity matrix.
+
+
+
+* **`normalmap`**: transform a normal vector from encoded tangent space to world space. The input normal vector is assumed to be encoded with all channels in the [0-1] range, as would commonly be output from a normal map.
+ * `in` (vector3): the input vector; default is (0.5, 0.5, 1.0).
+ * `scale` (float or vector2): a scalar multiplier for the (x,y) components of the incoming vector; defaults to 1.0
+ * `normal` (vector3): surface normal; defaults to the current world-space normal.
+ * `tangent` (vector3): surface tangent vector, defaults to the current world-space tangent vector.
+ * `bitangent` (vector3): surface bitangent vector, defaults to the current world-space bitangent vector.
+
+
+
+* **`creatematrix`**: build a 3x3 or 4x4 matrix from three vector3 or four vector3 or vector4 inputs. A matrix44 may also be created from vector3 input values, in which case the fourth value will be set to 0.0 for in1-in3, and to 1.0 for in4 when creating the matrix44.
+ * `in1` (vector3 or vector4): the vector for the first row of the matrix. Default is (1,0,0) for matrix33 or (1,0,0,0) for matrix44.
+ * `in2` (vector3 or vector4): the vector for the second row of the matrix. Default is (0,1,0) for matrix33 or (0,1,0,0) for matrix44.
+ * `in3` (vector3 or vector4): the vector for the third row of the matrix. Default is (0,0,1) for matrix33 or (0,0,1,0) for matrix44.
+ * `in4` (vector3 or vector4): For matrix44 output type, the vector for the fourth row of the matrix. Default is (0, 0, 0, 1).
+
+
+
+* **`transpose`**: output the transpose of the incoming matrix.
+ * `in` (matrixNN): the input value or nodename
+
+
+
+* **`determinant`**: output the float determinant of the incoming matrixNN stream.
+ * `in` (matrixNN): the input value or nodename
+
+
+
+* **`invertmatrix`**: output the inverse of the incoming matrix; if the input matrix is not invertible, the output matrix will consist of all floating-point "NaN" values.
+ * `in` (matrixNN): the input value or nodename
+
+
+
+* **`rotate2d`**: rotate a vector2 value about the origin in 2D.
+ * `in` (vector2): the input value or nodename
+ * `amount` (float): the amount to rotate, specified in degrees, with positive values rotating the incoming vector counterclockwise. Default is 0.
+
+
+
+* **`rotate3d`**: rotate a vector3 value about a specified unit axis vector.
+ * `in` (vector3): the input value or nodename
+ * `amount` (float): the amount to rotate, specified in degrees; default is 0.
+ * `axis` (vector3): For vector3 inputs only, the unit axis vector about which to rotate; default is (0,1,0).
+
+
+
+* **`reflect`**: computes the vector3 reflection of an input vector against a surface normal vector.
+ * `in` (vector3): the input vector to reflect, defaults to (1.0, 0.0, 0.0).
+ * `normal` (vector3): the normal vector about which to reflect "in", defaults to the value of the "Nworld" (world space view direction) geometric property. This vector is expected to be prenormalized to length 1.0.
+
+
+
+* **`refract`**: computes the vetor3 refraction vector of an input vector through a surface with a given index of refraction.
+ * `in` (vector3): the input vector to reflect, defaults to (1.0, 0.0, 0.0).
+ * `normal` (vector3): the normal vector about which to reflect "in", defaults to the value of the "Nworld" (world space view direction) geometric property. This vector is expected to be prenormalized to length 1.0.
+ * `ior` (float): the index of refraction of the surface, defaults to 1.0.
+
+
+
+* **`place2d`** (NG): transform incoming UV texture coordinates for 2D texture placement.
+ * `texcoord` (vector2): the input UV coordinate to transform; defaults to the current surface index=0 uv coordinate.
+ * `pivot` (vector2): the pivot coordinate for scale and rotate: this is subtracted from u,v before applying scale/rotate, then added back after. Default is (0,0).
+ * `scale` (vector2): divide the u,v coord (after subtracting `pivot`) by this, so a scale (2,2) makes the texture image appear twice as big. Negative values can be used to flip or flop the texture space. Default is (1,1).
+ * `rotate` (float): rotate u,v coord (after subtracting pivot) by this amount in degrees, so a positive value rotates UV coords counter-clockwise, and the image clockwise. Default is 0.
+ * `offset` (vector2): subtract this amount from the scaled/rotated/“pivot added back” UV coordinate; since U0,V0 is typically the lower left corner, a positive offset moves the texture image up and right. Default is (0,0).
+ * `operationorder` (integer enum): the order in which to perform the transform operations. "0" or "SRT" performs "-pivot scale rotate translate +pivot" as per the original implementation matching the behavior of certain DCC packages, and "1" or "TRS" performs "-pivot translate rotate scale +pivot" which does not introduce texture shear. Default is 0 "SRT" for backward compatibility.
+
+
+
+* **`dot`**: a no-op, passes its input through to its output unchanged. Users can use dot nodes to shape edge connection paths or provide documentation checkpoints in node graph layout UI's. Dot nodes may also pass uniform values from <constant>, <tokenvalue> or other nodes with uniform="true" outputs to uniform <input>s and <token>s.
+ * `in` (any type): the nodename to be connected to the Dot node's "in" input. Unlike inputs on other node types, the <dot> node's input is specifically disallowed to provide a `channels` attribute: input data can only be passed through unmodified.
+
+
+### Logical Operator Nodes
+
+Logical operator nodes have one or two boolean typed inputs, and are used to construct higher level logical flow through the nodegraph.
+
+
+
+* **`and`**: logically And the two input boolean values.
+ * `in1` (boolean): the value or nodename for the first input; the default is false.
+ * `in2` (boolean): the value or nodename for the second input; the default is false.
+
+
+
+* **`or`**: logically Inclusive Or the two input boolean values.
+ * `in1` (boolean): the value or nodename for the first input; the default is false.
+ * `in2` (boolean): the value or nodename for the second input; the default is false.
+
+
+
+* **`xor`**: logically Exclusive Or the two input boolean values.
+ * `in1` (boolean): the value or nodename for the first input; the default is false.
+ * `in2` (boolean): the value or nodename for the second input; the default is false.
+
+
+
+* **`not`**: logically Not the input boolean value.
+ * `in1` (boolean): the value or nodename for the first input; the default is false.
+ * `in2` (boolean): the value or nodename for the second input; the default is false.
+
+
+### Adjustment Nodes
+
+Adjustment nodes have one input named "in", and apply a specified function to values in the incoming stream.
+
+
+
+* **`contrast`** (NG): increase or decrease contrast of incoming float/color values using a linear slope multiplier.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `amount` (same type as `in` or float): slope multiplier for contrast adjustment, 0.0 to infinity range. Values greater than 1.0 increase contrast, values between 0.0 and 1.0 reduce contrast. Default is 1.0 in all channels.
+ * `pivot` (same type as `in` or float): center pivot value of contrast adjustment; this is the value that will not change as contrast is adjusted. Default is 0.5 in all channels.
+
+
+
+* **`remap`**: linearly remap incoming values from one range of float/color/vector values to another.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `inlow` (same type as `in` or float): low value for input range; default is 0.0 in all channels
+ * `inhigh` (same type as `in` or float): high value for input range; default is 1.0 in all channels
+ * `outlow` (same type as `in` or float): low value for output range; default is 0.0 in all channels
+ * `outhigh` (same type as `in` or float): high value for output range; default is 1.0 in all channels
+
+
+
+* **`range`** (NG): remap incoming values from one range of float/color/vector values to another, optionally applying a gamma correction "in the middle". Input values below `inlow` or above `inhigh` are extrapolated unless `doclamp` is true, in which case the output values will be clamped to the `outlow`..`outhigh` range.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `inlow` (same type as `in` or float): low value for input range. Default is 0.0 in all channels.
+ * `inhigh` (same type as `in` or float): high value for input range. Default is 1.0 in all channels.
+ * `gamma` (same type as `in` or float): inverse exponent applied to input value after first transforming from `inlow`..`inhigh` to 0..1; `gamma` values greater than 1.0 make midtones brighter. Default is 1.0 in all channels.
+ * `outlow` (same type as `in` or float): low value for output range. Default is 0.0 in all channels.
+ * `outhigh` (same type as `in` or float): high value for output range. Default is 1.0 in all channels.
+ * `doclamp` (boolean): If true, the output is clamped to the range `outlow`..`outhigh`. Default is false.
+
+
+
+* **`smoothstep`**: output a smooth (hermite-interpolated) remapping of input values from low-high to output 0-1.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `low` (same type as `in` or float): input low value; an input value of this or lower will result in an output value of 0; default is 0.0 in all channels
+ * `high` (same type as `in` or float): input high value; an input value of this or higher will result in an output value of 1; default is 1.0 in all channels
+
+
+
+* **`luminance`**: (color3 or color4 only) output a grayscale value containing the luminance of the incoming RGB color in all color channels, computed using the dot product of the incoming color with the luma coefficients of the working colorspace; the alpha channel is left unchanged if present.
+ * `in` (color3/color4): the input value or nodename
+ * `lumacoeffs` (uniform color3): the luma coefficients of the current working color space; if no specific color space can be determined, the ACEScg (ap1) luma coefficients [0.2722287, 0.6740818, 0.0536895] will be used. Applications which support color management systems may choose to retrieve the luma coefficients of the working colorspace from the CMS to pass to the <luminance> node's implementation directly, rather than exposing it to the user.
+
+
+
+* **`rgbtohsv`**: (color3 or color4 only) convert an incoming color from RGB to HSV space (with H and S ranging from 0 to 1); the alpha channel is left unchanged if present. This conversion is not affected by the current color space.
+ * `in` (color3/color4): the input value or nodename
+
+
+
+* **`hsvtorgb`**: (color3 or color4 only) convert an incoming color from HSV to RGB space; the alpha channel is left unchanged if present. This conversion is not affected by the current color space.
+ * `in` (color3/color4): the input value or nodename
+
+
+
+* **`hsvadjust`** (NG): adjust the hue, saturation and value of an RGB color by converting the input color to HSV, adding amount.x to the hue, multiplying the saturation by amount.y, multiplying the value by amount.z, then converting back to RGB. A positive "amount.x" rotates hue in the "red to green to blue" direction, with amount of 1.0 being the equivalent to a 360 degree (e.g. no-op) rotation. Negative or greater-than-1.0 hue adjustment values are allowed, wrapping at the 0-1 boundaries. The internal conversions between RGB and HSV spaces are not affected by the current color space. For color4 inputs, the alpha value is unchanged.
+ * `in` (color3 or color4): the input value or nodename
+ * `amount` (vector3): the HSV adjustment; a value of (0, 1, 1) is "no change" and is the default.
+
+
+
+* **`saturate`** (NG): (color3 or color4 only) adjust the saturation of a color; the alpha channel will be unchanged if present. Note that this operation is **not** equivalent to the "amount.y" saturation adjustment of `hsvadjust`, as that operator does not take the working or any other colorspace into account.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `amount` (float): a multiplier for saturation; the saturate operator performs a linear interpolation between the luminance of the incoming color value (copied to all three color channels) and the incoming color value itself. Note that setting amount to 0 will result in an R=G=B gray value equal to the value that the `luminance` node (below) returns. Default is 1.0.
+ * `lumacoeffs` (uniform color3): the luma coefficients of the current working color space; if no specific color space can be determined, the ACEScg (ap1) luma coefficients [0.272287, 0.6740818, 0.0536895] will be used. Applications which support color management systems may choose to retrieve this value from the CMS to pass to the <saturate> node's implementation directly, rather than exposing it to the user.
+
+
+
+* **`colorcorrect`** (NG): Combines various adjustment nodes into one artist-friendly color correction node. For color4 inputs, the alpha value is unchanged.
+ * `in` (color3 or color4): the input color to be adjusted.
+ * `hue` (float): Rotates the color hue, with values wrapping at 0-1 boundaries; default is 0.
+ * `saturation` (float): Multiplies the input color saturation level; default is 1.
+ * `gamma` (float): Applies a gamma correction to the color; default is 1.
+ * `lift` (float): Raise the dark color values, leaving the white values unchanged; default is 0.
+ * `gain` (float): Multiplier increases lighter color values, leaving black values unchanged; default is 1.
+ * `contrast` (float): Linearly increase or decrease the color contrast; default is 1.
+ * `contrastpivot` (float): Pivot value around which contrast applies. This value will not change as contrast is adjusted; default is 0.5.
+ * `exposure` (float): Multplier which increases or decreases color brightness by 2^value; default is 0.
+
+
+
+### Compositing Nodes
+
+Compositing nodes have two (required) inputs named `fg` and `bg`, and apply a function to combine them. Compositing nodes are split into five subclassifications: [Premult Nodes](#premult-nodes), [Blend Nodes](#blend-nodes), [Merge Nodes](#merge-nodes), [Masking Nodes](#masking-nodes), and the [Mix Node](#mix-node).
+
+
+#### Premult Nodes
+
+Premult nodes operate on 4-channel (color4) inputs/outputs, have one input named `in`, and either apply or unapply the alpha to the float or RGB color.
+
+
+
+* **`premult`**: multiply the RGB channels of the input by the Alpha channel of the input.
+ * `in` (color4): the input value or nodename; default is (0,0,0,1).
+
+
+
+* **`unpremult`**: divide the RGB channels of the input by the Alpha channel of the input. If the Alpha value is zero, the original color4 input value is passed through unchanged.
+ * `in` (color4): the input value or nodename; default is (0,0,0,1).
+
+
+#### Blend Nodes
+
+Blend nodes take two 1-4 channel inputs and apply the same operator to all channels (the math for alpha is the same as for R or RGB). In the Blend Operator table, "F" and "B" refer to any individual channel of the `fg` and `bg` inputs respectively. Blend nodes support an optional float input `mix`, which can be used to mix the original `bg` value (`mix`=0) with the result of the blend operation (`mix`=1, the default).
+
+
+
+
+
+
+
+
+
+
+| Blend Operator | Each Channel Output | Supported Types |
+| --- | --- | --- |
+| **`plus`** | B+F | float, colorN |
+| **`minus`** | B-F | float, colorN |
+| **`difference`** | abs(B-F) | float, colorN |
+| **`burn`** | 1-(1-B)/F | float, colorN |
+| **`dodge`** | B/(1-F) | float, colorN |
+| **`screen`** | 1-(1-F)(1-B) | float, colorN |
+| **`overlay`** | 2FB if B<0.5; 1-2(1-F)(1-B) if B>=0.5 | float, colorN |
+
+
+#### Merge Nodes
+
+Merge nodes take two 4-channel (color4) inputs and use the built-in alpha channel(s) to control the compositing of the `fg` and `bg` inputs. In the Merge Operator table, "F" and "B" refer to the non-alpha channels of the `fg` and `bg` inputs respectively, and "f" and "b" refer to the alpha channels of the `fg` and `bg` inputs. Merge nodes are not defined for 1-channel or 3-channel inputs, and cannot be used on vectorN streams. Merge nodes support an optional float input `mix`, which can be used to mix the original `bg` value (`mix`=0) with the result of the blend operation (`mix`=1, the default).
+
+
+
+
+
+
+
+
+
+| Merge Operator | RGB output | Alpha Output |
+| --- | --- | --- |
+| **`disjointover`** | F+B if f+b<=1; F+B(1-f)/b if f+b>1 | min(f+b,1) |
+| **`in`** | Fb | fb |
+| **`mask`** | Bf | bf |
+| **`matte`** | Ff+B(1-f) | f+b(1-f) |
+| **`out`** | F(1-b) | f(1-b) |
+| **`over`** | F+B(1-f) | f+b(1-f) |
+
+
+#### Masking Nodes
+
+Masking nodes take one 1-4 channel input `in` plus a separate float `mask` input and apply the same operator to all channels (if present, the math for alpha is the same as for R or RGB). The default value for the `mask` input is 1.0 for the `inside` operator, and 0.0 for the `outside` operator In the Masking Operator table, "F" refers to any individual channel of the `in` input.
+
+
+
+
+
+| Masking Operator | Each Channel Output |
+| --- | --- |
+| **`inside`** | Fm |
+| **`outside`** | F(1-m) |
+
+
+Note: for all types, `inside` is equivalent to the `multiply` node: both operators exist to provide companion functions for other data types or their respective inverse or complementary operations.
+
+
+#### Mix Node
+
+The Mix node takes two 1-4 channel inputs `fg` and `bg` plus a separate 1-channel (float) or N-channel (same type and number of channels as `fg` and `bg`) `mix` input and mixes the `fg` and `bg` according to the mix value, either uniformly for a "float" `mix` type, or per-channel for non-float `mix` types. The equation for "mix" is as follows, with "F" and "B" referring to any channel of the `fg` and `bg` inputs respectively (which can be float, colorN or vectorN but must match), and "m" referring to the float `mix` input value (which has a default value of 0):
+
+
+
+
+| Mix Operator | Each Channel Output |
+| --- | --- |
+| **`mix`** | Fm+B(1-m) |
+
+
+See also the [Standard Library Shader Nodes](#standard-library-shader-nodes) section below for additional `mix` operator variants supporting shader-semantic types.
+
+
+
+### Conditional Nodes
+
+Conditional nodes are used to compare values of two streams, or to select a value from one of several streams.
+
+
+
+
+* **`ifgreater`**: output the value of the `in1` or `in2` stream depending on whether the value of one test input is greater than the value of another. Ifgreater nodes can be of output type float, integer, colorN, vectorN or matrixNN. There is also a "boolean" output-type **`ifgreater`** node, with `value1` and `value2` inputs but no `in1` or `in2`: output is "true" if `value1` > `value2`.
+ * `value1` (integer or float): the first value or nodename to compare. Default is 1.0.
+ * `value2` (integer or float): the second value or nodename to compare must be the same type as `value1`. Default is 0.0.
+ * `in1` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` > `value2`; must be the same type as the `ifgreater` node's output. Default is 0.0 in all channels.
+ * `in2` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` <= `value2`; must be the same type as the `ifgreater` node's output. Default is 0.0 in all channels.
+
+
+
+* **`ifgreatereq`**: output the value of the `in1` or `in2` stream depending on whether the value of one test input is greater than or equal to the value of another. Ifgreatereq nodes can be of output type float, integer, colorN, vectorN or matrixNN. There is also a "boolean" output-type **`ifgreatereq`** node, with `value1` and `value2` inputs but no `in1` or `in2`: output is "true" if `value1` >= `value2`.
+ * `value1` (integer or float): the first value or nodename to compare. Default is 1.0.
+ * `value2` (integer or float): the second value or nodename to compare; must be the same type as `value1`. Default is 0.0.
+ * `in1` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` >= `value2`; must be the same type as the `ifgreatereq` node's output. Default is 0.0 in all channels.
+ * `in2` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` < `value2`; must be the same type as the `ifgreatereq` node's output. Default is 0.0 in all channels.
+
+
+
+* **`ifequal`**: output the value of the `in1` or `in2` stream depending on whether the value of two test inputs are equal or not. Ifequal nodes can be of output type float, integer, colorN, vectorN or matrixNN. There is also a "boolean" output-type **`ifequal`** node, with `value1` and `value2` inputs but no `in1` or `in2`: output is "true" if `value1` == `value2`.
+ * `value1` (boolean or integer or float): the first value or nodename to compare. Default is 0 or "false".
+ * `value2` (boolean or integer or float): the second value or nodename to compare; must be the same type as `value1`. Default is 0 or "false".
+ * `in1` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` == `value2`; must be the same type as the `ifequal` node's output. Default is 0.0 in all channels.
+ * `in2` (float or integer or colorN or vectorN or matrixNN): the value or nodename to output if `value1` != `value2`; must be the same type as the `ifequal` node's output. Default is 0.0 in all channels.
+
+
+
+* **`switch`**: output the value of one of up to ten input streams, according to the value of a selector input `which`. Switch nodes can be of output type float, colorN, vectorN or matrixNN, and have ten inputs, in1 through in10 (not all of which need be connected), which must match the output type.
+ * `in1`, `in2`, `in3`, `in4`, `in5`, `in6`, `in7`, `in8`, `in9`, `in10` (float or colorN or vectorN or matrixNN): the values or nodenames to select from based on the value of the `which` input. The types of the various `in`N inputs must match the type of the `switch` node itself. The default value of all `in`N inputs is 0.0 in all channels.
+ * `which` (integer or float): a selector to choose which input to take values from; the output comes from input "floor(`which`)+1", clamped to the 1-10 range. So `which`<1 will pass on the value from in1, 1<=`which`<2 will pass the value from in2, 2<=`which`<3 will pass the value from in3, and so on up to 9<=`which` will pass the value from in10. The default value of `which` is 0.
+
+
+
+### Channel Nodes
+
+Channel nodes are used to perform channel manipulations and data type conversions on streams.
+
+
+
+
+* **`extract`**: extract the specified channel number from a colorN or vectorN stream.
+ * `in` (colorN or vectorN): the input value or nodename
+ * `index` (integer): the channel number to extract. For colorN streams, use "0" to extract the red channel, "1" for green, "2" for blue and "3" for alpha; for vectorN streams, use "0" to extract the x channel, "1" for y, "2" for z and "3" for w. Default is 0.
+
+
+
+* **`convert`**: convert a stream from one data type to another. Only certain unambiguous conversions are supported; see list below.
+ * `in` (boolean or integer or float or colorN or vectorN): the input value or nodename
+
+
+
+
+
+* **`combine2`**, **`combine3`**, **`combine4`**: combine the channels from two, three or four streams into the same total number of channels of a single output stream of a specified compatible type; please see the table below for a list of all supported combinations of input and output types. For colorN output types, no colorspace conversion will take place; the channels are simply copied as-is.
+ * `in1` (float/color3/vector2/vector3): the input value or nodename which will be sent to the N channels of the output; default is 0.0 in all channels
+ * `in2` (float/vector2): the input value or nodename which will be sent to the next N channels of the output; default is 0.0 in all channels
+ * `in3` (float): for **`combine3`** or **`combine4`**, the input value or nodename which will be sent to the next channel of the output after `in2`; default is 0.0
+ * `in4` (float): for **`combine4`**, the input value or nodename which will be sent to the last channel of the output; default is 0.0
+
+
+
+* **`separate2`** (NG): output each of the channels of a vector2 as a separate float output.
+ * `in` (vector2): the input value or nodename
+ * `outx` (**output**, float): the value of x channel.
+ * `outy` (**output**, float): the value of y channel.
+
+
+
+* **`separate3`** (NG): output each of the channels of a color3 or vector3 as a separate float output.
+ * `in` (color3 or vector3): the input value or nodename
+ * `outr`/`outx` (**output**, float): the value of the red (for color3 streams) or x (for vector3 streams) channel.
+ * `outg`/`outy` (**output**, float): the value of the green (for color3 streams) or y (for vector3 streams) channel.
+ * `outb`/`outz` (**output**, float): the value of the blue (for color3 streams) or z (for vector3 streams) channel.
+
+
+
+* **`separate4`** (NG): output each of the channels of a color4 or vector4 as a separate float output.
+ * `in` (color4 or vector4): the input value or nodename
+ * `outr`/`outx` (**output**, float): the value of the red (for color4 streams) or x (for vector4 streams) channel.
+ * `outg`/`outy` (**output**, float): the value of the green (for color4 streams) or y (for vector4 streams) channel.
+ * `outb`/`outz` (**output**, float): the value of the blue (for color4 streams) or z (for vector4 streams) channel.
+ * `outa`/`outw` (**output**, float): the value of the alpha (for color4 streams) or w (for vector4 streams) channel.
+
+
+The following input/output data type conversions are supported by **`convert`**:
+
+* boolean or integer to float: output is 0.0 or 1.0
+* boolean to integer: output is 0 or 1
+* integer to boolean: true for any non-zero input value
+* float/integer/boolean to colorN/vectorN: copy the input value to all channels of the output
+* colorN / vectorN to colorM / vectorM
+ * if _N_ is the same as _M_, then channels are directly copied.
+ * if _N_ is larger than _M_, then channels the first _N_ channels are used.
+ * if _N_ is smaller than _M_, then channels are directly copied and additional channels are populated with 0, aside from the fourth channel which is populated with 1
+
+Table of allowable input/output types for **`combine2`**, **`combine3`**, **`combine4`**:
+
+| Operator | `type` | `in1` | `in2` | `in3` | `in4` | Output |
+| --- | --- | --- | --- | --- | --- | --- |
+| `combine2` | `vector2` | `float` "x" | `float` "y" | n/a | n/a | "xy" |
+| `combine3` | `color3` | `float` "r" | `float` "g" | `float` "b" | n/a | "rgb" |
+| `combine3` | `vector3` | `float` "x" | `float` "y" | `float` "z" | n/a | "xyz" |
+| `combine4` | `color4` | `float` "r" | `float` "g" | `float` "b" | `float` "a" | "rgba" |
+| `combine4` | `vector4` | `float` "x" | `float` "y" | `float` "z" | `float` "w" | "xyzw" |
+| `combine2` | `color4` | `color3` "rgb" | `float` "a" | n/a | n/a | "rgba" |
+| `combine2` | `vector4` | `vector3` "xyz" | `float` "w" | n/a | n/a | "xyzw" |
+| `combine2` | `vector4` | `vector2` "xy" | `vector2` "zw" | n/a | n/a | "xyzw" |
+
+
+
+
+### Convolution Nodes
+
+Convolution nodes have one input named "in", and apply a defined convolution function on the input stream. Some of these nodes may not be implementable in ray tracing applications; they are provided for the benefit of purely 2D image processing applications.
+
+
+
+
+* **`blur`**: a convolution blur.
+ * `in` (float or colorN or vectorN): the input value or nodename
+ * `size` (float): the size of the blur kernel, relative to 0-1 UV space; default is 0.
+ * `filtertype` (uniform string): the spatial filter used in the blur, either "box" for a linear box filter, or "gaussian" for a gaussian filter. Default is "box".
+
+
+
+* **`heighttonormal`**: convert a scalar height map to a normal map of type vector3.
+ * `in` (float): the input value or nodename
+ * `scale` (float): the scale of normal map deflections relative to the gradient of the height map. Default is 1.0.
+ * `space` (string): the space in which the output normal map vector should be; defaults to "tangent".
+
+
+
+## Standard Node Inputs
+
+All standard nodes which define a `defaultinput` or `default` value support the following input:
+
+
+
+* `disable` (uniform boolean): if set to true, the node will pass its default input or value to its output, effectively disabling the node; default is false. Applications may choose to implement the `disable` input by skipping over the disabled node during traversal and instead passing through a connection to the defaultinput node or outputting the node's default value, rather than using an actual `disable` input in the node implementation.
+
+
+## Standard UI Attributes
+
+All elements support the following additional UI-related attributes:
+
+
+
+* `doc` (string attribute): a description of the function or purpose of this element; may include standard HTML formatting strings such as <b>, <ul>, <p>, etc. but no complex formatting such as CSS or external references (e.g. no hyperlinks or images). May be used for functional documentation, or for UI pop-up "tool tip" strings.
+
+
+All node types (sources, operators, shader nodes and material nodes) as well as <look> elements support the following UI-related attributes:
+
+
+
+* `xpos` (float attribute): X-position of the upper-left corner of the node when drawn in a UI.
+
+
+
+* `ypos` (float attribute): Y-position of the upper-left corner of the node when drawn in a UI.
+
+
+
+* `width` (float attribute): the relative width of the node when drawn in a UI; default is 1.0.
+
+
+
+* `height` (float attribute): the relative height of the node when drawn in a UI; default is 1.0.
+
+
+
+* `uicolor` (color3 attribute): the display-referred color of the node as drawn in the UI, normalized to 0.0-1.0 range; default is to not specify a particular color so the application's default node color would be used. `uicolor` values are expressed as color3 values in "none" colorspace, and thus are not affected by the current `colorspace`.
+
+All positioning and sizing attribute values are specified relative to an application's default size for drawing a node including any minimal-length connection edges and arrows. So a node drawn at position (xpos, ypos) will "look good" if connected to nodes drawn at position (xpos+width, ypos) and at position (xpos, ypos+height), and a node specifying `width="2"` would be drawn twice as wide (including outside whitespace for a minimal connecting arrow) as a node with the default width. It is not necessary that nodes be placed exactly on integer grid boundaries; this merely states the scale of nodes. It is also not assumed that the pixel scaling factors for X and Y are the same: the actual UI unit "grid" does not have to be square. If xpos and ypos are not both specified, placement of the node when drawn in a UI is undefined, and it is up to the application to figure out placement (which could mean "all piled up in the center in a tangled mess").
+
+MaterialX defines xpos values to be increasing left to right, ypos values to be increasing top to bottom, and the general flow is generally downward. E.g. node inputs are on the top and outputs on the bottom, and a node at (10, 10) could connect naturally to a node at (10, 11). Content creation applications using left-to-right flow can simply exchange X and Y coordinates in their internal representations when reading or writing MaterialX data, and applications that internally use Y coordinates increasing upward rather than downward can invert the Y coordinates between MTLX files and their internal representations.
+
+The <input> and <token> elements within <nodedef>s and node instantiations (but not within <implementation>s or <nodegraph> parameter interfaces) support the following UI-related attributes:
+
+
+
+* `uivisible` (boolean attribute): whether or not the input is visible in the UI. If `uivisible` is specified on an input/token in a <nodedef> that defines the default visibility of that input/token, while a `uivisible` specified on a input/token in a node instantiation affects just the visibility of the input/token within that particular instantiation. Default is "true".
+
+
+
+* `uiadvanced` (boolean attribute): whether or not the input is considered to be an "advanced" parameter which an application may choose to hide in a more "basic" mode. Should normally be declared only within a <nodedef>. Default is "false", meaning the input should be displayed if `uivisible` is true, while "true" means the input would be displayed if `uivisible` is true and the application UI is set to show "advanced" parameters.
+
+
+
+## Backdrop Elements
+
+Backdrop elements are used to contain, group, and document nodes within a node graph, and they have no impact on the functionality of the graph. The following attributes are supported by <backdrop> elements:
+
+* `contains` (stringarray attribute): a comma-separated list of node names that the backdrop "contains"; default is to contain no nodes.
+* `minimized` (boolean attribute): whether or not this backdrop is collapsed to a single node-sized box in the application's UI or not; default is false.
+
+Backdrop elements also support the standard `width`, `height`, `xpos`, `ypos` and `doc` attributes.
+
+
+
+
+## Node Graph Examples
+
+#### Nodegraph Example 1
+
+A simple merge of two single-layer images with a separate mask image, followed by a simple color operation.
+
+
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+#### Nodegraph Example 2
+
+A more complex nodegraph using geometry properties to define two diffuse albedo colors and two masks, then color-correcting one albedo less red and more blue and increasing the contrast of the other, blending the two through an area mask, and adding a small amount of scaled 2D Perlin noise within a second mask. The graph outputs the area mask layer separately from the composited diffuse albedo color.
+
+
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+# Customization, Targeting and Shading
+
+While the Standard Nodes are considered universal across all MaterialX applications, there are many circumstances in which one would like to extend this with new custom functionality, or define functionality or underlying implementations specific to different applications or renderers. This includes the definition of nodes for shading and materials.
+
+
+## Target Definition
+
+MaterialX supports the definition of nodes, attributes and inputs that are specific to particular rendering "targets". This allows a single implementation to restrict certain values or nodes to only the targets for which they are valid, or to allow separate definitions of the same node functionality for different renderers.
+
+Targets are declared using a <targetdef> element:
+
+```xml
+
+
+
+```
+
+A target may inherit from another target, so that any reference to a parent target will automatically include any definitions specific to the inherited child target that do not have a definition for the parent target itself:
+
+```xml
+
+
+
+```
+
+In the above example, any renderer that requests nodes/inputs/attributes for the "osl" target will also see any node/input/attribute that is defined with `target="oslpattern"`. A renderer may also declare that it will accept implementations for multiple targets, e.g. Vray might declare it will accept either "vrayosl", "mdl" or "vrayglsl", with "vrayosl" preferred.
+
+A targetdef element may also specify additional custom attributes for that target, such as configuration or code generation options.
+
+
+## Custom Attributes and Inputs
+
+#### Custom Attributes
+
+While the MaterialX specification describes the attributes and elements that are meaningful to MaterialX-compliant applications, it is permissible to add custom attributes and inputs to standard MaterialX elements. These custom attributes and child elements are ignored by applications that do not understand them, although applications should preserve and re-output them with their values and connections even if they do not understand their meaning.
+
+If an application requires additional information related to any MaterialX element, it may define and utilize additional attributes with non-standard names. Custom attributes are defined using <attributedef> elements:
+
+
+```xml
+
+```
+
+where _name_ is a unique name for the attributedef, _attrname_ is the name of the custom attribute to define, _type_ is the type of the attribute (typically string, stringarray, integer or boolean, although any MaterialX type is allowed), _defaultvalue_ is the default value for the attribute, _target_ is an optional list of targets to which this attribute applies, and _elements_ is an optional list of element names or elementname/inputname in which the attribute may be used. It is also permissible to provide enum and enumvalues attributes for an attributedef, to define specific labels and values that the custom attribute is allowed to take, using the same syntax and limitations as enum/enumvalues on nodedef inputs and tokens (see below). By default, a custom attribute is not emitted as metadata in generated shaders, but can be exported if the `exportable` attribute is set to "true". Examples:
+
+```xml
+
+
+
+```
+
+The first example above defines a 3ds Max-specific name attribute for surface materials, which may be given a value in addition to its MaterialX-compliant name in order to preserve the original package-specific name; it is assumed here that `maxmtlname` is the attribute name used by that particular implementation for this purpose. The second example defines a "mystudio"-specific boolean attribute "vflip", which could be used in the "file" input of <image> nodes.
+
+Once defined, custom attributes may be used in exactly the same manner as standard attributes:
+
+```xml
+
+
+
+
+
+ ...
+
+```
+
+
+#### Custom Inputs
+
+If an application requires additional custom inputs within a standard MaterialX node, it may define a target application-specific <nodedef> for that node inheriting the base input definitions from the standard node's <nodedef>, then add inputs specific to that target application.
+
+```xml
+
+
+
+```
+
+In the above example, a Maya-specific version of the color4-type <image> node has been declared, inheriting from the standard declaration then adding a maya-specific "preFilter" input.
+
+When using a node, the definition appropriate for the current target will automatically be used, and other targets will ignore any inputs that are not part of the nodedef for that target. However, one may specify a documentational `target` attribute on an input to hint what target it is intended for if desired. In this example, the "preFilter" input has indicated that it is specific to the "maya" target.
+
+```xml
+
+
+
+
+```
+
+
+## Custom Nodes
+
+Specific applications will commonly support sources and operators that do not map directly to standard MaterialX nodes. Individual implementations may provide their own custom nodes, with <nodedef> elements to declare their parameter interfaces, and <implementation> and/or <nodegraph> elements to define their behaviors.
+
+
+### Custom Node Declaration NodeDef Elements
+
+Each custom node must be explicitly declared with a <nodedef> element, with child <input>, <token> and <output> elements specifying the expected names and types of the node’s inputs and output(s).
+
+Attributes for <nodedef> elements:
+
+* `name` (string, required): a unique name for this <nodedef>
+* `node` (string, required): the name of the custom node being defined
+* `inherit` (string, optional): the `name` of a <nodedef> to inherit node definitions from; the output types of this nodedef and the inherited one must match, and the input/output definitions of this nodedef will be applied on top of those in the inherited-from one.
+* `nodegroup` (string, optional): an optional group to which this node declaration belongs. Standard MaterialX nodes have `nodegroup` values matching the titles of the section headings in which they are described, e.g. "texture2d", "procedural", "geometric", "application", "math", "adjustment", "compositing", "conditional", "channel", "convolution", or "organization".
+* `version` (string, optional): a version string for this nodedef, allowing usage of a node to reference a specific version of a node. Version strings should be of the format "_major_[._minor_]", i.e. one or two integer numbers separated by a dot (the minor version is assumed to be "0" if not provided). If there are multiple nodedefs for the same `node` and `target` with the same combination of input and output types, they must each specify a `version`.
+* `isdefaultversion` (boolean, optional): If true, then this nodedef should be used for node instances which do not request a specific version. Specifying `isdefaultversion` "true" is only required if there are multiple nodedefs for a node declaring a `version`, and it is not permissible for multiple nodedefs for the same `node` and `target` with the same combination of input and output types to set `isdefaultversion` "true". Defaults to "false".
+* `target` (stringarray, optional): the set of targets to which this nodedef is restricted. By default, a nodedef is considered universal, not restricted to any specific targets, but it is possible that certain targets may have different parameter names or usage for the same node.
+* `uiname` (string, optional): an alternative "node" value for this nodedef to be displayed in the UI. If `uiname` is not provided, then `node` is the presumed UI node value for the nodedef. This is most useful when the <nodedef> defines a namespace, so the user doesn't need to see a full namespaced path for the node.
+* `internalgeomprops` (stringarray, optional): a list of MaterialX geometric properties (e.g. "position", "normal", "texcoord", etc. or any name defined by a <geompropdef> element) that the node expects to be able to access internally. This metadata hint allows code generators to ensure this data is available and can be used for error checking. `Internalgeomprops` is most useful for nodes whose implementation is defined by external code; it is not necessary for nodegraph-defined nodes, as the list of geometric properties accessed can be determined by examining the nodegraph.
+
+Custom nodes are allowed to overload a single `node` name by providing multiple <nodedef> elements with different combinations of input and output types. This overloading is permitted both for custom `node` names and for the standard MaterialX node set. Within the scope of a single MaterialX document and its included content, no two <nodedef> elements with an identical combination of input and output types for the same target and version may be provided for a single `node` name. It is recommended that all <nodedef> variations for a `node` use exactly the same set of input names differing only in their types, with no variation adding or removing any inputs. It is also recommended that newer versions of nodes be fully backward-compatible with earlier versions (including default values of input) so that a change in default version of a node does not break functionality; if this is not possible, using a different `node` name is recommended.
+
+The `inherit` attribute may be provided to allow one <nodedef> to inherit from another: this is most useful for defining additional inputs in a target- or version-specific <nodedef>, inheriting from a generic, canonical definition of a node or shader. NodeDefs which inherit from another nodedef may not re-declare <output>s from the parent nodedef, only add additional new <output>s.
+
+NodeDefs must define one or more child <output> elements within the <nodedef> to state the name and type of each output; for nodes defined using a nodegraph, the names and types of the outputs must agree with the <output> elements in the nodegraph. The output name for a single-output <nodedef> is less important, as any connection made to the output of a single-output node will succeed regardless of the actual `name` referenced, although by convention, the name "out" is preferred for single-output nodes. See the [**NodeDef Output Elements**](#nodedef-output-elements) section below for details.
+
+
+#### NodeDef Parameter Interface
+
+The parameter interface of a custom node is specified via a set of child <input> and <token> elements of the <nodedef>, while documentation of the folder structure of a node may be defined using a number of <uifolder> elements, each of which may provide a doc attribute to provide documentation for that folder layer. A <uifolder> element may not contain any other elements; in particular, the <input>s and <token>s of the nodedef interface must be direct children of the <nodedef>. Nested folders may be indicated using a full path for the folder, with a "/" separator between folder levels.
+
+```xml
+
+
+
+
+ ...input and token definitions...
+
+```
+
+
+#### NodeDef Input Elements
+
+**Input** elements are used within a <nodedef> to declare the spatially-varying and uniform inputs for a node:
+
+```xml
+
+```
+
+Attributes for NodeDef Input elements:
+
+* `name` (string, required): the name of the shader input
+* `type` (string, required): the MaterialX type of the shader input
+* `value` (same type as `type`, optional): a default value for this input, to be used if the input remains unconnected and is not otherwise assigned a value
+* `uniform` (boolean, optional): if set to "true", then this input can only take uniform values and may only be connected to the outputs of <constant> nodes or any other node whose output is explicitly declared to be "uniform" (optionally through a number of <dot> nodes), but not to the outputs of other (non-"uniform") nodes. `uniform` must be set to true for string and filename-type inputs.
+* `defaultgeomprop` (string, optional): for vector2 or vector3 inputs, the name of an intrinsic geometric property that provides the default value for this input, must be one of "position", "normal", "tangent", "bitangent" or "texcoord" or vector3-type custom geometric property for vector3 inputs, or "texcoord" or vector2-type custom geometric property for vector2 inputs. For standard geometric properties, this is effectively the same as declaring a default connection of the input to a Geometric Node with default input values. May not be specified on uniform inputs.
+* `enum` (stringarray, optional): a comma-separated non-exclusive list of string value descriptors that the input couldmayis allowed to take: for string- and stringarray-type inputs, these are the actual values (or values per array index for stringarrays); for other types, these are the "enum" labels e.g. as shown in the application user interface for each of the actual underlying values specified by `enumvalues`. The enum list can be thought of as a list of commonly used values or UI labels for the input rather than a strict list, and MaterialX itself does not enforce that a specified input enum value is actually in this list, with the exception that if the input is a "string" (or "stringarray") type and an enum list is provided, then the value(s) must in fact be one of the enum stringarray values.
+* `enumvalues` (typearray, optional): for non-string/stringarray types, a comma-separated list of values of the same base type as the <input>, representing the values that would be used if the corresponding `enum` string was chosen in the UI. MaterialX itself does not enforce that a specified input value is actually in this list. Note that implementations are allowed to redefine `enumvalues` (but not `enum`) for specific targets: see the [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements) section below.
+* `colorspace` (string, optional): for color3- or color4-type inputs, the expected colorspace for this input. Nodedef inputs do not typically specify a colorspace; the most common use case is to specify `colorspace="none"` for inputs that are color-like but which should not be affected by colorspace conversions.
+* `unittype` (string, optional): the type of unit for this input, e.g. "distance", which must be defined by a <unittypedef>. Default is to not specify a unittype. Only float-, vectorN- and filename-type inputs may specify a `unittype`.
+* `unit` (string, optional): the specific unit for this input. Nodedef inputs do not typically specify a unit; if it does, that would indicate that the implementation of that node expects values to be specified in that unit, and that any invocation of that node using a different unit should be converted to the nodedef-specified unit for that input rather than to the application's scene unit. The most common instance of this is for angular values, where a nodedef might specify that it expects values to be given in degrees.
+* `uiname` (string, optional): an alternative name for this input as it appears in the UI. If `uiname` is not provided, then `name` is the presumed UI name for the input.
+* `uifolder` (attribute, string, optional): the pathed name of the folder in which this input appears in the UI, using a "/" character as a separator for nested UI folders.
+* `uimin` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the minimum value that the UI allows for this particular value. MaterialX itself does not enforce this as an actual minimum value.
+* `uimax` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the maximum value that the UI allows for this particular value. MaterialX itself does not enforce this as an actual maximum value.
+* `uisoftmin` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, a suggested minimum UI slider value for this input, should be >= `uimin`. MaterialX itself does not enforce this as an actual minimum value.
+* `uisoftmax` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, a suggested maximum UI slider value for this inputs, should be <= `uimax`. MaterialX itself does not enforce this as an actual maximum value.
+* `uistep` (integer or float or colorN or vectorN, optional): for inputs of type integer, float, colorN or vectorN, the increment size that the UI would increment or decrement a component of the input value.
+* `hint` (string): A hint to help code generators understand how the input may be used. The following hints for nodedef inputs are currently defined:
+ * "transparency": the input is indicating a level of shading transparency.
+ * "opacity": the input is indicating a level of shading opacity (inverse of transparency).
+ * "anisotropy": the presence of this hint on an input indicates that anisotropic reflections _may_ (but not necessarily) be taking place; if no input on a shading node(def) defines an "anisotropic" hint, then some implementations may use this as an optimization to allow only isotropic reflections.
+
+It is permissible to define a `value` or a `defaultgeomprop` for an input but not both. If neither `value` or `defaultgeomprop` are defined, then the input becomes required, and any invocation of the custom node without providing a value or connection for this input would be in error.
+
+
+#### NodeDef Token Elements
+
+**Token** elements are used within a <nodedef> to declare uniform "interface token" string-substitution values to be referenced and substituted within filenames used in a node's nodegraph implementation:
+
+```xml
+
+```
+
+Attributes for NodeDef Token elements:
+
+* `name` (string, required): the name of the token
+* `type` (string, required): the MaterialX type of the token; when the token's value is substituted into a filename, the token value will be cast to a string, so string or integer types are recommended for tokens, although any MaterialX type is permitted.
+* `value` (same type as `type`, optional): a default value for this token, to be used if the node is invoked without a value defined for this token. If a default value is not defined, then the token becomes required, so any invocation of the custom node without a value assigned to that token would be in error.
+* `enum` (stringarray, optional): a comma-separated non-exclusive list of string value descriptors that the token could take: for string-type tokens, these are the actual values; for other types, these are the "enum" labels e.g. as shown in the application user interface for each of the actual underlying values specified by enumvalues. The enum list can be thought of as a list of commonly used values or UI labels for the input rather than a strict list, and MaterialX itself does not enforce that a specified token enum value is actually in this list, with the exception that if the input is a "string" (or "stringarray") type and an enum list is provided, then the value(s) must in fact be one of the enum stringarray values.
+* `enumvalues` (typearray, optional): for non-string types, a comma-separated list of values of the same base type as the <token>, representing the values that would be used if the corresponding enum string was chosen in the UI. MaterialX itself does not enforce that a specified token value is actually in this list. Note that implementations are allowed to redefine enumvalues (but not enum) for specific targets: see the [Custom Node Definition Using Implementation Elements](#custom-node-definition-using-implementation-elements) section below.
+* `uiname` (string, optional): an alternative name for this token as it appears in the UI. If `uiname` is not provided, then `name` is the presumed UI name for the token.
+* `uifolder` (string, optional): the pathed name of the folder in which this token appears in the UI, using a "/" character as a separator for nested UI folders.
+
+Please see the [Example Pre-Shader Compositing Material](#example-pre-shader-compositing-material) in the [Material Nodes](#material-nodes) section below for an example of how Tokens are used.
+
+
+#### NodeDef Output Elements
+
+**Output** elements are used within a <nodedef> to declare an output for node definitions, including the output's name, type, and default value or "defaultinput" connection:
+
+```xml
+
+```
+
+Attributes for NodeDef Output elements:
+
+* `name` (string, required): the name of the output. For nodes with a single output, the name "out" is preferred.
+* `type` (string, required): the MaterialX type of the output.
+* `defaultinput` (string, optional): the name of an <input> element within the <nodedef>, which must be the same type as `type`, that will be passed through unmodified by applications that don’t have an implementation for this node.
+* `default` (same type as `type`, optional): a constant value which will be output by applications that don’t have an implementation for this node, or if a `defaultinput` input is specified but that input is not connected.
+
+The <output> elements for NodeDefs are similar to those for NodeGraph outputs, except that they may define default output values for the node but may not define a connection to another node (except for the `defaultinput` pass-through connection declaration) or any output file-related attributes such as width, height, colorspace or bitdepth.
+
+
+
+### Custom Node Definition Using Implementation Elements
+
+Once the parameter interface of a custom node has been declared through a <nodedef>, MaterialX provides two methods for precisely defining its functionality: via an <implementation> element that references external source code, or via a <nodegraph> element that composes the required functionality from existing nodes. Providing a definition for a custom node is optional in MaterialX, but is recommended for maximum clarity and portability.
+
+**Implementation** elements are used to associate external function source code with a specific nodedef. Implementation elements support the following attributes:
+
+* `name` (string, required): a unique name for this <implementation>
+* `nodedef` (string, required): the name of the <nodedef> for which this <implementation> applies
+* `nodegraph` (string, optional): the name of the <nodegraph> which is the implementation for the specified nodedef; see the [Custom Node Definition Using Node Graphs](#custom-node-definition-using-node-graphs) section below.
+* `implname` (string, optional): an alternative name for this node for the specified target; this allows one to say that for this particular target, the node/shader is called something else but is functionally equivalent to the node described by the nodedef. Note that node graphs in MaterialX documents should always use the node names defined in the nodedefs, never implementation-specific names.
+* `file` (filename, optional): the URI of an external file containing the source code for the entry point of this particular node template. This file may contain source code for other templates of the same custom node, and/or for other custom nodes.
+* `sourcecode` (string, optional): a string containing the actual source code for the node.
+* `function` (string, optional): the name of a function within the given source code that contains the implementation of this node. If this attribute is not given it is assumed the source code is an inline expression for a shader code generator like ShaderGen. Please refer to appropriate language specifications and developer guides (such as the ShaderGeneration.md file in the GitHub documents/DeveloperGuide directory) for valid syntax for using inline code.
+* `target` (stringarray, optional): the set of targets to which this implementation is restricted. By default, an implementation is considered applicable to all targets that the referenced nodedef applies to. If the referenced <nodedef> also specifies a target, then this `target` must be a subset of the nodedef's target list.
+* `format` (string, optional): the format used by the given source code, typically "shader" if the source code is a complete shader that can be compiled and executed as is by a target renderer, or "fragment" if the source code is a code fragment that requires processing of a code generator before it can be compiled and executed. Default is "shader".
+
+An <implementation> may define a `file` or `sourcecode` attribute, or neither, but not both. If an <implementation> element specifies a `target` with no `file` or `sourcecode`, then it is interpreted purely as documentation that a private definition exists for the given target. Because the definition in an <implementation> may be restricted to specific targets, a <nodedef> that is defined with such restrictions may not be available in all applications; for this reason, a <nodedef> that is defined through an <implementation> is expected to provide a value for `default` and/or `defaultinput` when possible, specifying the expected behavior when no definition for the given node can be found. It should be noted that specifying `target` is intended to help applications differentiate between different implementations of nodes and implies compatibility for specific situations, but does not necessarily guarantee compatibility: they are intended to be hints about the particular implementation, and it is up to the host application to determine which <implementation>, if any, is appropriate for any particular use.
+
+Because the names used for node inputs (such as "normal" or "default") may conflict with the reserved words in various shading languages, or may simply be different for specific targets, <implementation> elements may contain a number of <input> elements to remap the `name`s of <input>s as specified in the <nodedef> to different `implname`s to indicate what the input name is actually called in the implementation's code. Only the inputs that need to be remapped to new `implname`s need to be listed; for each, it is recommended that the `type` of that input be listed for clarity, but if specified, it must match the type specified in the <nodedef>: <implementation>s are not allowed to change the type or any other attribute defined in the <nodedef>. In this example, the <implementation> declares that the "default" input defined in the "ND_image_color3" nodedef is actually called "default_value" in the "mx_image_color" function:
+
+```xml
+
+
+
+```
+
+For uniform inputs and tokens whose nodedef description includes an enum list of allowable values, individual implementations may associate different target-specific resolved values for them potentially of a different type; these may be described by providing an `enumvalues` attribute on the uniform input or token within an <implementation> and if appropriate, an `impltype` to declare the target-specific type of these enumvalues. Note that if the type of an enum input in the nodedef is an array type, then the `impltype` (if specified) must also be an array type, while `enumvalues` is a list of values of the base (non-array) type. The following <implementation> states that for the "mystudio" target, the uaddressmode and vaddressmode inputs of the "image" node are actually called "extrapolate_u" and "extrapolate_v", are integers rather than strings, and take different values (e.g. "clamp" is 2):
+
+```xml
+
+
+
+
+
+```
+
+
+#### Example Custom Nodes Defined by External File Implementations
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+This example defines two templates for a custom operator node called "mariBlend" (one operating on color3 values, and one operating on floats), and one template for a custom source node called "mariCustomNoise". Implementations of these functions have been defined in both OSL and GLSL. There is also in this example an alternate implementation of the "mariCustomNoise" function specifically for VRay, as if the author had determined that the generic OSL version was not appropriate for that renderer.
+
+Here is an example of a two-output node definition and external implementation declaration.
+
+```xml
+
+
+
+
+
+
+
+```
+
+
+
+### Custom Node Definition Using Node Graphs
+
+Alternatively, a custom node's implementation may be described using a Node Graph. A <nodegraph> element wraps a graph of standard or custom nodes, taking the inputs and producing the output(s) described in the specified <nodedef>.
+
+A **<nodegraph>** element consists of at least one node element and at least one <output> element contained within a <nodegraph> element. Nodegraph elements may be one of two types: a **functional nodegraph**, which is the implementation of a node defined by a separate <nodedef>, or a **compound nodegraph**, which is a set of nodes grouped together into a nodegraph container. A functional nodegraph must either itself specify a `nodedef` attribute or be referenced by an <implementation> element with a "nodegraph" attribute, while a compound nodegraph may do neither but may optionally specify one or more <input> and/or <token> elements.
+
+
+#### Functional Nodegraphs
+
+A **functional nodegraph** is a nodegraph-based implementation for a specified <nodedef>, with the <nodedef> declaring the set of inputs that the nodegraph accepts: a functional nodegraph may not itself specify any direct child input elements.
+
+```xml
+
+ ...node element(s)...
+ ...output element(s)...
+
+```
+
+or
+
+```xml
+
+ ...node element(s)...
+ ...output element(s)...
+
+
+```
+
+The type(s) of the <output>(s) of the <nodedef> and the type(s) of the nodegraph <output>(s) must agree, and if there are multiple outputs, then the `name`s of the <output>s in the <nodegraph> and <nodedef> must also agree. The inputs and tokens of the <nodedef> can be referenced within <input> and <token> elements of nodes within the nodegraph implementation using `interfacename` attributes in place of `value` or `nodename` attributes, e.g. a nodedef input "i2" and interface token "diffmap" could be referenced as follows:
+
+```xml
+
+
+```
+
+Note that a uniform <input> of a node within the nodegraph may use `interfacename` to reference a uniform input in the nodedef, but it may not reference a non-uniform nodedef input.
+
+
+#### Compound Nodegraphs
+
+A **compound <nodegraph>** element may specify one or more child <input> and/or <token> elements. In this case, the <nodegraph> functions as a collapsible "wrapper" for the contained nodes.
+
+```xml
+
+ [...input and/or token element(s)...]
+ ...node and/or (compound) nodegraph element(s)...
+ ...output element(s)...
+
+```
+
+A compound nodegraph provides a set of named input and output connection ports which may be referenced by its contained nodes using `interfacename` attributes, and interface token names whose values may be substituted into filenames used within the nodegraph; nodes within this <nodegraph> adopt the context of that nodegraph. The <input>s and <token>s of a compound nodegraph may also be connected to other nodes outside the <nodegraph> at the same scope as the <nodegraph> itself using `nodename` attributes; inputs of nodes within a compound nodegraph may only be connected to the outputs of other nodes within the same compound nodegraph, or to the input connection ports using interfacename. This is in contrast to a <backdrop> node whose contained nodes connect directly to nodes outside the backdrop at the same level of context without going through an intermediate named <input>. A <nodegraph> element of this form may specify the same float `width` and `height` and boolean `minimized` attributes as <backdrop> nodes. Inputs of other nodes, or the inputs of a compound nodegraph, can connect to an output of a (different) compound nodegraph using a `nodegraph` attribute (and for multiple-output compound nodegraphs, an `output` attribute as well) on a node's <input>.
+
+It is permissible to define multiple nodegraph- and/or file-based implementations for a custom node for the same combination of input and output types, as long as the specified `version`/`target`/`format` combinations are unique, e.g. one implementation for target "oslpattern" and another for "glsl", or one "osl" target with `format="shader"` and another with `format="fragment"`. It is allowable for there to be both a <nodegraph> and an <implementation> for the same nodedef target/version, with the <implementation> generally prevailing in order to allow for optimized native-code node implementations, although ultimately it would be up to the host application to determine which implementation to actually use.
+
+
+#### Example Custom Node Defined by a Nodegraph
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+The inputs of the nodegraph are declared by the <nodedef>, and the nodes within the nodegraph reference those inputs using `interfacename` attributes. The "fg" and "bg" inputs provide default values which are used if an input is left unconnected when the custom node is used, and the "amount" input defines a default value which will be used if invocations of the node do not explicitly provide a value for "amount".
+
+
+### Custom Node Use
+
+Once defined with a <nodedef>, using a custom node within a node graph follows the same syntax as any other standard node: the name of the element is the name of the custom node, and the MaterialX type of the node's output is required; the custom node's child elements define connections of inputs to other node outputs as well as any input values for the custom node.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+```
+
+When invoking nodes with multiple outputs, the `type` of the node should be declared as "multioutput", and other node inputs connecting to an output of the node must include an `output` attribute to specify which output of the node to connect to:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+
+## Shader Nodes
+
+Custom nodes that output data types with a "shader" semantic are referred to in MaterialX as "Shader Nodes". Shaders, along with their inputs, are declared using the same <nodedef>, <implementation> and <nodegraph> elements described above:
+
+```xml
+
+ ...input declarations...
+
+
+```
+
+The attributes for <nodedef> elements as they pertain to the declaration of shaders are:
+
+* `name` (string, required): a user-chosen name for this shader node definition element.
+* `node` (string, required): the name of the shader node being defined, which typically matches the name of an associated shader function such as “blinn_phong”, “Disney_BRDF_2012”, “volumecloud_vol”. Just as for custom nodes, this shading program may be defined precisely through an <implementation> or <nodegraph>, or left to the application to locate by name using any shader definition method that it chooses.
+
+The child <output> element within the <nodedef> defines the "data type" of the output for this shader, which must have been defined with a "shader" semantic; see the [Custom Data Types](#custom-data-types) section above and discussion below for details.
+
+NodeDef elements defining shader nodes do not typically include `default` or `defaultinput` attributes, though they are permitted using the syntax described in the [Custom Data Types](#custom-data-types) section if the output type of the shader node is not a blind data type.
+
+As mentioned in the [Custom Data Types](#custom-data-types) section earlier, the standard MaterialX distribution includes the following standard data types for shaders:
+
+```xml
+
+
+
+
+```
+
+These types all declare that they have "shader" semantic, but define different contexts in which a rendering target should interpret the output of the shader node. For a shading language based on deferred lighting computations (e.g. OSL), a shader-semantic data type is equivalent to a radiance closure. For a shading language based on in-line lighting computations (e.g. GLSL), a shader-semantic data type is equivalent to the final output values of the shader.
+
+Instantiation of shader nodes to give them specific values is done the same way as instantiating any other node type:
+
+```xml
+
+
+
+
+
+```
+
+Instantiated shader nodes can also inherit from other shader nodes of the same class:
+
+```xml
+
+
+
+```
+
+Declarations of shader node source implementations are accomplished using either <implementation> elements for external source file declarations, or functional nodegraphs for nodegraph-based definitions.
+
+As with non-shader custom nodes, **Input** elements are used within a <nodedef> to declare the input ports for a shader node.
+
+An input with a shader-semantic type may be given a value of "" to indicate no shader node is connected to this input; this is typically the default for shader-semantic inputs of operator nodes. It is up to applications to decide what to do with unconnected shader-semantic inputs.
+
+
+
+### Standard Library Shader Nodes
+
+The Standard MaterialX Library defines the following nodes and node variants operating on "shader"-semantic types. Standard library shaders do not respond to external illumination; please refer to the [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md#materialx-pbs-library) document for definitions of additional nodes and shader constructors which do respond to illumination.
+
+
+
+* **`surface_unlit`**: an unlit surface shader node, representing a surface that can emit and transmit light, but does not receive illumination from light sources or other surfaces. Output type surfaceshader.
+ * `emission` (float): the surface emission amount; default is 1.0
+ * `emission_color` (color3): surface emission color; default is (1, 1, 1)
+ * `transmission` (float): the surface transmission amount; default is 0
+ * `transmission_color` (color3): surface transmission color; default is (1, 1, 1)
+ * `opacity` (float): surface cutout opacity; default is 1.0
+
+
+
+* **`displacement`**: Constructs a displacement shader describing geometric modification to surfaces. Output type "displacementshader".
+ * `displacement` (float or vector3): Scalar (along the surface normal direction) or vector displacement (in (dPdu, dPdv, N) tangent/normal space) for each position. Default is 0.
+ * `scale` (float): Scale factor for the displacement vector. Default is 1.0.
+
+
+
+* **`mix`**: linear blend between two surface/displacement/volumeshader closures.
+ * `bg` (surface/displacement/volumeshader): the name of the background shader-semantic node
+ * `fg` (surface/displacement/volumeshader): the name of the foreground shader-semantic node
+ * `mix` (float): the blending factor used to mix the two input closures
+
+
+
+## Material Nodes
+
+Custom nodes that output data types with a "material" semantic are referred to in MaterialX as "Material Nodes". Material nodes typically have one or more "shader" semantic inputs which establish what shaders the material references; previous versions of MaterialX used <shaderref> elements to establish these shader-to-material connections. Material Nodes are declared using the same <nodedef> elements as described above:
+
+```xml
+
+
+ ...additional shader or input declarations...
+
+
+```
+
+The attributes for <nodedef> elements as they pertain to the declaration of materials are:
+
+* `name` (string, required): a user-chosen name for this material node definition element.
+* `node` (string, required): the name of the material node class being defined.
+
+The standard MaterialX distribution includes a single material type definition used as the output type for all material nodes:
+
+```xml
+
+```
+
+as well as definitions for three standard material nodes, all outputting type "material":
+
+
+
+* **`surfacematerial`**: a surface shading material.
+ * `surfaceshader` (surfaceshader): the name of the surfaceshader node.
+ * `backsurfaceshader` (surfaceshader): the name of the surfaceshader node to be used for the back surface of an object, if the geometry is two-sided. Default is "", meaning the `surfaceshader` shader will be used for both sides of a surface if the geometry is two-sided.
+ * `displacementshader` (displacementshader): the name of the displacementshader node to use; default is "" for no displacement.
+
+
+
+* **`volumematerial`**: a volume shading material.
+ * `volumeshader` (volumeshader): the name of the volumeshader node.
+
+
+
+* **`lightmaterial`**: a light shader material.
+ * `lightshader` (lightshader): the name of the lightshader node.
+
+Material nodes supporting multiple shaders of the same type for different rendering targets can be defined:
+
+```xml
+
+
+
+
+
+
+
+
+```
+
+Creating materials with specific values bound to shader inputs involves instantiating a Shader Node for each desired shader type and setting values on those shader nodes, and connecting the shader node(s) to the inputs of a Material Node:
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+```
+
+Alternatively, and perhaps more usefully, a complete network of multiple shader nodes of different types or for different targets along with a material node to collect them all can be packaged within a nodegraph, and the various inputs of the shader nodes and any other nodes connected to their inputs can be connected to a single material nodedef interface to provide parameter values for the entire multi-shader network. Because nodedef inputs can be referenced by more than one node, a single unified interface could be created for several shaders for different targets, and the networks for those targets could contain input value conversion nodes as needed to handle differences in parametrization or shading methodologies.
+
+
+#### Example Pre-Shader Compositing Material
+
+A material to blend between three different surface layers using mask textures. This example also demonstrates the use of the "target" attribute of a shader implementation element to define multiple renderer-specific shaders of the same type referenced within a single material, and the use of interface tokens to define texture filenames.
+
+```xml
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+```
+
+
+## Material Variants
+
+A Variant is a container for any number of uniform values for material inputs and interface tokens. One or more mutually-exclusive variants are defined as part of a <variantset>; variants may not be defined outside of a <variantset>.
+
+```xml
+
+
+
+
+
+
+ ...additional declarations for this variantset...
+
+```
+
+<Input> elements within a <variant> may only define a `value`, not a connection to a node or <output>.
+
+Example uses for variants include defining a number of allowable colors and texture tokens for different costume variations, and defining values for progressively increasing levels of damage to a model.
+
+Variants and variantsets are not intrinsically associated with any particular material; they merely state a number of values for a number of named inputs/tokens. However, variantsets may state that they are associated with specific shader-semantic nodes and/or <nodedef> declarations by providing stringarray-type `node` and/or `nodedef` attributes:
+
+```xml
+
+ ...
+
+ ...
+```
+
+Variants and variantsets can be defined in any MaterialX implementation, but because variants are applied to materials within a <look>, they can only be applied in applications supporting MaterialX Geometry Extensions; please see the [**VariantAssign Elements**](./MaterialX.GeomExts.md#variantassign-elements) section in that document for information on using material variants.
+
+
+# References
+
+[^1]:
+
diff --git a/MaterialX/documents/Specification/MaterialX.StandardNodes.md b/MaterialX/documents/Specification/MaterialX.StandardNodes.md
deleted file mode 100644
index e515b29..0000000
--- a/MaterialX/documents/Specification/MaterialX.StandardNodes.md
+++ /dev/null
@@ -1,2363 +0,0 @@
-
-
-
-# MaterialX Standard Nodes
-
-**Version 1.39**
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-November 9, 2025
-
-
-# Introduction
-
-The MaterialX Specification defines a content schema to describe materials, image processing and shading networks and how the nodes in those networks access textural and geometric information, in a platform- and shading-language-independent manner.
-
-This document describes a specific set of **Standard Nodes** that can be used to read and process image and geometric attribute data, as well as create new image data procedurally. These "stdlib" nodes are an essential core part of all MaterialX implementations. Additional nodes are described in companion documents [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md) and [**MaterialX NPR Shading Nodes**](./MaterialX.NPRSpec.md).
-
-In the node descriptions below, tables define the names, allowable types, default values, and where appropriate, accepted values for the node's inputs and output(s). For outputs, the Default value specified is the value output (or passed through from an input) if the node is disabled. Node descriptions with multiple tables accept any combination of inputs/outputs/types described within any single table.
-
-## Table of Contents
-
-**[Introduction](#introduction)**
-
-**[Standard Source Nodes](#standard-source-nodes)**
- [Texture Nodes](#texture-nodes)
- [Texture Node Notes](#texture-node-notes)
- [Procedural Nodes](#procedural-nodes)
- [Procedural Node Notes](#procedural-node-notes)
- [Noise Nodes](#noise-nodes)
- [Noise Node Notes](#noise-node-notes)
- [Shape Nodes](#shape-nodes)
- [Geometric Nodes](#geometric-nodes)
- [Geometric Node Notes](#geometric-node-notes)
- [Application Nodes](#application-nodes)
- [Application Node Notes](#application-node-notes)
-
-**[Standard Operator Nodes](#standard-operator-nodes)**
- [Math Nodes](#math-nodes)
- [Logical Operator Nodes](#logical-operator-nodes)
- [Adjustment Nodes](#adjustment-nodes)
- [Compositing Nodes](#compositing-nodes)
- [Conditional Nodes](#conditional-nodes)
- [Channel Nodes](#channel-nodes)
- [Convolution Nodes](#convolution-nodes)
-
-**[Standard Shader Nodes](#standard-shader-nodes)**
-
-
-
-
-# Standard Source Nodes
-
-Source nodes use external data and/or procedural functions to form an output; they do not have any required inputs. Each source node must define its output type.
-
-This section defines the Source Nodes that all MaterialX implementations are expected to support. Standard Source Nodes are grouped into the following classifications: [Texture Nodes](#texture-nodes), [Procedural Nodes](#procedural-nodes), [Noise Nodes](#noise-nodes), [Shape Nodes](#shape-nodes), [Geometric Nodes](#geometric-nodes) and [Application Nodes](#application-nodes).
-
-
-## Texture Nodes
-
-Texture nodes are used to read filtered image data from image or texture map files for processing within a node graph.
-
-```xml
-
-
-
-
-
-
-
-
-```
-
-Standard Texture nodes:
-
-
-
-### `image`
-
-Samples data from a single image, or from a layer within a multi-layer image. When used in the context of rendering a geometry, the image is mapped onto the geometry based on geometry UV coordinates, with the lower-left corner of an image mapping to the (0,0) UV coordinate (or to the fractional (0,0) UV coordinate for tiled images).
-
-The type of the <image> node determines the number of channels output, which may be less than the number of channels in the image file, outputting the first N channels from the image file. So a `float` <image> would return the Red channel of an RGB image, and a `color3` <image> would return the RGB channels of an RGBA image. If the type of the <image> node has more channels than the referenced image file, then the output will contain zero values in all channels beyond the N channels of the image file.
-
-The `file` input value can include one or more substitutions to change the file name that is accessed, as described in the [Filename Substitutions](./MaterialX.Specification.md#filename-substitutions) section in the main Specification document.
-
-If no value for `layer` is provided and the input file has multiple layers, then the "default" layer will be used, or "rgba" if there is no "default" layer. Note: the number of channels defined by the type of the `image` must match the number of channels in the named layer.
-
-The `default` input is the default value to use if the file reference can not be resolved (e.g. if a geometry token, interface token, or hostattr is included in the filename but no substitution value or default is defined, or if the resolved file URI cannot be read), or if the specified layer does not exist in the file. The default value must be the same type as the <image> element itself. If `default` is not defined, the default color value will be 0.0 in all channels.
-
-|Port |Description |Type |Default |Accepted Values |
-|----------------|-----------------------------------------------------------------------------------------------------------------|----------------------|---------|---------------------------------|
-|`file` |The URI of the image file |filename |__empty__| |
-|`layer` |The name of the layer to extract from a multi-layer input file |string |__empty__| |
-|`default` |A default value to use if the file reference can not be resolved |Same as `out` |__zero__ | |
-|`texcoord` |The 2D texture coordinate at which the image data is read |vector2 |_UV0_ | |
-|`uaddressmode` |Determines how U coordinates outside the 0-1 range are processed before sampling the image |string |periodic |constant, clamp, periodic, mirror|
-|`vaddressmode` |Determines how V coordinates outside the 0-1 range are processed before sampling the image |string |periodic |constant, clamp, periodic, mirror|
-|`filtertype` |The type of texture filtering to use |string |linear |closest, linear, cubic |
-|`framerange` |A string "minframe-maxframe", e.g. "10-99", to specify the range of frames that the image file is allowed to have|string |__empty__| |
-|`frameoffset` |A number that is added to the current frame number to get the image file frame number |integer |0 | |
-|`frameendaction`|What to do when the resolved image frame number is outside the `framerange` range |string |constant |constant, clamp, periodic, mirror|
-|`out` |Output: the sampled texture value |float, colorN, vectorN|__zero__ | |
-
-
-
-### `tiledimage`
-Samples data from a single image, with provisions for tiling and offsetting the image across UV space.
-
-The `file` input can include one or more substitutions to change the file name that is accessed, as described in the [Filename Substitutions](./MaterialX.Specification.md#filename-substitutions) section in the main Specification document.
-
-|Port |Description |Type |Default |Accepted Values |
-|--------------------|-----------------------------------------------------------------------------------------------------------------|----------------------|---------|---------------------------------|
-|`file` |The URI of the image file |filename |__empty__| |
-|`default` |A default value to use if the file reference can not be resolved |Same as `out` |__zero__ | |
-|`texcoord` |The 2D texture coordinate at which the image data is read |vector2 |_UV0_ | |
-|`uvtiling` |The tiling rate for the given image along the U and V axes |vector2 |1.0, 1.0 | |
-|`uvoffset` |The offset for the given image along the U and V axes |vector2 |0.0, 0.0 | |
-|`realworldimagesize`|The real-world size represented by the file image |vector2 |1.0, 1.0 | |
-|`realworldtilesize` |The real-world size of a single square 0-1 UV tile |vector2 |1.0, 1.0 | |
-|`filtertype` |The type of texture filtering to use |string |linear |closest, linear, cubic |
-|`framerange` |A string "minframe-maxframe", e.g. "10-99", to specify the range of frames that the image file is allowed to have|string |__empty__| |
-|`frameoffset` |A number that is added to the current frame number to get the image file frame number |integer |0 | |
-|`frameendaction` |What to do when the resolved image frame number is outside the `framerange` range |string |constant |constant, clamp, periodic, mirror|
-|`out` |Output: the sampled texture value |float, colorN, vectorN|__zero__ | |
-
-
-
-### `latlongimage`
-Samples an equiangular map along a view direction with adjustable latitudinal offset.
-
-The `file` input can include one or more substitutions to change the file name that is accessed, as described in the [Filename Substitutions](./MaterialX.Specification.md#filename-substitutions) section in the main Specification document.
-
-|Port |Description |Type |Default |
-|----------|-----------------------------------------------------------------------------------|--------|-------------|
-|`file` |The URI of the image file |filename|__empty__ |
-|`default` |A default value to use if the file reference can not be resolved |color3 |0.0, 0.0, 0.0|
-|`viewdir` |The view direction determining the value sampled from the projected equiangular map|vector3 |0.0, 0.0, 1.0|
-|`rotation`|The longitudinal sampling offset, in degrees |float |0.0 |
-|`out` |Output: the sampled texture value |color3 |0.0, 0.0, 0.0|
-
-
-
-### `hextiledimage`
-Samples data from a single image, with provisions for hex-tiling and randomizing the image across UV space.
-
-The `file` input can include one or more substitutions to change the file name that is accessed, as described in the [Filename Substitutions](./MaterialX.Specification.md#filename-substitutions) section in the main Specification document.
-
-The `lumacoeffs` input represents the luma coefficients of the current working color space. If no specific color space can be determined, the ACEScg (ap1) luma coefficients [0.2722287, 0.6740818, 0.0536895] will be used. Applications which support color management systems may choose to retrieve the luma coefficients of the working colorspace from the CMS to pass to the node's implementation directly, rather than exposing it to the user.
-
-|Port |Description |Type |Default |
-|--------------------|---------------------------------------------------------------------------------------------------|-----------------|-------------------------------|
-|`file` |The URI of the image file |filename |__empty__ |
-|`default` |A default value to use if the file reference can not be resolved |Same as `out` |__zero__ |
-|`texcoord` |The 2D texture coordinate at which the image data is read |vector2 |_UV0_ |
-|`tiling` |The tiling rate for the given image along the U and V axes |vector2 |1.0, 1.0 |
-|`rotation` |Per-tile rotation randomness in degrees |float |0.0 |
-|`rotationrange` |Range in degrees used to randomize rotation for each tile |vector2 |0.0, 360.0 |
-|`scale` |Per-tile scale randomness multiplier applied to tile size |float |1.0 |
-|`scalerange` |Range of scale multipliers used to randomize tile scale |vector2 |0.5, 2.0 |
-|`offset` |Per-tile translation randomness in UV units |float |1.0 |
-|`offsetrange` |Range of offset values in UV units used to randomize tile positions |vector2 |0.0, 1.0 |
-|`falloff` |Falloff width used to blend neighboring tiles at their edges; larger values produce smoother blends|float |0.5 |
-|`falloffcontrast` |Contrast applied to the falloff blending to sharpen (values >1) or soften (values <1) transitions |float |0.5 |
-|`lumacoeffs` |The luma coefficients of the current working color space |color3 |0.2722287, 0.6740818, 0.0536895|
-|`out` |Output: the sampled texture value |colorN |__zero__ |
-
-
-
-### `triplanarprojection`
-Samples data from three images (or layers within multi-layer images), and projects a tiled representation of the images along each of the three respective coordinate axes, computing a weighted blend of the three samples using the geometric normal.
-
-|Port |Description |Type |Default |Accepted Values |
-|----------------|-----------------------------------------------------------------------------------------------------------------|----------------------|---------|---------------------------------|
-|`filex` |The URI of the image file to be projected in the direction from the +X axis back toward the origin |filename |__empty__| |
-|`filey` |The URI of the image file to be projected in the direction from the +Y axis back toward the origin |filename |__empty__| |
-|`filez` |The URI of the image file to be projected in the direction from the +Z axis back toward the origin |filename |__empty__| |
-|`layerx` |The name of the layer to extract from a multi-layer input file for the X-axis projection |string |__empty__| |
-|`layery` |The name of the layer to extract from a multi-layer input file for the Y-axis projection |string |__empty__| |
-|`layerz` |The name of the layer to extract from a multi-layer input file for the Z-axis projection |string |__empty__| |
-|`default` |A default value to use if the file reference can not be resolved |Same as `out` |__zero__ | |
-|`position` |A spatially-varying input specifying the 3D position at which the projection is evaluated |vector3 |_Pobject_| |
-|`normal` |A spatially-varying input specifying the 3D normal vector used for blending |vector3 |_Nobject_| |
-|`upaxis` |Which axis is considered to be 'up', either 0 for X, 1 for Y, or 2 for Z |integer |2 |0, 1, 2 |
-|`blend` |Weighting factor for blending samples using the geometric normal, with higher values giving softer blending |float |1.0 | |
-|`filtertype` |The type of texture filtering to use |string |linear |closest, linear, cubic |
-|`framerange` |A string "minframe-maxframe", e.g. "10-99", to specify the range of frames that the image file is allowed to have|string |__empty__| |
-|`frameoffset` |A number that is added to the current frame number to get the image file frame number |integer |0 | |
-|`frameendaction`|What to do when the resolved image frame number is outside the `framerange` range |string |constant |constant, clamp, periodic, mirror|
-|`out` |Output: the blended texture value |float, colorN, vectorN|__zero__ | |
-
-
-### Texture Node Notes
-
-
-
-The following values are supported by `uaddressmode` and `vaddressmode` inputs of Texture nodes:
-
-* “constant”: Texture coordinates outside the 0-1 range return the value of the node's `default` input.
-* “clamp”: Texture coordinates are clamped to the 0-1 range before sampling the image.
-* “periodic”: Texture coordinates outside the 0-1 range "wrap around", effectively being processed by a modulo 1 operation before sampling the image.
-* "mirror": Texture coordinates outside the 0-1 range will be mirrored back into the 0-1 range, e.g. u=-0.01 will return the u=0.01 texture coordinate value, and u=1.01 will return the u=0.99 texture coordinate value.
-
-
-
-
-The `filtertype` input for Texture nodes supports options `closest` (nearest-neighbor single-sample), `linear`, and `cubic`.
-
-
-
-
-Texture nodes using `file*` inputs also support the following inputs to handle boundary conditions for image file frame ranges for all `file*` inputs:
-
-* `framerange` (uniform string): a string "_minframe_-_maxframe_", e.g. "10-99", to specify the range of frames that the image file is allowed to have, usually the range of image files on disk. Default is unbounded.
-* `frameoffset` (integer): a number that is added to the current frame number to get the image file frame number. E.g. if `frameoffset` is 25, then processing frame 100 will result in reading frame 125 from the imagefile sequence. Default is no frame offset.
-* `frameendaction` (uniform string): what to do when the resolved image frame number is outside the `framerange` range:
- * "constant": Return the value of the node's `default` input (default action)
- * "clamp": Hold the minframe image for all frames before _minframe_ and hold the maxframe image for all frames after _maxframe_
- * "periodic": Frame numbers "wrap around", so after the _maxframe_ it will start again at _minframe_ (and similar before _minframe_ wrapping back around to _maxframe_)
- * "mirror": Frame numbers "mirror" or "ping-pong" at the endpoints of framerange, so a read of the frame after _maxframe_ will return the image from frame _maxframe_-1, and a read of the frame before _minframe_ will return the image from frame _minframe_+1.
-
-Arbitrary frame number expressions and speed changes are not supported.
-
-
-
-## Procedural Nodes
-
-Procedural nodes are used to generate value data programmatically.
-
-```xml
-
-
-
-
-
-
-
-```
-
-Standard Procedural nodes:
-
-
-
-### `constant`
-Outputs a constant value.
-
-|Port |Description |Type |Default |
-|-------|------------------------------------|----------------------------------------|--------|
-|`value`|The value that will be sent to `out`|float, colorN, vectorN, boolean, integer|__zero__|
-|`out` |Output: `value` |Same as `value` |__zero__|
-
-|Port |Description |Type |Default|
-|-------|------------------------------------|---------------|-------|
-|`value`|The value that will be sent to `out`|matrixNN |__one__|
-|`out` |Output: `value` |Same as `value`|__one__|
-
-|Port |Description |Type |Default |
-|-------|------------------------------------|----------------|---------|
-|`value`|The value that will be sent to `out`|string, filename|__empty__|
-|`out` |Output: `value` |Same as `value` |__empty__|
-
-
-
-
-### `ramplr`
-A left-to-right linear value ramp.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------------|----------------------|--------|
-|`valuel` |Value at the left (U=0) edge |float, colorN, vectorN|__zero__|
-|`valuer` |Value at the right (U=1) edge |Same as `valuel` |__zero__|
-|`texcoord`|2D texture coordinate at which the ramp interpolation is evaluated |vector2 |_UV0_ |
-|`out` |Output: the interpolated ramp value |Same as `valuel` |__zero__|
-
-
-
-### `ramptb`
-A top-to-bottom linear value ramp.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------------|----------------------|--------|
-|`valuet` |Value at the top (V=1) edge |float, colorN, vectorN|__zero__|
-|`valueb` |Value at the bottom (V=0) edge |Same as `valuet` |__zero__|
-|`texcoord`|2D texture coordinate at which the ramp interpolation is evaluated |vector2 |_UV0_ |
-|`out` |Output: the interpolated ramp value |Same as `valuet` |__zero__|
-
-
-
-### `ramp4`
-A 4-corner bilinear value ramp.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------------|----------------------|--------|
-|`valuetl` |Value at the top-left (U=0, V=1) corner |float, colorN, vectorN|__zero__|
-|`valuetr` |Value at the top-right (U=1, V=1) corner |Same as `valuetl` |__zero__|
-|`valuebl` |Value at the bottom-left (U=0, V=0) corner |Same as `valuetl` |__zero__|
-|`valuebr` |Value at the bottom-right (U=1, V=0) corner |Same as `valuetl` |__zero__|
-|`texcoord`|2D texture coordinate at which the ramp interpolation is evaluated |vector2 |_UV0_ |
-|`out` |Output: the interpolated ramp value |Same as `valuetl` |__zero__|
-
-
-
-### `splitlr`
-A left-right split matte, split at a specified U value.
-
-|Port |Description |Type |Default |
-|----------|--------------------------------------------------------------------|----------------------|--------|
-|`valuel` |Value at the left (U=0) edge |float, colorN, vectorN|__zero__|
-|`valuer` |Value at the right (U=1) edge |Same as `valuel` |__zero__|
-|`center` |U-coordinate of the split; left of it is `valuel`, right is `valuer`|float |0.5 |
-|`texcoord`|2D texture coordinate at which the ramp interpolation is evaluated |vector2 |_UV0_ |
-|`out` |Output: the interpolated split value |Same as `valuel` |__zero__|
-
-
-
-### `splittb`
-A top-bottom split matte, split at a specified V value.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------------|----------------------|--------|
-|`valuet` |Value at the top (V=1) edge |float, colorN, vectorN|__zero__|
-|`valueb` |Value at the bottom (V=0) edge |Same as `valuet` |__zero__|
-|`center` |V-coordinate of the split; below it is `valueb`, above is `valuet` |float |0.5 |
-|`texcoord`|2D texture coordinate at which the ramp interpolation is evaluated |vector2 |_UV0_ |
-|`out` |Output: the interpolated split value |Same as `valuet` |__zero__|
-
-
-
-### `randomfloat`
-Produces a stable randomized float value between `min` and `max`, based on an input signal and optional `seed` value. Uses a 2d cellnoise function to produce the output.
-
-|Port |Description |Type |Default |
-|----------|-------------------------------------------------------------------|--------------|--------|
-|`in` |Initial randomization seed |float, integer|__zero__|
-|`min` |The minimum output value |float |__zero__|
-|`max` |The maximum output value |float |__one__ |
-|`seed` |Additional randomization seed |integer |__zero__|
-|`out` |Output: the randomized value |float |__zero__|
-
-
-
-### `randomcolor`
-Produces a randomized RGB color within a randomized hue, saturation and brightness range, based on an input signal and optional `seed` value. Output type color3.
-
-|Port |Description |Type |Default |
-|----------------|-------------------------------------------------------------|--------------|--------|
-|`in` |Initial randomization seed |float, integer|__zero__|
-|`huelow` |The minimum hue value |float |__zero__|
-|`huehigh` |The maximum hue value |float |__one__ |
-|`saturationlow` |The minimum saturation value |float |__zero__|
-|`saturationhigh`|The maximum saturation value |float |__one__ |
-|`brightnesslow` |The minimum brightness value |float |__zero__|
-|`brightnesshigh`|The maximum brightness value |float |__one__ |
-|`seed` |Additional randomization seed |integer |__zero__|
-|`out` |Output: the randomized RGB color value |color3 |__zero__|
-
-
-### Procedural Node Notes
-
-To scale or offset the input coordinates for `rampX` or `splitX` or any other node with a `texcoord` input, use a <place2d> node, or a <texcoord> or similar Geometric node processed by vector2 <multiply>, <rotate> and/or <add> nodes, and connect to the node's `texcoord` input.
-
-
-
-## Noise Nodes
-
-Noise nodes are used to generate value data using one of several procedural noise functions.
-
-```xml
-
-
-
-
-```
-
-Standard Noise nodes:
-
-
-
-### `noise2d`
-2D Perlin noise in 1, 2, 3 or 4 channels.
-
-|Port |Description |Type |Default |
-|-----------|---------------------------------------------------------|----------------------|--------|
-|`amplitude`|The center-to-peak amplitude of the noise |Same as `out` or float|__one__ |
-|`pivot` |The center value of the output noise |float |0.0 |
-|`texcoord` |The 2D texture coordinate at which the noise is evaluated|vector2 |_UV0_ |
-|`out` |Output: the computed noise value |float, vectorN |__zero__|
-
-
-
-### `noise3d`
-3D Perlin noise in 1, 2, 3 or 4 channels.
-
-|Port |Description |Type |Default |
-|-----------|-----------------------------------------------|----------------------|---------|
-|`amplitude`|The center-to-peak amplitude of the noise |Same as `out` or float|__one__ |
-|`pivot` |The center value of the output noise |float |0.0 |
-|`position` |The 3D position at which the noise is evaluated|vector3 |_Pobject_|
-|`out` |Output: the computed noise value |float, vectorN |__zero__ |
-
-
-
-### `fractal2d`
-Zero-centered 2D Fractal noise in 1, 2, 3 or 4 channels, created by summing several octaves of 2D Perlin noise, increasing the frequency and decreasing the amplitude at each octave.
-
-|Port |Description |Type |Default |
-|------------|---------------------------------------------------------------|----------------------|---------|
-|`amplitude` |The center-to-peak amplitude of the noise |Same as `out` or float|__one__ |
-|`octaves` |The number of octaves of noise to be summed |integer |3 |
-|`lacunarity`|The exponential scale between successive octaves of noise |float |2.0 |
-|`diminish` |The rate at which noise amplitude is diminished for each octave|float |0.5 |
-|`texcoord` |The 2D texture coordinate at which the noise is evaluated |vector2 |_UV0_ |
-|`out` |Output: the computed noise value |float, vectorN |__zero__ |
-
-
-
-### `fractal3d`
-Zero-centered 3D Fractal noise in 1, 2, 3 or 4 channels, created by summing several octaves of 3D Perlin noise, increasing the frequency and decreasing the amplitude at each octave.
-
-|Port |Description |Type |Default |
-|------------|---------------------------------------------------------------|----------------------|---------|
-|`amplitude` |The center-to-peak amplitude of the noise |Same as `out` or float|__one__ |
-|`octaves` |The number of octaves of noise to be summed |integer |3 |
-|`lacunarity`|The exponential scale between successive octaves of noise |float |2.0 |
-|`diminish` |The rate at which noise amplitude is diminished for each octave|float |0.5 |
-|`position` |The 3D position at which the noise is evaluated |vector3 |_Pobject_|
-|`out` |Output: the computed noise value |float, vectorN |__zero__ |
-
-
-
-### `cellnoise2d`
-2D cellular noise, 1 or 3 channels (type float or vector3).
-
-|Port |Description |Type |Default|
-|----------|---------------------------------------------------------|-------|-------|
-|`texcoord`|The 2D texture coordinate at which the noise is evaluated|vector2|_UV0_ |
-|`out` |Output: the computed noise value |float |0.0 |
-
-
-
-### `cellnoise3d`
-3D cellular noise, 1 or 3 channels (type float or vector3).
-
-|Port |Description |Type |Default |
-|----------|-----------------------------------------------|-------|---------|
-|`position`|The 3D position at which the noise is evaluated|vector3|_Pobject_|
-|`out` |Output: the computed noise value |float |0.0 |
-
-
-
-### `worleynoise2d`
-2D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features) values.
-
-|Port |Description |Type |Default|Accepted Values |
-|----------|---------------------------------------------------------|-----------------------|-------|-----------------------|
-|`texcoord`|The 2D texture coordinate at which the noise is evaluated|vector2 |_UV0_ | |
-|`jitter` |The amount to jitter the cell center position |float |1.0 | |
-|`style` |The output style |integer |0 |0 (Distance), 1 (Solid)|
-|`out` |Output: the computed noise value |float, vector2, vector3|0.0 | |
-
-
-
-### `worleynoise3d`
-3D Worley noise using centered jitter, outputting float (distance metric to closest feature), vector2 (distance metrics to closest 2 features) or vector3 (distance metrics to closest 3 features) values.
-
-|Port |Description |Type |Default |Accepted Values |
-|----------|-----------------------------------------------|-----------------------|---------|-----------------------|
-|`position`|The 3D position at which the noise is evaluated|vector3 |_Pobject_| |
-|`jitter` |The amount to jitter the cell center position |float |1.0 | |
-|`style` |The output style |integer |0 |0 (Distance), 1 (Solid)|
-|`out` |Output: the computed noise value |float, vector2, vector3|__zero__ | |
-
-
-
-### `unifiednoise2d`
-A single node supporting 2D Perlin, Cell, Worley or Fractal noise in a unified interface.
-
-|Port |Description |Type |Default|Accepted Values |
-|-------------|-------------------------------------------------------------------------------------------|-------|-------|-----------------------|
-|`texcoord` |The 2D texture coordinate at which the noise is evaluated |vector2|_UV0_ | |
-|`freq` |The noise frequency, with higher values producing smaller noise shapes. |vector2|1, 1 | |
-|`offset` |The amount to offset 2d space |vector2|0, 0 | |
-|`jitter` |The amount to jitter the cell center position |float |1 | |
-|`outmin` |The lowest output value |float |0 | |
-|`outmax` |The highest output value |float |1 | |
-|`clampoutput`|If enabled the output is clamped between the min and max output values |boolean|true | |
-|`octaves` |The number of octaves of noise to be summed |integer|3 | |
-|`lacunarity` |The exponential scale between successive octaves of noise |float |2 | |
-|`diminish` |The rate at which noise amplitude is diminished for each octave |float |0.5 | |
-|`type` |The type of noise function to use. One of 0 (Perlin), 1 (Cell), 2 (Worley), or 3 (Fractal)|integer|0 | |
-|`style` |The output style |integer|0 |0 (Distance), 1 (Solid)|
-|`out` |Output: the computed noise value |float |0.0 | |
-
-
-
-### `unifiednoise3d`
-A single node supporting 3D Perlin, Cell, Worley or Fractal noise in a unified interface.
-
-|Port |Description |Type |Default |Accepted Values |
-|-------------|-------------------------------------------------------------------------------------------|-------|---------|-----------------------|
-|`position` |The 3D position at which the noise is evaluated |vector3|_Pobject_| |
-|`freq` |The noise frequency, with higher values producing smaller noise shapes. |vector3|1, 1, 1 | |
-|`offset` |The amount to offset 3d space |vector3|0, 0, 0 | |
-|`jitter` |The amount to jitter the cell center position |float |1 | |
-|`outmin` |The lowest output value |float |0 | |
-|`outmax` |The highest output value |float |1 | |
-|`clampoutput`|If enabled the output is clamped between the min and max output values |boolean|true | |
-|`octaves` |The number of octaves of noise to be summed |integer|3 | |
-|`lacunarity` |The exponential scale between successive octaves of noise |float |2 | |
-|`diminish` |The rate at which noise amplitude is diminished for each octave |float |0.5 | |
-|`type` |The type of noise function to use. One of 0 (Perlin), 1 (Cell), 2 (Worley), or 3 (Fractal)|integer|0 | |
-|`style` |The output style |integer|0 |0 (Distance), 1 (Solid)|
-|`out` |Output: the computed noise value |float |0.0 | |
-
-
-### Noise Node Notes
-
-To scale or offset the noise pattern generated by a 3D noise node such as `noise3d`, `fractal3d` or `cellnoise3d`, use a <position> or other [Geometric Node](#geometric-nodes) (see below) connected to vector3 <multiply> and/or <add> nodes, in turn connected to the noise node's `position` input.
-
-To scale or offset the noise pattern generated by a 2D noise node such as `noise2d` or `cellnoise2d`, use a <place2d> node, or a <texcoord> or similar Geometric node processed by vector2 <multiply>, <rotate> and/or <add> nodes, and connect to the node's `texcoord` input.
-
-
-
-## Shape Nodes
-
-Shape nodes are used to generate shapes or patterns in UV space.
-
-```xml
-
-
-
-
-
-```
-
-Standard Shape nodes:
-
-
-
-### `checkerboard`
-2D checkerboard pattern.
-
-|Port |Description |Type |Default |
-|----------|-----------------------------------------------------------------------------------------------------|-------|-------------|
-|`color1` |The first color used in the checkerboard pattern. |color3 |1.0, 1.0, 1.0|
-|`color2` |The second color used in the checkerboard pattern. |color3 |0.0, 0.0, 0.0|
-|`uvtiling`|The tiling of the checkerboard pattern along each axis, with higher values producing smaller squares.|vector2|8, 8 |
-|`uvoffset`|The offset of the checkerboard pattern along each axis |vector2|0, 0 |
-|`texcoord`|The input 2d space. |vector2|_UV0_ |
-|`out` |Output: the checkerboard pattern |color3 | |
-
-
-
-### `line`
-2D line pattern: outputs 1 if texcoord is at less than `radius` distance from a line segment defined by `point1` and `point2`, otherwise outputs 0.
-
-|Port |Description |Type |Default |
-|----------|---------------------------------------------------------------|-------|----------|
-|`texcoord`|The input 2d space |vector2|_UV0_ |
-|`center` |An offset value added to both the point1 and point2 coordinates|vector2|0, 0 |
-|`radius` |The radius or 'half thickness' of the line |float |0.1 |
-|`point1` |The UV coordinate of the first endpoint |vector2|0.25, 0.25|
-|`point2` |The UV coordinate of the second endpoint |vector2|0.75, 0.75|
-|`out` |Output: the line pattern |float | |
-
-
-
-### `circle`
-2D circle (disk) pattern: outputs 1 if texcoord is inside a circle defined by `center` and `radius`, otherwise outputs 0.
-
-|Port |Description |Type |Default|
-|----------|-----------------------------------|-------|-------|
-|`texcoord`|The input 2d space |vector2|_UV0_ |
-|`center` |The center coordinate of the circle|vector2|0, 0 |
-|`radius` |The radius of the circle |float |0.5 |
-|`out` |Output: the circle pattern |float | |
-
-
-
-### `cloverleaf`
-2D cloverleaf pattern: four semicircles on the edges of a square defined by `center` and `radius`. Outputs 1 if texcoord is within the pattern, otherwise outputs 0.
-
-|Port |Description |Type |Default|
-|----------|---------------------------------------|-------|-------|
-|`texcoord`|The input 2d space |vector2|_UV0_ |
-|`center` |The center coordinate of the cloverleaf|vector2|0, 0 |
-|`radius` |The radius of the cloverleaf |float |0.5 |
-|`out` |Output: the cloverleaf pattern |float | |
-
-
-
-### `hexagon`
-2D hexagon pattern: outputs 1 if texcoord is inside a hexagon shape inscribed by a circle defined by `center` and `radius`; otherwise outputs 0.
-
-|Port |Description |Type |Default|
-|----------|------------------------------------|-------|-------|
-|`texcoord`|The input 2d space |vector2|_UV0_ |
-|`center` |The center coordinate of the hexagon|vector2|0, 0 |
-|`radius` |The radius of the hexagon |float |0.5 |
-|`out` |Output: the hexagon pattern |float | |
-
-
-
-### `grid`
-Creates a grid pattern of (1, 1, 1) white lines on a (0, 0, 0) black background with the given tiling, offset, and line thickness. Pattern can be regular or staggered.
-
-|Port |Description |Type |Default |
-|-----------|-----------------------------------------------------------------------------|-------|--------|
-|`texcoord` |The input 2d space |vector2|_UV0_ |
-|`uvtiling` |Tiling factor, with higher values producing a denser grid. |vector2|1.0, 1.0|
-|`uvoffset` |UV Offset |vector2|0.0, 0.0|
-|`thickness`|The thickness of the grid lines |float |0.05 |
-|`staggered`|If true, every other row will be offset 50% to produce a 'brick wall' pattern|boolean|false |
-|`out` |Output: the grid pattern |color3 | |
-
-
-
-### `crosshatch`
-Creates a crosshatch pattern with the given tiling, offset, and line thickness. Pattern can be regular or staggered.
-
-|Port |Description |Type |Default |
-|-----------|---------------------------------------------------------------------------------------|-------|--------|
-|`texcoord` |The input 2d space |vector2|_UV0_ |
-|`uvtiling` |Tiling factor, with higher values producing a denser grid. |vector2|1.0, 1.0|
-|`uvoffset` |UV Offset |vector2|0.0, 0.0|
-|`thickness`|The thickness of the grid lines |float |0.05 |
-|`staggered`|If true, every other row will be offset 50% to produce an 'alternating diamond' pattern|boolean|false |
-|`out` |Output: the crosshatch pattern |color3 | |
-
-
-
-### `tiledcircles`
-Creates a black and white pattern of circles with a defined tiling and size (diameter). Pattern can be regular or staggered.
-
-|Port |Description |Type |Default |
-|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------|--------|
-|`texcoord` |The input 2d space |vector2|_UV0_ |
-|`uvtiling` |Tiling factor, with higher values producing a denser grid. |vector2|1.0, 1.0|
-|`uvoffset` |UV Offset |vector2|0.0, 0.0|
-|`size` |The diameter of the circles in the tiled pattern. If `size` is 1.0, the edges of adjacent circles in the tiling will exactly touch. |float |0.5 |
-|`staggered`|If true, every other row will be offset 50%, and the spacing of the tiling will be adjusted in the V direction to center the circles on the vertices of an equilateral triangle grid|boolean|false |
-|`out` |Output: the tiled circle pattern |color3 | |
-
-
-
-### `tiledcloverleafs`
-Creates a black and white pattern of cloverleafs with a defined tiling and size (diameter of the circles circumscribing the shape). Pattern can be regular or staggered.
-
-|Port |Description |Type |Default |
-|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------|-------|--------|
-|`texcoord` |The input 2d space |vector2|_UV0_ |
-|`uvtiling` |Tiling factor, with higher values producing a denser grid. |vector2|1.0, 1.0|
-|`uvoffset` |UV Offset |vector2|0.0, 0.0|
-|`size` |The outer diameter of the cloverleafs in the tiled pattern. If size is 1.0, the edges of adjacent cloverleafs in the tiling will exactly touch.|float |0.5 |
-|`staggered`|If true, an additional pattern of cloverleafs will be generated in between the originals offset by 50% in both U and V |boolean|false |
-|`out` |Output: the tiled cloverleaf pattern |color3 | |
-
-
-
-### `tiledhexagons`
-Creates a black and white pattern of hexagons with a defined tiling and size (diameter of the circles circumscribing the shape). Pattern can be regular or staggered.
-
-|Port |Description |Type |Default |
-|-----------|--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------|--------|
-|`texcoord` |The input 2d space |vector2|_UV0_ |
-|`uvtiling` |Tiling factor, with higher values producing a denser grid. |vector2|1.0, 1.0|
-|`uvoffset` |UV Offset |vector2|0.0, 0.0|
-|`size` |The inner diameter of the hexagons in the tiled pattern. if size is 1.0, the edges of adjacent hexagons in the U-direcction tiling will exactly touch |float |0.5 |
-|`staggered`|If true, every other row will be offset 50%, and the spacing of the tiling will be adjusted in the V direction to center the hexagons on the vertices of an equilateral triangle grid.|boolean|false |
-|`out` |Output: the tiled hexagon pattern |color3 | |
-
-
-
-## Geometric Nodes
-
-Geometric nodes are used to reference local geometric properties from within a node graph:
-
-```xml
-
-
-
-
-```
-
-Standard Geometric nodes:
-
-
-
-### `position`
-The coordinates associated with the currently-processed data, as defined in a specific coordinate space.
-
-|Port |Description |Type |Default |Accepted Values |
-|-------|-------------------------------------------|-------|-------------|--------------------|
-|`space`|The coordinate space of the output position|string |object |model, object, world|
-|`out` |Output: the position in `space` |vector3|0.0, 0.0, 0.0| |
-
-
-
-### `normal`
-The normalized geometric normal associated with the currently-processed data, as defined in a specific coordinate space.
-
-|Port |Description |Type |Default |Accepted Values |
-|-------|-------------------------------------------|-------|-------------|--------------------|
-|`space`|The coordinate space of the output position|string |object |model, object, world|
-|`out` |Output: the normal in `space` |vector3|0.0, 1.0, 0.0| |
-
-
-
-### `tangent`
-The geometric tangent vector associated with the currently-processed data, as defined in a specific coordinate space.
-
-|Port |Description |Type |Default |Accepted Values |
-|-------|-------------------------------------------------------------------------------------|-------|-------------|--------------------|
-|`space`|The coordinate space of the output position |string |object |model, object, world|
-|`index`|The index of the texcoord space to use to compute the tangent vector |integer|0 | |
-|`out` |Output: the tangent vector associated with the `index`th coordinate space, in `space`|vector3|1.0, 0.0, 0.0| |
-
-
-
-### `bitangent`
-The geometric bi-tangent vector associated with the currently-processed data, as defined in a specific coordinate space.
-
-|Port |Description |Type |Default |Accepted Values |
-|-------|---------------------------------------------------------------------------------------|-------|-------------|--------------------|
-|`space`|The coordinate space of the output position |string |object |model, object, world|
-|`index`|The index of the texcoord space to use to compute the bitangent vector |integer|0 | |
-|`out` |Output: the bitangent vector associated with the `index`th coordinate space, in `space`|vector3|0.0, 0.0, 1.0| |
-
-
-
-### `bump`
-The normalized normal computed by offsetting the surface world space position along its world space normal.
-
-|Port |Description |Type |Default |
-|-----------|------------------------------------|-------|--------|
-|`height` |Amount to offset the surface normal.|float |0 |
-|`scale` |Scalar to adjust the height amount. |float |1 |
-|`normal` |Surface normal |vector3|_Nworld_|
-|`tangent` |Surface tangent vector |vector3|_Tworld_|
-|`bitangent`|Surface bitangent vector |vector3|_Bworld_|
-|`out` |Output: offset surface normal |vector3| |
-
-
-
-### `texcoord`
-The 2D or 3D texture coordinates associated with the currently-processed data
-
-|Port |Description |Type |Default |
-|-------|---------------------------|----------------|--------|
-|`index`|Texcoord index |integer |0 |
-|`out` |Output: texture coordinates|vector2, vector3|__zero__|
-
-
-
-### `geomcolor`
-The color associated with the current geometry at the current position, generally bound via per-vertex color values. The type must match the type of the "color" bound to the geometry.
-
-|Port |Description |Type |Default |
-|-------|----------------------------|-------------|--------|
-|`index`|index of the geometric color|integer |0 |
-|`out` |Output: geometric color |float, colorN|__zero__|
-
-
-
-### `geompropvalue`
-The value of the specified varying geometric property (defined by a <geompropdef>) of the currently-bound geometry. This node's type must match that of the referenced geomprop.
-
-|Port |Description |Type |Default |
-|----------|------------------------------------------------------------------------------------|----------------------------------------|---------|
-|`geomprop`|The geometric property to be referenced |string |__empty__|
-|`default` |A value to return if the specified `geomprop` is not defined on the current geometry|float, colorN, vectorN, boolean, integer|__zero__ |
-|`out` |Output: the `geomprop` value |Same as `default` |__zero__ |
-
-
-
-### `geompropvalueuniform`
-The value of the specified uniform geometric property (defined by a <geompropdef>) of the currently-bound geometry. This node's type must match that of the referenced geomprop.
-
-|Port |Description |Type |Default |
-|----------|--------------------------------------------------------------------------------------------|-----------------|---------|
-|`geomprop`|The geometric property to be referenced |string |__empty__|
-|`default` |A value to return if the specified `geomprop` is not defined on the current geometry |string, filename |__zero__ |
-|`out` |Output: A value to return if the specified `geomprop` is not defined on the current geometry|Same as `default`|__zero__ |
-
-
-### Geometric Node Notes
-
-A `colorspace` attribute may be specified for color3/color4-type properties of <geomcolor> and <geompropvalue> nodes to declare what colorspace the color property value is in; the default is "none" for no colorspace declaration (and hence no colorspace conversion).
-
-
-
-## Application Nodes
-
-Application nodes are used to reference application-defined properties within a node graph, and have no inputs:
-
-```xml
-
-
-```
-
-Standard Application nodes:
-
-
-
-### `frame`
-The current frame number as defined by the host environment.
-
-|Port |Description |Type |Default|
-|-----|-------------------------------------------------------|-----|-------|
-|`out`|Output: frame number as defined by the host environment|float|1.0 |
-
-
-
-### `time`
-The current time in seconds, as defined by the host environment.
-
-|Port |Description |Type |Default|
-|-----|------------------------------------------------------------------|-----|-------|
-|`out`|Output: current time in seconds as defined by the host environment|float|0.0 |
-
-
-### Application Node Notes
-
-Applications may use whatever method is appropriate to communicate the current frame number or time to the <frame> or <time> node's implementation, whether via an internal state variable, a custom input, dividing the current frame number by a local "frames per second" value (<time> node only), or other method. Real-time applications may return some variation of wall-clock time.
-
-
-
-
-# Standard Operator Nodes
-
-Operator nodes process one or more required input streams to form an output. Like other nodes, each operator must define its output type, which in most cases also determines the type(s) of the required input streams.
-
-```xml
-
-
-
-
-
-
-
-
-
-
-
-
-```
-
-The inputs of compositing operators are called "fg" and "bg" (plus "alpha" for float and color3 variants, and "mix" for all variants of the `mix` operator), while the inputs of most other operators are called "in" if there is exactly one input, or "in1", "in2" etc. if there are more than one input. If an implementation does not support a particular operator, it should generally pass through the "bg", "in" or "in1" input unchanged.
-
-This section defines the Operator Nodes that all MaterialX implementations are expected to support. Standard Operator Nodes are grouped into the following classifications: [Math Nodes](#math-nodes), [Adjustment Nodes](#adjustment-nodes), [Compositing Nodes](#compositing-nodes), [Conditional Nodes](#conditional-nodes), [Channel Nodes](#channel-nodes) and [Convolution Nodes](#convolution-nodes).
-
-
-
-## Math Nodes
-
-Math nodes have one or two spatially-varying inputs, and are used to perform a math operation on values in one spatially-varying input stream, or to combine two spatially-varying input streams using a specified math operation. The given math operation is performed for each channel of the input stream(s), and the data type of each input must either match that of the input stream(s), or be a float value that will be applied to each channel separately.
-
-
-
-
-### `add`
-Add a value to the incoming float/color/vector/matrix
-
-|Port |Description |Type |Default |
-|-----|------------------------------|-------------------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN, integer|__zero__|
-|`in2`|The stream to add to `in1` |Same as `in1` |__zero__|
-|`out`|Output: sum of `in1` and `in2`|Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|-----|------------------------------|---------------|--------|
-|`in1`|The primary input stream |colorN, vectorN|__zero__|
-|`in2`|The stream to add to `in1` |float |__zero__|
-|`out`|Output: sum of `in1` and `in2`|Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|-----|------------------------------|----------------------|--------|
-|`in1`|The primary input stream |matrixNN |__one__ |
-|`in2`|The stream to add to `in1` |Same as `in1` or float|__zero__|
-|`out`|Output: sum of `in1` and `in2`|Same as `in1` |`in1` |
-
-
-
-### `subtract`
-Subtract a value from the incoming float/color/vector/matrix
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|-------------------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN, integer|__zero__|
-|`in2`|The stream to subtract from `in1`|Same as `in1` |__zero__|
-|`out`|Output: `in1` minus `in2` |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|---------------|--------|
-|`in1`|The primary input stream |colorN, vectorN|__zero__|
-|`in2`|The stream to subtract from `in1`|float |__zero__|
-|`out`|Output: `in1` minus `in2` |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|----------------------|--------|
-|`in1`|The primary input stream |matrixNN |__one__ |
-|`in2`|The stream to subtract from `in1`|Same as `in1` or float|__zero__|
-|`out`|Output: `in1` minus `in2` |Same as `in1` |`in1` |
-
-
-
-### `multiply`
-Multiply two values together. Scalar and vector types multiply component-wise, while matrices multiply using a standard matrix product.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------|----------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN|__zero__|
-|`in2`|The stream to multiply `in1` by |Same as `in1` or float|__one__ |
-|`out`|Output: product of `in1` and `in2`|Same as `in1` |`in1` |
-
-|Port |Description |Type |Default|
-|-----|----------------------------------|-------------|-------|
-|`in1`|The primary input stream |matrixNN |__one__|
-|`in2`|The stream to multiply `in1` by |Same as `in1`|__one__|
-|`out`|Output: product of `in1` and `in2`|Same as `in1`|`in1` |
-
-
-
-### `divide`
-Divide one value by another. Scalar and vector types divide component-wise, while for matrices `in1` is multiplied by the inverse of `in2`.
-
-|Port |Description |Type |Default |
-|-----|------------------------------|----------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN|__zero__|
-|`in2`|The stream to divide `in1` by |Same as `in1` or float|__one__ |
-|`out`|Output: `in1` divided by `in2`|Same as `in1` |`in1` |
-
-|Port |Description |Type |Default|
-|-----|------------------------------|-------------|-------|
-|`in1`|The primary input stream |matrixNN |__one__|
-|`in2`|The stream to divide `in1` by |Same as `in1`|__one__|
-|`out`|Output: `in1` divided by `in2`|Same as `in1`|`in1` |
-
-
-
-### `modulo`
-The remaining fraction after dividing an incoming float/color/vector by a value and subtracting the integer portion. Modulo always returns a non-negative result.
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|-----------------------------|----------------------|--------|---------------|
-|`in1`|The primary input stream |float, colorN, vectorN|__zero__| |
-|`in2`|The stream to modulo `in1` by|Same as `in1` or float|__one__ |`in2` != 0 |
-|`out`|Output: `in1` modulo `in2` |Same as `in1` |`in1` | |
-
-
-
-### `fract`
-Returns the fractional part of the floating-point input.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`out`|Output: The fractional part of `in`|Same as `in` |`in` |
-
-
-
-### `invert`
-Subtract the incoming float, color, or vector from `amount` in all channels, outputting: `amount - in`.
-
-|Port |Description |Type |Default |
-|--------|-------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`amount`|The value to subtract `in` from|Same as `in` or float |__one__ |
-|`out` |Output: `amount` minus `in` |Same as `in` |`in` |
-
-
-
-### `absval`
-The per-channel absolute value of the incoming float/color/vector.
-
-|Port |Description |Type |Default |
-|-----|------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`out`|Output: absolute value of `in`|Same as `in` |`in` |
-
-
-
-### `sign`
-The per-channel sign of the incoming float/color/vector value: -1 for negative, +1 for positive, or 0 for zero.
-
-|Port |Description |Type |Default |
-|-----|------------------------|----------------------|--------|
-|`in` |The primary input stream|float, colorN, vectorN|__zero__|
-|`out`|Output: sign of `in` |Same as `in` |`in` |
-
-
-
-### `floor`
-The per-channel nearest integer value less than or equal to the incoming float/color/vector. The output remains in floating point per-channel, i.e. the same type as the input, except that <floor> of a float input also has a variant outputting an integer type.
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`out`|Output: nearest integer less than or equal to `in`|Same as `in` |`in` |
-
-|Port |Description |Type |Default|
-|-----|--------------------------------------------------|-------|-------|
-|`in` |The primary input stream |float |0.0 |
-|`out`|Output: nearest integer less than or equal to `in`|integer|`in` |
-
-
-
-### `ceil`
-The per-channel nearest integer value greater than or equal to the incoming float/color/vector. The output remains in floating point per-channel, i.e. the same type as the input, except that <ceil> of a float input also has a variant outputting an integer type.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`out`|Output: nearest integer greater than or equal to `in`|Same as `in` |`in` |
-
-|Port |Description |Type |Default|
-|-----|-----------------------------------------------------|-------|-------|
-|`in` |The primary input stream |float |0.0 |
-|`out`|Output: nearest integer greater than or equal to `in`|integer|`in` |
-
-
-
-### `round`
-Round each channel of the incoming float/color/vector values to the nearest integer value.
-
-|Port |Description |Type |Default |
-|-----|-------------------------------------------|----------------------|--------|
-|`in` |The primary input stream |float, colorN, vectorN|__zero__|
-|`out`|Output: `in` rounded to the nearest integer|Same as `in` |`in` |
-
-|Port |Description |Type |Default|
-|-----|-------------------------------------------|-------|-------|
-|`in` |The primary input stream |float |0.0 |
-|`out`|Output: `in` rounded to the nearest integer|integer|`in` |
-
-
-
-### `power`
-Raise incoming float/color values to the specified exponent, commonly used for "gamma" adjustment.
-
-|Port |Description |Type |Default |
-|-----|------------------------------|----------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN|__zero__|
-|`in2`|The exponent to raise `in1` to|Same as `in1` or float|__one__ |
-|`out`|Output: `in1` raised to `in2` |Same as `in1` |`in1` |
-
-
-
-### `safepower`
-Raise incoming float/color values to the specified exponent. Negative "in1" values will result in negative output values.
-
-|Port |Description |Type |Default |
-|-----|------------------------------|----------------------|--------|
-|`in1`|The primary input stream |float, colorN, vectorN|__zero__|
-|`in2`|The exponent to raise `in1` to|Same as `in1` or float|__one__ |
-|`out`|Output: `in1` raised to `in2` |Same as `in1` |`in1` |
-
-
-
-### `sin`
-The sine of the incoming value, which is expected to be expressed in radians.
-
-|Port |Description |Type |Default |
-|-----|------------------------|--------------|--------|
-|`in` |The primary input stream|float, vectorN|__zero__|
-|`out`|Output: sin of `in1` |Same as `in` |`in` |
-
-
-
-### `cos`
-The cosine of the incoming value, which is expected to be expressed in radians.
-
-|Port |Description |Type |Default |
-|-----|------------------------|--------------|--------|
-|`in` |The primary input stream|float, vectorN|__zero__|
-|`out`|Output: cos of `in1` |Same as `in` |`in` |
-
-
-
-### `tan`
-The tangent of the incoming value, which is expected to be expressed in radians.
-
-|Port |Description |Type |Default |
-|-----|------------------------|--------------|--------|
-|`in` |The primary input stream|float, vectorN|__zero__|
-|`out`|Output: cos of `in1` |Same as `in` |`in` |
-
-
-
-### `asin`
-The arcsine of the incoming value. The output will be expressed in radians.
-
-|Port |Description |Type |Default |Accepted Values |
-|-----|------------------------|--------------|--------|-------------------|
-|`in` |The primary input stream|float, vectorN|__zero__|[-__one__, __one__]|
-|`out`|Output: asin of `in1` |Same as `in` |`in` | |
-
-
-
-### `acos`
-The arccosine of the incoming value. The output will be expressed in radians.
-
-|Port |Description |Type |Default |Accepted Values |
-|-----|------------------------|--------------|--------|-------------------|
-|`in` |The primary input stream|float, vectorN|__zero__|[-__one__, __one__]|
-|`out`|Output: acos of `in1` |Same as `in` |`in` | |
-
-
-
-### `atan2`
-The arctangent of the expression (`iny`/`inx`). The output will be expressed in radians.
-
-|Port |Description |Type |Default |
-|-----|------------------------------------------------------------------------------------------------|--------------|--------|
-|`iny`|Vertical component of the point to which the the angle is to be found |float, vectorN|__zero__|
-|`inx`|Horizontal component of the point to which the angle is to be found |Same as `iny` |__one__ |
-|`out`|Output: angle relative to the X-axis of the line joining the origin and the point (`inx`, `iny`)|Same as `iny` |`iny` |
-
-
-
-### `sqrt`
-The square root of the incoming value.
-
-|Port |Description |Type |Default |Accepted Values |
-|-----|---------------------------|--------------|--------|--------------------|
-|`in` |The primary input stream |float, vectorN|__zero__|[__zero__, __+inf__)|
-|`out`|Output: square root of `in`|Same as `in` |`in` | |
-
-
-
-### `ln`
-The natural logarithm of the incoming value.
-
-|Port |Description |Type |Default|Accepted Values |
-|-----|---------------------------------|--------------|-------|----------------------|
-|`in` |The primary input stream |float, vectorN|__one__| (__zero__, __+inf__) |
-|`out`|Output: natural logarithm of `in`|Same as `in` |`in` | |
-
-
-
-### `exp`
-$e$ to the power of the incoming value.
-
-|Port |Description |Type |Default |
-|-----|---------------------------|--------------|--------|
-|`in` |The primary input stream |float, vectorN|__zero__|
-|`out`|Output: exponential of `in`|Same as `in` |`in` |
-
-
-
-### `clamp`
-Clamp incoming values per-channel to a specified range of float/color/vector values.
-
-|Port |Description |Type |Default |
-|------|------------------------------------------------------------------|----------------------|--------|
-|`in` |The input stream to be clamped |float, colorN, vectorN|__zero__|
-|`low` |Any value of `in` lower than this value will be set to this value |Same as `in` or float |__zero__|
-|`high`|Any value of `in` higher than this value will be set to this value|Same as `low` |__one__ |
-|`out` |Output: clamped `in` |Same as `in` |`in` |
-
-
-
-### `trianglewave`
-Generate a triangle wave from the given scalar input. The generated wave ranges from zero to one and repeats on integer boundaries.
-
-|Port |Description |Type |Default|
-|-----|-----------------------------|-----|-------|
-|`in` |The primary input stream |float|0 |
-|`out`|Output: generated wave signal|float| |
-
-
-
-### `min`
-Select the minimum of the two incoming values.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------|----------------------|--------|
-|`in1`|The first input stream |float, colorN, vectorN|__zero__|
-|`in2`|The second input stream |Same as `in1` or float|__zero__|
-|`out`|Output: minimum of `in1` and `in2`|Same as `in1` |`in1` |
-
-
-
-### `max`
-Select the maximum of the two incoming values.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------|----------------------|--------|
-|`in1`|The first input stream |float, colorN, vectorN|__zero__|
-|`in2`|The second input stream |Same as `in1` or float|__zero__|
-|`out`|Output: maximum of `in1` and `in2`|Same as `in1` |`in1` |
-
-
-
-### `normalize`
-Output the incoming vectorN stream normalized.
-
-|Port |Description |Type |Default |
-|-----|-----------------------|------------|--------|
-|`in` |Vector to be normalized|vectorN |__zero__|
-|`out`|Output: normalized `in`|Same as `in`|`in` |
-
-
-
-### `magnitude`
-Output the float magnitude (vector length) of the incoming vectorN stream; cannot be used on float or colorN streams. Note: the fourth channel in vector4 streams is not treated any differently, e.g. not as a homogeneous "w" value.
-
-|Port |Description |Type |Default |
-|-----|-------------------------|-------|--------|
-|`in` |Input vector stream |vectorN|__zero__|
-|`out`|Output: magnitude of `in`|float |0.0 |
-
-
-
-### `distance`
-Measures the distance between two points in 2D, 3D, or 4D.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------------|-------------|--------|
-|`in1`|Point to calculate distance from |vectorN |__zero__|
-|`in2`|Point to calculate distance to |Same as `in1`|__zero__|
-|`out`|Output: distance between `in1` and `in2`|float | |
-
-
-
-### `dotproduct`
-Output the (float) dot product of two incoming vectorN streams; cannot be used on float or colorN streams.
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------|-------------|--------|
-|`in1`|The first input vector stream |vectorN |__zero__|
-|`in2`|The second input vector stream |Same as `in1`|__zero__|
-|`out`|Output: dot product of `in1` and `in2`|float |0.0 |
-
-
-
-### `crossproduct`
-Output the (vector3) cross product of two incoming vector3 streams; cannot be used on any other stream type. A disabled crossproduct node passes through the value of `in1` unchanged.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------------|-------|-------------|
-|`in1`|The first input vector stream |vector3|0.0, 0.0, 0.0|
-|`in2`|The second input vector stream |vector3|0.0, 0.0, 0.0|
-|`out`|Output: cross product of `in1` and `in2`|vector3|`in1` |
-
-
-
-### `transformpoint`
-Transform the incoming vector3 coordinate from one specified space to another; cannot be used on any other stream type.
-
-|Port |Description |Type |Default |
-|-----------|-----------------------------------------------------------------------------------------------------------------------------------------------------|-------|-------------|
-|`in` |The point to be transformed |vector3|0.0, 0.0, 0.0|
-|`fromspace`|The name of a vector space understood by the rendering target to transform the `in` point from; may be empty to specify the renderer's working space.|string |__empty__ |
-|`tospace` |The name of a vector space understood by the rendering target for the space to transform the `in` point to. |string |__empty__ |
-|`out` |Output: point transformed from `fromspace` to `tospace` |vector3|`in` |
-
-
-
-### `transformvector`
-Transform the incoming vector3 coordinate from one specified space to another; cannot be used on any other stream type.
-
-|Port |Description |Type |Default |
-|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------|-------|-------------|
-|`in` |The vector to be transformed |vector3|0.0, 0.0, 0.0|
-|`fromspace`|The name of a vector space understood by the rendering target to transform the `in` vector from; may be empty to specify the renderer's working space.|string |__empty__ |
-|`tospace` |The name of a vector space understood by the rendering target for the space to transform the `in` vector to. |string |__empty__ |
-|`out` |Output: point transformed from `fromspace` to `tospace` |vector3|`in` |
-
-
-
-### `transformnormal`
-Transform the incoming vector3 normal from one specified space to another; cannot be used on any other stream type.
-
-|Port |Description |Type |Default |
-|-----------|------------------------------------------------------------------------------------------------------------------------------------------------------|-------|-------------|
-|`in` |The normal to be transformed |vector3|0.0, 0.0, 1.0|
-|`fromspace`|The name of a vector space understood by the rendering target to transform the `in` normal from; may be empty to specify the renderer's working space.|string |__empty__ |
-|`tospace` |The name of a vector space understood by the rendering target for the space to transform the `in` normal to. |string |__empty__ |
-|`out` |Output: point transformed from `fromspace` to `tospace` |vector3|`in` |
-
-
-
-### `transformmatrix`
-Transform the incoming vectorN by the specified matrix.
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|--------|--------|
-|`in` |Vector to be transformed |vector2 |__zero__|
-|`mat`|Matrix to transform `in` by |matrix33|__one__ |
-|`out`|Output: `in` transformed by `mat`|vector2 |`in` |
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|--------|--------|
-|`in` |Vector to be transformed |vector3 |__zero__|
-|`mat`|Matrix to transform `in` by |matrixNN|__one__ |
-|`out`|Output: `in` transformed by `mat`|vector3 |`in` |
-
-|Port |Description |Type |Default |
-|-----|---------------------------------|--------|--------|
-|`in` |Vector to be transformed |vector4 |__zero__|
-|`mat`|Matrix to transform `in` by |matrix44|__one__ |
-|`out`|Output: `in` transformed by `mat`|vector4 |`in` |
-
-
-
-### `normalmap`
-Transform a normal vector from the encoded tangent space to world space. The input normal vector is assumed to be encoded with all channels in the [0-1] range, as would commonly be output from a normal map.
-
-|Port |Description |Type |Default |
-|-----------|--------------------------------------------------------------------------------|--------------|-------------|
-|`in` |Input normal in space of frame defined by `normal`, `tangent`, `bitangent` ports|vector3 |0.5, 0.5, 1.0|
-|`scale` |Scaling factor to apply to the normal |float, vector2|__one__ |
-|`normal` |Normal of the local frame from which to transform `in` |vector3 |_Nworld_ |
-|`tangent` |Tangent of the local frame from which to transform `in` |vector3 |_Tworld_ |
-|`bitangent`|Bitangent of the local frame from which to transform `in` |vector3 |_Bworld_ |
-|`out` |Output: Ouptut normal in world space |vector3 |`normal` |
-
-
-
-### `hextilednormalmap`
-Samples data from a single normalmap, with provisions for hex-tiling and randomizing the normalmap across UV space.
-
-The `file` input can include one or more substitutions to change the file name that is accessed, as described in the [Filename Substitutions](./MaterialX.Specification.md#filename-substitutions) section in the main Specification document.
-
-The `strength` input controls how strongly the sampled normal map affects the final normal. A value of 0.0 leaves the surface normal unchanged, 1.0 applies the sampled normal at full strength, and values >1.0 amplify the normal perturbation.
-
-|Port |Description |Type |Default |
-|--------------------|----------------------------------------------------------------------------------------------------|--------|-------------|
-|`file` |The URI of the image file |filename|__empty__ |
-|`default` |A default value to use if the file reference can not be resolved |vector3 |0.5, 0.5, 1.0|
-|`texcoord` |The 2D texture coordinate at which the image data is read |vector2 |_UV0_ |
-|`tiling` |The tiling rate for the given image along the U and V axes |vector2 |1.0, 1.0 |
-|`rotation` |Per-tile rotation randomness in degrees |float |0.0 |
-|`rotationrange` |Range in degrees used to randomize rotation for each tile |vector2 |0.0, 360.0 |
-|`scale` |Per-tile scale randomness multiplier applied to tile size |float |1.0 |
-|`scalerange` |Range of scale multipliers used to randomize tile scale |vector2 |0.5, 2.0 |
-|`offset` |Per-tile translation randomness in UV units |float |1.0 |
-|`offsetrange` |Range of offset values in UV units used to randomize tile positions |vector2 |0.0, 1.0 |
-|`falloff` |Falloff width used to blend neighboring tiles at their edges; larger values produce smoother blends |float |0.5 |
-|`strength` |Controls how strongly the sampled normal map affects the final normal. |float |1.0 |
-|`flip_g` |If true, negate the green channel of the sampled normal map to accommodate tangent-space conventions|boolean |false |
-|`normal` |Surface normal |vector3 |_Nworld_ |
-|`tangent` |Surface tangent vector |vector3 |_Tworld_ |
-|`bitangent` |Surface bitangent vector |vector3 |_Bworld_ |
-|`out` |Output: the sampled normal map value |vector3 |0.5, 0.5, 1.0|
-
-
-
-### `creatematrix`
-Build a 3x3 or 4x4 matrix from three vector3 or four vector3 or vector4 inputs. A matrix44 may also be created from vector3 input values, in which case the fourth value will be set to 0.0 for `in1`-`in3`, and to 1.0 for `in4` when creating the matrix44.
-
-|Port |Description |Type |Default |
-|-----|------------------------------|--------|-------------|
-|`in1`|The first row of `out` |vector3 |1.0, 0.0, 0.0|
-|`in2`|The second row of `out` |vector3 |0.0, 1.0, 0.0|
-|`in3`|The third row of `out` |vector3 |0.0, 0.0, 1.0|
-|`out`|Output: the constructed matrix|matrix33|__one__ |
-
-|Port |Description |Type |Default |
-|-----|----------------------------------------|--------|-------------|
-|`in1`|The first row of `out`, appended with 0 |vector3 |1.0, 0.0, 0.0|
-|`in2`|The second row of `out`, appended with 0|vector3 |0.0, 1.0, 0.0|
-|`in3`|The third row of `out`, appended with 0 |vector3 |0.0, 0.0, 1.0|
-|`in4`|The fourth row of `out`, appended with 1|vector3 |0.0, 0.0, 0.0|
-|`out`|Output: the constructed matrix |matrix44|__one__ |
-
-|Port |Description |Type |Default |
-|-----|------------------------------|--------|------------------|
-|`in1`|The first row of `out` |vector4 |1.0, 0.0, 0.0, 0.0|
-|`in2`|The second row of `out` |vector4 |0.0, 1.0, 0.0, 0.0|
-|`in3`|The third row of `out` |vector4 |0.0, 0.0, 1.0, 0.0|
-|`in4`|The fourth row of `out` |vector4 |0.0, 0.0, 0.0, 1.0|
-|`out`|Output: the constructed matrix|matrix44|__one__ |
-
-
-
-### `transpose`
-Transpose the incoming matrix.
-
-|Port |Description |Type |Default|
-|-----|-------------------------|------------|-------|
-|`in` |The input matrix |matrixNN |__one__|
-|`out`|Output: transpose of `in`|Same as `in`|`in` |
-
-
-
-### `determinant`
-Output the determinant of the incoming matrix.
-
-|Port |Description |Type |Default|
-|-----|---------------------------|--------|-------|
-|`in` |The input matrix |matrixNN|__one__|
-|`out`|Output: determinant of `in`|float |1.0 |
-
-
-
-### `invertmatrix`
-Invert the incoming matrix.
-
-|Port |Description |Type |Default|
-|-----|-----------------------|------------|-------|
-|`in` |The input matrix |matrixNN |__one__|
-|`out`|Output: inverse of `in`|Same as `in`|`in` |
-
-
-
-### `rotate2d`
-Rotate the incoming 2D vector about the origin.
-
-|Port |Description |Type |Default |
-|--------|-----------------------------------------------------------------------------------|-------|--------|
-|`in` |The input vector to rotate |vector2|0.0, 0.0|
-|`amount`|The angle to rotate, specified in degrees. Positive values rotate counter-clockwise|float |0.0 |
-|`out` |Output: rotated vector |vector2|`in` |
-
-
-
-### `rotate3d`
-Rotate the incoming 3D vector about the specified unit axis vector.
-
-|Port |Description |Type |Default |
-|--------|-----------------------------------------------------------------------------------|-------|-------------|
-|`in` |The input vector to rotate |vector3|0.0, 0.0, 0.0|
-|`amount`|The angle to rotate, specified in degrees. Positive values rotate counter-clockwise|float |0.0 |
-|`axis` |The unit axis vector to rotate `in` around |vector3|0.0, 1.0, 0.0|
-|`out` |Output: rotated vector |vector3|`in` |
-
-
-
-### `reflect`
-Reflect the incoming 3D vector about a surface normal vector.
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------------|-------|-------------|
-|`in` |Input vector to reflect |vector3|1.0, 0.0, 0.0|
-|`normal`|Vector normal to the surface about which to reflect `in`|vector3|_Nworld_ |
-|`out` |Output: reflection of `in` about `normal` |vector3| |
-
-
-
-### `refract`
-Refract the incoming 3D vector through a surface with the given surface normal and relative index of refraction.
-
-|Port |Description |Type |Default |
-|--------|-------------------------------------------------------------------------------|-------|-------------|
-|`in` |Input vector to refract |vector3|1.0, 0.0, 0.0|
-|`normal`|Vector normal to the surface through which to refract `in` |vector3|_Nworld_ |
-|`ior` |The relative index of refraction of the interior of the surface to the exterior|float |1.0 |
-|`out` |Output: refraction of `in` through `normal` |vector3| |
-
-
-
-### `place2d`
-Transform incoming 2D texture coordinates from one frame of reference to another.
-
-The `operationorder` input controls the order in which transform operations are performed. The `SRT` option performs -pivot, scale, rotate, translate, +pivot. The `TRS` option performs -pivot, translate, rotate, scale, +pivot.
-
-|Port |Description |Type |Default |Accepted Values |
-|----------------|-------------------------------------------------------|-------|----------|----------------|
-|`texcoord` |Input texture coordinates to transform |vector2|0.0, 0.0 | |
-|`pivot` |Pivot point around which to rotate and scale `texcoord`|vector2|0.0,0.0 | |
-|`scale` |Scaling factor to apply to `in` |vector2|1.0,1.0 | |
-|`rotate` |Amount to rotate `in`, in degrees |float |0.0 | |
-|`offset` |Amount to translate `in` |vector2|0.0,0.0 | |
-|`operationorder`|The order in which transform operations are performed |integer|0 |0 (SRT), 1 (TRS)|
-|`out` |Output: transformed texture coordinates |vector2|`texcoord`| |
-
-
-
-### `dot`
-A no-op, which passes its input through to its output unchanged.
-
-Users can use dot nodes to shape edge connection paths or provide documentation checkpoints in node graph layout UI's. Dot nodes may also pass uniform values from `constant` or other nodes with uniform="true" outputs to uniform inputs and tokens.
-
-|Port |Description |Type |Default |
-|-----|----------------------------------|--------------------------------------------------------------------|--------|
-|`in` |The input data stream |float, colorN, vectorN, matrixNN, boolean, integer, string, filename|__zero__|
-|`out`|Output: the unchanged input stream|Same as `in` |__zero__|
-
-
-## Logical Operator Nodes
-
-Logical operator nodes have one or two boolean typed inputs, and are used to construct higher level logical flow through the nodegraph.
-
-
-
-### `and`
-Logically AND the two input boolean values.
-
-|Port |Description |Type |Default|
-|-----|-----------------------|-------|-------|
-|`in1`|The first input stream |boolean|false |
-|`in2`|The second input stream|boolean|false |
-|`out`|Output: `in1` AND `in2`|boolean|`in1` |
-
-
-
-### `or`
-Logically Inclusive OR the two input boolean values.
-
-|Port |Description |Type |Default|
-|-----|-----------------------|-------|-------|
-|`in1`|The first input stream |boolean|false |
-|`in2`|The second input stream|boolean|false |
-|`out`|Output: `in1` OR `in2` |boolean|`in1` |
-
-
-
-### `xor`
-Logically Exclusive OR the two input boolean values.
-
-|Port |Description |Type |Default|
-|-----|-----------------------|-------|-------|
-|`in1`|The first input stream |boolean|false |
-|`in2`|The second input stream|boolean|false |
-|`out`|Output: `in1` XOR `in2`|boolean|`in1` |
-
-
-
-### `not`
-Logically NOT the input boolean value.
-
-|Port |Description |Type |Default|
-|-----|----------------|-------|-------|
-|`in` |The input stream|boolean|false |
-|`out`|Output: NOT `in`|boolean|true |
-
-
-## Adjustment Nodes
-
-Adjustment nodes have one input named "in", and apply a specified function to values in the incoming stream.
-
-
-
-### `contrast`
-Increase or decrease the contrast of the incoming `in` values using `amount` as a linear slope multiplier.
-
-|Port |Description |Type |Default |Accepted Values |
-|--------|--------------------------------------------------------------------------------------------------------------------------------|----------------------|--------|--------------------|
-|`in` |The input color stream to be adjusted |float, colorN, vectorN|__zero__| |
-|`amount`|Slope multiplier for contrast adjustment. Values greater than 1.0 increase contrast, values between 0.0 and 1.0 reduce contrast.|Same as `in` or float |__one__ |[__zero__, __+inf__)|
-|`pivot` |Center pivot value of contrast adjustment; this is the value that will not change as contrast is adjusted. |Same as `amount` |__half__| |
-|`out` |Output: the adjusted color value |Same as `in` |`in` | |
-
-
-
-### `remap`
-Linearly remap incoming values from one range of values [`inlow`, `inhigh`] to another [`outlow`, `outhigh`].
-
-|Port |Description |Type |Default |
-|---------|-------------------------------|----------------------|--------|
-|`in` |The input stream to be adjusted|float, colorN, vectorN|__zero__|
-|`inlow` |Low value for the input range |Same as `in` or float |__zero__|
-|`inhigh` |High value for the input range |Same as `inlow` |__one__ |
-|`outlow` |Low value for the output range |Same as `inlow` |__zero__|
-|`outhigh`|High value for the output range|Same as `inlow` |__one__ |
-|`out` |Output: the adjusted value |Same as `in` |`in` |
-
-
-
-### `range`
-Remap incoming values from one range of values to another, optionally applying a gamma correction "in the middle".
-
-|Port |Description |Type |Default |
-|---------|--------------------------------------------------------|----------------------|--------|
-|`in` |The input stream to be adjusted |float, colorN, vectorN|__zero__|
-|`inlow` |Low value for the input range |Same as `in` or float |__zero__|
-|`inhigh` |High value for the input range |Same as `inlow` |__one__ |
-|`gamma` |Reciprocal of the exponent applied to the remapped input|Same as `inlow` |__one__ |
-|`outlow` |Low value for the output range |Same as `inlow` |__zero__|
-|`outhigh`|High value for the output range |Same as `inlow` |__one__ |
-|`doclamp`|If true, the output is clamped to [`outlow`, `outhigh`] |boolean |false |
-|`out` |Output: the adjusted value |Same as `in` |`in` |
-
-
-
-### `smoothstep`
-Output a smooth, hermite-interpolated remapping of input values from [`low`, `high`] to [0,1].
-
-|Port |Description |Type |Default |
-|------|------------------------------------------|----------------------|--------|
-|`in` |The input value to the smoothstep function|float, colorN, vectorN|__zero__|
-|`low` |Low value for the input range |Same as `in` or float |__zero__|
-|`high`|Low value for the output range |Same as `low` |__one__ |
-|`out` |Output: the adjusted value |Same as `in` |`in` |
-
-
-
-### `luminance`
-Output a grayscale value containing the luminance of the incoming RGB color in all color channels.
-
-The `lumacoeffs` input represents the luma coefficients of the current working color space. If no specific color space can be determined, the ACEScg (ap1) luma coefficients [0.2722287, 0.6740818, 0.0536895] will be used. Applications which support color management systems may choose to retrieve the luma coefficients of the working colorspace from the CMS to pass to the <luminance> node's implementation directly, rather than exposing it to the user.
-
-|Port |Description |Type |Default |
-|------------|--------------------------------------------------------|------------|-------------------------------|
-|`in` |The input color stream to be converted |colorN |__zero__ |
-|`lumacoeffs`|The luma coefficients of the current working color space|color3 |0.2722287, 0.6740818, 0.0536895|
-|`out` |Output: the luminance of `in` |Same as `in`|`in` |
-
-
-
-### `rgbtohsv`
-Convert an incoming color from RGB to HSV space (with H and S ranging from 0 to 1); the alpha channel is left unchanged if present. This conversion is not affected by the current color space.
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------|------------|--------|
-|`in` |The input color stream to be converted|colorN |__zero__|
-|`out`|Output: `in` converted from RGB to HSV|Same as `in`|`in` |
-
-
-
-### `hsvtorgb`
-Convert an incoming color from HSV to RGB space; the alpha channel is left unchanged if present. This conversion is not affected by the current color space.
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------|------------|--------|
-|`in` |The input color stream to be converted|colorN |__zero__|
-|`out`|Output: `in` converted from HSV to RGB|Same as `in`|`in` |
-
-
-
-### `hsvadjust`
-Adjust the hue, saturation and value of an RGB color by converting the input color to HSV, adding `amount.x` to the hue, multiplying the saturation by `amount.y`, multiplying the value by `amount.z`, then converting back to RGB.
-
-Positive `amount.x` values rotate hue in the "red to green to blue" direction, with `amount.x` of 1.0 being the equivalent to a 360 degree (e.g. no-op) rotation. Negative or greater-than-1.0 hue adjustment values are allowed, wrapping at the 0-1 boundaries. The internal conversions between RGB and HSV spaces are not affected by the current color space, and for color4 inputs, the alpha value is left unchanged.
-
-|Port |Description |Type |Default |
-|--------|----------------------------------------------------------------------------|------------|-------------|
-|`in` |The input color stream to be adjusted |colorN |__zero__ |
-|`amount`|Hue offset, saturation scale, and luminance scale in (x, y, z), respectively|vector3 |0.0, 1.0, 1.0|
-|`out` |Output: the adjusted value |Same as `in`|`in` |
-
-
-
-### `saturate`
-Adjust the saturation of a color, the alpha channel will be unchanged if present.
-
-The `lumacoeffs` input represents the luma coefficients of the current working color space. If no specific color space can be determined, the ACEScg (ap1) luma coefficients [0.2722287, 0.6740818, 0.0536895] will be used. Applications which support color management systems may choose to retrieve the luma coefficients of the working colorspace from the CMS to pass to the node's implementation directly, rather than exposing it to the user.
-
-|Port |Description |Type |Default |
-|------------|---------------------------------------------------------------|------------|-------------------------------|
-|`in` |The input color stream to be adjusted |colorN |__zero__ |
-|`amount` |Multiplier on the saturation `in` |float |1.0 |
-|`lumacoeffs`|The luma coefficients to use to calculate the desaturated value|color3 |0.2722287, 0.6740818, 0.0536895|
-|`out` |Output: the adjusted value |Same as `in`|`in` |
-
-
-
-### `colorcorrect`
-Combines various adjustment nodes into one artist-friendly color correction node. For color4 inputs, the alpha value is unchanged.
-
-|Port |Description |Type |Default|
-|---------------|-------------------------------------------------------------------------|------------|-------|
-|`in` |The input color stream |colorN |__one__|
-|`hue` |Rotates the color hue |float |0 |
-|`saturation` |Multiplies the input color saturation level |float |1 |
-|`gamma` |Applies a gamma correction to the color |float |1 |
-|`lift` |Raises the dark color values, leaving the white values unchanged |float |0 |
-|`gain` |Multiplier increases lighter color values, leaving black values unchanged|float |1 |
-|`contrast` |Linearly increase or decrease the color contrast |float |1 |
-|`contrastpivot`|Pivot value around which contrast applies |float |0.5 |
-|`exposure` |Logarithmic brightness multiplier as 2^`exposure` |float |0 |
-|`out` |Output: the color-corrected value |Same as `in`| |
-
-
-## Compositing Nodes
-
-Compositing nodes have two (required) inputs named `fg` and `bg`, and apply a function to combine them. Compositing nodes are split into five subclassifications: [Premult Nodes](#premult-nodes), [Blend Nodes](#blend-nodes), [Merge Nodes](#merge-nodes), [Masking Nodes](#masking-nodes), and the [Mix Node](#mix-node).
-
-
-### Premult Nodes
-
-Premult nodes operate on 4-channel (color4) inputs/outputs, have one input named `in`, and either apply or unapply the alpha to the float or RGB color.
-
-
-
-### `premult`
-Multiply the RGB channels of the input by the Alpha channel of the input.
-
-|Port |Description |Type |Default |
-|-----|------------------------------------|------|------------------|
-|`in` |The input stream to be premultiplied|color4|0.0, 0.0, 0.0, 1.0|
-|`out`|Output: premultiplied `in` |color4|`in` |
-
-
-
-### `unpremult`
-Divide the RGB channels of the input by the Alpha channel of the input. If the Alpha value is zero, the `in` value is passed through unchanged.
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------|------|------------------|
-|`in` |The input stream to be unpremultiplied|color4|0.0, 0.0, 0.0, 1.0|
-|`out`|Output: unpremultiplied `in` |color4|`in` |
-
-
-### Blend Nodes
-
-Blend nodes take two 1-4 channel inputs and apply the same operator to all channels (the math for alpha is the same as for R or RGB); below, "F" and "B" refer to any individual channel of the `fg` and `bg` inputs respectively.
-
-
-
-
-### `plus`
-Add two 1-4 channel inputs, with optional mixing between the bg input and the result.
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|----------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'plus' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output: `fg` plus `bg` |Same as `fg` |`bg` | |
-
-
-
-### `minus`
-Subtract two 1-4 channel inputs, with optional mixing between the bg input and the result.
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|-----------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'minus' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-
-### `difference`
-Absolute-value difference of two 1-4 channel inputs, with optional mixing between the bg input and the result.
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|----------------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'difference' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-
-### `burn`
-Take two 1-4 channel inputs and apply the same operator to all channels:
-```
-1-(1-B)/F
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|----------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'burn' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-
-### `dodge`
-Take two 1-4 channel inputs and apply the same operator to all channels:
-```
-B/(1-F)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|-----------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'dodge' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-
-### `screen`
-Take two 1-4 channel inputs and apply the same operator to all channels:
-```
-1-(1-F)*(1-B)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|------------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'screen' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-
-### `overlay`
-Take two 1-4 channel inputs and apply the same operator to all channels:
-```
-2FB if B<0.5;
-1-2(1-F)(1-B) if B>=0.5
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|-------------------------------------------------------------------------------------|-------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'overlay' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |Same as `fg` |`bg` | |
-
-
-### Merge Nodes
-
-Merge nodes take two 4-channel (color4) inputs and use the built-in alpha channel(s) to control the compositing of the `fg` and `bg` inputs; "F" and "B" refer to individual non-alpha channels of the `fg` and `bg` inputs respectively, while "f" and "b" refer to the alpha channels of the `fg` and `bg` inputs. Merge nodes are not defined for 1-channel or 3-channel inputs, and cannot be used on vectorN streams.
-
-
-
-
-### `disjointover`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-F+B if f+b<=1
-F+B(1-f)/b if f+b>1
-alpha: min(f+b,1)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|------------------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'disjointover' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-
-### `in`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-RGB = Fb
-Alpha = fb
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|--------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'in' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-
-### `mask`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-RGB = Bf
-Alpha = bf
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|----------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'mask' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-
-### `matte`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-RGB = Ff+B(1-f)
-Alpha = f+b(1-f)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|-----------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'matte' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-
-### `out`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-RGB = F(1-b)
-Alpha = f(1-b)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|---------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'out' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-
-### `over`
-Take two color4 inputs and use the built-in alpha channel(s) to control the compositing of the fg and bg inputs:
-```
-RGB = F+B(1-f)
-Alpha = f+b(1-f)
-```
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|----------------------------------------------------------------------------------|------|------------------|---------------|
-|`fg` |The foreground input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`bg` |The background input stream |color4|0.0, 0.0, 0.0, 0.0| |
-|`mix`|A mixing value between `bg` (mix=0) and the result of the 'over' operation (mix=1)|float |1.0 |[0, 1] |
-|`out`|Output |color4|`bg` | |
-
-
-### Masking Nodes
-
-Masking nodes take one 1-4 channel input `in` plus a separate float `mask` input and apply the same operator to all "in" channels; "F" refers to any individual channel of the `in` input, while "m" refers to the mask input.
-
-
-
-
-### `inside`
-An "inside" mask operation returning Fm
-
-|Port |Description |Type |Default |Accepted Values|
-|------|---------------------------------|-------------|--------|---------------|
-|`in` |The input stream to be masked |float, colorN|__zero__| |
-|`mask`|The masking input signal |float |1.0 |[0, 1] |
-|`out` |Output: `in` multiplied by `mask`|Same as `in` |`in` | |
-
-
-
-### `outside`
-An "outside" mask operation returning F(1-m)
-
-|Port |Description |Type |Default |Accepted Values|
-|------|-----------------------------------|-------------|--------|---------------|
-|`in` |The input stream to be masked |float, colorN|__zero__| |
-|`mask`|The masking input signal |float |1.0 |[0, 1] |
-|`out` |Output: `in` multiplied by 1-`mask`|Same as `in` |`in` | |
-
-
-### Mix Node
-
-The Mix node takes two 1-4 channel inputs `fg` and `bg` plus a separate 1-channel (float) or N-channel (same type and number of channels as `fg` and `bg`) `mix` input and mixes the `fg` and `bg` according to the mix value, either uniformly for a "float" `mix` type, or per-channel for non-float `mix` types; "F" refers to any individual channel of the `in` input, while "m" refers to the appropriate channel of the mix input.
-
-
-
-### `mix`
-A "mix" operation blending from "bg" to "fg" according to the mix amount, returning Fm+B(1-m)
-
-|Port |Description |Type |Default |Accepted Values|
-|-----|---------------------------------------|----------------------|--------|---------------|
-|`fg` |The foreground input stream |float, colorN, vectorN|__zero__| |
-|`bg` |The background input stream |Same as `fg` |__zero__| |
-|`mix`|The amount to mix `bg` to `fg` |float |0.0 |[0, 1] |
-|`out`|Output: the result of the mix operation|Same as `fg` |`bg` | |
-
-|Port |Description |Type |Default |
-|-----|-------------------------------|---------------|--------|
-|`fg` |The foreground input stream |colorN, vectorN|__zero__|
-|`bg` |The background input stream |Same as `fg` |__zero__|
-|`mix`|The amount to mix `bg` to `fg` |Same as `fg` |__zero__|
-|`out`|Output |Same as `fg` |`bg` |
-
-See also the [Standard Shader Nodes](#standard-shader-nodes) section below for additional shader-semantic variants of the [`mix` node](#node-mix-shader).
-
-
-
-## Conditional Nodes
-
-Conditional nodes are used to compare values of two streams, or to select a value from one of several streams.
-
-
-
-
-### `ifgreater`
-
-Output the value of the `in1` or `in2` stream depending on whether the `value1` input is greater than the `value2` input.
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|The first value to be compared |float, integer |__one__ |
-|`value2`|The second value to be compared |Same as `value1` |__zero__|
-|`in1` |The value stream to output if `value1` > `value2` |float, colorN, vectorN, matrixNN, integer|__zero__|
-|`in2` |The value stream to output if `value1` <= `value2`|Same as `in1` |__zero__|
-|`out` |Output: the result of the comparison |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|the first value to be compared |float, integer |__one__ |
-|`value2`|the second value to be compared |Same as `value1` |__zero__|
-|`out` |Output: true if `value1` > `value2 |boolean |false |
-
-
-
-### `ifgreatereq`
-
-Output the value of the `in1` or `in2` stream depending on whether the `value1` input is greater or equal to the `value2` input.
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|the first value to be compared |float, integer |__one__ |
-|`value2`|the second value to be compared |Same as `value1` |__zero__|
-|`in1` |The value stream to output if `value1` >= `value2`|float, colorN, vectorN, matrixNN, integer|__zero__|
-|`in2` |The value stream to output if `value1` < `value2` |Same as `in1` |__zero__|
-|`out` |Output: the result of the comparison |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|the first value to be compared |float, integer |__one__ |
-|`value2`|the second value to be compared |Same as `value1` |__zero__|
-|`out` |Output: true if `value1` >= `value2 |boolean |false |
-
-
-
-### `ifequal`
-
-Output the value of the `in1` or `in2` stream depending on whether the `value1` input is equal to the `value2` input.
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|the first value to be compared |float, integer |__one__ |
-|`value2`|the second value to be compared |Same as `value1` |__zero__|
-|`in1` |The value stream to output if `value1` = `value2` |float, colorN, vectorN, matrixNN, integer|__zero__|
-|`in2` |The value stream to output if `value1` != `value2`|Same as `in1` |__zero__|
-|`out` |Output: the result of the comparison |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|The first value to be compared |boolean |false |
-|`value2`|The second value to be compared |boolean |false |
-|`in1` |The value stream to output if `value1` = `value2` |float, colorN, vectorN, matrixNN, integer|__zero__|
-|`in2` |The value stream to output if `value1` != `value2`|Same as `in1` |__zero__|
-|`out` |Output: the result of the comparison |Same as `in1` |`in1` |
-
-|Port |Description |Type |Default |
-|--------|--------------------------------------------------|-----------------------------------------|--------|
-|`value1`|the first value to be compared |float, integer |__one__ |
-|`value2`|the second value to be compared |Same as `value1` |__zero__|
-|`out` |Output: true if `value1` = `value2` |boolean |false |
-
-|Port |Description |Type |Default|
-|--------|-----------------------------------|-------|-------|
-|`value1`|The first value to be compared |boolean|false |
-|`value2`|The first value to be compared |boolean|false |
-|`out` |Output: true if `value1` = `value2`|boolean|false |
-
-
-
-### `switch`
-
-Output the value of one of up to ten input streams, according to the value of a selector input `which`. Note that not all inputs need to be connected. The output has the same type as `in1`, with a default value of __zero__.
-
-|Port |Description |Type |Default |
-|-------|---------------------------------------------------------------------------------------------------------------------------|--------------------------------|--------|
-|`in1` |Input stream to select from using `which` |float, colorN, vectorN, matrixNN|__zero__|
-|`in2` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in3` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in4` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in5` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in6` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in7` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in8` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in9` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`in10` |Input stream to select from using `which` |Same as `in1` |__zero__|
-|`which`|Selector to choose which input to take values from; the output comes from input floor(`which`)+1, clamped to the 1-10 range|float, integer |__zero__|
-|`out` |Output: the selected input |Same as `in1` |`in1` |
-
-
-
-## Channel Nodes
-
-Channel nodes are used to perform channel manipulations and data type conversions on streams.
-
-
-
-
-### `extract`
-
-Isolate a single float channel from a __vectorN__ or __colorN__ stream. The output value is of type `float` with a default value of __zero__.
-
-|Port |Description |Type |Default |
-|-------|--------------------------------------------|-------|-------------|
-|`in` |The input stream from which to extract `out`|color3 |0.0, 0.0, 0.0|
-|`index`|The index of the channel in `in` to extract |integer|0 |
-|`out` |Output: the `index`th channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|-------|--------------------------------------------|-------|------------------|
-|`in` |The input stream from which to extract `out`|color4 |0.0, 0.0, 0.0, 0.0|
-|`index`|The index of the channel in `in` to extract |integer|0 |
-|`out` |Output: the `index`th channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|-------|--------------------------------------------|-------|--------|
-|`in` |The input stream from which to extract `out`|vector2|0.0, 0.0|
-|`index`|The index of the channel in `in` to extract |integer|0 |
-|`out` |Output: the `index`th channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|-------|--------------------------------------------|-------|-------------|
-|`in` |The input stream from which to extract `out`|vector3|0.0, 0.0, 0.0|
-|`index`|The index of the channel in `in` to extract |integer|0 |
-|`out` |Output: the `index`th channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|-------|--------------------------------------------|-------|------------------|
-|`in` |The input stream from which to extract `out`|vector4|0.0, 0.0, 0.0, 0.0|
-|`index`|The index of the channel in `in` to extract |integer|0 |
-|`out` |Output: the `index`th channel of `in` |float |0.0 |
-
-The valid range for `index` should be clamped to $[0,N)$ in the user interface, where __N__ is the size of the input vector stream. `index` is a uniform, non-varying value. Any `index` values outside of the valid range should result in an error.
-
-
-
-### `convert`
-Convert a stream from one data type to another.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------|-------|--------|
-|`in` |The input stream to convert |boolean|false |
-|`out`|Output: the converted value, either 0.0 or 1.0 |float |0.0 |
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------|-------|--------|
-|`in` |The input stream to convert |integer|0 |
-|`out`|Output: the converted value |float |0.0 |
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------|-------|--------|
-|`in` |The input stream to convert |boolean|false |
-|`out`|Output: the converted value, either 0 or 1 |integer|0 |
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------|-------|--------|
-|`in` |The input stream to convert |integer|0 |
-|`out`|Output: true for any non-zero input value |boolean|false |
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------|--------------|--------|
-|`in` |The input stream to convert |float,integer |__zero__|
-|`out`|Output: copy input value to all channels |colorN,vectorN|__zero__|
-
-|Port |Description |Type |Default |
-|-----|--------------------------------------------------|--------------|--------|
-|`in` |The input stream to convert |boolean |false |
-|`out`|Output: 1 in all channels if `in`=true, 0 if false|colorN,vectorN|__zero__|
-
-|Port |Description |Type |Default |
-|-----|-----------------------------|--------------|--------|
-|`in` |The input stream to convert |colorN,vectorN|__zero__|
-|`out`|Output: see below |colorM,vectorM|__zero__|
-
-For colorN/vectorN to colorM/vectorM:
-
- * if _N_ is the same as _M_, then channels are directly copied.
- * if _N_ is larger than _M_, then the first _M_ channels are used and the excess channels ignored.
- * if _N_ is smaller than _M_, then the _N_ channels are directly copied and additional channels are populated with 0, aside from the fourth channel which is populated with 1.
-
-
-
-
-### `combine2`
-
-Combine the channels from two streams into the same number of channels of a single output stream of a compatible type.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|-------|--------|
-|`in1`|The input stream that will be sent to the first channel of `out` |float |0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|float |0.0 |
-|`out`|Output: the combined value |vector2|0.0, 0.0|
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|------|------------------|
-|`in1`|The input stream that will be sent to the first channel of `out` |color3|0.0, 0.0, 0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|float |0.0 |
-|`out`|Output: the combined value |color4|0.0, 0.0, 0.0, 0.0|
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|-------|------------------|
-|`in1`|The input stream that will be sent to the first channel of `out` |vector3|0.0, 0.0, 0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|float |0.0 |
-|`out`|Output: the combined value |vector4|0.0, 0.0, 0.0, 0.0|
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|-------|------------------|
-|`in1`|The input stream that will be sent to the first channel of `out` |vector2|0.0, 0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|vector2|0.0, 0.0 |
-|`out`|Output: the combined value |vector4|0.0, 0.0, 0.0, 0.0|
-
-
-
-### `combine3`
-
-Combine the channels from three streams into the same number of channels of a single output stream of a compatible type.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|---------------|--------|
-|`in1`|The input stream that will be sent to the first channel of `out` |float |0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|float |0.0 |
-|`in3`|The input stream that will be sent to the third channel of `out` |float |0.0 |
-|`out`|Output: the combined value |color3, vector3|__zero__|
-
-
-
-### `combine4`
-
-Combine the channels from four streams into the same number of channels of a single output stream of a compatible type.
-
-|Port |Description |Type |Default |
-|-----|-----------------------------------------------------------------|---------------|--------|
-|`in1`|The input stream that will be sent to the first channel of `out` |float |0.0 |
-|`in2`|The input stream that will be sent to the second channel of `out`|float |0.0 |
-|`in3`|The input stream that will be sent to the third channel of `out` |float |0.0 |
-|`in4`|The input stream that will be sent to the fourth channel of `out`|float |0.0 |
-|`out`|Output: the combined value |color4, vector4|__zero__|
-
-
-
-### `separate2`
-
-Split the channels of a 2-channel stream into separate float outputs.
-
-|Port |Description |Type |Default |
-|------|--------------------------------|-------|--------|
-|`in` |The input stream to be separated|vector2|0.0, 0.0|
-|`outx`|Output: the x channel of `in` |float |0.0 |
-|`outy`|Output: the y channel of `in` |float |0.0 |
-
-For the vector2-input `in`, `outx` and `outy` correspond to the x- and y-components of `in`..
-
-
-
-### `separate3`
-
-Split the channels of a 3-channel stream into separate float outputs.
-
-|Port |Description |Type |Default |
-|------|--------------------------------|------|-------------|
-|`in` |The input stream to be separated|color3|0.0, 0.0, 0.0|
-|`outr`|Output: the r channel of `in` |float |0.0 |
-|`outg`|Output: the g channel of `in` |float |0.0 |
-|`outb`|Output: the b channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|------|--------------------------------|-------|-------------|
-|`in` |The input stream to be separated|vector3|0.0, 0.0, 0.0|
-|`outx`|Output: the x channel of `in` |float |0.0 |
-|`outy`|Output: the y channel of `in` |float |0.0 |
-|`outz`|Output: the z channel of `in` |float |0.0 |
-
-When the input `in` is a color3, `outr`, `outg`, and `outb` correspond to the r-, g-, and b-components of `in`, respectively.
-
-When the input `in` is a vector3, `outx`, `outy`, and `outz` correspond to the x-, y-, and z-components of `in`, respectively.
-
-
-
-### `separate4`
-
-Split the channels of a 4-channel stream into separate float outputs.
-
-|Port |Description |Type |Default |
-|------|--------------------------------|------|------------------|
-|`in` |The input stream to be separated|color4|0.0, 0.0, 0.0, 0.0|
-|`outr`|Output: the r channel of `in` |float |0.0 |
-|`outg`|Output: the g channel of `in` |float |0.0 |
-|`outb`|Output: the b channel of `in` |float |0.0 |
-|`outa`|Output: the a channel of `in` |float |0.0 |
-
-|Port |Description |Type |Default |
-|------|--------------------------------|-------|------------------|
-|`in` |The input stream to be separated|vector4|0.0, 0.0, 0.0, 0.0|
-|`outx`|Output: the x channel of `in` |float |0.0 |
-|`outy`|Output: the y channel of `in` |float |0.0 |
-|`outz`|Output: the z channel of `in` |float |0.0 |
-|`outw`|Output: the w channel of `in` |float |0.0 |
-
-When the input `in` is a color4, `outr`, `outg`, `outb`, and `outa` correspond to the r-, g-, b-, and alpha components of `in`, respectively.
-
-When the input `in` is a vector4, `outx`, `outy`, `outz`, and `outw` correspond to the x-, y-, z-, and w-components of `in`, respectively.
-
-
-## Convolution Nodes
-
-Convolution nodes have one input named "in", and apply a defined convolution function on the input stream. Some of these nodes may not be implementable in ray tracing applications; they are provided for the benefit of purely 2D image processing applications.
-
-
-
-
-### `blur`
-
-Applies a convolution blur to the input stream.
-
-|Port |Description |Type |Default |Accepted Values|
-|------------|-------------------------------------------|----------------------|--------|---------------|
-|`in` |The input stream to be blurred |float, colorN, vectorN|__zero__| |
-|`size` |The size of the blur kernel in 0-1 UV space|float |0.0 | |
-|`filtertype`|The spatial filter used in the blur |string |box |box, gaussian |
-|`out` |Output: the blurred `in` |Same as `in` |`in` | |
-
-
-
-### `heighttonormal`
-
-Convert a scalar height map to a tangent-space normal map of type `vector3`. The output normal map is encoded with all channels in the [0-1] range, enabling its storage in unsigned image formats.
-
-|Port |Description |Type |Default |
-|----------|---------------------------------------------------------------------------------|-------|-------------|
-|`in` |The input scalar height map |float |0.0 |
-|`scale` |Multiplier applied to the `in` signal |float |1.0 |
-|`texcoord`|The texture coordinates that the heightfield gradient is computed with respect to|vector2|_UV0_ |
-|`out` |Output: tangent-space normal computed from `in` |vector3|0.5, 0.5, 1.0|
-
-
-
-
-
-# Standard Shader Nodes
-
-The Standard MaterialX Library defines the following nodes and node variants operating on "shader"-semantic types. Standard library shaders do not respond to external illumination; please refer to the [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md#materialx-pbs-library) document for definitions of additional nodes and shader constructors which do respond to illumination, as well as [**MaterialX NPR Shading Nodes**](./MaterialX.NPRSpec.md) for definitions of shaders and nodes applicable to non-photorealistic rendering.
-
-
-
-### `surface_unlit`
-An unlit surface shader node, representing a surface that can emit and transmit light, but does not receive illumination from light sources or other surfaces.
-
-|Port |Description |Type |Default |
-|--------------------|-------------------------------------|-------------|-------------|
-|`emission` |The surface emission amount |float |1.0 |
-|`emission_color` |Surface emission color |color3 |1.0, 1.0, 1.0|
-|`transmission` |The surface transmission amount |float |0.0 |
-|`transmission_color`|Surface transmission color |color3 |1.0, 1.0, 1.0|
-|`opacity` |Surface cutout opacity |float |1.0 |
-|`out` |Output: unlit surface shader closure |surfaceshader| |
-
-
-
-### `displacement`
-Constructs a displacement shader describing geometric modification to surfaces.
-
-The scalar signature displaces along the surface normal direction, while the vector signature allows displacement in tangent/normal space using (dPdu, dPdv, N) coordinates.
-
-|Port |Description |Type |Default |
-|--------------|----------------------------------------|------------------|--------|
-|`displacement`|Displacement amount or direction |float, vector3 |__zero__|
-|`scale` |Scale factor for the displacement |float |1.0 |
-|`out` |Output: the computed displacement shader|displacementshader| |
-
-
-
-### `mix`
-A linear blend between two surface/displacement/volumeshader closures.
-
-|Port |Description |Type |Default|
-|------|------------------------------------------------------|-------------|-------|
-|`bg` |The background surface closure |surfaceshader| |
-|`fg` |The foreground surface closure |surfaceshader| |
-|`mix` |The blending factor used to mix the two input closures|float |0.0 |
-|`out` |Output: surface shader closure |surfaceshader| |
-
-|Port |Description |Type |Default|
-|------|------------------------------------------------------|------------------|-------|
-|`bg` |The background displacement closure |displacementshader| |
-|`fg` |The foreground displacement closure |displacementshader| |
-|`mix` |The blending factor used to mix the two input closures|float |0.0 |
-|`out` |Output: displacement shader closure |displacementshader| |
-
-|Port |Description |Type |Default|
-|------|------------------------------------------------------|------------|-------|
-|`bg` |The background volume closure |volumeshader| |
-|`fg` |The foreground volume closure |volumeshader| |
-|`mix` |The blending factor used to mix the two input closures|float |0.0 |
-|`out` |Output: volume shader closure |volumeshader| |
-
diff --git a/MaterialX/documents/Specification/MaterialX.Supplement.md b/MaterialX/documents/Specification/MaterialX.Supplement.md
old mode 100644
new mode 100755
index 8b3eee8..05226de
--- a/MaterialX/documents/Specification/MaterialX.Supplement.md
+++ b/MaterialX/documents/Specification/MaterialX.Supplement.md
@@ -1,264 +1,261 @@
-
-
-
-# MaterialX: Supplemental Notes
-
-**Version 1.39**
-Doug Smythe - Industrial Light & Magic
-Jonathan Stone - Lucasfilm Advanced Development Group
-March 25, 2023
-
-
-
-# Introduction
-
-This document details additional information about MaterialX and how it may be incorporated into studio pipelines. The document describes recommended naming convention for node definition elements and a directory structure to define packages of node definitions and implementations from various sources.
-
-Previous versions of the MaterialX Supplemental Notes document included descriptions of additional node types: these node descriptions have now been folded back into the [Main Specification Document](./MaterialX.Specification.md#nodes) alongside all the other standard node descriptions.
-
-
-## Table of Contents
-
-**[Introduction](#introduction)**
-
-**[Recommended Element Naming Conventions](#recommended-element-naming-conventions)**
-
-**[Material and Node Library File Structure](#material-and-node-library-file-structure)**
- [Examples](#examples)
-
-**[Definitions, Assets, and Libraries](#definitions-assets-and-libraries)**
- [Organization Using Node Graphs](#organization-using-node-graphs)
- [Publishing Definitions](#publishing-definitions)
- [Dependencies and Organization](#dependencies-and-organization)
- [Deployment, Transmission, and Translation](#deployment-transmission-and-translation)
-
-
-
-
-# Recommended Element Naming Conventions
-
-While MaterialX elements can be given any valid name as described in the MaterialX Names section of the main specification, adhering to the following recommended naming conventions will make it easier to predict the name of a nodedef for use in implementation and nodegraph elements as well as help reduce the possibility of elements from different sources having the same name.
-
-**Nodedef**: "ND\__nodename_\__outputtype_[\__target_][\__version_]", or for nodes with multiple input types for a given output type (e.g. <convert>), "ND\__nodename_\__inputtype_\__outputtype_[\__target_][\__version_]".
-
-**Implementation**: "IM\__nodename_[\__inputtype_]\__outputtype_[\__target_][\__version_]".
-
-**Nodegraph**, as an implementation for a node: "NG\__nodename_[\__inputtype_]\__outputtype_[\__target_][\__version_]".
-
-
-
-
-# Material and Node Library File Structure
-
-As studios and vendors develop libraries of shared definitions and implementations of MaterialX materials and nodes for various targets, it becomes beneficial to have a consistent, logical organizational structure for the files on disk that make up these libraries. In this section, we propose a structure for files defining libraries of material nodes, <nodedef>s, nodegraph implementations and actual target-specific native source code, as well as a mechanism for applications and MaterialX content to find and reference files within these libraries.
-
-Legend for various components within folder hierarchies:
-
-| Term | Description |
-| --- | --- |
-| _libname_ | The name of the library; the MaterialX Standard nodes are the "stdlib" library. Libraries may choose to declare themselves to be in the libname namespace, although this is not required. |
-| _target_ | The target for an implementation, e.g. "glsl", "oslpattern", "osl" or "mdl". |
-| _sourcefiles_ | Source files (including includes and makefiles) for the target, in whatever format and structure the applicable build system requires. |
-
-
-Here is the suggested structure and naming for the various files making up a MaterialX material or node definition library setup. Italicized terms should be replaced with appropriate values, while boldface terms should appear verbatim. The optional "\_\*" component of the filename can be any useful descriptor of the file's contents, e.g. "\_ng" for nodegraphs or "\_mtls" for materials.
-
-
- _libname_/_libname_**\_defs.mtlx** (1)
- _libname_/_libname_\_\***.mtlx** (2)
- _libname_/_target_/_libname_\_target[\_\*]**\_impl.mtlx** (3)
- _libname_/_target_/_sourcefiles_ (4)
-
-
-
-1. Nodedefs and other definitions in library _libname_.
-2. Additional elements (e.g. nodegraph implementations for nodes, materials, etc.) in library _libname_.
-3. Implementation elements for _libname_ specific to target _target_.
-4. Source code files for _libname_ implementations specific to target _target_.
-
-Note that nodedef files and nodegraph-implementation files go at the top _libname_ level, while <implementation> element files go under the corresponding _libname_/_target_ level, next to their source code files. This is so that studios may easily install only the implementations that are relevant to them, and applications can easily locate the implementations of nodes for specific desired targets. Libraries are free to add additional arbitrarily-named folders for related content, such as an "images" subfolder for material library textures.
-
-The _libname_\_defs.mtlx file typically contains nodedefs for the library, but may also contain other node types such as implementation nodegraphs, materials, looks, and any other element types. The use of additional _libname_\_\*.mtlx files is optional, but those files should be Xincluded by the _libname_\_defs.mtlx file.
-
-A file referenced by a MaterialX document or tool (e.g. XInclude files, filenames in <image> or other MaterialX nodes, or command-line arguments in MaterialX tools) can be specified using either a relative or a fully-qualified absolute filesystem path. A relative path is interpreted to be relative to either the location of the referencing MaterialX document itself, or relative to a location found within the current MaterialX search path: this path may be specified via an application setting (e.g. the `--path` option in MaterialXView) or globally using the MATERIALX_SEARCH_PATH environment variable. These search paths are used for both XIncluded definitions and filename input values (e.g. images for nodes or source code for <implementation>s), and applications may choose to define different search paths for different contexts if desired, e.g. for document processing vs. rendering.
-
-The standard libraries `stdlib` and `pbrlib` are typically included _automatically_ by MaterialX applications, rather than through explicit XInclude directives within .mtlx files. Non-standard libraries are included into MaterialX documents by XIncluding the top-level _libname_/_libname_\_defs.mtlx file, which is expected to in turn XInclude any additional .mtlx files needed by the library.
-
-
-### Examples
-
-In the examples below, MXROOT is a placeholder for one of the root paths defined in the current MaterialX search path.
-
-A library of studio-custom material shading networks and example library materials:
-
-```
- MXROOT/mtllib/mtllib_defs.mtlx (material nodedefs and nodegraphs)
- MXROOT/mtllib/mtllib_mtls.mtlx (library of materials using mtllib_defs)
- MXROOT/mtllib/images/*.tif (texture files used by mtllib_mtls nodes)
-```
-
-Documents may include the above library using
-
-```xml
-
-```
-
-and that file would XInclude `mtllib_mtls.mtlx`. <Image> nodes within `mtllib_mtls.mtlx` would use `file` input values such as "images/bronze_color.tif", e.g. relative to the path of the `mtllib_mtls.mtlx` file itself.
-
-Standard node definitions and reference OSL implementation:
-
-```
- MXROOT/stdlib/stdlib_defs.mtlx (standard library node definitions)
- MXROOT/stdlib/stdlib_ng.mtlx (supplemental library node nodegraphs)
- MXROOT/stdlib/osl/stdlib_osl_impl.mtlx (stdlib OSL implementation elem file)
- MXROOT/stdlib/osl/*.{h,osl} (etc) (stdlib OSL source files)
-```
-
-Layout for "genglsl" and "genosl" implementations of "stdlib" for MaterialX's shadergen component, referencing the above standard `stdlib_defs.mtlx` file:
-
-```
- # Generated-GLSL implementations
- MXROOT/stdlib/genglsl/stdlib_genglsl_impl.mtlx (stdlib genGLSL implementation file)
- MXROOT/stdlib/genglsl/stdlib_genglsl_cm_impl.mtlx (stdlib genGLSL color-mgmt impl. file)
- MXROOT/stdlib/genglsl/*.{inline,glsl} (stdlib common genGLSL code)
-
- # Generated-OSL implementations
- MXROOT/stdlib/genosl/stdlib_genosl_impl.mtlx (stdlib genOSL implementation file)
- MXROOT/stdlib/genosl/stdlib_genosl_cm_impl.mtlx (stdlib genOSL color-mgmt impl. file)
- MXROOT/stdlib/genosl/*.{inline,osl} (stdlib common genOSL code)
-```
-
-Layout for the shadergen PBR shader library ("pbrlib") with implementations for "genglsl" and "genosl" (generated GLSL and OSL, respectively) targets:
-
-```
- MXROOT/pbrlib/pbrlib_defs.mtlx (PBR library definitions)
- MXROOT/pbrlib/pbrlib_ng.mtlx (PBR library nodegraphs)
- MXROOT/pbrlib/genglsl/pbrlib_genglsl_impl.mtlx (pbr impl file referencing genGLSL source)
- MXROOT/pbrlib/genglsl/*.{inline,glsl} (pbr common genGLSL code)
- MXROOT/pbrlib/genosl/pbrlib_genosl_impl.mtlx (pbr impl file referencing genOSL source)
- MXROOT/pbrlib/genosl/*.{inline,osl} (pbr common genOSL code)
-```
-
-
-
-
-# Definitions, Assets, and Libraries
-
-In this section we propose a set of guidelines for managing unique definitions or assets and organization into libraries, wherein:
-
-* Definitions: Correspond directly to <nodedefs> which may or be either source code implementations or based on existing node definitions.
-* Assets: is a term which corresponds to a definition plus any additional metadata on a definition and /or related resources such as input images. These can be organized in logical groupings based on a desired semantic.
-* Libraries: are a collection of assets.
-
-
-### Organization Using Node Graphs
-
-While it is possible to just have a set of connected nodes in a document, it is not possible to have any formal unique interface. This can invariably lead to nodes which have duplicate names, the inability to control what interfaces are exposed and inability to maintain variations over time.
-
-Thus the base requirement for a definition is to encapsulate the nodes into a <nodegraph>. This provides for:
-
-1. Hiding Complexity: Where all nodes are scoped with the graph. For user interaction point, it makes possible the ability to “drill down” into a graph as needed but otherwise a black box representation can be provided.
-2. Identifier / Path Uniqueness : The nodegraph name decreases the chances of name clashes. For example two top level nodes both called “foo” would have unique paths “bar1/foo” and “bar2/foo” when placed into two nodegraphs “bar1” and “bar2”.
-3. Interface / node signature control where specific inputs may be exposed via “interfacename” connections and outputs as desired. This differs from “hiding” inputs or outputs which do not change the signature. The former enforces what is exposed to the user while the latter are just interface hints.
-
-For individual inputs it is recommended to add the following additional attributes as required:
-
-1. Real World Units : If an input value depends on scene / geometry size then a unit attribute should always be added. For example if the graph represents floor tile, then to place it properly the size of the tile. A preset set of “distance” units is provided as part of the standard library.
-2. Colorspace: If an input value is represented in a given color space then to support proper transformation into rendering color space this attribute should be set. A preset set of colorspace names conforming to the AcesCg 1.2 configuration is provided as part of the standard library.
-
-Though not strictly required it is very useful to have appropriate default values as without these the defaults will be zero values. Thus for example a “scale” attribute for a texture node should not be left to default to zero.
-
-
-### Publishing Definitions
-
-From a <nodegraph> a definition can be (new <nodedef>) created or “published”. Publishing allows for the following important capabilities:
-
-1. Reuse: The ability to reuse an unique node definition as opposed to duplicating graph implementations.
-2. Variation: The ability to create or apply variations to an instance independent from the implementation.
-3. Interoperability: Support definitions with common properties that are mutually understood by all consumers be exchanged.
-
-In order to support these capabilities It is recommended that the following attributes always be specified:
-
-1. A unique name identifier: This can follow the ND\_ and NG\_ convention described. It is recommended that the signature of the interface also be encoded to provide uniqueness, especially if the definition may be polymorphic.
-2. A namespace identifier (\*): When checking uniqueness namespace is always used so it is not required to be part of the name identifier to provide uniqueness.
- * It should not be used as it will result in the namespace being prepended multiple times. E.g. a “foo” node with a namespace “myspace” has a unique identifier of “myspace:node”. If the node is named “myspace:node”, then the resulting identifier is “myspace:myspace:node”.
- * Note that import of a Document will prepend namespaces as required without namespace duplication.
-3. A version identifier: While this can be a general string, it is recommended that this be a template with a specific format to allow for known increment numbering. E.g. The format may be “v#.#” to support minor and major versioning. This requires that only one out of all versions be tagged as the default version. Care should be taken to ensure this as the first one found will be used as the default.
-4. A nodegroup identifier: This can be one mechanism used for definition organization, or for user interface presentation. It is also used for shader generation to some extent as it provides hints as to the type of node. For example <image> nodes are in the “texture2d” node group.
-5. A documentation string. Though not strictly required this provides some ability to tell what a node does, and can be used as a user interface helper. Currently there is no formatting associated with this but it is possible to embed a format.
-
-Note that utilities which codify publishing logic are provided as part of the core distribution.
-
-To support variation it is proposed that both <token>s and <variant>s be used.
-
-
-
-1. Tokens: These allow for the sample “template” be used for filenames with having to create new definitions. This can reduce the number of required definitions but also reduce the number of presets required. For example tokens can be used to control the format, resolution of the desired filename identifier.
-2. Variants and Variant Sets: There are no hard-and-fast “rules” for when to create a definition vs use a definition with variants but one possible recommendation is to use variants when there are no interface signature differences (_Discuss_?). Some advantages include the fact that variants may be packaged and deployed independent of definitions and/or new definitions do not need to be deployed per variation. Note that for now only value overrides are possible.
-
-
-### Dependencies and Organization
-
-The more definitions are added including those based on other definitions, the harder it can be to discover what definitions are required given documents with some set of node instances.
-
-To support separability of dependents, the following logical high level semantic breakdown is proposed:
-
-
-
-1. Static “Core” library definitions. These include stdlib, pbrlib and bxdf. The recommendation is to always load these in and assume that they exist. For separability, it is recommended that these all be stored in a single runtime Document.
-2. Static custom library definitions. These are based on core libraries. The recommendation is to not directly reference any core libraries using the Xinclude mechanism. This can result in duplicate possibly conflicting definitions being loaded. The “upgrade” mechanism will ensure that all core and custom libraries are upgraded to the appropriate target version. For separability, it is recommended that these all be stored in a single runtime Document.
-3. Dynamically created definitions. If this capability is allowed then it can be useful to have a fixed set of locations that these definitions can update. This could be local to the user or to update an existing custom library.
-
-Additional groupings can be added to provide semantic organization (such as by “nodegroup”) though the recommendation is that they live within a common library root or package.
-
-For an asset with dependent resources there are many options. Two of which are:
-
-
-
-1. Co-locate resources with the definition. This allows for easier “packaging” of a single asset such as for transmission purposes but this can require additional discovery logic to find resources associated with a definition and may result in duplication of resources.
-2. Located in a parallel folder structure to definitions. The onus is to maintain this parallel structure but the search logic complexity is the same for resources as it is for definitions.
-
-If a definition is a source code implementation, then additional path search logic is required for discoverability during generation.
-
-The following search paths are available:
-
-
-
-* MATERIALX_SEARCH_PATH: This environment variable is used as part of both definition and resource search (e.g. relative filename path support).
-* Source code paths: This can be registered at time of code generation as part of the generation “context”. It is recommended to follow the source path locations which would be relative to any custom definitions, using the “language” identifier of the code generator to discover the appropriate source code files.
-
-An example usage of pathing can be found in the sample Viewer. The logic is as follows:
-
-
-
-* The module/binary path is set as the default “root” definition path. Additional definition roots are included via MATERIALX_SEARCH_PATH.
-* The set of roots are considered to be the parent of “resources” and “libraries” folders, for resource and definitions respectively.
-* The search path root for resources would be the “`/resources`” by default. This allows for handling of resources which are part of an assets definition. For example a brick shader located at “`/myroot/shaders/brick.mtlx`” may have the brick textures referenced at location “`/myroot/textures/brick.exr`”. Setting a single search path to “`/myroot`” handles the “parallel” folder organization mentioned, with the relative reference being “`textures/brick.exr`”
-* For any shader at a given path a path to that shader can be added when resolving dependent resources. This can be used to handle the co-located folder organization. For example the shader may reside in “`/myroot/shader/brick.mtlx`”, and the texture in “`/myroot/shader/textures/brick.exr`”. Setting a root to “`myroot/shader`” and a relative reference to “`textures/brick.exr`” will allow for proper discovery.
-
-For runtime, it is recommended that instead of reading in documents that they be “imported”. This allows for mechanisms such as namespace handling as well as tagging of source location (“sourceURI”) to occur per document. At some point all dependent documents need to be merged into a single one as there is no concept of referenced in-memory documents. Tagging is a useful mechanism to allow filtering out / exclusion of definitions from the main document content. For example, the main document can be “cleared” out while retaining the library definitions.
-
-As there may be definitions dependent on other definitions, it is never recommended to unload core libraries, and care be taken when unloading custom or dynamic libraries. It may be useful to re-load all definitions if there is a desire to unload any one library.
-
-Note that code generation is context based. If the context is not cleared, then dependent source code implementations will be retained. It is recommended to clear implementations if definitions are unloaded.
-
-
-### Deployment, Transmission, and Translation
-
-Given a set of definitions it is useful to consider how it will be deployed.
-
-Some deployments for which file access may be restricted or accessing many files is a performance issue, pre-package up definitions, source and associated resources may be required. For example, this is currently used for the sample Web viewer deployment.
-
-Some deployments may not want to handle non-core definitions or may not be able to handle (complex) node graphs. Additionally the definition may be transmitted as a shader. Thus, when creating a new definition it is recommended to determine the level of support for:
-
-
-
-1. Flattening: Can the definition be converted to a series of nodes which have source code implementations.
-2. Baking: Can the definition be converted to an image.
-3. Translation: Can the implementation be converted mapped / converted to another implementation which can be consumed.
-4. Shader Reflection: Can the desired metadata be passed to the shader for introspection.
-
-Additional metadata which is not a formal part of the specification may lead to the inability to be understood by consumers.
-
+
+
+
+# MaterialX: Supplemental Notes
+
+**Version 1.39**
+Doug Smythe - Industrial Light & Magic
+Jonathan Stone - Lucasfilm Advanced Development Group
+March 25, 2023
+
+
+
+# Introduction
+
+This document details additional information about MaterialX and how it may be incorporated into studio pipelines. The document describes recommended naming convention for node definition elements and a directory structure to define packages of node definitions and implementations from various sources.
+
+Previous versions of the MaterialX Supplemental Notes document included descriptions of additional node types: these node descriptions have now been folded back into the [Main Specification Document](./MaterialX.Specification.md#nodes) alongside all the other standard node descriptions.
+
+
+## Table of Contents
+
+**[Introduction](#introduction)**
+
+**[Recommended Element Naming Conventions](#recommended-element-naming-conventions)**
+
+**[Material and Node Library File Structure](#material-and-node-library-file-structure)**
+ [Examples](#examples)
+
+**[Definitions, Assets, and Libraries](#definitions-assets-and-libraries)**
+ [Organization Using Node Graphs](#organization-using-node-graphs)
+ [Publishing Definitions](#publishing-definitions)
+ [Dependencies and Organization](#dependencies-and-organization)
+ [Deployment, Transmission, and Translation](#deployment-transmission-and-translation)
+
+
+
+# Recommended Element Naming Conventions
+
+While MaterialX elements can be given any valid name as described in the MaterialX Names section of the main specification, adhering to the following recommended naming conventions will make it easier to predict the name of a nodedef for use in implementation and nodegraph elements as well as help reduce the possibility of elements from different sources having the same name.
+
+**Nodedef**: "ND\__nodename_\__outputtype_[\__target_][\__version_]", or for nodes with multiple input types for a given output type (e.g. <convert>), "ND\__nodename_\__inputtype_\__outputtype_[\__target_][\__version_]".
+
+**Implementation**: "IM\__nodename_[\__inputtype_]\__outputtype_[\__target_][\__version_]".
+
+**Nodegraph**, as an implementation for a node: "NG\__nodename_[\__inputtype_]\__outputtype_[\__target_][\__version_]".
+
+
+
+# Material and Node Library File Structure
+
+As studios and vendors develop libraries of shared definitions and implementations of MaterialX materials and nodes for various targets, it becomes beneficial to have a consistent, logical organizational structure for the files on disk that make up these libraries. In this section, we propose a structure for files defining libraries of material nodes, <nodedef>s, nodegraph implementations and actual target-specific native source code, as well as a mechanism for applications and MaterialX content to find and reference files within these libraries.
+
+Legend for various components within folder hierarchies:
+
+| Term | Description |
+| --- | --- |
+| _libname_ | The name of the library; the MaterialX Standard nodes are the "stdlib" library. Libraries may choose to declare themselves to be in the libname namespace, although this is not required. |
+| _target_ | The target for an implementation, e.g. "glsl", "oslpattern", "osl" or "mdl". |
+| _sourcefiles_ | Source files (including includes and makefiles) for the target, in whatever format and structure the applicable build system requires. |
+
+
+Here is the suggested structure and naming for the various files making up a MaterialX material or node definition library setup. Italicized terms should be replaced with appropriate values, while boldface terms should appear verbatim. The optional "\_\*" component of the filename can be any useful descriptor of the file's contents, e.g. "\_ng" for nodegraphs or "\_mtls" for materials.
+
+
+ _libname_/_libname_**\_defs.mtlx** (1)
+ _libname_/_libname_\_\***.mtlx** (2)
+ _libname_/_target_/_libname_\_target[\_\*]**\_impl.mtlx** (3)
+ _libname_/_target_/_sourcefiles_ (4)
+
+
+
+1. Nodedefs and other definitions in library _libname_.
+2. Additional elements (e.g. nodegraph implementations for nodes, materials, etc.) in library _libname_.
+3. Implementation elements for _libname_ specific to target _target_.
+4. Source code files for _libname_ implementations specific to target _target_.
+
+Note that nodedef files and nodegraph-implementation files go at the top _libname_ level, while <implementation> element files go under the corresponding _libname_/_target_ level, next to their source code files. This is so that studios may easily install only the implementations that are relevant to them, and applications can easily locate the implementations of nodes for specific desired targets. Libraries are free to add additional arbitrarily-named folders for related content, such as an "images" subfolder for material library textures.
+
+The _libname_\_defs.mtlx file typically contains nodedefs for the library, but may also contain other node types such as implementation nodegraphs, materials, looks, and any other element types. The use of additional _libname_\_\*.mtlx files is optional, but those files should be Xincluded by the _libname_\_defs.mtlx file.
+
+A file referenced by a MaterialX document or tool (e.g. XInclude files, filenames in <image> or other MaterialX nodes, or command-line arguments in MaterialX tools) can be specified using either a relative or a fully-qualified absolute filesystem path. A relative path is interpreted to be relative to either the location of the referencing MaterialX document itself, or relative to a location found within the current MaterialX search path: this path may be specified via an application setting (e.g. the `--path` option in MaterialXView) or globally using the MATERIALX_SEARCH_PATH environment variable. These search paths are used for both XIncluded definitions and filename input values (e.g. images for nodes or source code for <implementation>s), and applications may choose to define different search paths for different contexts if desired, e.g. for document processing vs. rendering.
+
+The standard libraries `stdlib` and `pbrlib` are typically included _automatically_ by MaterialX applications, rather than through explicit XInclude directives within .mtlx files. Non-standard libraries are included into MaterialX documents by XIncluding the top-level _libname_/_libname_\_defs.mtlx file, which is expected to in turn XInclude any additional .mtlx files needed by the library.
+
+
+### Examples
+
+In the examples below, MXROOT is a placeholder for one of the root paths defined in the current MaterialX search path.
+
+A library of studio-custom material shading networks and example library materials:
+
+```
+ MXROOT/mtllib/mtllib_defs.mtlx (material nodedefs and nodegraphs)
+ MXROOT/mtllib/mtllib_mtls.mtlx (library of materials using mtllib_defs)
+ MXROOT/mtllib/images/*.tif (texture files used by mtllib_mtls nodes)
+```
+
+Documents may include the above library using
+
+```xml
+
+```
+
+and that file would XInclude `mtllib_mtls.mtlx`. <Image> nodes within `mtllib_mtls.mtlx` would use `file` input values such as "images/bronze_color.tif", e.g. relative to the path of the `mtllib_mtls.mtlx` file itself.
+
+Standard node definitions and reference OSL implementation:
+
+```
+ MXROOT/stdlib/stdlib_defs.mtlx (standard library node definitions)
+ MXROOT/stdlib/stdlib_ng.mtlx (supplemental library node nodegraphs)
+ MXROOT/stdlib/osl/stdlib_osl_impl.mtlx (stdlib OSL implementation elem file)
+ MXROOT/stdlib/osl/*.{h,osl} (etc) (stdlib OSL source files)
+```
+
+Layout for "genglsl" and "genosl" implementations of "stdlib" for MaterialX's shadergen component, referencing the above standard `stdlib_defs.mtlx` file:
+
+```
+ # Generated-GLSL implementations
+ MXROOT/stdlib/genglsl/stdlib_genglsl_impl.mtlx (stdlib genGLSL implementation file)
+ MXROOT/stdlib/genglsl/stdlib_genglsl_cm_impl.mtlx (stdlib genGLSL color-mgmt impl. file)
+ MXROOT/stdlib/genglsl/*.{inline,glsl} (stdlib common genGLSL code)
+
+ # Generated-OSL implementations
+ MXROOT/stdlib/genosl/stdlib_genosl_impl.mtlx (stdlib genOSL implementation file)
+ MXROOT/stdlib/genosl/stdlib_genosl_cm_impl.mtlx (stdlib genOSL color-mgmt impl. file)
+ MXROOT/stdlib/genosl/*.{inline,osl} (stdlib common genOSL code)
+```
+
+Layout for the shadergen PBR shader library ("pbrlib") with implementations for "genglsl" and "genosl" (generated GLSL and OSL, respectively) targets:
+
+```
+ MXROOT/pbrlib/pbrlib_defs.mtlx (PBR library definitions)
+ MXROOT/pbrlib/pbrlib_ng.mtlx (PBR library nodegraphs)
+ MXROOT/pbrlib/genglsl/pbrlib_genglsl_impl.mtlx (pbr impl file referencing genGLSL source)
+ MXROOT/pbrlib/genglsl/*.{inline,glsl} (pbr common genGLSL code)
+ MXROOT/pbrlib/genosl/pbrlib_genosl_impl.mtlx (pbr impl file referencing genOSL source)
+ MXROOT/pbrlib/genosl/*.{inline,osl} (pbr common genOSL code)
+```
+
+
+
+# Definitions, Assets, and Libraries
+
+In this section we propose a set of guidelines for managing unique definitions or assets and organization into libraries, wherein:
+
+* Definitions: Correspond directly to <nodedefs> which may or be either source code implementations or based on existing node definitions.
+* Assets: is a term which corresponds to a definition plus any additional metadata on a definition and /or related resources such as input images. These can be organized in logical groupings based on a desired semantic.
+* Libraries: are a collection of assets.
+
+
+### Organization Using Node Graphs
+
+While it is possible to just have a set of connected nodes in a document, it is not possible to have any formal unique interface. This can invariably lead to nodes which have duplicate names, the inability to control what interfaces are exposed and inability to maintain variations over time.
+
+Thus the base requirement for a definition is to encapsulate the nodes into a <nodegraph>. This provides for:
+
+1. Hiding Complexity: Where all nodes are scoped with the graph. For user interaction point, it makes possible the ability to “drill down” into a graph as needed but otherwise a black box representation can be provided.
+2. Identifier / Path Uniqueness : The nodegraph name decreases the chances of name clashes. For example two top level nodes both called “foo” would have unique paths “bar1/foo” and “bar2/foo” when placed into two nodegraphs “bar1” and “bar2”.
+3. Interface / node signature control where specific inputs may be exposed via “interfacename” connections and outputs as desired. This differs from “hiding” inputs or outputs which do not change the signature. The former enforces what is exposed to the user while the latter are just interface hints.
+
+For individual inputs it is recommended to add the following additional attributes as required:
+
+1. Real World Units : If an input value depends on scene / geometry size then a unit attribute should always be added. For example if the graph represents floor tile, then to place it properly the size of the tile. A preset set of “distance” units is provided as part of the standard library.
+2. Colorspace: If an input value is represented in a given color space then to support proper transformation into rendering color space this attribute should be set. A preset set of colorspace names conforming to the AcesCg 1.2 configuration is provided as part of the standard library.
+
+Though not strictly required it is very useful to have appropriate default values as without these the defaults will be zero values. Thus for example a “scale” attribute for a texture node should not be left to default to zero.
+
+
+### Publishing Definitions
+
+From a <nodegraph> a definition can be (new <nodedef>) created or “published”. Publishing allows for the following important capabilities:
+
+1. Reuse: The ability to reuse an unique node definition as opposed to duplicating graph implementations.
+2. Variation: The ability to create or apply variations to an instance independent from the implementation.
+3. Interoperability: Support definitions with common properties that are mutually understood by all consumers be exchanged.
+
+In order to support these capabilities It is recommended that the following attributes always be specified:
+
+1. A unique name identifier: This can follow the ND\_ and NG\_ convention described. It is recommended that the signature of the interface also be encoded to provide uniqueness, especially if the definition may be polymorphic.
+2. A namespace identifier (\*): When checking uniqueness namespace is always used so it is not required to be part of the name identifier to provide uniqueness.
+ * It should not be used as it will result in the namespace being prepended multiple times. E.g. a “foo” node with a namespace “myspace” has a unique identifier of “myspace:node”. If the node is named “myspace:node”, then the resulting identifier is “myspace:myspace:node”.
+ * Note that import of a Document will prepend namespaces as required without namespace duplication.
+3. A version identifier: While this can be a general string, it is recommended that this be a template with a specific format to allow for known increment numbering. E.g. The format may be “v#.#” to support minor and major versioning. This requires that only one out of all versions be tagged as the default version. Care should be taken to ensure this as the first one found will be used as the default.
+4. A nodegroup identifier: This can be one mechanism used for definition organization, or for user interface presentation. It is also used for shader generation to some extent as it provides hints as to the type of node. For example <image> nodes are in the “texture2d” node group.
+5. A documentation string. Though not strictly required this provides some ability to tell what a node does, and can be used as a user interface helper. Currently there is no formatting associated with this but it is possible to embed a format.
+
+Note that utilities which codify publishing logic are provided as part of the core distribution.
+
+To support variation it is proposed that both <token>s and <variant>s be used.
+
+
+
+1. Tokens: These allow for the sample “template” be used for filenames with having to create new definitions. This can reduce the number of required definitions but also reduce the number of presets required. For example tokens can be used to control the format, resolution of the desired filename identifier.
+2. Variants and Variant Sets: There are no hard-and-fast “rules” for when to create a definition vs use a definition with variants but one possible recommendation is to use variants when there are no interface signature differences (_Discuss_?). Some advantages include the fact that variants may be packaged and deployed independent of definitions and/or new definitions do not need to be deployed per variation. Note that for now only value overrides are possible.
+
+
+### Dependencies and Organization
+
+The more definitions are added including those based on other definitions, the harder it can be to discover what definitions are required given documents with some set of node instances.
+
+To support separability of dependents, the following logical high level semantic breakdown is proposed:
+
+
+
+1. Static “Core” library definitions. These include stdlib, pbrlib and bxdf. The recommendation is to always load these in and assume that they exist. For separability, it is recommended that these all be stored in a single runtime Document.
+2. Static custom library definitions. These are based on core libraries. The recommendation is to not directly reference any core libraries using the Xinclude mechanism. This can result in duplicate possibly conflicting definitions being loaded. The “upgrade” mechanism will ensure that all core and custom libraries are upgraded to the appropriate target version. For separability, it is recommended that these all be stored in a single runtime Document.
+3. Dynamically created definitions. If this capability is allowed then it can be useful to have a fixed set of locations that these definitions can update. This could be local to the user or to update an existing custom library.
+
+Additional groupings can be added to provide semantic organization (such as by “nodegroup”) though the recommendation is that they live within a common library root or package.
+
+For an asset with dependent resources there are many options. Two of which are:
+
+
+
+1. Co-locate resources with the definition. This allows for easier “packaging” of a single asset such as for transmission purposes but this can require additional discovery logic to find resources associated with a definition and may result in duplication of resources.
+2. Located in a parallel folder structure to definitions. The onus is to maintain this parallel structure but the search logic complexity is the same for resources as it is for definitions.
+
+If a definition is a source code implementation, then additional path search logic is required for discoverability during generation.
+
+The following search paths are available:
+
+
+
+* MATERIALX_SEARCH_PATH: This environment variable is used as part of both definition and resource search (e.g. relative filename path support).
+* Source code paths: This can be registered at time of code generation as part of the generation “context”. It is recommended to follow the source path locations which would be relative to any custom definitions, using the “language” identifier of the code generator to discover the appropriate source code files.
+
+An example usage of pathing can be found in the sample Viewer. The logic is as follows:
+
+
+
+* The module/binary path is set as the default “root” definition path. Additional definition roots are included via MATERIALX_SEARCH_PATH.
+* The set of roots are considered to be the parent of “resources” and “libraries” folders, for resource and definitions respectively.
+* The search path root for resources would be the “`/resources`” by default. This allows for handling of resources which are part of an assets definition. For example a brick shader located at “`/myroot/shaders/brick.mtlx`” may have the brick textures referenced at location “`/myroot/textures/brick.exr`”. Setting a single search path to “`/myroot`” handles the “parallel” folder organization mentioned, with the relative reference being “`textures/brick.exr`”
+* For any shader at a given path a path to that shader can be added when resolving dependent resources. This can be used to handle the co-located folder organization. For example the shader may reside in “`/myroot/shader/brick.mtlx`”, and the texture in “`/myroot/shader/textures/brick.exr`”. Setting a root to “`myroot/shader`” and a relative reference to “`textures/brick.exr`” will allow for proper discovery.
+
+For runtime, it is recommended that instead of reading in documents that they be “imported”. This allows for mechanisms such as namespace handling as well as tagging of source location (“sourceURI”) to occur per document. At some point all dependent documents need to be merged into a single one as there is no concept of referenced in-memory documents. Tagging is a useful mechanism to allow filtering out / exclusion of definitions from the main document content. For example, the main document can be “cleared” out while retaining the library definitions.
+
+As there may be definitions dependent on other definitions, it is never recommended to unload core libraries, and care be taken when unloading custom or dynamic libraries. It may be useful to re-load all definitions if there is a desire to unload any one library.
+
+Note that code generation is context based. If the context is not cleared, then dependent source code implementations will be retained. It is recommended to clear implementations if definitions are unloaded.
+
+
+### Deployment, Transmission, and Translation
+
+Given a set of definitions it is useful to consider how it will be deployed.
+
+Some deployments for which file access may be restricted or accessing many files is a performance issue, pre-package up definitions, source and associated resources may be required. For example, this is currently used for the sample Web viewer deployment.
+
+Some deployments may not want to handle non-core definitions or may not be able to handle (complex) node graphs. Additionally the definition may be transmitted as a shader. Thus, when creating a new definition it is recommended to determine the level of support for:
+
+
+
+1. Flattening: Can the definition be converted to a series of nodes which have source code implementations.
+2. Baking: Can the definition be converted to an image.
+3. Translation: Can the implementation be converted mapped / converted to another implementation which can be consumed.
+4. Shader Reflection: Can the desired metadata be passed to the shader for introspection.
+
+Additional metadata which is not a formal part of the specification may lead to the inability to be understood by consumers.
+
diff --git a/MaterialX/documents/Specification/README.md b/MaterialX/documents/Specification/README.md
old mode 100644
new mode 100755
index 29f2766..9fc72c0
--- a/MaterialX/documents/Specification/README.md
+++ b/MaterialX/documents/Specification/README.md
@@ -1,115 +1,119 @@
-
-
-**MaterialX** is an open standard for representing rich material and look-development content in computer graphics, enabling its platform-independent description and exchange across applications and renderers. MaterialX addresses the need for a common, open standard to represent the data values and relationships required to describe the look of a computer graphics model, including shading networks, patterns and texturing, complex nested materials and geometric assignments. To further encourage interchangeable CG look setups, MaterialX also defines a large set of standard shading and processing nodes with a precise mechanism for functional extensibility.
-
-The documents in this folder comprise the complete MaterialX Specification, version 1.39.
-
-* [**MaterialX Specification**](./MaterialX.Specification.md) - the main Specification, describing definitions and core functionality
-* [**MaterialX Standard Nodes**](./MaterialX.StandardNodes.md) - describes the standard node library
-* [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md) - describes BSDF and other shading function nodes useful in constructing complex layered rendering shaders using node graphs
-* [**MaterialX NPR Shading Nodes**](./MaterialX.NPRSpec.md) - specifies shading nodes that are designed for use in non-photorealistic and stylized rendering
-* [**MaterialX Geometry Extensions**](./MaterialX.GeomExts.md) - additional MaterialX elements to define geometry-related information such as collections, properties and material assignments
-* [**MaterialX Supplemental Notes**](./MaterialX.Supplement.md) - describes recommended naming and structuring conventions for libraries of custom node definitions
-* [**MaterialX: Proposed Additions and Changes**](./MaterialX.Proposals.md) - describes proposed future updates to various components of the Specification
-
-
-
----
-
-
-**MaterialX v1.39** provides the following enhancements over v1.38:
-
-
-**MaterialX Geometry Extensions**
-
-The parts of the main MaterialX Specification document dealing with various Geometry-related features has now been split into a separate [**MaterialX Geometry Extensions**](./MaterialX.GeomExts.md) document, describing Collections, Geometry Name Expressions, geometry-related data types, Geometry Info elements and the GeomProp and Token elements used within them, and Look, Property, Visibility and assignment elements.
-
-With this split, applications can claim to be MaterialX Compatible if they support all the things described in the main Specification, e.g. the elements for nodegraph shading networks and materials as well as the standard set of nodes, while using an application's native mechanisms or something like USD to describe the assignment of these materials to geometry. Applications may additionally support the MaterialX Geometry Extensions and thus use a single unified representation for complete CG object looks.
-
-
-**Array Types Now Uniform and Static Length**
-
-Many shading languages do not support dynamic array types with a variable length, so MaterialX now only supports arrays with a fixed maximum length, and all array-type node inputs must be uniform; nodes are no longer permitted to output an array type. Array-type inputs may be accompanied by a uniform integer input declaring the number of array elements actually used in the array (the <curveadjust> node has been updated in this way). Because of this change, the unimplemented <arrayappend> node has been removed.
-
-
-**Connectable Uniform Inputs and New Tokenvalue Node**
-
-A uniform node input is now explicitly allowed to be connected to the output of a <constant> node. This makes it possible to define a uniform value and use it in multiple places in a nodegraph.
-
-Similarly, <token>s in materials and other node instances may now be connected to the output of a new <tokenvalue> node: this is essentially a <constant> node but which connects to <token>s rather than <input>s.
-
-
-**Standardized Color Space Names**
-
-The [standard colorspace names](./MaterialX.Specification.md#color-spaces-and-color-management-systems) in MaterialX have now been defined explicitly in the Specification, and are aligned to their definitions in the ACES 1.2 OCIO config file. With this change, there is no need for a definition of "cms" or "cmsconfig" in MaterialX documents, so those two attributes have been deprecated. Additionally, two new colorspaces, "srgb_displayp3" and "lin_displayp3" have been added as standard colorspaces.
-
-
-**Disambiguated Nodedef and Nodegraph References**
-
-Normally, the set of provided inputs to a node and their types in conjunction with the output type of the node itself is sufficient to disambiguate exactly which nodedef signature should be applied. In the rare situations where this is not sufficient, it is now permissible for any node instantiation to specify the name of a nodedef to completely disambiguate the intended node signature.
-
-Additionally, a <nodegraph> could previously declare itself to be an implementation of a particular <nodedef> by providing a "nodedef" attribute, which is still the preferred method for making this association. Now, it is also permissible for an [<implementation> element](39/MaterialX.Specification.md#custom-node-definition-using-implementation-elements) to provide a "nodegraph" attribute to declare that nodegraph to be the implementation for the nodedef specified in the <implementation>. This allows a single nodegraph to be the implementation of multiple nodedefs, e.g. two different node names with the same underlying implementation, or if the only difference between two versions of a nodedef is the default values.
-
-
-**Generalized Swizzle Operator Removed**
-
-The standard <swizzle> node using a string of channel names and allowing arbitrary channel reordering is very inefficient (and in some shading languages virtually impossible) to implement as previously specified, and as such has been removed. Nodegraphs should instead use combinations of <extract> (which is now a standard node), <separateN> and <combineN> nodes to perform arbitrary channel reordering. Additionally, the previous "channels" attribute for inputs which allowed arbitrary channel reordering and used string "swizzle" channel naming has been removed.
-
-
-**New Unlit Surface Shader and Standard Materials**
-
-A new <surface_unlit> node for unlit surfaces has been added to the standard library.
-
-Additionally, the standard <surfacematerial> material now supports both single- or double-sided surfaces with the addition of a separate `backsurface` input.
-
-
-**Inheritance and Hints for Typedefs**
-
-Typedefs may now inherit from other types, including built-in types, and may provide hints about their values such as floating-point precision. These new "inherit" and "hint" attributes are themselves merely metadata hints about the types; applications and code generators are still expected to provide their own precise definitions for all custom types.
-
-
-**New and Updated Standard Library Nodes**
-
-In 1.39, we are removing the distinction between "standard nodes" and "supplemental nodes", and descriptions of both can now be found in the main Specification document. Nodes that are implemented in the standard distribution using nodegraphs are annotated with "(NG)" in the Spec to differentiate them from nodes implemented in each rendering target's native shading language.
-
-Additionally, the following new operator nodes have been added to the standard library:
-
-* [Procedural nodes](./MaterialX.Specification.md#procedural-nodes): **tokenvalue**, **checkerboard**, **fractal2d**, **cellnoise1d**, **unifiednoise2d**, **unifiednoise3d**
-* [Geometric nodes](./MaterialX.Specification.md#geometric-nodes): **bump**, **geompropvalueuniform**
-* [Math nodes](./MaterialX.Specification.md#math-nodes): boolean **and**, **or**, **not**; **distance**, **transformcolor**, **creatematrix** and **triplanarblend**, as well as integer-output variants of **floor** and **ceil**
-* [Adjustment nodes](./MaterialX.Specification.md#adjustment-nodes): **curveinversecubic**, **curveuniformlinear**, **curveuniformcubic** and **colorcorrect**
-* [Conditional nodes](./MaterialX.Specification.md#conditional-nodes): boolean-output variants of **ifgreater**, **ifgreatereq** and **ifequal**; new **ifelse** node
-* [Channel nodes](./MaterialX.Specification.md#channel-nodes): **extractrowvector** and **separatecolor4**
-
-
-**New Physically Based Shading Nodes**
-
-The following new standard physically based shading nodes have been added:
-
-* [EDF nodes](./MaterialX.PBRSpec.md#edf-nodes): **generalized_schlick_edf**
-* [Shader nodes](./MaterialX.PBRSpec.md#shader-nodes): **environment** (latlong environment light source)
-
-
-**Other Changes**
-
-* The "valuerange" and "valuecurve" attributes describing expressions and function curves have been removed, in favor of using the new <curveinversecubic> / <curveuniformcubic> / etc. nodes.
-* The <geomcolor>, <geompropvalue> and <geompropvalueuniform> nodes for color3/4-type values can now take a "colorspace" attribute to declare the colorspace of the property value.
-* The <cellnoise2d> and <cellnoise3d> nodes now support vectorN output types in addition to float output.
-* The <noise2d/3d>, <fractal2d/3d>, <cellnoise2d/3d> and <worleynoise2d/3d> nodes now support a "period" input.
-* The <worleynoise2d> and <worleynoise3d> nodes now support a number of different distance metrics.
-* The <time> node no longer has a "frames per second" input: the application is now always expected to generate the "current time in seconds" using an appropriate method. The "fps" input was removed because variable-rate real-time applications have no static "fps", and it's generally not good to bake a situation-dependent value like fps into a shading network.
-* A standard "tangent" space is now defined in addition to "model", "object" and "world" spaces, and the <heighttonormal> node now accepts a uniform "space" input to define the space of the output normal vector.
-* The <switch> node now supports 10 inputs instead of just 5.
-* The <surface> and <displacement> nodes are now part of the main Specification rather than being Physically Based Shading nodes.
-* <Token> elements are now explicitly allowed to be children of compound nodegraphs, and token values may now have defined enum/enumvalues.
-* Inputs in <nodedef>s may now supply "hints" to code generators as to their intended interpretation, e.g. "transparency" or "opacity".
-* <Attributedef> elements may now define enum/enumvalues to list acceptable values or labels/mapped values for an attribute.
-* If a string input specifies an "enum" list, the list is now considered a "strict" list of allowable values; no values are allowed outside that list. To make the input non-strict, one must omit the "enum" attribute from the input.
-
-
-Suggestions for v1.39:
-
-* Add a boolean “bound” output to the various geometry property nodes, so materials can be flexible if a given attribute doesn’t exist. Especially ones like <texcoord> that don’t let users specify names.
-
+
+
+**MaterialX** is an open standard for representing rich material and look-development content in computer graphics, enabling its platform-independent description and exchange across applications and renderers. MaterialX addresses the need for a common, open standard to represent the data values and relationships required to describe the look of a computer graphics model, including shading networks, patterns and texturing, complex nested materials and geometric assignments. To further encourage interchangeable CG look setups, MaterialX also defines a large set of standard shading and processing nodes with a precise mechanism for functional extensibility.
+
+The documents in this folder comprise the complete MaterialX Specification, version 1.39.
+
+* [**MaterialX Specification**](./MaterialX.Specification.md) - the main Specification, describing definitions, core functionality and the standard node library
+* [**MaterialX Physically Based Shading Nodes**](./MaterialX.PBRSpec.md) - describes BSDF and other shading function nodes useful in constructing complex layered rendering shaders using node graphs
+* [**MaterialX NPR Shading Nodes**](./MaterialX.NPRSpec.md) - specifies shading nodes that are designed for use in non-photorealistic and stylized rendering
+* [**MaterialX Geometry Extensions**](./MaterialX.GeomExts.md) - additional MaterialX elements to define geometry-related information such as collections, properties and material assignments
+* [**MaterialX Supplemental Notes**](./MaterialX.Supplement.md) - describes recommended naming and structuring conventions for libraries of custom node definitions
+* [**MaterialX: Proposed Additions and Changes**](./MaterialX.Proposals.md) - describes proposed future updates to various components of the Specification
+
+
')
- inputList = nd.getActiveInputs() if opts.showInherited else nd.getInputs()
- tokenList = nd.getActiveTokens() if opts.showInherited else nd.getTokens()
- outputList = nd.getActiveOutputs() if opts.showInherited else nd.getOutputs()
- totalList = inputList + tokenList + outputList;
- for port in totalList:
- print('
')
- infos = []
- if port in outputList:
- infos.append(''+ port.getName() + '')
- elif port in tokenList:
- infos.append(port.getName())
- else:
- infos.append(''+ port.getName() + '')
- infos.append(port.getType())
- val = port.getValue()
- if port.getType() == "float":
- val = round(val, 6)
- infos.append(str(val))
- for attrname in ATTR_NAMES:
- infos.append(port.getAttribute(attrname))
- for info in infos:
- print('
' + info + '
')
- print('
')
- print('
')
-
- # Markdown output
- else:
- print('- *Nodedef*: %s' % nd.getName())
- print('- *Type*: %s' % nd.getType())
- if len(nd.getNodeGroup()) > 0:
- print('- *Node Group*: %s' % nd.getNodeGroup())
- if len(nd.getVersionString()) > 0:
- print('- *Version*: %s. Is default: %s' % (nd.getVersionString(), nd.getDefaultVersion()))
- if len(nd.getInheritString()) > 0:
- print('- *Inherits From*: %s' % nd.getInheritString())
- print('- *Doc*: %s\n' % nd.getAttribute('doc'))
- print('| ' + ' | '.join(HEADERS) + ' |')
- print('|' + ' ---- |' * len(HEADERS) + '')
- inputList = nd.getActiveInputs() if opts.showInherited else nd.getInputs()
- tokenList = nd.getActiveTokens() if opts.showInherited else nd.getTokens()
- outputList = nd.getActiveOutputs() if opts.showInherited else nd.getOutputs()
- totalList = inputList + tokenList + outputList;
- for port in totalList:
- infos = []
- if port in outputList:
- infos.append('*'+ port.getName() + '*')
- elif port in tokenList:
- infos.append(port.getName())
- else:
- infos.append('**'+ port.getName() + '**')
- infos.append(port.getType())
- val = port.getValue()
- if port.getType() == "float":
- val = round(val, 6)
- infos.append(str(val))
- for attrname in ATTR_NAMES:
- infos.append(port.getAttribute(attrname))
- print('| ' + " | ".join(infos) + ' |')
-
-if __name__ == '__main__':
- main()
+#!/usr/bin/env python
+'''
+Print markdown documentation for each nodedef in the given document.
+'''
+
+import argparse
+import sys
+
+import MaterialX as mx
+
+HEADERS = ('Name', 'Type', 'Default Value',
+ 'UI name', 'UI min', 'UI max', 'UI Soft Min', 'UI Soft Max', 'UI step', 'UI group', 'UI Advanced', 'Doc', 'Uniform')
+
+ATTR_NAMES = ('uiname', 'uimin', 'uimax', 'uisoftmin', 'uisoftmax', 'uistep', 'uifolder', 'uiadvanced', 'doc', 'uniform' )
+
+def main():
+ parser = argparse.ArgumentParser(description="Print documentation for each nodedef in the given document.")
+ parser.add_argument(dest="inputFilename", help="Filename of the input MaterialX document.")
+ parser.add_argument('--docType', dest='documentType', default='md', help='Document type. Default is "md" (Markdown). Specify "html" for HTML output')
+ parser.add_argument('--showInherited', default=False, action='store_true', help='Show inherited inputs. Default is False')
+ opts = parser.parse_args()
+
+ doc = mx.createDocument()
+ try:
+ mx.readFromXmlFile(doc, opts.inputFilename)
+ except mx.ExceptionFileMissing as err:
+ print(err)
+ sys.exit(0)
+
+ for nd in doc.getNodeDefs():
+ # HTML output
+ if opts.documentType == "html":
+ print('')
+ print('
')
+ inputList = nd.getActiveInputs() if opts.showInherited else nd.getInputs()
+ tokenList = nd.getActiveTokens() if opts.showInherited else nd.getTokens()
+ outputList = nd.getActiveOutputs() if opts.showInherited else nd.getOutputs()
+ totalList = inputList + tokenList + outputList;
+ for port in totalList:
+ print('
')
+ infos = []
+ if port in outputList:
+ infos.append(''+ port.getName() + '')
+ elif port in tokenList:
+ infos.append(port.getName())
+ else:
+ infos.append(''+ port.getName() + '')
+ infos.append(port.getType())
+ val = port.getValue()
+ if port.getType() == "float":
+ val = round(val, 6)
+ infos.append(str(val))
+ for attrname in ATTR_NAMES:
+ infos.append(port.getAttribute(attrname))
+ for info in infos:
+ print('