How We Shrunk a 3D Avatar by 91% Without Losing Visual Quality
From 21.4 MB to 1.89 MB: a practical look at optimising 3D characters for mobile applications.
A 3D character can look perfect and still be far too expensive for a mobile app.
We started with a 21.4 MB GLB asset containing a character, textures, skeleton, and 20 animations. After optimisation, the asset was reduced to just 1.89 MB – a 91% reduction – while preserving the character, animations, and visual appearance.
The Challenge
An initial audit revealed:
| Metric | Initial Value |
|---|---|
| File size | 21.4 MB |
| Triangles | 54,510 |
| Vertices | 31,953 |
| Textures | 2 × 4096×4096 PNG |
| Bones | 24 |
| Animations | 20 |
The biggest surprise was the textures.
Two 4K textures accounted for approximately 18.2 MB – around 85% of the entire asset.
That gave us our biggest optimisation opportunity.
1. Optimise Textures First
The first major improvement came from reducing unnecessary texture data.
We:
- Removed a redundant emissive texture.
- Reused the base-colour texture where appropriate.
- Reduced the main texture from 4096×4096 to 2048×2048.
- Removed an unnecessary alpha dependency.
- Enabled single-sided rendering for the closed character mesh.
The result:
21.4 MB → 3.22 MB
And we had not removed a single triangle yet.
2. Reduce Geometry Without Breaking Animation
The original character contained 54,510 triangles, significantly more than our mobile target.
Using Blender’s Decimate modifier, we reduced the geometry to exactly 15,000 triangles.
The vertex count dropped from 31,953 to 10,774.
But reducing polygons is only useful when the animation continues to work correctly.
We verified that:
- UV coordinates remained intact.
- Skinning data was preserved.
- Vertex groups remained valid.
- The character still deformed correctly.
This matters because a model can look fine in a rest pose and still fall apart once animation begins.
3. Test in Motion, Not Just in the Viewport
Rest-pose validation is not enough.
We tested the character in demanding poses, including squats and push-ups, and inspected the silhouette around the knees, elbows, and shoulders.
We also re-checked the final GLB to confirm that all 20 animations were still present with their original durations.
An optimisation is successful only when the asset is smaller and still behaves correctly.
4. Watch the Hidden Pipeline Assumptions
During optimisation, changing the Blender scene from 24 fps to 30 fps caused animations to play 25% faster.
The geometry was fine. The textures were fine. The problem was timing.
The solution was to restore 24 fps and document it as a pipeline requirement.
Small pipeline assumptions can create surprisingly large runtime problems.
The Final Result
| Metric | Before | After |
|---|---|---|
| File size | 21.4 MB | 1.89 MB |
| Triangles | 54,510 | 15,000 |
| Vertices | 31,953 | 10,774 |
| Textures | 2 × 4096×4096 | 1 × 2048×2048 |
| Bones | 24 | 24 |
| Animations | 20 | 20 |
The Result
91% smaller. Same character. Same animations. No visible difference.
The Key Lessons
Measure First
Analyse the exact asset that reaches the device rather than relying on the source project.
Optimise the Biggest Bottleneck First
In this case, textures accounted for most of the file size.
Set a Clear Geometry Budget
Don’t carry unnecessary polygons onto a mobile device.
Validate Animation After Every Major Change
A smaller mesh is useless if it breaks when it moves.
Keep the Optimisation Reversible
Preserve the original high-quality asset so you can create different versions for different platforms later.
Document Pipeline Assumptions
Frame rate, scale, coordinate systems, and other seemingly small settings can affect the final result.
The Bigger Picture
AI-generated 3D assets make it easier than ever to create detailed characters.
But generation and optimisation are two different problems.
An asset designed to look impressive in a preview is not automatically ready for a mobile application.
The goal isn’t simply to make a model smaller.
The goal is to find the best balance between visual quality, performance, memory usage, and application size.
In this case, that meant taking a 21.4 MB asset and turning it into a 1.89 MB production-ready asset without sacrificing the experience.
Measure. Optimise. Validate. Repeat.
FAQ
Is 15,000 triangles a universal limit?
No. It is a mobile-oriented budget. The right number depends on the device, scene complexity, and how many characters are rendered simultaneously.
Will reducing a 4K texture to 2K always reduce visual quality?
Not necessarily. The practical impact depends on how large the character appears on the target screen. Testing on the actual device is the best validation.
Can 3D asset optimisation be automated?
Much of the process can be scripted, including texture processing, mesh optimisation, and validation. Visual deformation testing is still harder to automate reliably.
