Export a GameObject with a LOD Group attached to glb through Unity's built-in exporter or glTFast, and every LOD level below LOD0 disappears. Open the file in Blender, Godot, or a browser viewer and you're looking at the full-detail mesh only — the culled level, the mid-detail level, all of it, gone. This isn't a bug you triggered by misconfiguring something. Unity's glTF exporters don't write LOD data at all; they walk the hierarchy, find the LOD Group's active renderer, and serialize that one mesh. The rest is silently dropped.
Why the exporter throws levels away
glTF's core spec has no concept of level of detail. There's an extension for it — `KHR_lod` — that lets a node point to alternate meshes at different screen-coverage thresholds. It's been around since 2020 and it's still not something you can rely on. Neither Unity's official glTFast exporter nor UnityGLTF (the Khronos-maintained fork) ships `KHR_lod` support on export as of their current releases — check UnityGLTF's README and you'll see the extensions it does ship: `KHR_animation_pointer`, `KHR_audio`, `KHR_materials_variants`. LOD isn't on that list. The request to add it (glTFast issue #345) has been open since March 2022 with no shipped fix. On the import side, coverage is just as thin — Godot's glTF importer and UE5's Interchange pipeline both ignore `KHR_lod` nodes when they're present, so even a glb authored correctly by a tool that does write the extension won't show multiple LODs once it lands in those engines.
Practically: if your pipeline is Unity LOD Group → export → another engine, you are exporting LOD0 and nothing else, every time.
What Unity's LOD Group is actually holding onto
Open the LOD Group component in the inspector and you'll see the piece the exporter ignores: a list of LOD levels, each with a Renderers list and a Screen % slider (the culled tail past your last level shows as Culled). A typical four-level setup on a hero prop looks like LOD0 at 60%, LOD1 at 30%, LOD2 at 10%, Culled below 1% — those percentages are screen-height coverage, not distance, which is why the same LOD Group behaves consistently at different camera FOVs. None of that structure — the renderer list, the thresholds — makes it into the glb. The exporter only sees whichever renderer is enabled at export time, which is normally LOD0.
Keeping every LOD in the file
Three approaches actually work today:
Export each LOD as a separate glb. Toggle each renderer active one at a time and run the export per level, naming files `prop_lod0.glb`, `prop_lod1.glb`, `prop_lod2.glb`. This is the only method that survives re-import anywhere, because you're not depending on `KHR_lod` support at all — each file is a normal single-mesh glb.
```csharp
// Loop LOD Group levels, isolate one renderer at a time, export per level
var lods = lodGroup.GetLODs();
for (int i = 0; i < lods.Length; i++) {
foreach (var r in allRenderers) r.enabled = lods[i].renderers.Contains(r);
GLTFSceneExporter.ExportScene($"prop_lod{i}", rootTransform); // UnityGLTF API
}
```
Author `KHR_lod` manually in a post-process step if your target engine actually reads it — right now that's a short list, so verify before you invest time here. Test the resulting glb in the specific importer you're shipping to, not just a generic viewer, since viewers are more permissive than engine importers.
Skip engine LOD Groups for anything that leaves Unity. Decimate once per target tier in a DCC tool or a browser-based reducer before the model ever gets a LOD Group, and export flat meshes named by tier. BitSoul3D's 3D Studio does the poly-reduce step in-browser on your own GPU, which is useful specifically for this case — you can generate a 30%-tris pass on a downloaded glb and re-export it as its own file without touching Unity's LOD system at all.
Engine support at a glance
| Engine / tool | Reads `KHR_lod` on import | Writes `KHR_lod` on export |
|---|---|---|
| Unity (glTFast) | No | No |
| Unity (UnityGLTF) | No | No |
| Godot 4.x | No | N/A (no native glb export of LOD chains) |
| UE5 Interchange | No | N/A |
| Blender glTF I/O | No | No |
Gotchas
Texture sets have to match across your exported LOD files if you're swapping meshes at runtime — a mid-poly LOD baked against a different UV layout than LOD0 will pop visibly at the swap distance, not just lose detail. Watch collision meshes too: if a collider was parented under the LOD Group and you isolate renderers for export, make sure the collider isn't tied to a renderer that gets disabled, or physics breaks on the exported prefab equivalent. And name your per-LOD files consistently before you hand them to a teammate or an importer script — `_lod0`/`_lod1` suffixes are the de facto convention because nothing in the glb itself records which file is which tier once `KHR_lod` isn't in play.
For a concrete test case, BitSoul3D's Concept Hypercar ships at 1,954,488 triangles — high enough that you'd never use it at native density in real time. Running it through a decimation pass to build 2-3 lower tiers before it touches a LOD Group is exactly the workflow above: reduce first, tag files by tier, skip relying on the exporter to carry LOD structure for you. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships — see pricing.
If you're already fighting glTFast material output on the same project, the pink-material issue outside the Unity Editor is a related exporter gap worth checking: gltfast-glb-pink-materials-outside-unity-editor. For batching the per-LOD export step across many props at once, GPU instancing on scattered glb props covers a similar loop-and-export pattern: gpu-instancing-nothing-scattered-glb-props-urp. And if your LODs are coming from an AI generator rather than manual retopology, verify what you're actually getting first: tripo-meshy-skip-retopology-what-to-verify.
---
*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.*