Progressive LOD in glTF Using Extensions

The glTF (GL Transmission Format) specification is designed for efficient delivery and loading of 3D content, but core glTF does not natively define Level-of-Detail (LOD) mechanisms. To deliver progressive and discrete LOD representations, glTF relies on an ecosystem of specialized extensions. This article explains how glTF implements LODs through discrete switching extensions like MSFT_lod, progressive geometry streaming pipelines using EXT_meshopt_compression, and hybrid tile-based approaches for massive spatial data.

Discrete Level of Detail: The MSFT_lod Extension

The most direct way glTF handles LOD is through the multi-vendor extension MSFT_lod. This extension allows an asset to define multiple versions of a node or material, switching between them depending on the viewer's distance or on-screen size.

When using MSFT_lod:

  • The extension is declared in the root extensionsUsed array and applied directly to node or material objects.
  • A base node contains an extensions.MSFT_lod object with an ids array. This array references alternative nodes representing lower-detail versions of the mesh.
  • Each alternative level is assigned a screenCoverage threshold (a value between 0.0 and 1.0). Runtimes evaluate the proportion of the screen occupied by the object's bounding sphere and render the appropriate level automatically.

This approach allows runtimes to download or parse low-detail models first to render the scene rapidly, deferring the loading of high-resolution geometry until needed.

Progressive Geometry Streaming via EXT_meshopt_compression

While discrete LOD switches entire meshes, true progressive LOD streams geometry incrementally, starting with a coarse base mesh and refining it with vertex and index deltas.

glTF achieves this using EXT_meshopt_compression. Developed as part of the meshoptimizer library, this extension organizes buffer data into independently decodable, highly compressed chunks.

Key progressive capabilities include:

  • Chunked Decoding: Mesh buffers are split into small sub-blocks. A runtime can stream these chunks over the network and decode geometry sequentially, displaying an initial low-density surface before higher-frequency topological details arrive.
  • Index and Vertex Filtering: Data is optimized for progressive topological reconstruction, significantly reducing bandwidth and memory consumption compared to storing fully independent meshes for each LOD stage.

Texture and Material Progressive Delivery

Geometry LOD is frequently coupled with texture LOD to prevent memory bottlenecks. glTF facilitates this using the KHR_texture_basisu extension.

Basis Universal textures support KTX2 containers, allowing mipmaps to be arranged such that lower-resolution mip levels appear first in the file or can be fetched via HTTP range requests. A client can download only the lowest-resolution mipmaps for distant objects, progressively requesting higher-resolution mip levels as the camera approaches.

Spatial Progressive LOD: glTF within 3D Tiles

For massive datasets such as terrain, point clouds, or city-scale scans, progressive LOD is often managed outside of a single glTF file using OGC 3D Tiles (specifically 3D Tiles 1.1), which integrates glTF directly.

In this structure:

  • A hierarchical bounding tree (such as an octree or quadtree) defines the spatial structure.
  • Each tile in the tree points to a discrete glTF asset representing a specific geometric resolution for that spatial partition.
  • As the camera moves through the space, tiles refine down the tree, replacing coarse glTF models with subdivided, higher-detail glTF tiles.

Through discrete switching (MSFT_lod), compressed chunk streaming (EXT_meshopt_compression), and spatial tiling integration, glTF provides a modular framework for both discrete and progressive LOD implementations across web, mobile, and desktop 3D engines.