The glTF Extension Mechanism Explained

This article explains how the glTF (GL Transmission Format) extension mechanism works to expand the core specification's capabilities. Readers will learn about the role of the top-level extension arrays, how individual elements implement custom properties, how engines handle compatibility, and the distinctions between different categories of glTF extensions.

The core mechanism allowing base glTF functionality to be enhanced without altering the core specification relies on a structured, JSON-based extension architecture. This architecture operates through three primary components defined within the glTF asset: the extensionsUsed array, the extensionsRequired array, and the extensions object attached to individual glTF elements.

The Extension Declarations

At the root level of a glTF JSON file, developers declare the presence of any extensions using two arrays:

  1. extensionsUsed: Lists all extensions present within the file. A parser or viewer can read this array to determine if it supports the advanced features needed to render the asset as intended. If a viewer does not recognize an extension listed only in extensionsUsed, it can safely ignore it and continue rendering the base components.
  2. extensionsRequired: Lists extensions that are strictly necessary to read or render the file properly. If a loader or runtime environment encounters an extension in extensionsRequired that it cannot support, it must reject loading the file or fail gracefully. For example, geometry compressed using the KHR_draco_mesh_compression extension cannot be decoded by a baseline parser, making it a required extension.

The extensions Property Object

Beyond declaring extensions at the root, glTF allows the extensions property to be added to virtually any glTF object, including nodes, meshes, materials, textures, and scenes. Within this dictionary, extension-specific data is nested under keys corresponding to the extension's standardized name. This design keeps proprietary or experimental data structured and isolated from the core schema while preserving compatibility with standard engines.

Extension Prefixes and Governance

glTF extensions follow a strict naming convention governed by the Khronos Group to prevent collisions:

  • Khronos Extensions (KHR_): Formally reviewed and ratified by the Khronos 3D Formats Working Group, representing cross-industry standards such as advanced PBR material models (KHR_materials_clearcoat, KHR_materials_transmission).
  • Multi-Vendor Extensions (EXT_): Developed and agreed upon by two or more independent vendors to address common requirements.
  • Vendor-Specific Extensions (<VENDOR>_): Implemented by a single company or organization (e.g., MSFT_, ADOBE_, CESIUM_) to serve unique platform needs or test features prior to broader standardization.

By providing a backward-compatible structure through extensionsUsed, extensionsRequired, and localized extensions objects, the glTF format allows 3D authoring tools and runtimes to evolve rapidly while maintaining a universal, rock-solid baseline standard.