Shader Translation: Support transmission in Standard Surface to glTF PBR

[kwokcb]

Issue

Unlike standard surface and openpbr, base color on gltf pbr affects transmission. This seems to be the way it's supposed to work but is inconsistent with the other shading models.

For example if you take the glass example which has a base value if 0, this renders as a "clear" material using standard surface and openpbr, but renders opaque black with gltf pbr.

Test

This is the glTF after translation, but can just create a material and set baseColorFactor to 0 and transmissionFactor to non-0.

"materials": [
    {
      "extensions": {
        "KHR_materials_transmission": {
          "transmissionFactor": 1
        },
        "KHR_materials_ior": {
          "ior": 1.5
        }
      },
      "pbrMetallicRoughness": {
        "baseColorFactor": [
          0,
          0,
          0,
          1
        ],
        "metallicFactor": 0,
        "roughnessFactor": 0
      },
      "emissiveFactor": [
        0,
        0,
        0
      ],
      "doubleSided": true,
      "name": "SR_glass"
    }
  ],

Result in model-viewer:

Result in MaterialX Graph Editor:

Workaround

Modify the base color to be white.

CC'ing @proog128 , @emackey as a possible item to check for future OpenPBR compatibility.

Repro Steps:

1. Load the glass material into MaterialXVew from the installed resources/Materials/Examples/StandardSurface folder
2. Open up the advanced settings and set the target shader model to be glt_pbr:
3. Close the dialog and press 't' (to translate) which will save a new file to disk in the same folder.
4. Load in the new file. See if it's black :).

[emackey]

Yes, this was a design decision for glTF transmission: Base color is also the transmission color. When transmission is 1.0 you should use other material systems' transmission color as the glTF base color (default is white typically).

[kwokcb]

Thanks @emackey,

Then I think the remaining issue lies with the std_surface -> gltf_pbr translation graph that this should be taken into account. Also when a OpenPBR -> gltf_pbr translation graph is created it should use the same logic.

Leaving this issue open for that.

[emackey]

So it sounds like this is specifically a bug in standard_surface_to_gltf_pbr.mtlx.

Right now SS transmission_color is hooked up exclusively to glTF's volumetric attenuationColor. But reading the SS spec, this should only be true when SS transmission_depth is non-zero. When SS transmission_depth is zero, transmission_color should displace SS base_color, becoming glTF's base color.

And that means yes, when SS transmission is in effect and transmission_depth is nonzero, SS transmission_color becomes glTF attenuationColor, and glTF base color is only ever white in that case.

[charo-m]

can I pick this issue for ASF DevDays 2024 ?

[jstone-lucasfilm]

Done, and thanks @charo-m!

[Avgilles]

can I pick this issue for ASF DevDays 2024 ?

ohh to late for me, good luck !

[kwokcb]

I've added some repro steps which I hope will help.

For faster setup, it is feasible to download the current release of MaterialX, and modify the file in libraries/bxdf/translation to avoid having to build everything. You need to restart MaterialXView after modification.

Of course to check in you'd want to run against a proper development build.

[charo-m]

For the repro steps, I wasn't able to get MaterialXView working (I'm on an Intel macbook, and couldn't use the prebuilt binary as it was arm64 only - and the one that I built gets into a bad state when I try to load a different material). So instead, I added some lines to write out to disk the translated material (removed before submitting PR) to the unit test which translates SS glass to glTF PBR, then inspected that in MaterialXGraphEditor which works fine.

PR: https://github.com/AcademySoftwareFoundation/MaterialX/pull/2027

[jstone-lucasfilm]

Thanks to @kwokcb for this original report, and to @charo-m for addressing this in #2027!