glTF 2.0 Specification (Khronos Group, version 2.0.1, 2021-10-11)

The Khronos Group's specification for glTF, the format most of the corpus's engines read when a model comes in from Blender or a store. Version 2.0.1, last updated 2021-10-11; editors Saurabh Bhatia (Microsoft), Patrick Cozzi (Cesium), Alexey Knyazev, Tony Parisi (Unity), with a working group that lists Adobe, Dassault, Google, Fraunhofer IGD, UX3D and others. Copyright Khronos, with IANA media types model/gltf+json and model/gltf-binary. The spec's own one-line self-description: "glTF is an API-neutral runtime asset delivery format."

What kind of thing it is, in its own words

The spec draws the line this spoke's edge 6 was missing — between an authoring format and a transmission one: "glTF's focus on run-time efficiency is a different design goal than typical 3D 'authoring' formats. Authoring formats are typically more verbose, with higher processing overheads, to carry authoring data that is no longer needed after iterative design is complete. glTF is complementary to authoring formats, providing a common, interoperable distillation target." So Blender files and USD stay upstream; glTF is what crosses the boundary into a runtime.

Four stated goals: compact (JSON description, binary geometry/textures/animation that "can often be loaded directly into GPU buffers with no additional parsing"); runtime-independent ("purely an asset format and does not mandate any runtime behavior" — any renderer, "up to and including path tracing renderers"); complete scenes, not single objects (nodes, transform hierarchy, meshes, materials, cameras, animations); and extensible, with widely adopted extensions folded into later versions.

The model, briefly

• Two file forms: .gltf JSON with external .bin/image URIs, or a single GLB binary container. Minor versions are required to be backward and forward compatible.
• Data: buffer → bufferView → accessor typed views over binary; meshes are primitives with attribute accessors; morph targets and skins (joint hierarchies) for deformation; animations as keyframe channels with linear, step and cubic-spline interpolation.
• Conventions fixed by the spec: right-handed, +Y up, +Z forward, −X right; linear distances in metres, angles in radians; colour primaries BT.709.
• Materials: one model, PBR metallic-roughness, chosen "to be rendered consistently across platforms"; sheen, clearcoat and the rest arrive as KHR_materials_* extensions.
• Extensions: listed in extensionsUsed; anything a loader cannot skip goes in extensionsRequired. KHR_ is the ratified prefix; vendor prefixes are allowed.

What it does not define, and says so by omission: no physics, no scripting, no scene logic, no compression in core (Draco and KTX2 are extensions). It is a container for what the engine will draw and animate, and nothing about how the engine should behave.

For the spoke

Edge 6 asked for "format specs plus one studio's pipeline description." This is the spec half, and it answers the question the edge did not quite ask: the format engines share is deliberately the end of the pipeline, a distillation target, so the engine differences the spoke catalogues start upstream of it in the authoring tool and downstream of it in the renderer. USD, the other format the edge named, is on the authoring side of the spec's own line. The studio pipeline account is still owed.

Related

content-pipeline · webgpu · godot-engine · unreal-engine · unity-engine · o3de · synthesis