Export a rigged character from Blender to GLB, open it in Unity or Unreal Engine 5, and your facial expressions or cloth-jiggle blend shapes are just gone — zero morph targets on the mesh, even though they animate perfectly inside Blender. The cause: Blender's glTF exporter can't apply modifiers and preserve shape keys in the same pass, and if your export settings have Apply Modifiers on, it silently drops every shape key rather than erroring. The fix takes ten minutes once you know the shape: duplicate, apply, rejoin as shapes.
Why "Apply Modifiers" kills your shape keys
This isn't a bug that snuck into a recent build — it's a structural limitation in Blender's modifier stack. You cannot apply a modifier to a mesh that has shape keys through the normal operator, because applying a modifier changes vertex count or position per-shape, and Blender has no way to reconcile that against every shape key's own vertex data at once. The glTF exporter hits the same wall: when Apply Modifiers is checked and shape keys exist, it exports the base mesh with modifiers baked in and quietly discards the shapes.
This is documented across the Blender tracker going back years — issue #69622 (fails to export shape keys with Apply Modifiers on) and issue #73724 (exporting GLB with a modifier applied kills shape key animation) both describe the exact symptom, and neither is fixed as of Blender 5.0. A related open request, #157826, asks the exporter to at least warn instead of failing silently. Blender 5.0 did fix the equivalent FBX-path bug for skeletal deformation, but that fix didn't carry over to the glTF/GLB path — if you're exporting GLB (which you should be, for browser and most engine imports), you still hit this.
The fix: duplicate, apply, rejoin as shapes
The workaround engines have used for years — and the one the community add-ons for this automate — is to bake each shape key into its own mesh, apply modifiers to each copy individually, then merge them back as shape keys on a clean base.
- Set the shape key value to 0 (base pose), select the mesh, `Shift+D` to duplicate, then Object menu → Apply → Visual Geometry to Mesh. This gives you a modifier-free base with correct topology.
- For each shape key, set its value to 1.0 (all others to 0), duplicate the mesh again, apply modifiers the same way. You now have one modifier-free mesh per shape.
- Select all the shape duplicates, shift-select the clean base last, then Object menu → Shape Keys → Join as Shapes. Each duplicate becomes a shape key on the base.
- Delete the duplicate meshes, rename the shape keys to match your originals, and export the base mesh to GLB with Apply Modifiers left off — the modifiers are already baked into the geometry, so there's nothing left for the exporter to choke on.
For more than four or five shape keys, script it instead of clicking through each one:
```python
import bpy
def bake_modifiers_to_shape(obj, shape_name):
dup = obj.copy()
dup.data = obj.data.copy()
bpy.context.collection.objects.link(dup)
bpy.context.view_layer.objects.active = dup
for mod in dup.modifiers:
bpy.ops.object.modifier_apply(modifier=mod.name)
dup.name = shape_name
return dup
```
Run that once per shape key value with the key pinned to 1.0, collect the resulting objects, then join them onto the clean base with the same Join as Shapes operator. It's the same three-step logic the `Menithal` and `przemir` community scripts use, just without installing an add-on.
What still breaks after the fix
| Symptom | Cause | Fix |
|---|---|---|
| Shapes join but deform wrong | Duplicates made at different modifier states (e.g. Subdivision level changed between dupes) | Lock modifier settings before duplicating any shape |
| Shape key animation exports flat/zero | Driver-based shape keys (not raw keyframes) | Bake drivers to keyframes first — driven shape keys export as zero across the whole range |
| Vertices misaligned after Join as Shapes | Base and shape duplicates have different vertex counts | Never add/remove geometry (Boolean, Decimate) between duplicating shapes — only deforming modifiers (Armature, Mirror, Subdivision) are safe here |
| Extra unwanted shape keys appear | Mirror modifier applied inconsistently across duplicates | Apply Mirror on the base first, before creating any shape key duplicates, so topology is locked before you start |
| File larger than expected, shapes still missing on reimport | "Use Sparse Accessor" left on in export settings interacts badly with baked shapes on some builds | Uncheck it for character exports, leave it on for props with no shapes |
The one universal rule underneath all five rows: every duplicate has to start from geometry with identical vertex count and order. Anything that changes topology between your base and a shape duplicate breaks the join silently — no error, just a mesh that deforms into garbage.
Verifying the export actually kept your shape keys
Don't trust the exporter's success message — open the resulting GLB back up before you hand it to an engine. Re-importing into a fresh Blender scene and checking the Shape Keys panel confirms the count matches, but it won't catch topology drift between shapes. For that, load the GLB in BitSoul's 3D Studio and check the UV and tris counts against your source mesh — if the duplicate-and-apply process introduced an extra triangle somewhere, it shows up there before it shows up as a broken face in-engine. In Unity, morph targets land on `SkinnedMeshRenderer.blendShapeCount`; in UE5, they show as Morph Targets in the Skeletal Mesh asset details panel; Godot lists them under the MeshInstance3D's Blend Shapes tab. If any of those read zero after following the steps above, the most common cause is still topology drift — go back and check every duplicate started from the exact same base state.
If you're building a rigged character to test this against rather than one of your own, Elven Ranger ships with facial shape keys already set up, so you can run the duplicate-apply-join cycle without building a test rig from scratch. A free account's two monthly downloads cover evaluation; commercial use is included with paid memberships — see pricing.
This same modifier-versus-shape-key conflict is also why rigged imports break in unexpected ways when engines try to auto-generate deformation — any pipeline that applies deformation after the fact runs into the same vertex-order problem covered above. And if your export target is Unreal Engine 5 specifically, pair this with the glTF reimport fixes for UE 5.4 through 5.7 — reimporting a GLB with baked shape keys hits the same transform-reset behavior described there. For everything else that changes when you move from Blender 5.0's FBX path to glTF, the full breakdown of what breaks across Unity, Godot, and UE5 covers the rest of the export surface.
---
*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.*