glTF KHR Materials Transmission Rendering Fallbacks

This article provides an overview of how glTF client applications handle rendering fallbacks when they cannot decode or do not support the KHR_materials_transmission extension. It explains the structural dependency on the core glTF 2.0 PBR model, the behavior of default material parameters in unsupported environments, and how content creators control the visual appearance of fallback states.

Core PBR Metallic-Roughness as the Primary Fallback

The KHR_materials_transmission extension is designed to be backwards-compatible by relying on the core glTF 2.0 specification. If a client application does not support or cannot decode this extension—and the extension is not listed under extensionsRequired—it must ignore the extension data and fall back to the standard pbrMetallicRoughness model defined in the core material.

When the extension is ignored, the renderer bypasses the physical simulation of light transmitting through the volume of the mesh (such as refraction and absorption) and treats the surface as a standard reflective, opaque, or alpha-blended surface.

Opaque Rendering Fallback

By default, materials utilizing KHR_materials_transmission typically specify their core alphaMode as "OPAQUE". Optical transmission operates independently of alpha blending, as real-world transmissive objects (such as clear glass or water) are physically solid boundaries rather than partially transparent cutouts.

When an unsupported client renders such an asset:

  • The transmissionFactor and transmissionTexture values are ignored.
  • The surface is drawn strictly according to its alphaMode: "OPAQUE" setting.
  • The object renders as a solid, non-transparent surface using the baseColorFactor, baseColorTexture, metallicFactor, and roughnessFactor specified in the core material.

For example, a clear glass sphere authored with a white base color and low roughness will fall back to a highly polished, mirror-like solid opaque sphere in an unsupported viewer.

Fallback to Alpha Blending

Content creators can intentionally author an approximate transparency fallback for clients lacking transmission support. This is achieved by combining transmission with traditional alpha settings:

  1. Configuring alphaMode: Authors can set alphaMode to "BLEND" instead of "OPAQUE".
  2. Base Color Alpha: Authors set the alpha channel of baseColorFactor or baseColorTexture to a value less than 1.0.

In an unsupported client, the object will fall back to classic rasterized alpha blending, providing a semi-transparent appearance rather than a completely solid surface.

In a supported client, the implementation must resolve both transmission and alpha according to the specification: the alpha value dictates the coverage of the surface, while the transmission factor dictates how light passes through the covered areas.

The Role of extensionsRequired

If an asset demands transmission for its visual integrity and cannot degrade gracefully to standard PBR or alpha blending, the exporter can declare KHR_materials_transmission inside the asset's top-level extensionsRequired array.

When listed under extensionsRequired, the specification defines no rendering fallback: any client that cannot decode the extension must refuse to load or render the asset entirely, preventing incorrect or broken visual output.