When a GLB Is Too Large: Start With Textures, Not Geometry

When a GLB file is too large, look at the textures first and the geometry second. The oversized files the development team has met in 3D configurator projects were usually oversized because of textures. One more premise is easy to miss: file size and GPU footprint are two different numbers. An audit that reads file size cannot catch a texture that compresses to a few kilobytes and still fills its full resolution once decoded.

glTF is the open, interoperable transmission format for 3D assets defined by the Khronos Group (Khronos Group, 2021). GLB files belong to that format, and the texture compression and geometry compression discussed below are both extensions of it.

Why Textures Come First

A texture's weight comes from its pixel count. Cutting the edge length from 4096 to 1024 leaves one sixteenth of the pixels, and GPU memory shrinks in the same proportion. For a batch of 14 body-color textures, dropping to 1024 took GPU usage from about 160 MB to about 10 MB. Of those 14, 12 were solid colors from the start. The other 2 were two-color textures, and scaling those two down and back up to full resolution produced a difference of 0, so the image lost nothing.

Reducing the resolution of a solid-color texture costs nothing in image quality, so 3D model slimming starts with the textures. The order runs as follows.

1. Decode each texture at full resolution and compute the per-channel standard deviation to find the solid-color ones.
2. Shrink solid-color textures to 4×4 and convert the rest to KTX2.
3. After compression, decode the files back and compare the results with the original values, across the full set.
4. Only then look at the geometry, meaning the choice of compression format.

File Size and GPU Footprint Are Different Numbers

The file size of a compressed texture depends on the content of the image and the compression method. The memory a texture occupies on the GPU depends on its resolution. The two do not move together, so a solid-color texture can be the smallest file and the largest waste at once.

The development team once worked on a batch of models in which solid-color materials were exported as 2048² textures, with the same image repeated across 8 GLB files. Compressed, that image came to only about 1 KB, so no audit based on file size would flag it. Across the 8 GLB files, though, it wasted about 43 MB of GPU memory.

The judging quantity therefore cannot be file size. It has to be the standard deviation after decoding. The method is to decode the texture at full resolution and compute the standard deviation per channel, alpha included. A standard deviation of 0 means a solid color: shrink it to 4×4 and the image does not change. The reverse also holds, since a small file does not mean a texture can be shrunk. One decal texture was only about 110 KB, yet its standard deviation was in the tens. It is a real image and has to stay as it is.

One pitfall sits in the decoding step: read only the RGBA32 output from basisu. The RGBA4444 copy quantizes 18 to 17, so a solid color comes out one step off across the whole image.

When a texture is edited in place, the geometry must not be touched. The method works at the byte level: the new image is written back into the original bufferView, only the length is changed, the file size stays the same, and every other byte is left alone. Reading and writing the whole file through a graphics library re-encodes the geometry. After that treatment, three GLB files grew to about 1.4 to 2.9 times the original size.

LIDROP's 3D configurator puts this test into the release process. Once a texture is confirmed to be a solid color, it is shrunk to 4×4, the image does not change, and the first screen of each vehicle uses about 16 MB less GPU memory.

What to Compress Textures Into

Textures that carry real content are compressed into KTX2 with Basis Universal. The KTX v2 container with Basis Universal supercompression ships the texture in a universal format, and the engine then transcodes it into a block-compressed format that the platform supports (Callow et al., 2020). After transcoding, GPU footprint is still set by resolution, so download size and GPU footprint have to be measured separately.

The MDN documentation lists texture memory as a category of its own, with advice that includes allocating only the mipmap levels that are needed and using GPU-compressed formats (MDN Web Docs, 2026).

Basis Universal offers two encodings: ETC1S at a low bit rate and UASTC at high quality. ETC1S produces small files, but the colors of individual textures can be pulled toward gray. Re-encoding the same source with UASTC restores the colors, at a cost of only about 27 to 29 KB per texture. Any texture with transparency always goes to UASTC, because ETC1S encodes alpha as a separate slice and the edges of cutouts break apart.

