README.md

glTF Extension Registry

Extensions for glTF 2.0

Ratified Khronos Extensions

• KHR_draco_mesh_compression
• KHR_lights_punctual
• KHR_materials_clearcoat
• KHR_materials_pbrSpecularGlossiness
• KHR_materials_unlit
• KHR_mesh_quantization
• KHR_texture_transform

Multi-Vendor Extensions

• EXT_lights_image_based
• EXT_mesh_gpu_instancing
• EXT_texture_webp

Vendor Extensions

• ADOBE_materials_thin_transparency
• AGI_articulations
• AGI_stk_metadata
• CESIUM_primitive_outline
• FB_geometry_metadata
• MSFT_lod
• MSFT_packing_normalRoughnessMetallic
• MSFT_packing_occlusionRoughnessMetallic
• MSFT_texture_dds

In-progress Khronos and multi-vendor extensions

Draft Khronos (KHR) extensions are not ratified yet. Multi-vendor (EXT) extensions do not require ratification, but may still change before they are complete.

Extension	Status
KHR_materials_ior	In development.
KHR_materials_thinfilm	In development.
KHR_materials_transmission	In development.
KHR_materials_sheen	Ready for implementation and feedback.
KHR_materials_specular	Ready for implementation and feedback. Two proposals in #1719 and #1741.
KHR_materials_volume	In development.
KHR_texture_basisu	Ready for implementation and feedback.
KHR_xmp	In development.

This section tracks the status of Khronos and multi-vendor extensions that are either already in development, or that we feel show enough consensus to be highly likely for future development. We welcome feedback for these and all other extensions (see GitHub issues). This list is intended to give a general sense of current priorities and direction.

For features that are not listed here but may be important for different uses, we encourage the community to begin with vendor extensions (which do not require review), reach out for feedback and collaborators, and as consensus forms we may consider the best way to bring a vendor extension into the broader ecosystem: via multi-vendor extensions, Khronos extensions, or inclusion in a future version of the glTF specification.

Extensions for glTF 1.0

Khronos extensions

• KHR_binary_glTF
• KHR_materials_common

Vendor extensions

• CESIUM_RTC
• WEB3D_quantized_attributes

About glTF Extensions

glTF extensions extend the base glTF model format. Extensions can introduce new properties (including properties that reference external data, and the extension can define the format of those data), new parameter semantics, reserved IDs, and new container formats. Extensions are written against a specific version of glTF and may be promoted to core glTF in a later glTF version.

Extension Mechanics

All glTF object properties (see glTFProperty.schema.json) have an optional extensions object property that can contain new extension-specific properties. This allows extensions to extend any part of glTF, including geometry, materials, animations, etc. Extensions can also introduce new parameter semantics, reserved IDs, and new formats containing glTF.

Extensions can't remove existing glTF properties or redefine existing glTF properties to mean something else.

Examples include:

• New properties: KHR_texture_transform introduces a set of texture transformation properties, e.g.,

{
  "materials": [{
    "emissiveTexture": {
      "index": 0,
      "extensions": {
        "KHR_texture_transform": {
          "offset": [0, 1],
          "rotation": 1.57079632679,
          "scale": [0.5, 0.5]
        }
      }
    }
  }]
}

Extensions may add new properties and values, such as attribute semantics or texture mime types. In all Khronos (KHR) extensions, and as best practice for vendor extensions, these feature additions are designed to allow safe fallback consumption in tools that do not recognize an extension in the extensionsUsed array.

All extensions used in a model are listed as strings in the top-level extensionsUsed array; all required extensions are listed as strings in the top-level extensionsRequired array, e.g.,

{
  "extensionsUsed": [
    "KHR_materials_pbrSpecularGlossiness", "VENDOR_physics"
  ],
  "extensionsRequired": [
    "KHR_materials_pbrSpecularGlossiness"
  ]
}

This allows an engine to quickly determine if it supports the extensions needed to render the model without inspecting the extensions property of all objects.

Creating Extensions

To create a new extension, use the extension template and open a pull request into this repo. Make sure to add the extension to the glTF Extension Registry (top of this file).

If the extension adds a new top-level array (by extending the root glTF object), its elements should inherit all properties of glTFChildOfRootProperty.schema.json. Other objects introduced by the extension should inherit all properties of glTFProperty.schema.json. By glTF 2.0 conventions, schemas should allow additional properties. See KHR_lights_punctual as an example.

If lack of extension support prevents proper geometry loading, extension specification must state that (and such extension must be mentioned in extensionsRequired top-level glTF property).

Extensions start as a vendor extension, then can become a multi-vendor extensions if there are multiple implementations, and can become a ratified Khronos extension (the multi-vendor extension is an optional step).

Naming

NOTE: For historical reasons, older extensions may not follow these guidelines. Future extensions should do so.

1. Names MUST begin with an UPPERCASE prefix, followed by an underscore. Prefixes are KHR for Khronos extensions, EXT for Multi-vendor extensions, and others may be reserved for Vendor extensions.
2. Names MUST use lowercase snake-case following the prefix, e.g. KHR_materials_unlit.
3. Names SHOULD be structured as <PREFIX>_<scope>_<feature>, where scope is an existing glTF concept (e.g. mesh, texture, image) and feature describes the functionality being added within that scope. This structure is recommended, but not required.
4. Scope SHOULD be singular (e.g. mesh, texture), except where this would be inconsistent with an existing Khronos extension (e.g. materials, lights).

Promoting Extensions

Vendor Extensions

A list of vendor prefixes is maintained in Prefixes.md. Any vendor, not just Khronos members, can request an extension prefix by submitting an issue on GitHub requesting one. Requests should include:

• The name of the prefix.
• The name of the vendor using the prefix.
• Vendor's contact information (optionally).

Vendor extensions are not covered by the Khronos IP framework.

Multi-Vendor Extensions

When an extension is implemented by more than one vendor, its name can use the reserved EXT prefix. To promote a vendor extension to a multi-vendor extension, open a pull request labeled extension that contains a new copy of the extension (even if there aren't any changes) with the new name using the EXT prefix, e.g., KHR_binary_glTF.

Multi-vendor extensions are not covered by the Khronos IP framework.

Khronos Extensions

Khronos extensions use the reserved KHR prefix and are ratified by Khronos and therefore are covered by the Khronos IP framework. Extensions that are intended to be ratified can also use the KHR prefix to avoid name/code/version thrashing. Khronos members can submit an extension for ratification, which is then voted on by the Khronos Board of Promoters.

Extensions vs. Extras

In addition to extensions, the extras object can also be used to extend glTF. This is completely separate from extensions.

All glTF object properties allow adding new properties to an extras object sub-property, e.g.,

{
  "asset": {
    "version": 2.0,
    "extras": {
      "guid": "9abb92a3-39cf-4986-a758-c43d4bb4ab58",
    }
  }
}

This enables glTF models to contain application-specific properties without creating a full glTF extension. This may be preferred for niche use cases where an extension would not be widely adopted.