Why your GLB is still huge after simplifying

We cut a model's triangle count by 82.8% and its file got 4.7% smaller. Both numbers are from the same run, and the gap between them is the most useful thing we can tell you about optimizing a GLB for the web.

The model is a flight helmet on a wooden stand, the kind of prop a scene has several of. As published it is a multi-file glTF that packs to a 46 MB GLB carrying 94,722 triangles across six materials. Too heavy for a browser, which has to fetch all of it before anything appears.

The settings

Auto mode, at the near-lossless quality that is also the default. Auto does not take a triangle target. It searches for the smallest mesh whose measured distance from the original stays inside a tolerance, which here was 0.005 of the model's bounding diagonal. Appearance was preserved and the surface was not rebuilt, so the run had to carry the materials rather than replace them.

The alternative was to name a ratio. We did not, because a ratio is a guess about a model you have not measured yet. Six search passes took sixteen seconds in total.

• Source: 46.1 MB, 94,722 triangles, 55,392 vertices, six materials, fifteen textures.
• Result: 44.0 MB, 16,277 triangles, 11,628 vertices, six materials, fifteen textures.
• Sixteen seconds, across six search passes.

What worked

• Triangles fell from 94,722 to 16,277, a reduction of 82.8%.
• Vertices fell from 55,392 to 11,628.
• The surface moved by 0.0009 of the bounding diagonal on average, against a budget of 0.005.
• All six materials and all fifteen textures came through, matched one for one against the source.

Why the file barely shrank

The file went from 46.1 MB to 44.0 MB. That is 4.7%, next to a triangle count that fell by more than four fifths, and it is the most useful number on this page.

93% of that GLB is texture data. Six materials carry fifteen PNG images between them, and simplification does not touch a single one of them. Cutting the geometry by 83% cut 83% of the 7% that was geometry.

So the two problems are separate, and the second one is not a mesh problem. If a model is slow to download, measure what is actually in the file before optimizing the geometry. If it is slow to draw, the triangle count is usually the thing that matters, and this run is what that fix looks like.

What visibly changed

• The visor glass is opaque. The source declared KHR_materials_transmission, which the pipeline does not carry, and the run recorded a warning saying exactly that.
• Tangents were dropped. Renderers regenerate them from the UVs and normals, so the normal maps still read correctly.
• Look along the rim of the helmet and the curve is faceted where it was smooth. At the distance this prop is meant to be seen from, it is not visible.
• Hard edges defined only by split normals come back softened, because normals are recomputed from the simplified topology.

When not to push this far

• A hero asset the camera moves close to. Auto is measuring average deviation, not the one silhouette a viewer studies.
• A model that will be inspected rather than looked at, where a faceted rim is the thing being judged.
• Hard-surface models whose edges are defined by split normals rather than by geometry, which this pipeline smooths.
• Anything using material extensions you rely on. Check the run's warnings before you ship the result.