Your asset browser renders an entire GLB just to draw a thumbnail, and if a scene needs more than 4 GiB of combined mesh and texture data, current glTF has no way to hold it in one file. Khronos, the standards body behind the format, addressed both problems on June 11, 2026, when the 3D Formats Working Group published the confirmed feature set for glTF 2.1 — the first revision to the core spec since glTF 2.0 shipped in 2017. Nothing here changes your export settings this week: the spec text is still being drafted in the open, and the working group held its annual Ecosystem Forum on the roadmap at SIGGRAPH on July 23. The feature list is locked enough to plan around, though, and two of the changes will eventually touch every GLB you ship.
Nine years, one revision, five confirmed pieces
glTF 2.0 turned nine this year — old enough that Khronos's own announcement called it notable that the format has run this long on constraints set in 2017. glTF 2.1 stays strictly backward-compatible: existing 2.0 files remain valid, and 2.1 importers read them exactly as before. The revision splits into two groups. Complex Scenes gives engines a standard way to assemble large scenes from many files: External Assets, Packaging, Shapes, Bounding Volume Hierarchies, and Unified File References, five features released together because each depends on the others. Quality of Life fixes six smaller pieces of friction: embedded thumbnails, a 64-bit GLB container, four promoted extensions, non-sequential UV attributes, wider accessor types, and Unique IDs for cross-file references. Ratification hasn't landed — the spec text is still open on Khronos's GitHub tracker — but this is the confirmed scope, not a wishlist.
The two changes that touch every GLB you ship
Two pieces of glTF 2.1 matter even if a multi-file scene never enters the picture. First, the GLB binary container has used 32-bit length fields since 2.0, capping any single chunk at 4 GiB. Binary format version 3 raises that to 64-bit — an 8 exbibyte ceiling — once ratified. In practice this fixes dense point clouds, Gaussian splat captures, and large geospatial datasets, not a hero character or prop export; a typical game-ready GLB runs megabytes, nowhere near the old limit, and version 2 files stay fully valid so nothing about a current pipeline breaks or needs to change. If GLB size is already a concern for reasons that have nothing to do with a 4 GiB ceiling — frame budget, download time — the in-browser way to check and cut poly count before it reaches your engine hasn't changed.
Second, glTF 2.0 has no standard field for a preview image, so every marketplace, file browser, or DAM either renders the full scene graph to generate a thumbnail or falls back to a generic icon. glTF 2.1 adds an optional thumbnail any tool can read without loading the scene into an engine — the same "know what's inside without paying the rendering cost" problem BitSoul's browser-based 3D Studio already solves for full inspection, tris, UVs, and materials, no engine required, at /marketplace/workspace. Thumbnails just standardize the lightest version of that problem at the file-format level, for every tool in the chain.
Multi-file scenes: the instancing trick indie teams can actually use
Complex Scenes targets digital twins and BIM first, but one piece is directly useful for games. External Assets lets a glTF file reference other glTF files and instantiate them inside its own scene hierarchy at load time, and the same referenced asset can be instantiated any number of times while its mesh data loads once. Picture a battlefield built from forty placed copies of one rigged character, something like Character Clockwork Automaton Knight. Today that's forty duplicated copies of the mesh baked into one GLB, or forty separate files an engine has to load and de-duplicate on its own. Under 2.1, the scene references the model once and reuses it thirty-nine times, with Bounding Volume Hierarchies attached to each instance so an engine can cull or stream them without walking full geometry. A free account's two monthly downloads cover evaluation on a model like that; commercial use is included with paid memberships — see pricing. It's the same goal as GPU instancing inside Unity, Unreal Engine 5, or Godot, solved one layer down, at the file format instead of the render pipeline.
The exporter gotcha: attribute order and the scenes array
Two smaller changes are worth checking against an actual pipeline rather than filed away as trivia. glTF 2.0 required indexed attributes like TEXCOORD_0 and TEXCOORD_1 to start at zero and stay consecutive — a file with TEXCOORD_1 but no TEXCOORD_0 was technically invalid. glTF 2.1 drops that restriction, which matters if an export chain, a lightmap UV pass bolted onto a Blender export, for instance, has ever produced attributes out of that strict order. It was invalid before; it's legal now, but only in importers already updated for 2.1, so current tools will keep rejecting it until they catch up. The Blender glTF export settings breakdown covers the settings that keep UV sets clean today, under 2.0 or 2.1.
Separately, glTF 2.1 formally deprecates the multiple-scenes pattern — a file's `scenes` array holding more than one scene. It isn't broken in existing files, but if a DCC exporter in a pipeline bakes LOD variants or turntable setups into multiple scenes inside one GLB, that convention is now discouraged for anything new built going forward.
glTF 2.1 at a glance
| Change | Who it actually affects | Ship-today impact |
|---|---|---|
| 64-bit GLB (8 EiB ceiling) | Point cloud, Gaussian splat, and geospatial pipelines | None — 2.0's 4 GiB ceiling doesn't bind typical props or characters |
| Embedded thumbnails | Marketplaces, asset libraries, DAM tooling | None yet — no exporter writes them until the spec ratifies |
| External Assets + Packaging | Teams instancing the same model across a large scene | Worth planning around if heavy assets get duplicated today |
| Non-sequential UV attributes | Anyone with a nonstandard export chain | Check attribute order; invalid under 2.0, legal under 2.1 |
| Multiple-scenes deprecation | Exporters that bake LOD or turntable variants into one GLB | Confirm the pipeline doesn't depend on it |
| Promoted extensions (WebP, mesh quantization, and others) | Everyone, eventually | None — already available today as opt-in extensions |
What to actually do this week
Nothing above is shippable yet. The spec text for glTF 2.1 is still open on Khronos's GitHub tracker, no exporter in Blender, Unity, Unreal Engine 5, or Godot writes any 2.1-only feature, and hand-authoring one into a GLB today produces a file most current loaders read incorrectly or reject outright. The useful move this week is an audit, not a migration: check whether any exporter in a pipeline relies on the multiple-scenes pattern, confirm UV attribute order is already clean with the settings linked above, and if a scene is already brushing against the 4 GiB ceiling, treat that as a reason to split it into smaller assets now rather than wait on tooling that doesn't exist yet.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*