diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/README.md b/extensions/2.0/Khronos/KHR_texture_procedurals/README.md index 64d5fcd1fb..fe1a57029f 100644 --- a/extensions/2.0/Khronos/KHR_texture_procedurals/README.md +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/README.md @@ -2,14 +2,20 @@ ## Contributors -To fill in... +- Ashwin Bhat, Autodesk, ashwin.bhat@autodesk.com +- Alexey Knyazev, Individual Contributor, [@lexaknyazev](https://github.com/lexaknyazev) +- Bernard Kwok, Individual Contributor, [@kwokcb](https://github.com/kwokcb) +- Ed Mackey, AGI, [@emackey](https://twitter.com/emackey) +- Lutz Kettner, NVIDIA, lkettner@nvidia.com +- Richard Sahlin, IKEA [@rsahlin](https://github.com/rsahlin) +- Timothy Blut, NVIDIA, tblut@nvidia.com Copyright 2024 The Khronos Group Inc. See [Appendix](#appendix-full-khronos-copyright-statement) for full Khronos Copyright Statement. ## Status -To fill in... +Draft ## Dependencies @@ -18,20 +24,514 @@ Written against the glTF 2.0 spec. ## Overview This extension provides a standardized way to represent -procedural graphs which can be mapped to materials in glTF. +procedural graphs which can be mapped to material channels in glTF. ### Motivation -To fill in... -## Schema +Textures represented as procedural graphs provides a way to extend the capabilities of glTF materials beyond what is possible with traditional texture maps. Key objectives includes: + +1. **Interoperability**: Adhere to an industry a standard node schema (MaterialX) with a runtime friendly JSON representation. + + More specifically __only__ nodes defined in the MaterialX specification are supported. This ensures that the procedural graphs can be easily converted to MaterialX and USDShade graphs. + + For the first version of this extension nodes which are used to define shading models are not allowed. Please refer to the [resources](#resources) section for links to supported MaterialX node definitions. + +2. **Fidelity**: Provide the ability to generate complex patterns, noise, or other effects that are currently must be "baked" into texture maps. Reduce in runtime memory usage by generating textures programmatically. + +3. **Editability and Extensibility**: Extend runtime editability by exposing logic and interfaces for procedural graphs as well as providing a means to create new or extend existing node definitions. + +4. **Validity**: Ensure that procedurals graphs can be validated both against a schema as well as against reference rendering implementations. + +| Original | Baked | +| :---: | :---: | +| | | + +Example of fully procedural vs baked marble texture + +### Definitions + +The following is a set of definitions using MaterialX nomenclature to provide context for the procedural graph representation. + +* A **Node** is a function that generates or operates upon spatially-varying data. The MaterialX specification provides the set of standard nodes with precise definitions and also supports the creation of custom nodes. + +* **Node Input and Output Ports** The interface for a node’s incoming data is declared through **input ports**, which may be spatially-varying or uniform. The interface for a node’s outgoing data is declared through **output ports**. + +* There is a specific set of supported **Data Types**. Every port must have a data type. + +* 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 to a given material. + +* A **Node Graph** is a directed acyclic graph (DAG) of nodes, which may be used to define arbitrarily complex generation or processing networks. Node Graphs describe a network of "pattern" nodes flowing into shader inputs, or to define a complex or layered node in terms of simpler nodes. The former is called a **compound nodegraph** and the latter a **functional nodegraph**. + +* A Node Graphs's: + * **Inputs** are nodes that define the interface for a node graph’s incoming data. + * **Outputs** are nodes that define the interface for a node graph’s outgoing data. + +* A **Node Definition** is a specification for a unique function with a given set of input and output ports. The logic for each functions is represented either as a `functional graph` or as shader code. + +## Extension Declaration + +To use the extension the `KHR_texture_procedurals` extension identifier must be added to the `extensionsUsed` array in the asset object. + +```json +{ + "extensionsUsed": [ + "KHR_texture_procedurals" + ] +} +``` +with the extension object defined as follows: + +```json +{ + "extensions": { + "KHR_texture_procedurals": { + "mimetype": "application/mtlx+json;version=", + "procedurals": [] + } + } +} +``` +It is assumed that a mimetype is always required. As part of the mimetype a version `` is specified. This is the version of the MaterialX library specification used when writing to glTF. The version is specified as a string in the form of `.`. For example, if the MaterialX library version is 1.39, the mimetype would be `application/mtlx+json;version=1.39`. + +This corresponds to the following XML element in MaterialX: + +```xml + + +``` + +The version in the mimetype __is not__ the extension version. If in the future the schema needs to be modified (perhaps due to changes in MaterialX) then a new extension version would be required. + +The `procedurals` array specifies the procedural graphs that are used in the glTF asset. + +## Representation + +For all applicable JSON objects, any / all supported MaterialX meta-data information may be specified. This includes information such as UI hints, node placement, and documentation, colorspace, and real world units to support interoperability or editability. + +Information which is used for resolving input data identifiers is not supported. For example specification of a `fileprefix` at the graph level is not supported. + +Tooling is expected to pre-resolve all resource identifiers for images and streams appropriately. + +### Data Types + +The supported data types are: + +* single `float` +* single `integer` +* tuples: + * `color3`, `color4` : 3 and 4 channel color + * `vector2`, `vector3`, `vector4` : 2, 3, 4 channel float vector + * `integer2`, `integer3`, `integer4` : 2, 3, 4 channel integer vector +* matrix: + * `matrix3x3`, and `matrix4x4` : Matrices of floats of size 3 or 4. + +Tuples and matrices are represented as arrays of values. For example, a `color3` is represented as an array of 3 floats. + +### Procedural Graphs + +One ore more procedurals graphs can be defined in the `procedurals` array. + +A graph __cannot__ be nested (contain another graph), as is allowed for *OpenUSD* for instance. Any such configurations must be “flattened” to single level graphs. ( As MaterialX does not support nested graphs OpenUSD utilities perform flattening upon conversion to MaterialX. ) + +Each procedural graph object is composed of: + + * An optional string `name` identifier + * A `nodetype` which must be `nodegraph` + * A `type` which is the output type of the graph. This is a supported data type, or `multioutput` if there is more than one output node for the graph. + * A set of children nodes: + * `inputs` input "interface" nodes for passing data into the graph. + * `outputs` output "interface" nodes for passing data out of the graph. See [Node Graph Connections](#node-graph-connections) for connection information. + * `nodes` processing nodes. + +The structure of atomic nodes is described in ["Procedural" Nodes](#procedural-nodes) section. + +Note that input and output node types are `input` and `output` respectively. + +#### Procedural Graph Object + +```JSON +{ + name": "my_procedural", + "nodetype": "nodegraph", + "type": "", + "inputs": [...list of input nodes...], + "outputs": [...list of output nodes...], + "nodes": [...List of processing nodes...], +} +``` + +### "Procedural" Nodes + +* An atomic function is represented as a single node with the following properties: + + * An optional string `name` identifier + + * A `nodetype` which is a string identifier for the node type. This is a MaterialX node type or a custom node type. + + * A `type` which is the output type of the node. This is a supported data type or `multioutput` if there is more than one output port on a node. + + * A list of input ports under an `inputs` array. + If an input is specified it's input value overrides that of the node definition default. + * A list of output ports under an `outputs` array. Every output port defined for the corresponding node definition must be specified. + + - Each input port: + * Must have a node type: `input` for input ports and `output` for output ports. + * May have an optional string name identifier + * Must have a type which is a supported data type. + * Either: + * A `value` which is a constant value for the node. or + * A connection. See [Node Graph Connections](#node-graph-connections) for more information. + * An `input` which is a reference to another node in the graph. This is only valid for `output` nodes. + * All `output` ports specified on a node’s corresponding definition must be specified for each node instance. Each output port: + * Must have a node type: `output` + * Must have a type which is a supported data type. + + +#### Procedural Graph Node + +```JSON +{ + "name": "", + "nodetype": "", + "type": "", + "inputs": [...optional list of input ports...], + "outputs": [...required list of output ports...] +} +``` +Where an input port has the following structure: +```JSON +{ + "name": "", + "nodetype": "input", + "type": "", + "value": or + "node": or + "input": + "output": +} +``` +and an output port has the following structure: + +```JSON +{ + "name": "", + "nodetype": "output", + "type": "", +} +``` + +### Node Graph Connections + +Connections inside a graph can be made between: + +* Between to a `node input` from a an `nodegraph input` by specifying a `input` index +* Between to a `node input` from a node `output` by specifying a `node` index. +* Between to a nodegraph output` from a node `output` and an ` by specifying a `node` index + +If the upstream node has multiple outputs, then the an `output` index __must__ additionally be specified. + +### Material Binding + +To connect a graph output to a surface or displacement shader input the procedural extension can be declared within the a texture reference for a given material in the `materials` array. + +For the first version of this extension only those material inputs which already support texture binding can support procedural graphs. This includes bindings such as: + +- `baseColorTexture` +- `metallicRoughnessTexture` +- `occlusionTexture` +- `emissiveTexture` +- `diffuseTexture` + +In this example the extension is specified on the "baseColorTexture" entry. The `index` value is a reference into the `procedurals` array. If the procedural graph has multiple outputs than an `output` index must be specified to indicate which output in the graphs `outputs` array to use. + +```JSON +"materials": [ + { + "pbrMetallicRoughness": { + "baseColorTexture": { + "index": 0, + "extensions": { + "KHR_texture_procedurals": { + "index": <"procedurals" array index> + "output": + } + } + } + } + } +``` + +__Notes__ + +If a texture binding packs values into a single output then a procedural graph must also pack the values into a single output. For example, a `metallicRoughnessTexture` is a multi-channel texture where the red channel is metallic and the green channel is roughness. If a procedural graph is used to generate this texture then the graph must output a multi-channel color. + +At the current time each texture reference requires an `index` entry to be specified. This can be used to reference the "fallback" texture to use instead of the procedural graph. This could be the “baked” version of the graph, or simply reference an embedded 1 pixel “dummy” image that resides inside the glTF document. + +```JSON +{ + "images": [ + { + "url": "data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAIAAACQd1PeAAAADElEQVQI12P4z/AfAAQAAf/zKSWvAAAAAElFTkSuQmCC" + } + ], + "textures": [ + { + "source": 0 + } + ] +} +``` +Example embedded "dummy" image + +### Resource Binding + +A procedural graph's `input`s nodes can either be bound to + +* A uniform value. +* A texture +* A geometric stream: An input reference to a stream is specified using a meshes `primitive` index number. + +#### Uniform Binding + +Either constant or animated values may be bound. + +It is assumed that the existing animation declarations can be used to reference the procedural input. (To validate: if a sampler `target` can be used to reference a procedural graph input) + +#### Texture Binding + +An `input` reference to an image is represented by an index to a `texture` element within the `textures` array object. If mapping from a MaterialX `filename`, then this `filename` string is used as the corresponding `image` source. + +Placement is specified by the procedural graph and __supersedes__ any placement information on the texture reference. That is, texture transforms are procedural in nature are not "baked" into a single texture coordinate matrix transform. + +( For interop from glTF to MaterialX any embedded images must be extracted and stored in a separate file. The `uri` field in the MaterialX `image` object is used to store the path to the extracted image. ) + +#### Input Stream Binding + +Streams must be explicitly specified by a procedural node as such as a `texcoord` node for texture coordinates. +There are two variants of such nodes: + 1. Ones which specify the stream by index + 2. Ones which specify the stream by string identifier. + +Only the first is supported. + +The index is a zero-based index used to lookup the corresponding stream type in a bound mesh's `primitives` array. + +For the texture coordinate example if the stream id is 1, then implementations must check for a stream with a label of `TEXCOORD_1` in a given meshes primitives. The mesh to search would be the one assigned to the material using the procedural graph. + +As another example a `geomcolor` node would be used to specify a color stream. A value of 1 means that an implicit binding to color stream `COLOR_1` is desired. + +## Procedural Definitions + +Procedural definitions specify the interfaces (inputs and outputs) and its associated node graph implementation. This allows for custom definitions to be specified within a glTF document. + +The structure for declaring definitions matches that used in MaterialX. This allows for these definitions to be convertible back into MaterialX and hence be consumable by OpenUSD (added to it's SDR - shading node registry). Iit is thus possible to create custom definitions within glTF which are inherently supported by OpenUSD integrations which support MaterialX definitions. + +### Structure + +All declarations and functional graphs are specified in a separate `procedural_definitions` array within the KHR_texture_procedurals extension parent. + +These elements **cannot be connected to nor modified**. + +The properties for a definition include: + +* `nodetype`: Must be `nodedef` +* `node`: The name of the node type. Can be used wherever `nodetype` is specified for a node instance. +* `version`: An optional version string. If not specified then it is assumed to be the default version. +* `default`: A boolean flag to indicate if this is the default version of the definition. If not specified then it is assumed to be false. +* `nodegraph` The semantic grouping for this node. The final name for this will correspond with the matching release of MaterialX. The assumption is this will be `procedural` for the first version. +* `doc` An optional string for documentation purposes. + +* Child arrays of `inputs` and `outputs`. This is specified in the same manner as for a procedural graph. + +Each input __must__ have a `value` specified. This is the default value for the input when not specified for an instance of the node (*) + +For each input it is useful to provide the following the following information as applicable: + * `name` : A user friendly name for the input. + * `unit` : The real-world unit of the input. This is used for interop with MaterialX and OpenUSD. + * `colorspace` : The color space of the input. This is used for interop with MaterialX and OpenUSD. + * `doc` : An optional string for documentation purposes. + * `uimin`, `uimax`, `uistep`, `uifolder`: UI hints for the input. This is used to support editability for node editors. + +Example: +```JSON +"procedural_definitions": [ + { + // Definition + "name": , + "nodetype": "nodedef", + "node": , + "nodegroup": "procedural", // optional but recommended to be interpreted as a "procedural" + "inputs": [], + "outpputs": [...] + } +} +``` + +(*) Note that default geometric streams can be specified for some input types using the `defaultgeomprop` meta-data specifier. This would need to be converted to a numbered stream (_TBD how to map this_ ) + + +For a functional nodegraph + +* `nodetype`: Must be `nodegraph` +* `nodedef` : Index into the `procedural_definitions` array to indicate the correspondence definition entry. +* A child array of `outputs`. The outputs must match those of the definition. +* It is considered invalid to specify a list of inputs. + +```JSON +// Functional node graph +{ + "name": "", + "nodedef": , + "outputs": [...], + "nodes": [...] +} +``` + +Below is the actual interface for the “checkboard” definition as specified within MaterialX. The graph nodes have been omitted for clarity. + +
+glTF definition + +```JSON +{ + "procedural_definitions": [ + { + // Definition + "name": "ND_checkerboard_color3", + "nodetype": "nodedef", // required + "node": "checkerboard", // required - "nodetype" for instances of this definition + "nodegroup": "procedural", // optional but recommended to be interpreted as a "procedural" + "inputs": [ + { + "name": "color1", + "doc": "The first color used in the checkerboard pattern.", + "type": "color3", + "value": [ + 1.0, + 1.0, + 1.0 + ] + }, + { + "name": "color2", + "doc": "The second color used in the checkerboard pattern.", + "type": "color3", + "value": [ + 0.0, + 0.0, + 0.0 + ] + }, + { + "name": "uvtiling", + "doc": "The tiling of the checkerboard pattern along each axis, with higher values producing smaller squares. Default is (8, 8).", + "type": "vector2", + "value": [ + 8, + 8 + ] + }, + { + "name": "uvoffset", + "doc": "The offset of the checkerboard pattern along each axis. Default is (0, 0).", + "type": "vector2", + "value": [ + 0, + 0 + ] + }, + { + "name": "texcoord", + "doc": "The input 2d space. Default is the first texture coordinates.", + "type": "vector2", + "defaultgeomprop": "UV0" + } + ], + "outputs": [ + { + "name": "out", + "type": "color3" + } + ] + }, + // Functional node graph + { + "name": "NG_checkerboard_color3", + "nodetype": "nodegraph", // required + "type": "color3", // required + "nodedef": 0, // required definition reference + "outputs": [ + { + "name": "out", + "type": "color3" + } + ], + "nodes": [ + // Nodes omitted... + ] + } + } +``` + +
+ +

