Skip to content

Commit

Permalink
Update on multi-channel texture_info and 3-channel texcoord bindings.
Browse files Browse the repository at this point in the history
  • Loading branch information
kwokcb committed Aug 20, 2024
1 parent 6b487dc commit 7e1798e
Show file tree
Hide file tree
Showing 3 changed files with 8 additions and 4 deletions.
2 changes: 2 additions & 0 deletions extensions/2.0/Khronos/KHR_texture_procedurals/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -442,6 +442,8 @@ Semantics for texture coordinate lookups are as follows:

1. The current [specification language for meshes]((https://registry.khronos.org/glTF/specs/2.0/glTF-2.0.html#meshes-overview)) notes that texture coordinates are
2 channel. In order to support 3D texture coordinates it is proposed that the semantics of this binding be extended to allow 3 channel texture coordinates.
This is currently beyond the scope of this extension, thus validation for
for this version will consider these nodes as being invalid.

2. Texture coordinates may be routed in a graph through one or more downstream nodes which may perform a mathematical operation on the coordinates. To avoid ambiguity any transform specified on a texture should be ignored / removed.

Expand Down
10 changes: 6 additions & 4 deletions extensions/2.0/Vendor/EXT_texture_procedurals_mx_1_39/README.md
Original file line number Diff line number Diff line change
Expand Up @@ -79,17 +79,19 @@ The `procedurals` array specifies the procedural graphs for a given set of nodes

## Handling MaterialX glTF PBR Nodes

The glTF PBR node specified within MaterialX exposes a number of input ports which may not map 1:1 with the glTF PBR material
for texture mapping. That is `texture_info` mappings in glTF PBR may not map directly to the input ports of the MaterialX PBR node.
The glTF PBR node specified within MaterialX exposes a number of input ports which may not map 1:1 with the glTF PBR material for texture mapping. That is, `texture_info` mappings in glTF PBR may not map directly to the input ports of the MaterialX PBR node.

One example is the mismatch of `metalicRoughnessTexture` which is a single packed 3 or 4 channel image which is minimally split into two input ports `metallic` and `roughness` on a glTF PBR shader in MaterialX. ( It is to be determined what it means to have different upstream connections for each port when mapping to a single `texture_info`).
One example is the mismatch of `metalicRoughnessTexture` which is a single packed 3 or 4 channel image which is minimally split into two input ports `metallic` and `roughness` on a glTF PBR shader in MaterialX.

Below is the Boombox glTF example as expressed in MaterialX. The top image shows the mapping to the shader port connects and the bottom a subgraph which shows how an ORM image is split to the `metallic` and `roughness` and `occlusion` ports.

<img src="figures/boombox_mapping.png" width=60%>
<img src="figures/boombox_mapping2.png" width=60%>

Any channels mapped on the MaterialX glTF PBR node which do not correspond to a `texture_info` mapping should be ignored or pre-processed to an appropriate scalar value.
Any channels mapped on the MaterialX glTF PBR node which do not correspond to a `texture_info` mapping should be ignored as being invalid or pre-processed to insert the appropriate node within the procedural graph to combine the outputs so that they are mappable. For the example, a `combine` node has been added. The
split outputs can be reconstituted when converted back (e.g. to MaterialX) for an integration which uses separated inputs.

<img src="figures/combine_channels.png" width=60%>

## JSON Schema

Expand Down
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.

0 comments on commit 7e1798e

Please sign in to comment.