Mipmap Generation for Compressed Textures in glTF

In 3D graphics pipelines utilizing the glTF format, mipmap generation is vital for maximizing rendering performance, eliminating visual artifacts, and optimizing GPU cache efficiency. When dealing with compressed texture extensions, such as KHR_texture_basisu, handling mipmaps effectively dictates loading speed and runtime behavior. This article examines the functional role of mipmaps, the limitations of generating them dynamically for block-compressed data, and why pre-computing them offline is essential for glTF runtimes.

Preventing Aliasing and Enhancing Visual Fidelity

Mipmaps are pre-filtered, progressively downscaled sequences of an original texture. When a surface textured via glTF is viewed at a distance or at an oblique angle, higher-frequency details exceed the sampling resolution of the screen pixels. Without mipmaps, the GPU samples high-resolution textures sparsely, resulting in severe pixel crawling, moiré patterns, and texture shimmering. Including a complete mip chain ensures that the GPU samples from a resolution level that matches the pixel footprint, smoothing out transitions and preserving visual stability across varying camera distances.

The Problem with Runtime Mipmap Generation on Compressed Formats

Traditional graphics pipelines loading uncompressed formats (like PNG or JPEG) often rely on API calls such as glGenerateMipmap in WebGL or OpenGL to downsample textures on the CPU or GPU during load time. However, this process becomes impractical and frequently unsupported when dealing with hardware-compressed textures:

  1. Hardware Limitations: Standard graphics APIs cannot automatically generate mipmaps directly from block-compressed data (such as BCn, ETC2, or ASTC). Downsampling requires uncompressed color data to filter pixels accurately.
  2. Decompression Overhead: To generate mipmaps at runtime for a compressed texture, the runtime would first have to decompress the base level into raw RGBA data, generate the downsampled chain, and then recompress each level back into the target GPU format. This recompression is computationally expensive, introducing severe frame drops and extended asset loading times.
  3. Universal Transcoding Issues: glTF compressed textures typically use Basis Universal (.ktx2), which transcodes intermediate UASTC or ETC1S formats directly into the client device's native GPU format. Transcoding is designed to be a lightweight, linear pass; it does not perform multi-level filtering or downsampling during the transcode step.

Reducing Memory Bandwidth and Improving GPU Cache Hits

Even though storing a full mipmap chain increases total texture data size by approximately 33%, it significantly reduces memory bandwidth demands during rendering.

Modern GPUs rely on texture caches (L1/L2) to keep fetch latencies low. When a full-resolution texture without mipmaps is mapped onto a distant object, adjacent screen pixels sample texels that are far apart in texture memory. This causes frequent cache misses, saturating memory bandwidth and decreasing framerates. With mipmaps available, adjacent screen pixels fetch adjacent texels from lower-resolution levels, maintaining high cache locality and overall rendering throughput.

The glTF Standard: Offline Mipmap Generation

Due to the technical barriers of generating mipmaps for compressed textures at runtime, the glTF specification and asset optimization guidelines mandate offline generation.

Asset pipelines typically generate all mip levels from the high-resolution source texture before compression takes place. Tools such as toktx or glTF-Transform generate the filtered levels on uncompressed data, compress each level into the KTX2 container, and output a self-contained texture asset. When a glTF runtime loads this texture, it reads the pre-calculated mip levels directly from the file, transcodes each level straight into the GPU's native block-compression format, and uploads the entire chain to the GPU without dynamic filtering or processing overhead.