glTF 1.0 vs glTF 2.0 Pipeline Changes

The transition from glTF 1.0 to glTF 2.0 marked a fundamental evolution in 3D asset delivery, shifting the format from a WebGL-dependent representation into a universally compatible, runtime-ready standard. This article breaks down the major rendering and data pipeline changes between the two versions, specifically focusing on the elimination of custom GLSL shaders, the adoption of physically based rendering (PBR), enhanced animation workflows, and standardized binary packing.

1. Shift from Custom Shaders to Standardized PBR

In glTF 1.0, materials were defined using WebGL-specific concepts like techniques, programs, and embedded or referenced GLSL shader source code. The default lighting model relied on traditional, unstandardized Blinn-Phong shading. This design created severe bottlenecks for rendering pipelines:

• Assets were tightly coupled to WebGL and OpenGL ES, requiring engines using DirectX, Metal, or Vulkan to translate or rewrite the incoming GLSL shaders.
• Visual output varied drastically across different runtimes because lighting equations and material implementations were left to the discretion of arbitrary shader code.

glTF 2.0 removed raw GLSL shaders and runtime-specific techniques from the core specification entirely. Instead, it introduced a standardized Metallic-Roughness Physically Based Rendering (PBR) model. By defining clear material parameters (such as base color, metallic factor, roughness factor, and occlusion) rather than execution logic, glTF 2.0 allows target rendering engines to compile their own optimal native shaders while ensuring consistent, portable visual results across all modern graphics APIs.

2. Elimination of WebGL-Centric Runtime Dependencies

Because glTF 1.0 stored explicit WebGL state states (such as blend modes, depth testing parameters, and uniform bindings), importing an asset required reproducing that exact WebGL pipeline state.

glTF 2.0 stripped away low-level graphics API state management. The runtime pipeline is no longer dictated by the asset; instead, the asset specifies raw scene data, geometry, and uniform material values, leaving resource allocation, pipeline state management, and command buffer generation to the host engine.

3. Native Support for Morph Targets and Blend Shapes

glTF 1.0 supported skeletal animation (skinning) and node transform hierarchies, but it lacked a native solution for blend shapes. Developers needing facial animation or fine organic deformations had to rely on non-standard vendor extensions.

glTF 2.0 integrated morph targets directly into the core specification:

• Sparse Accessors: Introduced to store only the vertex displacements that deviate from the base mesh, drastically reducing file size and bandwidth requirements.
• Weights Animation: Morph target weights can be directly targeted and sampled by animation channels alongside translation, rotation, and scale channels.

4. Animation Interpolation Improvements

Animation pipelines in glTF 1.0 supported linear and step interpolation. glTF 2.0 introduced cubic spline interpolation (CUBICSPLINE), allowing exporters to serialize tangent data directly alongside keyframe values. This enabled smooth, complex curves with significantly fewer keyframes, reducing CPU evaluation overhead and payload size.

5. Official Core Standardization of Binary glTF (.glb)

In glTF 1.0, the binary container format (.glb) was an experimental extension (KHR_binary_glTF). Assets typically required multiple files: a .gltf JSON manifest, an external .bin buffer, and separate texture files.

glTF 2.0 made the .glb format an official part of the core specification. It standardized a chunk-based binary container (structured into JSON and BIN chunks) that packs the scene graph, buffers, and image assets into a single streamable file, simplifying asset ingestion and content delivery networks.

6. Consistent Normal Mapping and Tangent Spaces

glTF 1.0 lacked strict guidelines for tangent space calculations, leading to common normal-mapping artifacts across different engines. glTF 2.0 established clear mathematical rules for normal mapping, explicitly adopting the MikkTSpace standard for calculating tangents when explicit vertex tangents are omitted from the geometry buffers.