Geometry in One Paragraph

Geometry has two compression specifications of its own: Draco (Zhang et al., 2013–2017) and meshopt, which is built around fast decoding (Kapoulkine et al., EXT_meshopt_compression).

The choice between the two flips with network speed: below about 46 Mbps, Draco is faster, and above it, meshopt is faster. The full comparison is in web 3D performance engineering and is not repeated here.

Parts That Cannot Be Compressed: Skinned Meshes

Skinned meshes, which deform with a skeleton, cannot be compressed by force. Quantization replaces the 32-bit floating-point numbers commonly used for vertex attributes with smaller component types, trading precision for memory and bandwidth (Kapoulkine et al., 2018–2020). If a file from the modeling side is already compressed and the pipeline compresses it again at the default bit depth, that is double quantization. Normals are pushed onto a different set of grid points, and the skinned part visibly deforms, as if it were not bound to the skeleton.

The handling is that skinned parts never go through a second quantization. The original file is served as is, and the compression script excludes such parts. Verification also cannot rely on the bounding box of the mesh, which reflects the flattened bind pose. The world coordinates of the bones have to be measured instead.

Verify Every Compressed File

Verifying a conversion means decoding the compressed file back and comparing the result with the original values, and doing so for the full set. When colors look gray after compression, compare the source with the decoded values first, and do not blame the asset first.

A common case: body-color textures converted to a GPU-compressed format can look gray, and the instinct is to judge the asset broken and ask the modeler for a new export. Decoding the source image and the compressed file at full resolution and comparing average colors shows that ETC1S has pulled the endpoints of individual textures toward gray. Re-encoding the same source with UASTC restored the colors. The other colors in the same batch were completely fine with ETC1S, so the effect appears texture by texture.

• Decode in a clean, separate folder and take the largest mip level. Grabbing files by filename glob can pull the wrong level and produce false numbers.
• The decompression command emits several variants. Feeding in the alpha one makes a whole set of colors check out as white-gray.

Do not sample: checking only a handful of textures can miss the one with the problem. A full comparison is only a loop, so there is no reason to sample.

Specification validation is a separate check. glTF-Validator checks JSON, GLB, buffers and textures against the glTF 2.0 specification, and comes as a browser version, a command-line tool and an npm package (Khronos Group, glTF-Validator). A validator answers whether the file conforms to the specification. Whether the colors drifted has to be checked against the source image.

A shipped file also has to be reproducible from its source: each file records its source, output and parameters, and nothing is copied straight into production. Before recompressing, compare the material flags of the live version against the original file. Recompressing from the original washes out blend modes that had been fixed by hand. The item-by-item elimination used at intake is covered in 3D model intake acceptance.

Self-Host the Decoders, Skip the Overseas CDN

The Draco and Basis decoders load from a public CDN by default. On restricted networks or in regions where that CDN is blocked, the decoders cannot be fetched and the 3D content fails to load at all. Two projects use self-hosted decoders, kept on servers the projects control, with no remaining dependency on an overseas CDN.

When This Does Not Fit

• The texture is a real image: its standard deviation is high, so it cannot be shrunk to 4×4, and only the trade-off between compression format and resolution remains, decided texture by texture by looking at the image.
• Only a compressed file exists and the original from the modeling side does not: a skinned part deforms if it is compressed again, so obtain the original first.
• Textures turn out to be a small share once measured: the problem is in the geometry, so read the process and format choices in web 3D performance engineering instead.
• File size and GPU footprint are already within the budget of the target device: there is no need to process anything just to make it smaller, and every extra step adds one more thing to verify.

Next Step: What to Prepare

To decide where to start with a given GLB, prepare three things: the GLB to be shipped together with the original file from the modeling side, the target devices and network conditions, and whether first-load download size or phone memory matters more right now. When aligning specifications with a modeling vendor, the asset creation guidelines that Khronos defines for e-commerce product 3D content are a useful reference (Khronos Group 3D Commerce, 2025); this article does not cite the modeling details. Once those are ready, contact the development team to discuss.