Static Mesh Batching with Different glTF Materials

Static mesh batching combines multiple geometries into a unified buffer to reduce draw calls and optimize rendering performance, but primitives utilizing different glTF materials severely restrict this process. When primitives do not share material properties, the rendering engine cannot submit them in a single draw call without significant pipeline reconfiguration. This article examines the core limitations encountered when batching static meshes that feature disparate glTF materials, including draw call fragmentation, pipeline state changes, texture management bottlenecks, and culling inefficiencies.

Draw Call Fragmentation

The fundamental objective of static batching is to merge geometry into a single draw call sent to the GPU. However, a standard graphics pipeline requires uniform state parameters—including shaders, textures, and blending modes—for each draw call. In glTF, each primitive points to a specific material index. If primitives reference different material definitions, the engine cannot merge them into a single command buffer without preprocessing. Consequently, the batch breaks into multiple sub-draw calls, directly defeating the primary CPU optimization that static batching is meant to achieve.

GPU Pipeline State Changes

Distinct glTF materials often dictate distinct graphics pipeline configurations. For instance, transitioning between an OPAQUE material and a BLEND or MASK material (with an alphaCutoff) requires changing the pipeline state object (PSO) or rasterizer state. Similarly, variations between standard PBR metallic-roughness and extensions like specular, transmission, or clearcoat necessitate different shader variants. Switching shaders and pipeline states mid-frame forces GPU pipeline flushes and introduces driver overhead, diminishing rendering throughput.

Texture Binding and Atlasing Limits

Materials in glTF define separate image sources for maps such as baseColorTexture, metallicRoughnessTexture, and normalTexture. A GPU can only bind a limited number of texture units per shader stage. When primitives use differing materials, they point to separate texture files. Merging these primitives into a single draw call requires either:

• Texture Atlasing: Combining separate textures into a single large texture sheet. This introduces preprocessing overhead, requires recalculating UV coordinates across vertices, and risks texture bleeding artifacts across mipmaps.
• Texture Arrays: Allocating a uniform 2D texture array. This demands that all textures share identical dimensions, bit depths, and formats, which is rarely standard in diverse glTF asset libraries.

Without automatic atlasing or texture arrays, materials cannot share shader executions, preventing geometry consolidation.

Memory Overhead and Vertex Duplication

glTF allows vertex attributes (like positions, normals, and UVs) to be referenced via sparse accessors or shared across primitives. To batch meshes with distinct materials into merged buffers, engines often must unroll, convert, and duplicate vertex data to match a common vertex format required by the most complex material in the batch. Adding padding or unused vertex attributes (such as an extra UV set or tangent vector required by only one material) inflates the vertex buffer size and consumes unnecessary VRAM and bandwidth.

Impaired Spatial and Occlusion Culling

Static batching combines the bounding boxes of individual primitives into a single aggregate bounding volume. If primitives with varied materials are scattered across a scene and combined into uniform batches based solely on material grouping, the resulting bounding boxes become artificially large and sparse. This diminishes the effectiveness of frustum and occlusion culling, forcing the GPU to process vertices and fragments that reside outside the camera's field of view or behind other occluders.