+The corresponding definition and functional graph in MaterialX looks like this. +

+MaterialX definition + +```xml + + + + + + + + + + + + + + + + +``` +
+ +## Structure Review + +The following diagrams show the overall structure of the extension. + +This diagram shows the bindings between materials and compound graphs as well as structure and connections for a graph. + + +This diagram shows the breakdown of a procedural graph definition and its associated node functional graph implementation. + + + +## JSON Schema [material.KHR_texture_procedurals.schema.json](schema/material.KHR_texture_procedurals_schema.json) -### Example JSON +### "Checkerboard" Example This example shows a "checkerboard" pattern which is defined as a procedural graph. This graph is mapped to the "base color" on a material. + + +
+glTF Graph + ```JSON { "materials": [ @@ -307,7 +807,14 @@ This example shows a "checkerboard" pattern which is defined as a procedural gra } ``` +
+

+ The equivalent MaterialX representation is: + +

+MaterialX Graph + ```XML @@ -353,51 +860,151 @@ The equivalent MaterialX representation is: ``` +
+ +#### Checkerboard Variants + +In the example below we create variants by declaring “checkerboard” node instances within a graph. We modify the inputs on each node to create a “red” and “green” variants. + +
+Variants + +```JSON +{ + "procedurals": [ + // Checkerboard variants graph + { + "name": "checkboard_variants", + "nodetype": "nodegraph", + "nodes": [ + { + "name": "checkerboard_green", + "nodetype": "checkerboard", // Instance of a checkerboard + "type": "color3", + // Override one input's value so that it is "green" + "inputs": [ + { + "name": "color1", + "type": "color3", + "value": [ + 0, + 1, + 0 + ] + } + ], + "outputs": [ + { + "name": "out", + "type": "color3" + } + ] + }, + { + "name" : "checkboard_red", + "nodetype": "checkerboard", + "type": "color3", + "inputs": [ + { + "name": "color1", + "type": "color3", + "value": [ + 1, + 0, + 0 + ] + } + ], + "outputs": [ + { + "name": "out", + "type": "color3" + } + ] + } + ], + // Route the outputs of the checkerboard nodes + "outputs": [ + { + "name": "green_out", + "type": "color3", + "node": 0 + }, + { + "name": "red_out", + "type": "color3", + "node": 1 + } + ] + } + ] +} +``` + +
+ +These procedural graphs can be bound to downstream materials as desired by chosing the appropriate output node. + +
+Variant Binding + +```JSON +{ + // Material references + "materials": [ + { + "name": "green_checker", + "pbrMetallicRoughness": { + "baseColorTexture": { + "index": 0, + "extensions": { + "KHR_texture_procedurals": { + "index": 0, // graph with variants + "output": 0 // "green checker" variant + } + } + } + }, + "name": "red_checker", + "pbrMetallicRoughness": { + "baseColorTexture": { + "index": 0, + "extensions": { + "KHR_texture_procedurals": { + "index": 0, // graph with variants + "output": 1 // "red checker" variant + } + } + } + } + } + ] +} +``` + +
+ +## Resources + +- [MaterialX Specification Documents](https://github.com/AcademySoftwareFoundation/MaterialX/tree/main/documents/Specification) +- [USDShade Schema](https://openusd.org/dev/api/usd_shade_page_front.html) +- [glTF stream names](https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html). Note that currently there are no stream names for multiple sets of _tangents_, _bitangents_, _normals_ or _positions_. ## Appendix: Full Khronos Copyright Statement Copyright 2024 The Khronos Group Inc. -This Specification is protected by copyright laws and contains material proprietary -to Khronos. Except as described by these terms, it or any components -may not be reproduced, republished, distributed, transmitted, displayed, broadcast -or otherwise exploited in any manner without the express prior written permission -of Khronos. - -Khronos grants a conditional copyright license to use and reproduce the unmodified -Specification for any purpose, without fee or royalty, EXCEPT no licenses to any patent, -trademark or other intellectual property rights are granted under these terms. - -Khronos makes no, and expressly disclaims any, representations or warranties, -express or implied, regarding this Specification, including, without limitation: -merchantability, fitness for a particular purpose, non-infringement of any -intellectual property, correctness, accuracy, completeness, timeliness, and -reliability. Under no circumstances will Khronos, or any of its Promoters, -Contributors or Members, or their respective partners, officers, directors, -employees, agents or representatives be liable for any damages, whether direct, -indirect, special or consequential damages for lost revenues, lost profits, or -otherwise, arising from or in connection with these materials. - -This specification has been created under the Khronos Intellectual Property Rights -Policy, which is Attachment A of the Khronos Group Membership Agreement available at -https://www.khronos.org/files/member_agreement.pdf. Khronos grants a conditional -copyright license to use and reproduce the unmodified specification for any purpose, -without fee or royalty, EXCEPT no licenses to any patent, trademark or other -intellectual property rights are granted under these terms. Parties desiring to -implement the specification and make use of Khronos trademarks in relation to that -implementation, and receive reciprocal patent license protection under the Khronos -IP Policy must become Adopters and confirm the implementation as conformant under -the process defined by Khronos for this specification; -see https://www.khronos.org/conformance/adopters/file-format-adopter-program. - -Where this Specification identifies specific sections of external references, only those -specifically identified sections define normative functionality. The Khronos Intellectual -Property Rights Policy excludes external references to materials and associated enabling -technology not created by Khronos from the Scope of this Specification, and any licenses -that may be required to implement such referenced materials and associated technologies -must be obtained separately and may involve royalty payments. - -Khronos® is a registered trademark, and glTF™ is a trademark of The Khronos Group Inc. All -other product names, trademarks, and/or company names are used solely for identification -and belong to their respective owners. +This Specification is protected by copyright laws and contains material proprietary to Khronos. Except as described by these terms, it or any components may not be reproduced, republished, distributed, transmitted, displayed, broadcast or otherwise exploited in any manner without the express prior written permission of Khronos. + +Khronos grants a conditional copyright license to use and reproduce the unmodified Specification for any purpose, without fee or royalty, EXCEPT no licenses to any patent, trademark or other intellectual property rights are granted under these terms. + +Khronos makes no, and expressly disclaims any, representations or warranties, express or implied, regarding this Specification, including, without limitation: merchantability, fitness for a particular purpose, non-infringement of any +intellectual property, correctness, accuracy, completeness, timeliness, and reliability. Under no circumstances will Khronos, or any of its Promoters, Contributors or Members, or their respective partners, officers, directors, employees, agents or representatives be liable for any damages, whether direct, indirect, special or consequential damages for lost revenues, lost profits, or otherwise, arising from or in connection with these materials. + +This specification has been created under the Khronos Intellectual Property Rights Policy, which is Attachment A of the Khronos Group Membership Agreement available at https://www.khronos.org/files/member_agreement.pdf. Khronos grants a conditional copyright license to use and reproduce the unmodified specification for any purpose, without fee or royalty, EXCEPT no licenses to any patent, trademark or other intellectual property rights are granted under these terms. Parties desiring to implement the specification and make use of Khronos trademarks in relation to that implementation, and receive reciprocal patent license protection under the Khronos IP Policy must become Adopters and confirm the implementation as conformant under +the process defined by Khronos for this specification; see https://www.khronos.org/conformance/adopters/file-format-adopter-program. + +Where this Specification identifies specific sections of external references, only those specifically identified sections define normative functionality. The Khronos Intellectual Property Rights Policy excludes external references to materials and associated enabling technology not created by Khronos from the Scope of this Specification, and any licenses that may be required to implement such referenced materials and associated technologies must be obtained separately and may involve royalty payments. + +Khronos® is a registered trademark, and glTF™ is a trademark of The Khronos Group Inc. All other product names, trademarks, and/or company names are used solely for identification and belong to their respective owners. diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.png new file mode 100644 index 0000000000..f686be2782 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.svg b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.svg new file mode 100644 index 0000000000..05d11f2290 --- /dev/null +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_classes.svg @@ -0,0 +1,3 @@ + + +Procedural Input+ nodetype: "input"Procedural Output+ nodetype: "output"Procedural Node+ nodetype: Classification+ outputs: Output_Port[]+ [ inputs: Input_Port[] ]Compound NodeGraph+ nodetype: "nodegraph"+ type: TypeDef | "multioutput"
Extends
Extends
Extends
Extends
Extends
<<interface>>Port+ [name] : string+ nodetype : string+ type: TypeDef+ [ "input" | "output" | "node" |"texture" : integer ]+ ui <meta-data>Input Port+ value: Value+ [defaultgromprop] : stringOutput Port
Extends
Extends
«enumeration»Value+ integer[2..4]+ float[2..4]+ float[3][3]+ float[4][4]+ "string"+ boolean«interface»Procedural+ [ name : string ]+ nodetype : Classification+ type : TypeDef«string»Classification+ MTLX Stdlib classifications+ e.g. add, noise, etc+ Custom classifications«enumeration»TypeDef+ "vec2", "vec3", "vec4"+ "color3", "color4"+ "string" + "boolean" + "matrix33", "matrix44"+ "integer",  "integer2", "integer3", "integer4"
Existing glTF Element
gltF Texture Procedural
interface / enumeration
gltF Texture Procedural
( Immutable / Unconnectable )
gltF Texture Procedural
( Mutable/  Connectable )
Color Coding
Functional NodeGraph+ nodetype: "nodegraph"+ nodedef: integer+ outputs: Input_Port[] + type: TypeDef | "multioutput"Procedural Definition+ node: Classification+ nodetype: "nodedef"+ nodegroup:  string+ inputs: Input_Port[] + outputs : Output_Port[] + version: string+ <additional meta_data>
Implements
1
1
Extends
Extends
Extends
 \ No newline at end of file diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.png new file mode 100644 index 0000000000..18bcd82621 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.svg b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.svg new file mode 100644 index 0000000000..5cfc0a3bb7 --- /dev/null +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/KHR_procedural_diagrams_connections.svg @@ -0,0 +1,3 @@ + + +
