Your character's facial shape keys play back perfectly in Blender's viewport, export to glTF without a single warning, and then do nothing in Unreal Engine — or the mesh fails to import entirely while a basic test cube with the same setup works fine. The cause is almost always one checkbox: Use Sparse Accessor if Better, under the Shape Keys section of Blender's glTF export panel. It ships unchecked, but anyone who's turned it on to shrink a face rig with a few dozen shape keys has likely broken Unreal import without knowing why.
This isn't a one-off report. Blender's tracker has it logged as issue #120064: a character exported from Blender 4.0 or 4.1 with shape keys fails to import into UE5, while the same rig re-exported from Blender 3.6 or earlier comes in fine. Testing narrowed it further — a plain cube with one morph target imports correctly, an icosphere with one doesn't. Same exporter, same engine, different result depending on mesh topology. That's what makes it expensive to debug: testing your pipeline on a placeholder cube tells you nothing about whether your actual character will import.
Why the export setting exists at all
Sparse accessors are a genuine optimization. Instead of storing a full array of vertex offsets per shape key — mostly zeros, since a shape key like "eyebrow raise" only moves a handful of vertices — a sparse accessor stores just the vertices that changed. On a face rig with 30+ blend shapes for lip sync and expressions, that's a real file-size win. Blender added the option in version 4.0, and per its own manual it ships off by default because "not all viewers managed it correctly." Unreal Engine is one of those viewers — it doesn't parse sparse accessors reliably on import, so a mesh that should have working morph targets loses them, or fails to load at all, with no error pointing at the actual cause.
Worth knowing the naming triangle too: Blender calls this feature "Shape Keys," the glTF spec calls the underlying data "morph targets," and Unity's importers call the same buffers "Blend Shapes." Same data, three names, which is why searching one tool's docs for another tool's term turns up nothing.
Blender export settings have bitten pipelines before in less obvious ways — Geometry Nodes instancing has its own glTF export trap that produces empty or bloated files for a similar reason: a setting that looks like an optimization behaves differently than expected once it leaves Blender.
Where Blender hides the shape key export setting
File > Export > glTF 2.0 (.glb/.gltf), expand Animation, then Shape Keys, and confirm Use Sparse Accessor if Better is unticked. It's off by default in current Blender — both the 4.x line and 5.2 LTS ship it disabled — so if a character is failing on Unreal import, check whether it got switched on for file-size reasons, often by whoever last touched the export preset rather than the person debugging the import months later.
Scripting the export locks the setting in so it can't drift back on:
```python
import bpy
bpy.ops.export_scene.gltf(
filepath="character.glb",
export_format='GLB',
export_try_sparse_sk=False, # keep shape keys UE5-safe
export_try_omit_sparse_sk=False,
)
```
Run that from Blender's Scripting tab, or headless with `blender --background --python export.py`, and every export from that script uses the same setting — nobody has to remember to check a box six months from now.
Where each engine actually stands on sparse accessors
| Target | Sparse accessor handling | What you'll see |
|---|---|---|
| Unreal Engine 5 (5.3–5.8) | Doesn't parse them reliably | Morph targets missing or import fails, inconsistently by mesh |
| Godot 4.3+ | Full read/write support in core `GLTFDocument` | Imports and exports cleanly, nothing to configure |
| Unity via glTFast | Reads sparse accessors for morph targets | Works out of the box |
| Unity via UnityGLTF | Export support shipped well ahead of import | Blend shapes can come in empty depending on version |
| Blender 4.0–5.2 exporter | Off by default | Only breaks if someone enables it |
If a switch to Godot is on the table for other reasons, this is one less thing to worry about — its `GLTFDocument` module handles sparse accessors natively since the 4.3 cycle, unlike the bone-renaming issue that still trips up rigged imports there. And if the target is Unreal specifically, this sits alongside UE5.8 dropping the Datasmith glTF importer as another case where Unreal's glTF path is pickier than Unity's or Godot's about what it'll accept.
The gotcha that costs the most time: assets you didn't export
None of the above helps if the GLB in question wasn't exported by you. A downloaded rig, a marketplace character, or a teammate's file can already have sparse accessors baked in, and there's no import-side setting in Unreal to compensate — the fix has to happen at the source. If re-exporting isn't an option, inspect the file before assuming the rig itself is broken: open it in the glTF Validator or search the JSON chunk for a `"sparse"` key under any accessor. That five-minute check saves an afternoon of debugging materials and skeleton setup that were never the actual problem.
A quest-giver like the Elder NPC (Male) is a realistic case for running into this: eyebrows, blinks, and mouth corners each become a separate morph target, so a dialogue-ready face is exactly the asset where sparse encoding looks worth turning on. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships (pricing).
Either way, test on the actual character before trusting a pipeline. A cube with a morph target proves the exporter runs — it doesn't prove the export is safe for the mesh you're about to ship.
---
*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.*