How glTF Handles High-Polygon Photogrammetry Scans

Photogrammetry captures real-world objects with remarkable visual fidelity, but it routinely produces dense meshes with millions of polygons and massive texture atlases that challenge real-time rendering. The glTF (GL Transmission Format) standard is engineered specifically to transmit and load 3D assets efficiently over networks and directly onto GPUs. While raw, unoptimized photogrammetry meshes can overwhelm runtime environments, glTF manages these high-polygon datasets through geometry compression algorithms, GPU-friendly texture formats, level-of-detail extensions, and integration with spatial streaming frameworks.

Geometry Compression

Standard glTF files store geometry as binary buffers containing vertex attributes such as positions, normals, and texture coordinates. For raw photogrammetry scans, these binary buffers can quickly reach hundreds of megabytes. glTF solves this primarily through two key compression extensions:

  • KHR_draco_mesh_compression: Uses Google’s Draco library to aggressively compress vertex buffers and index data. Draco can reduce mesh file sizes by up to 90%, making network transfer over the web fast. However, Draco requires client-side CPU decompression before data can be uploaded to the GPU, which can introduce a frame-rate hitch or loading delay for extremely high-poly meshes.
  • EXT_meshopt_compression: Designed by the meshoptimizer project, this extension compresses vertex and index streams while focusing on decoding speed. Meshopt decompresses significantly faster than Draco (often at multiple gigabytes per second), allowing high-polygon geometry to be parsed and sent to the GPU with minimal latency.

GPU-Native Texture Compression

Photogrammetry scans rely heavily on high-resolution diffuse/albedo maps (often 4K or 8K) to preserve photographic realism. In standard formats like PNG or JPEG, textures must be fully decompressed into raw RGBA in system memory, consuming gigabytes of video RAM (VRAM).

glTF addresses this bottleneck via the KHR_texture_basisu extension, which incorporates KTX 2.0 containers and Basis Universal compression. This format keeps textures compressed in system memory and transcodes them on the fly directly into native GPU-compressed formats (such as BCn, ASTC, or ETC) supported by the target hardware. This reduces VRAM consumption by 70–80%, preventing out-of-memory crashes when rendering photorealistic assets on mobile devices or lower-end GPUs.

Pre-Processing Pipelines: Decimation and Baking

Because glTF is an intermediate transmission format (often called the "JPEG of 3D") rather than an authoring format, best practices dictate preparing photogrammetry scans before exporting them to glTF:

  1. Mesh Decimation: High-density meshes (e.g., 5 to 20 million triangles) are decimated down to manageable budgets (e.g., 50,000 to 500,000 triangles) using quadric edge collapse algorithms.
  2. Texture Baking: Surface details from the ultra-high-poly original are baked into normal, ambient occlusion, and roughness maps applied to the lower-poly mesh.
  3. PBR Conversion: Pure photographic captures are converted into Physically Based Rendering (PBR) materials, aligning with the core glTF PBR specification to ensure consistent lighting behavior across different engines.

Handling Massive Datasets via LOD and 3D Tiles

When a photogrammetry scan is too large to fit into memory as a single asset—such as an entire building, archaeological site, or terrain scan—glTF handles the data hierarchically:

  • Hierarchical Level of Detail (HLOD): Extensions like MSFT_lod allow a glTF file to define multiple representations of the same object at varying polygon and texture resolutions. The runtime engine swaps between these levels based on camera distance or screen coverage.
  • 3D Tiles and OGC Standards: For geospatial photogrammetry, glTF serves as the underlying payload format inside the 3D Tiles specification (using B3DM or direct glTF integration in 3D Tiles 1.1). The scan is spatially partitioned into a bounding volume hierarchy (BVH). Only the visible chunks at the appropriate resolution are streamed and rendered, allowing users to navigate photogrammetry models containing billions of points and triangles smoothly.