Since the release of glTF™ 2.0 in 2017, the format has matured into a rich ecosystem spanning mesh compression, texture optimization, 3D Gaussian splats, and more. Today, the Khronos® 3D Formats Working Group is excited to announce plans for glTF 2.1: a focused, backward-compatible revision of the core specification, built around a single motivation — making glTF work as well for large, composed scenes as it already does for single assets.
Every feature in this release addresses a real gap that today forces teams toward proprietary conventions, custom tooling, or workarounds that break interoperability:
- Asset creators and pipeline teams can include preview thumbnails directly in glTF files, making asset libraries browsable without a renderer
- Developers building large-scale scenes now have a standardized way to compose and deliver multi-file scene graphs for digital twins, building information modeling (BIM), smart cities, geospatial, and simulation
- Engine and runtime developers get standardized spatial primitives through Shapes and Bounding Volume Hierarchies, expanded accessor component type definitions for extensions to build on, and Unique IDs that make object addressing stable and interoperable across tools
- Developers who need 3D streaming can build on complex scenes as the foundation for progressive delivery, including the spatial subdivision, availability maps, LOD and quality metrics, and streaming hints already proven at scale by the glTF extensions of OGC 3D Tiles
- Everyone benefits from a 64-bit GLB format that lifts the 4 GiB size ceiling, and a cleaner specification with the rarely-used multiple-scenes pattern formally deprecated
Every capability in glTF 2.1 holds to glTF's core mission as a delivery format: the efficient, reliable transmission and loading of 3D assets at runtime. Complex scenes extend what glTF can deliver — complete, composed, multi-asset experiences rather than single models — without turning glTF into an authoring or interchange format. glTF 2.1 is complementary to content creation ecosystems such as OpenUSD: scenes authored and assembled in creation pipelines can now be delivered, self-contained and interoperable, as glTF.
"This release has been guided by a clear philosophy: address the most impactful, widely needed improvements to the core spec while keeping glTF lean, interoperable, and backward-compatible," said Amanda Morgan, Khronos 3D Formats co-chair and senior director, Open Standards at Bentley Systems. "Each feature has gone through a structured 'Design First' process: working groups agreed on purpose, scope, behavior, and relationships before any schema work began, ensuring that every addition earns its place in the core."
Here's what's coming.
Complex Scenes
A factory digital twin is built from thousands of equipment models. A city block is composed of buildings, infrastructure, and terrain. A simulation environment is stitched together from assets supplied by many vendors. Scenes like these are assembled, not authored as single files — yet glTF 2.0 offers only two ways to deliver them: collapse everything into one monolithic file, or adopt proprietary conventions for multi-file composition. Neither preserves the interoperability that makes glTF valuable, and this gap has been one of the primary barriers to adopting glTF at this scale.
glTF 2.1 closes the gap with a coordinated set of core features. For scene composition, External Assets lets a glTF file reference other glTF files and instantiate them in its scene hierarchy at load time, while Packaging delivers a composed scene and all of its dependencies as a single self-contained asset. For spatial primitives, implicit volumes enter the core specification through Shapes, and Bounding Volume Hierarchies use them to make large scenes efficient to cull, stream, and query. Beneath both sits Unified File References — a single, consistent mechanism for resolving external, embedded, and packaged resources that the rest of the architecture depends on.
Together, these capabilities allow a complete, structured, multi-file scene to be delivered as one interoperable glTF asset — and they form the foundation on which features like progressive scene streaming, LOD hierarchies, distributed asset libraries, and large-scale collaborative environments can be built. They also render one piece of the 2.0 specification obsolete: glTF 2.1 formally deprecates the rarely-used multiple-scenes pattern, described at the end of this section.
External Assets
With External Assets, a glTF file can declaratively reference other glTF files and instantiate them as models within its own scene hierarchy. The model is familiar from CAD and BIM: an assembly file references part files, and the assembly is resolved when it is opened. In glTF 2.1, that resolution happens at load time — the root file declares what it needs, and the loader composes the scene.
This single mechanism carries several workflows. A large scene can be composed from many independently authored and maintained glTF files. The same referenced asset can be instantiated any number of times — a thousand instances of one equipment model load the asset once and reuse it — making large repetitive scenes compact to deliver. And because references are declarative, loading can be deferred: content is fetched only when an application decides it is needed, which is the building block that progressive scene streaming rests on. Cyclical references between assets are strictly prohibited, keeping every scene's load dependencies acyclic and predictable.
The working group has explored this capability before as a separate companion format, glTF External Reference — known to many in the community as "glTFX." glTF 2.1 resolves that long-running design discussion by bringing external referencing directly into the core specification, where every conformant loader will support it. The design also looks ahead: referenced assets are declared through a level of indirection that future extensions can use to customize instances — for example, overriding transforms to pose a referenced character — without changing the referencing mechanism itself. Paths to referenced files are expressed through the new files array, the unified reference mechanism described later in this section.
Packaging External Assets
The External Assets feature does more than link files: it can package them. When external glTF files are embedded as buffer views rather than referenced by URI, the host file's files array serves as a virtual file system — any URI found within an embedded file is resolved against the original URI values declared in that array, rather than against the file system or network.
This means a single glTF file can act as a fully self-contained package for a complex multi-file scene, carrying all of its dependencies — textures, buffers, and nested glTF files — without modifying any of the original data. A scene originally spread across many files can be packaged into one asset ready for distribution, archive, or interchange, while the internal structure and URIs of every component file remain untouched. Resources shared between nested assets — a texture used by several equipment models, for example — are stored once and resolved by all of them.
This approach was chosen deliberately over alternatives such as a ZIP-based container or a restructured multi-chunk GLB. By building packaging behavior directly on top of the External Assets and files mechanisms, glTF 2.1 delivers self-contained complex scenes with no additional container format to implement.
Packaging External Assets Explainer
Shapes
glTF 2.1 brings implicit geometric shapes into the core specification. This addresses a long-standing gap: glTF 2.0 has no native way to represent simple volumes such as boxes, spheres, capsules, or cylinders without resorting to explicit mesh geometry. That makes glTF expensive and inefficient to use in physics pipelines, spatial query systems, and procedural content workflows, where primitive shapes are the natural unit of work.
glTF 2.1 adds a top-level shapes array, superseding the pending KHR_implicit_shapes extension and giving these common primitives a stable, interoperable home in the spec. The base specification defines geometry, parameterization, and semantics for five shape types — box, sphere, capsule, cylinder, and plane — that are widely supported across physics engines and spatial query systems. More complex or specialized shape types may be added by extensions in the future. This layered approach keeps the core implementable and focused while leaving room for richer shape vocabularies to evolve through the extension ecosystem.
Within glTF 2.1 itself, shapes have one core consumer: they are the geometry from which Bounding Volume Hierarchies, described next, are built. Beyond the core, the same definitions are ready to serve physics colliders, trigger volumes, and procedural workflows through extensions — one shared shape vocabulary across every spatial use case, rather than each extension inventing its own.
Bounding Volume Hierarchies
Efficient spatial queries such as collision detection, occlusion culling, ray intersection, and physics simulation all depend on tight, well-structured bounding volumes attached to scene nodes. There is no standard way to express this in glTF 2.0, so every engine and runtime invents its own convention, undermining portability.
glTF 2.1 brings Bounding Volume Hierarchies (BVH) into the core specification with a new boundingVolume node property: a simple geometric shape, optionally transformed, that completely encloses the node's content. Volumes are built from the implicit shapes just described, and because they attach to nodes rather than meshes, they can bound any content — meshes, lights, cameras, or entire referenced assets. Volumes defined through a node hierarchy maintain spatial coherence: a node's volume fully encloses the content of its descendants, which is what makes the hierarchy cheap to traverse.
Authors keep full control over how tight each volume is. A volume for a skinned mesh can be sized to contain all reasonable deformation states; a parent with many animated children can omit its own volume and rely dynamically on theirs. Beyond culling and intersection, applications can use bounding volumes to drive deferred loading — fetching content only when its volume becomes relevant, by angular size on camera or any other metric — which, combined with External Assets, is precisely the machinery that progressive scene streaming is built from.
Unified File References
Both External Assets and Packaging rest on a mechanism that has appeared throughout this section: the new top-level files array. It exists because glTF 2.0 has no single, consistent convention for referencing external content. URIs appear in multiple places across the specification — buffers, images — each with its own handling, and every extension that references external files must define its own array repeating the same pattern of uri, bufferView, and mimeType properties.
The practical cost is that tools cannot reliably discover a glTF file's dependencies without understanding every extension. Operations that should be trivial — packing a glTF file and its dependencies into a self-contained asset, uploading a complete model from a file picker, validating that nothing is missing — become impossible to implement correctly without supporting every extension that ever references a file.
The files array resolves this. It works like the existing buffers and images arrays but accepts any file type, with a required mimeType, and every new file type added to glTF in the future will use it — while buffers and images continue unchanged for full backward compatibility. Cyclical references between files are strictly prohibited. The result: a tool needs to look in exactly three places to find every external dependency of a glTF file — buffers, images, and files — giving the format portable, well-defined path resolution across operating systems and deployment environments, and giving complex scenes the foundation everything above is built on.
Unified File References Explainer
| Feature | What it does |
|---|---|
|
External Assets |
Reference glTF/GLB assets from scene nodes and instantiate them — once or many times — at load time |
|
Packaging External Assets |
Deliver a composed scene and all its dependent resources as one portable artifact, without modifying the original files |
|
Shapes |
Describe simple, non-rendered volumes — box, sphere, capsule, cylinder, and plane — for compact bounds and proxies |
|
Bounding Volume Hierarchies (BVH) |
Attach a bounding volume to any node, forming hierarchies that make large scenes efficient to cull, stream, and query |
|
Unified File References |
Name, locate, and resolve external, embedded, and packaged resources, including glTF assets, textures, audio, behavior graphs, metadata schemas, and compressed payloads |
Multiple Scenes Deprecation
glTF 2.0 permits a file to contain multiple scenes in a scenes array, with a scene property indicating the default. In practice, this capability is rarely used, inconsistently supported, and a source of ambiguity in interchange — glTF 2.0 never defined a way to actually use multiple scenes at once, and its removal has been requested by the community for years. Most tools produce and consume exactly one scene per file.
The complex scenes capabilities described above now provide everything multiple scenes never did — a defined way to instantiate assets in the hierarchy, reuse them any number of times, and compose them across files — so glTF 2.1 formally deprecates the multiple-scenes pattern, clarifying that a glTF file contains at most one scene. This is not a breaking change: existing files remain valid, glTF 2.1 importers should continue to handle multiple scenes exactly as they did for glTF 2.0, and only new content is discouraged from relying on the pattern.
Multiple scenes deprecation explainer
Quality of Life Improvements
Alongside complex scenes, glTF 2.1 delivers a set of improvements the working group calls quality of life — a deliberately modest name for changes whose value compounds. None of these features, taken alone, transforms what glTF can express. Each one removes a specific piece of friction that today costs real time somewhere in a pipeline: a preview that has to be rendered before an asset can be browsed, a dataset that won't fit in a single GLB, a conversion that produces technically invalid files, an object that can't be reliably addressed from outside the file. Multiplied across every asset, every tool, and every handoff between them, removing this friction is one of the most direct ways glTF 2.1 makes daily work better.
The improvements span the full journey of an asset — from authoring and format conversion, through asset management and optimization, to delivery and toolchain integration. Several also correct acknowledged gaps in the glTF 2.0 specification, closing them in the core rather than leaving each implementation to work around them. Each improvement is described below.
Thumbnails
glTF 2.1 introduces first-class support for thumbnails, a practical addition that improves glTF workflows and usability. glTF 2.0 files have no standard mechanism to carry a preview image, so asset management systems, file browsers, and content pipelines must either render every asset in advance or fall back to a generic icon.
With glTF 2.1, a glTF file can declare a thumbnail image — embedded in the file or referenced alongside it — that applications can display without loading the scene graph into a 3D engine. Thumbnails are purely optional and can be ignored by applications that don't need them. The payoff is immediate: users browsing a library of hundreds of models can see what each asset is without launching a renderer, and authors can supply custom imagery beyond what is visible in the 3D scene — a posed character, a branded cover. For pipelines and digital asset management (DAM) systems, a standardized thumbnail removes the need for proprietary preview-generation steps entirely.
64-Bit Binary File Format
The GLB binary container format introduced in glTF 2.0 uses 32-bit length fields, capping individual chunks at 4 GiB. While this limit was seldom a concern for typical real-time 3D assets, it has become an increasingly significant constraint for high-fidelity content, large-scale point clouds, dense mesh data, geospatial datasets, and radiance field formats like 3D Gaussian splatting.
glTF 2.1 defines binary format version 3, which upgrades length fields to 64-bit — raising the ceiling from 4 GiB to 8 EiB, enough to address the full range of modern asset sizes for the foreseeable future. The existing version 2 format remains fully defined: glTF 2.1 importers must support both versions, and exporters may continue producing version 2 files for maximum compatibility wherever content fits within the existing limits. Version 3 also adds a reserved chunk-encoding field — always zero in glTF 2.1 — giving future versions and extensions a defined place for capabilities such as chunk-level compression. This is a pragmatic upgrade that future-proofs glTF for the data volumes already emerging in large-scale professional and geospatial workflows.
Promoted Extension Functionality
The functionality of the following ratified glTF 2.0 extensions is now required in glTF 2.1:
glTF implementations must support the functionality of these extensions in order to be compliant with glTF 2.1. Each earns its promotion: guaranteed WebP support lets authors ship WebP textures without fallbacks, emissive strength and mesh quantization close acknowledged oversights in the glTF 2.0 specification, and a standardized node visibility toggle directly supports the new complex scenes features and improves DCC workflows. The exact syntax for using this functionality in glTF 2.1 assets will be defined as the specification develops.
Promoted Extension Functionality Explainer
Non-Sequential Attributes
glTF 2.0 requires that all indexed attribute semantics start from zero and be consecutive positive integers: TEXCOORD_0, TEXCOORD_1, and so on. In practice, this restriction creates friction without delivering meaningful compatibility benefits.
glTF 2.1 relaxes this requirement, allowing texture coordinate and color attributes to be non-sequential and to start from any index. A mesh primitive can now legally declare TEXCOORD_1 without TEXCOORD_0 being present. This simplifies conversion between glTF and other formats that impose no such constraint and removes a source of technically invalid intermediate states during content authoring and editing.
To preserve the spirit of the original requirement, glTF 2.1 encourages the use of TEXCOORD_0 for the primary texture coordinate set. This best practice maintains compatibility with engines that support only a single texture coordinate set, while giving the format the flexibility that real-world workflows demand.
Non-Sequential Attributes Explainer
Accessor Component Type Definitions
glTF 2.0's accessors define a fixed set of component types: BYTE, UNSIGNED_BYTE, SHORT, UNSIGNED_SHORT, UNSIGNED_INT, and FLOAT. Certain use cases, particularly in scientific visualization, geospatial data, and high-precision engineering, require data types that the current specification cannot cleanly express.
glTF 2.1 brings an expanded set of accessor component type definitions, adding SIGNED_INT, DOUBLE, HALF_FLOAT, SIGNED_INT64, and UNSIGNED_INT64. Defining these types in the core does not change which component types existing glTF features such as meshes accept — those restrictions are unchanged in glTF 2.1. Instead, the core definitions give extensions a common, consistent foundation: an extension can enable the new types where they are needed, such as the proposed KHR_accessor_float16 and KHR_accessor_float64, without each extension having to redefine them.
Accessor Component Type Explainer
Unique IDs
As glTF evolves to support multi-file workflows and External Assets, cross-file object identification and referencing has become increasingly critical. Today, glTF's name property is optional and not required to be unique, making it unsuitable as a stable cross-file identifier.
glTF 2.1 introduces Unique IDs (UIDs) as a first-class concept. A UID is a string, drawn from a restricted character set, that can be applied to any object in a glTF file that uses the glTF child-of-root schema. Uniqueness is scoped to the file: a UID must not share its value with any other uid — or any name — in the same file. This gives toolchains, importers, and external reference systems a dependable handle for addressing specific objects within an asset. And where a name property already satisfies the uniqueness and character-set requirements of a UID, it may serve as a fallback identifier — allowing existing glTF 2.0 assets, and glTF 2.1 files authored without UIDs, to participate in external referencing as well.
Several questions, including how uniqueness is defined within complex multi-file scene assemblies and the exact set of permitted characters, are being worked through by a dedicated subgroup. We believe that now, while the scene graph is being meaningfully extended, is exactly the right time to build stable object identity into the format.
What's Next
The features described here represent the confirmed core features of glTF 2.1, agreed upon by the 3D Formats Working Group through a rigorous, community-driven design process. The full specification, detailed explainers, and schema definitions will be developed openly on the glTF 2.1 GitHub issue, and the Khronos Group welcomes feedback from the broader community as the specification is finalized.
Those attending SIGGRAPH 2026 in Los Angeles are invited to join a live discussion on glTF 2.1 at the seventh annual glTF Ecosystem Forum, taking place Thursday, July 23 from 1:30 PM – 8 PM. Attendees will have the opportunity to share feedback and engage directly with the glTF working group on the glTF 2.1 roadmap and the wider glTF ecosystem. Space is limited: reserve your spot.
From complex scenes assembled across many files to friction removed from everyday workflows, glTF 2.1 expands what glTF can deliver while keeping the format lean, interoperable, and backward-compatible. As always, glTF evolves in the open, for everyone. Stay tuned for further announcements as we approach the release of glTF 2.1.
Learn more about glTF and the Khronos 3D Formats Working Group at khronos.org/gltf. Companies interested in shaping the future of glTF and other Khronos standards are invited to join the Khronos Group.