KHR_texture_proedurals
mimetype: 
 application/mtlx+json;version=<MTLX version>
Procedurals
array
Procedural
NodeGraph
Material
KHR_texture_procedurals
extension
index
output
array
index
output
index
Procedural Definitions
array
Functional
Node Graph
Procedural
Definition
index
nodedef
Textures
array
Texture
source: integer
Images
array
Image
URI
meshes
array
TEXCOORD_#
COLOR_#
POSITION
NORMAL
primitives[]
MTLX "texcoord"+ index:integerMTLX "geom*"+ index: integer
References
References
MTLX "image"+ index:integer+ filename: string
"filename"
transferred
to Image URI
Is A
Is A
is A
Procedural Node+ name:string+ nodetype: Classification
outputs[]
Existing glTF Element
gltF Texture Procedural
Element
gltF Texture Procedural
( Immutable / Unconnectable )
gltF Texture Procedural
( Mutable/  Connectable )
Color Coding
Procedural
NodeGraph
outputs[]
 \ No newline at end of file diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/baked_marble.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/baked_marble.png new file mode 100644 index 0000000000..90293ffdd9 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/baked_marble.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown.svg b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown.svg new file mode 100644 index 0000000000..60951d5c79 --- /dev/null +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown.svg @@ -0,0 +1,3 @@ + + +
