Drone 3D Mesh to Chunked glTF Pipeline

Drone mapping platforms convert massive aerial datasets into web-ready 3D models through a pipeline of photogrammetric reconstruction, spatial partitioning, mesh optimization, and hierarchical file export. Because raw photogrammetry meshes of large terrains often contain tens of millions of polygons and gigabytes of 8K texture sheets, direct browser rendering is impossible. To overcome hardware and bandwidth limits, modern mapping software subdivides monolithic meshes into discrete, level-of-detail (LoD) chunks, optimizes the geometry and textures, and formats the output into standard glTF or binary GLB containers referenced by spatial indexing structures like 3D Tiles.

1. Photogrammetric Reconstruction to Monolithic Mesh

The process begins with Structure from Motion (SfM) and Multi-View Stereo (MVS) algorithms. Thousands of overlapping, georeferenced aerial images are matched via visual tie points to compute precise camera positions. The engine then builds a dense point cloud and wraps it in a continuous surface mesh—typically outputting a massive raw format such as OBJ or PLY—paired with high-resolution texture maps derived from the original drone orthophotos.

2. Spatial Subdivision and Chunking

To make the data manageable, the processing engine projects the global coordinates into a local spatial reference system (such as UTM or local Cartesian coordinates) and subdivides the continuous surface along a regular grid, quadtree, or octree.

  • Spatial Slicing: The algorithm clips vertices, edges, and triangles along defined spatial bounding boxes.
  • Seam Preservation: To prevent visible cracks or gaps between adjacent chunks during rendering, systems preserve boundary edge vertices across neighboring blocks or generate mesh "skirts"—slight vertical extensions along the perimeter that mask precision errors between adjacent tiles.

3. Level of Detail (LoD) Generation

Once partitioned into spatial chunks, each block undergoes geometric decimation. Using algorithms such as Quadric Error Metrics (QEM), the engine reduces the polygon count in stages while preserving critical topographic features, ridgelines, and sharp structural edges. This creates multiple hierarchical tiers:

  • Root/Coarse Levels: Low-poly versions of the terrain loaded when the camera is far away.
  • Leaf/Fine Levels: High-density meshes loaded only when the user zooms close to the surface.

4. Texture Atlas Repacking and Compression

Texture handling is adapted to match the chunked geometry:

  • UV Re-mapping: Texture atlases are sliced and re-baked so that each spatial chunk references only its dedicated image maps, rather than relying on a shared, global texture atlas.
  • Mipmapping and Compression: Textures are resized according to the mesh LoD and compressed into GPU-friendly formats such as KTX 2.0 with Basis Universal (UASTC or ETC1S). This allows graphics hardware to ingest textures directly into video memory without prior client-side decompression.

5. glTF/GLB Packaging and Spatial Indexing

Each individual mesh chunk and its associated material is serialized into a glTF (or binary .glb) payload:

  • Geometry Compression: Engines frequently apply Draco or EXT_meshopt_compression to reduce vertex buffer sizes, attribute streams, and index arrays.
  • Integration with 3D Tiles: While glTF defines the geometry, materials, and local transformations of the chunk itself, a master spatial index—most commonly an OGC 3D Tiles tileset.json—coordinates the files. This JSON schema outlines the bounding volumes (oriented bounding boxes or bounding spheres), geometric error thresholds, and URIs pointing to individual glTF/GLB assets.

When rendered, the client-side viewer uses camera distance and field of view to evaluate the geometric error of each bounding volume, streaming and assembling only the visible, appropriately detailed glTF chunks into a seamless, continuous 3D orthomosaic.