Web optimization: Draco, KTX2, poly budgets

Optimization differs by artifact. Do not configure every decoder for every file or rely on a fixed compression ratio. Start with the selected GLB, its README, and measurements from your own target devices.

Draco geometry#

Draco reduces geometry transfer size but requires a decoder. It is commonly used by individually downloaded catalog assets, joined pack catalogs, and some prebuilds. Current low-poly individual files inside licensed pack bundles are commonly uncompressed.

A pack README headline such as "Draco-compressed glTF" describes the combined catalog GLB for that pack. The individual GLBs shipped beside it are typically uncompressed, because per-file compression overhead outweighs the saving on a small low-poly model. Check the file you actually load rather than configuring a decoder for the whole bundle.

For a Draco file:

1. copy compatible decoder files into your application;
2. serve them from a stable same-origin path such as /draco/;
3. attach DRACOLoader before loading the GLB; and
4. measure transfer and decode time on a representative mobile device.

Some pack READMEs print a public CDN decoder path in their loader snippet. Self-host the decoder instead: a third-party origin adds a connection you do not control to your critical load path. threejsassets does not provide hosted decoder or asset URLs. See setting up the Draco + KTX2 decoders.

If a file instead declares EXT_meshopt_compression, it needs a different setup: register MeshoptDecoder on the loader rather than pointing at a decoder path. No current pack ships Meshopt-compressed geometry, so treat this as a check to run on the file you loaded, not a step to configure in advance.

KTX2 textures#

KTX2/Basis textures can reduce transfer and GPU-memory cost, but only files that contain those textures need KTX2Loader. Call detectSupport(renderer) before loading them.

Current low-poly environment packs often contain no textures at all. Do not infer KTX2 support or a texture workflow from the presence of a GLB alone.

Vertex-colour assets#

A common low-poly environment model stores colour in COLOR_0 and uses a simple material. This avoids image requests and texture memory. It also means a flattened runtime model does not retain a semantic link from vertices back to palette keys.

Configurator GLBs use named materials instead, trading some material simplicity for precise runtime recolouring. See configurator packs.

Geometry and draw calls#

Use the independently placeable GLBs required by your scene. Repeated models can share loaded geometry and materials, or use instancing in your own scene when appropriate.

An optional combined catalog can reduce file count for inspection, but it is a joined model rather than a reusable scene. It does not give you independently transformable pack assets. See individual GLBs vs the combined catalog.

Measure the actual release#

Triangle targets used during asset creation are not customer guarantees. For the files you plan to ship, record:

• compressed and transferred bytes;
• decoded geometry and texture memory;
• meshes, primitives, materials, and draw calls;
• triangles visible in the busiest view;
• initial decode and render time; and
• frame time on your lowest supported device.

Optional README statistics are useful starting points, but measurements in your complete scene determine the real budget.

Quick reference#

Related#

• Asset format specification — identify the selected file profile.
• Scale, orientation & pivots — verify placement before profiling a scene.
• Web-optimizing 3D assets: the Draco + KTX2 pipeline — learn the general optimization concepts.