Different Platforms, Different Fates: A Guide to Choosing Compression Schemes
The previous four articles covered the tools for vertex compression and texture compression. But knowing how to use a tool is one thing; knowing which one to use and in what scenario is another. This article is here to answer that question—and to make it so you can make a decision right after reading.
After reading this, you should be able to answer: What platform is my project running on? Is the first-screen bottleneck download speed or VRAM? Which scheme should I use for textures and vertices?
First, Set the Tone: Scenario-Driven, Not Tool-Driven
The entire article follows one core principle, which has been emphasized repeatedly in this series:
There is no "best" compression scheme, only the one that best matches the scenario.
The three variables that influence the choice:
- Platform/Device: Desktop PC, mobile browser, VR headset, mini-program—capabilities vary wildly
- Usage Pattern: One-time display (e-commerce product page) vs. long immersive experience (VR game)
- Primary Bottleneck: Is it slow download speed, insufficient VRAM, or decoding time that blocks the first screen?
First figure out the bottleneck, then come back to pick the tool. The matrix below solidifies this approach.
Core Decision Matrix: Platform × Recommended Scheme
This is the most important table in the entire article. Broken down by platform, it gives recommended schemes for textures and vertices, along with the reasoning.
| Platform / Scenario | Texture Scheme | Vertex Scheme | Primary Bottleneck | Key Reason |
|---|---|---|---|---|
| Desktop Web (PC browser) | KTX2 or WebP | MeshOpt / Quantization | Download speed | VRAM is ample; focus on small file size and fast loading |
| Mobile Web (phone browser) | KTX2 (must-use) | MeshOpt | VRAM | Phone VRAM is tight; textures must use block compression |
| WebXR / VR Headset | KTX2 (must-use) | MeshOpt + LOD | VRAM + Frame rate | Running out of VRAM crashes; frame drops cause motion sickness |
| WeChat Mini Programs | KTX2 / WebP | MeshOpt / Pure Quantization | Bundle size + Compatibility | Bundle size is limited; avoid heavy decoders |
| E-commerce Product Display | WebP (light) / KTX2 (quality) | MeshOpt | First-screen speed | Must load instantly; trade file size for speed |
| Large Scenes / Digital Twins | KTX2 (must-use) | MeshOpt + Draco + LOD | VRAM + Draw calls | Many textures, large models; compress everything possible |
A few key takeaways to remember:
- Whenever VRAM is the bottleneck, KTX2 is a must-use (mobile, VR, large scenes)
- When download speed is the bottleneck and VRAM is ample, WebP is sufficient (desktop, e-commerce)
- For bundle-size-sensitive environments like mini-programs, prioritize MeshOpt over Draco—the decoder is small and compatibility is better
- Only consider Draco for very large models; for most small-to-medium models, MeshOpt is more balanced
Full Dimension Comparison of Texture Formats
Knowing "use KTX2" is not enough. Let's break down all the dimensions for each texture format:
| Format | File Size | VRAM Usage | Upload Speed | Compatibility | Quality | Use Case |
|---|---|---|---|---|---|---|
| PNG | Large | Large (decompressed) | Slow | Very broad | Lossless | When you need exact values/transparency, or fallback for older platforms |
| JPG | Very small | Large (decompressed) | Slow | Very broad | Lossy | Color maps, network transfer priority |
| WebP | Very small | Large (decompressed) | Slow | Broad | High | Desktop web, when download speed is key |
| AVIF | Even smaller | Large (decompressed) | Slow | Gradually supported | High | Newer platforms, extreme compression |
| KTX2 (ETC1S) | Small | Very small | Fast | Requires transcoding | Medium (colors adequate) | Color maps, mobile/VR |
| KTX2 (UASTC) | Medium | Small | Fast | Requires transcoding | High | Normal/data maps |
Note the first three rows (PNG/JPG/WebP/AVIF) all have "Large" VRAM usage—no matter how small the disk file is, once in VRAM it must be decompressed back to raw pixels. This is a fundamental limitation of traditional formats.
Mixed strategies are common: use KTX2 for critical color maps to save VRAM, and use WebP for secondary maps (e.g., a small emissive) for simplicity. You don't have to go all-in on KTX2; allocate based on the bottleneck.
Decision Flowchart: Step-by-Step
The matrix is the result; the flowchart shows you how to get there.
Where does your project run?
│
├─ Desktop Web (VRAM ample)
│ └─ Is first-screen slow?
│ ├─ Slow → WebP (or AVIF) + MeshOpt [focus on download speed]
│ └─ Not slow, but many models → KTX2 + MeshOpt [leave room for future]
│
├─ Mobile Web / VR / Large scenes (VRAM tight)
│ └─ Textures must use KTX2 (color: ETC1S, data: UASTC)
│ └─ Model vertices extremely dense?
│ ├─ Yes → + Draco [extreme compression, accept slow decoding]
│ └─ No → + MeshOpt [balanced]
│
└─ Mini-programs / Constrained runtime
└─ Bundle size sensitive?
├─ Sensitive → Pure quantization or MeshOpt + WebP [zero/small decoder]
└─ Tolerable → MeshOpt + KTX2 [standard combination]
Vertex Compression vs. Texture Compression: Where to Invest
People often ask: with limited budget, which should I optimize first? Look at the model composition:
| Model Characteristics | Investment Priority | Reason |
|---|---|---|
| PBR characters/products (many textures) | Texture compression | Textures account for 80%+ of size; vertices yield low returns |
| CAD/Scanned models (very dense vertices, few textures) | Vertex compression | Vertices are the main volume |
| Animated characters (skeleton+skin) | Both, but vertex priority (beyond Draco) | Animation data also takes space; Draco has weak animation support |
| Architecture/Scenes (large, moderate textures) | Texture + LOD | Textures save VRAM, LOD saves draw calls |
A rough order of returns: Texture KTX2 > Vertex MeshOpt/Quantization > Geometry Simplification (LOD) > Vertex Draco. Start with the highest returns.
Mixed Strategy: KTX2 for Key Textures, WebP for Secondary
Not all textures are worth compressing to KTX2. A typical PBR material has 5-6 maps; compressing all to KTX2 is labor-intensive and sometimes unnecessary.
Practical breakdown:
- Must KTX2: albedo (large, color), normal (precision-sensitive), roughness/metallic (affects lighting)
- Can be WebP/JPG: emissive (usually small), AO (mid-low frequency), detail normal (if any)
Judgment criteria: Is the texture large? Does it contain high-frequency detail? Will it be sampled frequently? If all three are "yes" → KTX2; if none → use traditional formats for simplicity.
Automated Selection: One-Click with gltf-transform
The optimize command in gltf-transform is the silver bullet for most scenarios—it automatically detects texture types, compresses textures per recommended strategy, and optionally processes vertices.
# Install
npm install -g @gltf-transform/cli
# Standard optimization: textures to KTX2 + vertices to MeshOpt + remove redundancy
gltf-transform optimize model.glb model-optimized.glb \
--texture-compress basisu \
--meshopt
Parameter explanation:
| Parameter | Effect | Default |
|---|---|---|
--texture-compress basisu | Compress textures to KTX2 (auto-choose ETC1S/UASTC) | Off |
--meshopt | Enable MeshOpt compression on vertices | Off |
--simplify | Simplify geometry (reduce vertices, lossy) | Off |
--weld | Merge duplicate vertices | On |
--prune | Remove unused nodes/materials | On |
A "heavy compression" combo suitable for mobile:
gltf-transform optimize model.glb model-mobile.glb \
--texture-compress basisu \
--meshopt \
--simplify --simplify-ratio 0.5 \
--prune --weld
A "gentle" desktop combo (preserve details, only compress textures and vertices):
gltf-transform optimize model.glb model-desktop.glb \
--texture-compress webp \
--meshopt
Don't want to write scripts? Use Any3D Online Compression
Don't want to install Node or set up a toolchain locally? Any3D Online Compression processes your GLB directly in the browser—select a model, tweak parameters visually for your platform (mobile/desktop/VR), and the model never leaves your machine (all processing is local). One-click export of the compressed version. Under the hood it uses the same engine as the gltf-transform above, but with zero friction. The next article in the series will tie everything together with an end-to-end practical walkthrough.
One-Liner Cheat Sheet
- VRAM is the bottleneck → KTX2, no debate
- Download is the bottleneck, VRAM is ample → WebP/AVIF is fine
- Decoder size is sensitive → MeshOpt > Pure Quantization > Draco
- Very large models → Only then consider Draco
- Unsure →
gltf-transform optimizewith one click, then adjust if wrong
What's Next
Now that you have the selection framework, the final article wraps up: starting from a real model, walk through the entire pipeline—Blender export, texture compression, vertex compression, engine loading—complete with a full automation script and a series quick-reference table.