glTF Mesh Budgets: Triangles, Vertex Rows, and Scene Copies

For a glTF mesh budget, count exported triangle slots, vertex attribute rows, and scene copies separately. They answer different questions. A face target in a modeling or AI-generation tool cannot replace that inspection: our audit finds 12 triangles and 24 POSITION rows at only 8 distinct coordinates in an ordinary public cube.

Define what your budget actually counts

A file review starts with a unit and a scope. Does “10,000 faces” mean quads in the editable source, triangles in the export, or triangles across every scene copy? Does “vertices” mean distinct positions or complete attribute rows? Write down the definition before comparing variants.

Keep the requested topology, target count, export settings, and final file hash together. For an AI-generated prop, that gives you a way to compare delivered candidates without treating a generation setting as an observed result. For a hand-modeled prop, the same record catches changes introduced at export.

Count the delivery file, not only the modeling view

The Blender glTF exporter documentation explains that export triangulates quads and n-gons. It also warns that discontinuous UVs and flat-shaded edges can require split vertices. This article inspects existing GLB bytes; it does not reproduce a Blender export.[1]

For a simple all-quad surface split into two triangles per quad, 10,000 quads become 20,000 triangles. That is a conditional arithmetic example, not a measurement of an AI-generated asset. Mixed faces, edits, or export processing mean the final file must still be inspected.

In glTF, a primitive references vertex attributes such as POSITION and may reference an index accessor. For ordinary TRIANGLES mode, divide the index count by three; without indices, use the attribute count instead. Triangle strips and fans use different assembly rules, so dividing every accessor count by three is unsafe.[2]

TRIANGLES, indexed:     triangle slots = index count / 3
TRIANGLES, non-indexed: triangle slots = POSITION count / 3
TRIANGLE_STRIP or FAN:  triangle slots = element count - 2

Two real cubes: 12 triangles, 24 rows, 8 positions

We wrote a dependency-free Python inspector and ran it on the Box and BoxTextured GLBs in Khronos’s public sample repository, pinned to commit edc7c9e67c639d230715049ee31f9a96a6babbbe. It reads the container, follows buffer offsets and strides, decodes positions and normals, and counts selected-scene mesh copies. These reference files are not AI-generated test outputs.

Both files have 36 indices, one primitive, one referenced material, and one mesh copy in the default scene. At each of the eight distinct positions, the data contains three different normal values. That produces 24 distinct position-and-normal pairs. The untextured Box already has this split, so adding UVs is not the explanation for the threefold row count here.

Do not “fix” the 24 rows by welding solely on position. Identical coordinates can carry intentionally different normals or UVs. Our distinct-position count uses exact local floating-point tuples; it is a diagnostic count, not a claim about how many vertices a renderer may safely merge.[1]

The public samples are attributed to Cesium in the audit provenance. Their model licenses are CC BY 4.0, with logos and trademarks excluded; BoxTextured also lists a Cesium trademark notice. We publish measurements and links, not copies of the sample models or their texture images.[3][4]

Separate stored geometry from scene copies

A glTF mesh can be referenced by multiple nodes. Counting the mesh definition once answers a storage-oriented question; counting each selected-scene use answers a different one. The inspector reports both and uses the file’s declared default scene unless you explicitly choose another.[2]

Our original synthetic fixtures make that distinction visible. One indexed quad stored as two triangles has four POSITION rows. Referencing that mesh from two selected-scene nodes keeps the stored count at two triangles, while the scene count becomes four. The expanded row count is eight; that does not mean eight rows were allocated in a GPU buffer.

The shared-position fixture deliberately gives two primitives the same POSITION accessor and full index data. Adding their row counts gives eight, but there are only four rows in the one referenced position accessor. This is why the report labels both totals instead of calling either one simply “vertices.”

Primitive and material counts are useful inspection signals, but this script does not measure draw calls. Likewise, scene totals include copies before culling, runtime LOD selection, batching, or extra render passes. Do not turn these static counts into an FPS estimate.

Run the bounded inspector on your own export

Download inspect_glb.py and run it locally with Python 3.9 or newer. It makes no network calls and does not modify the input. The evidence links also include sample provenance, recorded results, and executable synthetic tests. Keep test-budget.py in the same folder as the inspector to reproduce those checks.

python3 inspect_glb.py asset.glb > asset-budget.json
python3 inspect_glb.py asset.glb --scene 0 > scene-0-budget.json
python3 test-budget.py

The supported input is an embedded, uncompressed GLB with FLOAT/VEC3 positions. The inspector handles ordinary indices, interleaved strides, core primitive modes, and declared EXT_mesh_gpu_instancing counts. It refuses sparse or compressed geometry, quantized positions, and unsupported required extensions rather than silently treating them as zero. It is not a complete glTF validator.

Use the report as a file-level preflight. It does not evaluate textures, memory use, skin deformation, animation, morph targets, visual quality, or engine performance. A failed inspection is a reason to examine the unsupported feature or export an inspection copy, not proof that the asset itself is invalid.

Choose a variant with an explicit acceptance record

1. 1

   Record the request and the delivered file

   Save topology mode, requested face count, variant label, export settings, and the final file hash. Keep the editable source separately.

2. 2

   Compare the same accounting scope

   Compare triangle slots, POSITION rows, shared-accessor totals, primitives, materials, and the same selected scene. Do not compare stored counts from one file with scene-expanded counts from another.

3. 3

   Review each intended LOD transition

   At your intended viewing distances, inspect silhouette changes, small holes, material boundaries, pivot alignment, and attachments. Treat this as a proposed visual acceptance test; no transition test was run here.

4. 4

   Finish in the target project

   Profile the chosen asset in its actual scene and verify usage rights and account terms before shipping. No universal triangle threshold follows from these two cube audits.

The useful outcome is a reviewable export record. Generation or modeling tools supply candidates; the final file and your project’s acceptance criteria decide which candidate belongs in the scene.