input
channel
index
material
input
channel
index
material
KHR materials
add
input
nodes
input
input
input
add
input=0
input=1
output
output
inputs
outputs
inputs
outpus
nodetype
input
nodegraph
nodegraph
procedurals
input
nodedef
nodegraph (functional)
procedural
definitions
KHR procedural graphs
mimetype: mtx-json
version: 1.39
 \ No newline at end of file diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown2.svg b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown2.svg new file mode 100644 index 0000000000..cafc8c406b --- /dev/null +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/breakdown2.svg @@ -0,0 +1,3 @@ + + +
input
nodegraph
nodegraph
procedurals
input
nodedef
nodegraph (functional)
procedural
definitions
KHR procedural graphs
mimetype: mtx-json
version: 1.39
input
input
input
input
output
inputs
outputs
nodetype="nodedef"
nodename=<category>
add
input
nodes
add
input=1
input=0
output
output
outputs
inputs
outpus
nodetype
nodedef=#
 \ No newline at end of file diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/checker_graph.svg b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/checker_graph.svg new file mode 100644 index 0000000000..873c382bb8 --- /dev/null +++ b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/checker_graph.svg @@ -0,0 +1,2 @@ + +
My_Checker
.surfaceshader
.base_color
.bg
.fg
.mix
.in1
.in1
.in
.in2
.in1
.in1
.in2
N_modulo
N_mtlxdotproduct
N_mtlxfloor
N_mtlxmix
My_Checker_N_mtlxmult
N_mtlxsubtract
color1
color2
texcoord
uvoffset
uvtiling
gltf_pbr_surfaceshader
surfacematerial
 \ No newline at end of file diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/interop.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/interop.png new file mode 100644 index 0000000000..324277fe24 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/interop.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/procedural_marble.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/procedural_marble.png new file mode 100644 index 0000000000..59e930aa63 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/procedural_marble.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/referencing.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/referencing.png new file mode 100644 index 0000000000..f192197c2e Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/referencing.png differ diff --git a/extensions/2.0/Khronos/KHR_texture_procedurals/figures/validation.png b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/validation.png new file mode 100644 index 0000000000..1b5ac87798 Binary files /dev/null and b/extensions/2.0/Khronos/KHR_texture_procedurals/figures/validation.png differ