Khronos artwork for glTF 2.1 illustrating composed 3D assets and complex scene-delivery workflows.
Khronos is planning glTF 2.1 as a focused, backward-compatible update for complex scenes, adding external assets, packaged multi-file scenes, shapes, BVHs, unified file references, thumbnails, 64-bit GLB files, and better support for large-scale runtime delivery.
Khronos has outlined plans for glTF 2.1, and the headline is not a new material model or rendering effect. It is better infrastructure for complex scenes: assets assembled from many files, dependencies, references, and independently maintained parts.
Since glTF 2.0 arrived in 2017, it has become a standard runtime delivery format for real-time 3D across the web and native engines. Its ecosystem already supports mesh compression, optimized textures, PBR materials, Gaussian splats, and broad engine integration.
But large scenes still force teams to rely on custom conventions. Digital twins, BIM models, smart cities, geospatial environments, simulations, and asset libraries are rarely built as a single file. glTF 2.1 aims to support these composed scenes without turning glTF into an authoring format.
OpenUSD and content-creation tools can remain where scenes are authored and assembled. glTF remains the runtime delivery format, now with better ways to package and load complete scenes without flattening them into one monolithic asset.
External assets and packaging
The central addition is external asset support. A glTF file will be able to reference other glTF files and instantiate them within its scene hierarchy.
A factory scene, for example, could reference one equipment model and place it thousands of times. The root asset describes the composition, while the loader resolves and instantiates the referenced content.
Packaging extends this model by allowing external assets to be embedded into one self-contained glTF file while preserving the original file structure and URIs.
Khronos intends to do this without introducing a ZIP-style container or a new multi-chunk GLB structure. That keeps dependency resolution, validation, distribution, and archival within the existing glTF model.
Shapes, BVHs, and streaming
glTF 2.1 also brings implicit shapes into the core specification, including boxes, spheres, capsules, cylinders, and planes.
These provide a shared representation for physics, spatial queries, procedural systems, collision geometry, and bounding volumes.
They also support the proposed bounding volume hierarchy system. Nodes can carry bounding volumes for meshes, lights, cameras, or entire referenced assets, giving runtimes a standard way to perform culling, spatial queries, and deferred loading.
Combined with external assets, this creates a foundation for progressive scene streaming. A city, factory, or simulation could load only the sections relevant to the current camera or task.
Pipeline improvements
The update also includes several practical pipeline features:
- Standard thumbnails for asset managers and file browsers
- A 64-bit GLB format that removes the current 4 GiB chunk limit
- Unique IDs for addressing objects across tools
- Unified handling of file references
- Formal deprecation of multiple scenes for newly created content
The larger GLB format is especially relevant for point clouds, dense geometry, geospatial datasets, and radiance-field assets.
For WebGL and WebGPU developers, these changes address a major constraint on ambitious browser-based 3D. The limiting factor is often not rendering capability, but oversized assets, fragmented dependencies, proprietary scene structures, and pipelines that work only inside one toolchain.
glTF 2.1 is not a flashy update. It focuses on making the infrastructure behind large 3D experiences more portable, predictable, and practical to ship.
Source: Introducing glTF 2.1 with Complex Scenes by the Khronos 3D Formats Working Group.