Your Blender export just got smaller, and your Godot project just stopped opening it. That's meshopt compression — glTF's EXT_meshopt_compression extension and its newer KHR_meshopt_compression sibling, the codec Blender's glTF exporter can now write into GLB files to shrink vertex, index, and animation buffers before any server-side gzip even runs. The catch: writing a meshopt-compressed GLB and having something read it back are two separate problems, and the gap between them changes by target. Three.js and Babylon.js decode it without complaint. Godot, Unity, and Blender's own importer do not, at least not by default.
What meshopt compression actually shrinks
Every GLB stores its geometry as raw binary buffers — one array of vertex positions, one of normals, one of UV coordinates, one of triangle indices, plus morph targets and animation curves if the mesh is rigged. Uncompressed, those buffers default to float32: precise, and larger than most game meshes need. Meshopt re-encodes each buffer type with filters suited to it — delta-encoding for indices, quantized deltas for positions and normals — which cuts the raw byte count and, more importantly, produces output that gzip or brotli can compress far harder than a naive float32 buffer would. That second pass isn't optional if you want the real size win: meshoptimizer's own documentation is explicit that its codecs are designed to be compressed further by a general-purpose compressor, not to be the final word on size by themselves.
Where meshopt compression works today
Here's what actually decodes an EXT_meshopt_compression or KHR_meshopt_compression buffer right now, checked against each project's own documentation and issue tracker rather than its release notes:
| Target | Reads meshopt-compressed GLBs? | Status |
|---|---|---|
| three.js | Yes, since r122+ | Requires calling `GLTFLoader.setMeshoptDecoder()` |
| Babylon.js | Yes, since 5.0+ | Works with no extra setup |
| Godot 4.x | No, natively | Open in godot-proposals discussion #14857; needs a third-party addon |
| Blender (import) | No | Tracked in glTF-Blender-IO issue #1460, open since 2021 |
| Unity (glTFast) | Experimental only | Needs the separate meshoptimizer-decompress package, still preview |
| Unreal Engine 5 | Undocumented | Not listed in Epic's official glTF importer docs |
Read that table twice if you're planning a pipeline around this: the tool that wrote the compressed file can't open it again.
Turning it on: Blender's exporter and gltfpack
Blender's GLB export dialog has carried a Compression panel for years, previously Draco-only; the meshopt options sit alongside it, off by default. Toggle it on, export, and compare file sizes yourself — that comparison is the only number that means anything for your specific mesh, since the ratio depends entirely on how much of the data was redundant to begin with. For the rest of that export panel, our rundown of game-ready glTF export settings covers what each option trades off.
If you want a result you can script and verify outside Blender, gltfpack — the reference command-line tool behind the codec — does the same job with flags you can drop into a build step:
```bash
# pack geometry with EXT_meshopt_compression (needs a meshopt-aware decoder)
gltfpack -i knight.glb -o knight-meshopt.glb -c
# push compression further, plus KTX2/BasisU textures
gltfpack -i knight.glb -o knight-packed.glb -cc -tc
```
Skip both flags and gltfpack still quantizes and optimizes the mesh by default, producing output any glTF loader with `KHR_mesh_quantization` support can read without a meshopt-specific decoder at all. Add `-c` or `-cc` and you're trading that broad compatibility for a smaller file only meshopt-aware loaders can open.
Reading it back in Three.js and Babylon.js
Babylon.js needs nothing extra — its glTF loader detects the extension and decodes it automatically from 5.0 onward. Three.js needs one explicit call before load, because the WASM decoder isn't wired up by default, on top of the Draco/KTX2 setup already covered in loading GLBs in Three.js:
```javascript
import { MeshoptDecoder } from 'three/addons/libs/meshopt_decoder.module.js';
const loader = new GLTFLoader();
loader.setMeshoptDecoder(MeshoptDecoder);
loader.load('knight-meshopt.glb', gltf => scene.add(gltf.scene));
```
Miss that `setMeshoptDecoder` call and the load doesn't always fail loudly — it can just come back with no geometry, which is a worse debugging session than a thrown error. Confirm the decoder is wired up before you assume the compressed export itself is broken.
The gotchas: Godot, Unity, and Blender itself
Three specific traps, roughly in the order they'll bite.
Godot developers who compress in Blender and hand the file straight to their project will watch the import fail or silently drop meshes — Godot's glTF importer doesn't speak EXT_meshopt_compression or KHR_meshopt_compression, and the request to add it, godot-proposals discussion #14857, is still open. If you want the file-size win on a Godot target today, that has to happen through a third-party addon or a different compression step, not Blender's meshopt checkbox.
Unity developers get further, then stall at "production-ready." glTFast can decode meshopt buffers, but only with the separate meshoptimizer-decompress package installed alongside it, and Unity's own package docs label it experimental — version 0.1.0-preview.7 as of this writing. Shipping on it means shipping on a preview dependency, which is a call your team should make on purpose, not by accident.
Blender users get the strangest one: export a meshopt-compressed GLB and Blender can't reopen its own file. Import support has been an open request, issue #1460, since 2021. Keep an uncompressed copy of anything you might need to reimport or hand-edit later — treat the compressed GLB as a distribution artifact, not a working file.
Unreal Engine 5's status is simply undocumented for this specific extension. Test a real export before you plan a pipeline around either answer.
What to reach for if your engine isn't ready
If your target engine is on the "no" side of that table, meshopt compression isn't the lever to pull yet — poly count and texture size are, and both work regardless of decoder support. 3D Studio runs poly reduction on your own GPU in the browser, the same technique covered in reducing GLB poly count without Blender — no export/reimport round trip, no extension the target engine has to decode.
Rigged, animation-heavy meshes make the best test case for meshopt itself, since the codec compresses animation curves along with geometry. Ornate Paladin is built for exactly that kind of test; a free account's two monthly downloads cover the evaluation, and commercial use comes with paid memberships.
Either way, export both versions and diff the file sizes before committing a pipeline to one — compression ratio depends on your specific mesh, not on a number from a release note.
---
*This post is part of the Ultimate Guide to Free 3D Game Assets — BitSoul's complete reference for formats, texturing, rigging, optimization, and engine integration.*