Von Blender bis Live: End-to-End-Komprimierung in der Praxis
Die Serie ist fast durch – Tools, Prinzipien, Auswahlkriterien, alles besprochen. In diesem letzten Beitrag setzen wir alles zu einer lauffähigen Pipeline zusammen: Wir starten mit einem echten Blender-Modell, komprimieren Schritt für Schritt, protokollieren bei jedem Schritt Dateigröße, VRAM und Ladezeit – und schauen am Ende, ob aus dem 50-MB-Brocken ein 5-MB-Schlankmacher wird, der auf dem Smartphone sofort lädt.
Zielgruppe: Alle, die die ersten 5 Teile gelesen haben und jetzt wirklich loslegen wollen. Dieser Beitrag enthält keine neuen Konzepte, nur kopierbare Workflows, Befehle und Skripte.
Ausgangspunkt: Ein echtes PBR-Modell
Wir nehmen ein typisches E-Commerce-Produktmodell als Beispiel: ein hochauflösendes Produktmodell mit vollständigen PBR-Texturen.
| Ausgangskennzahl | Wert |
|---|---|
| Blender-Quelldatei | ~120 MB (inkl. nicht exportierter High-Poly-Modelle) |
| Export als GLB (float32 + PNG) | ~50 MB |
| Vertexanzahl | ca. 180.000 |
| Texturen | 6 × 4096×4096 (Albedo, Normal, Roughness, Metallic, AO, Emissive) |
| VRAM-Auslastung (alle 6 dekomprimiert) | ~520 MB |
| Ziel | Datei ≤ 5 MB, VRAM kontrollierbar, sofortiges Laden auf Mobilgeräten |
50 MB Datei, 520 MB VRAM – dieses Modell würde jedes Mobilgerät in die Knie zwingen. Gehen wir es Schritt für Schritt an.
Schritt 0: Korrekt aus Blender exportieren
Der erste Engpass bei der Komprimierung ist eigentlich der Export – viele verlieren hier schon unnötig Blut.
Die entscheidenden Einstellungen beim glTF-Export aus Blender:
- Format:
glTF Binary (.glb)(Einzeldatei, einfach zu übertragen) - Geometrie:
NormalsundTangentsaktivieren (für PBR-Normalmaps erforderlich) - UVs: Sicherstellen, dass sie exportiert werden (standardmäßig aktiv)
- Texturen:
AutomaticoderJPEG(Das Format hier ist egal, wir komprimieren später neu – Hauptsache, sie werden exportiert) - Komprimierung: Blenders eigene Mesh-Komprimierung nicht aktivieren – wir verwenden dafür professionellere Tools
- Transformation:
+Y Up(glTF-Standard) - Daten: Nur das Nötigste exportieren (Animationen, Kameras, Lichter weglassen, wenn nicht gebraucht – spart Volumen)
Der exportierte model.glb: 50 MB, 6 PNG-Texturen, float32-Vertices. Das ist unsere Baseline.
Erster häufiger Stolperstein: Blender exportiert standardmäßig ungenutzte Meshes und versteckte Helfer-Objekte mit. Vor dem Export
Datei > Bereinigen > Verwaiste Daten löschenausführen und in der Outliner-Ansicht nur die zu exportierenden Objekte auswählen.
Die End-to-End-Pipeline im Überblick
Hier die komplette Pipeline als Übersicht:
Blender-Quelldatei
│ Export als .glb (float32 + PNG) 50 MB
▼
[1] Redundanz entfernen + doppelte Vertices verschweißen (gltf-transform) ~45 MB
│
[2] Vertex-Komprimierung: MeshOpt (gltfpack / gltf-transform) ~30 MB
│
[3] Textur-Komprimierung: PNG → KTX2 (ETC1S/UASTC) ~6 MB
│
[4] (Optional) Geometrie-Simplifizierung für LOD (simplify) ~4-5 MB
▼
Finales model-final.glb ~5 MB
│
Engine-Loading (Three.js / Babylon.js) → Runtime-Transkodierung → Live
Die Zahlen für jeden Schritt werden in der Tabelle unten live verfolgt.
Toolchain: Welche Tools wählen?
Es gibt mehrere Komprimierungswerkzeuge – hier ein Vergleich, damit du die richtige Wahl triffst:
| Tool | Stärken | Schwächen | Geeignet für |
|---|---|---|---|
| gltf-transform | Allrounder, Texturen + Vertices, API-basiert, scriptbar | Extreme Kompressionsraten nicht ganz auf Spezialisten-Niveau | Empfohlener Hauptakteur, die meisten Szenarien |
| gltfpack | Vertex-Komprimierungs-Profi, natives MeshOpt | Schwache Textur-Komprimierung | Vertex-lastige Modelle, feine MeshOpt-Steuerung |
| toktx | Professionellste Textur-Komprimierung, volle Parameterkontrolle | Nur Texturen, kein komplettes Modell | Feinabstimmung einzelner Texturen |
| gltf-pipeline | Etabliert, unterstützt Draco | Weniger aktiv gepflegt, wenige Funktionen | Bestehende Draco-Altprojekte |
| Online-Tools (gltf.report) | Keine Installation nötig | Nicht für Automatisierung/Massenverarbeitung | Experimente, Einmalaufgaben |
Empfohlener Hauptpfad: gltf-transform für den gesamten Workflow, bei Bedarf gltfpack für Vertices und toktx für einzelne Texturen. Alle folgenden Schritte basieren auf gltf-transform.
Schritt 1: Redundanz entfernen + Vertices verschweißen
Modelle enthalten oft doppelte Vertices, ungenutzte Nodes und Materialien. Zuerst aufräumen.
gltf-transform optimize model.glb step1.glb --weld --prune
| Phase | Dateigröße | VRAM | Änderung |
|---|---|---|---|
| Baseline | 50 MB | ~520 MB | — |
| Schritt 1: Aufräumen | 45 MB | ~520 MB | -5 MB (VRAM unverändert, Texturen noch da) |
Der VRAM bleibt fast gleich – das ist erwartbar: Aufräumen spart vor allem Vertices und Struktur, Texturen sind der VRAM-Fresser.
Schritt 2: Vertex-Komprimierung mit MeshOpt
gltf-transform optimize step1.glb step2.glb --meshopt --weld --prune
--meshopt quantisiert Vertices auf 16 Bit und kodiert sie verlustfrei mit MeshOpt, inklusive der EXT_meshopt_compression-Extension.
| Phase | Dateigröße | VRAM | Änderung |
|---|---|---|---|
| Schritt 1 | 45 MB | ~520 MB | — |
| Schritt 2 + MeshOpt | 30 MB | ~520 MB | -15 MB (Vertex-Anteil) |
VRAM immer noch ~520 MB? Richtig – weil Vertices nur einen kleinen Teil des VRAM ausmachen (10–20 %). Vertex-Einsparungen wirken sich kaum auf den VRAM aus. Der wahre VRAM-Gigant sind die Texturen – das lösen wir im nächsten Schritt.
Schritt 3: Textur-Komprimierung PNG → KTX2
Dieser Schritt ist der König der Effizienz.
gltf-transform optimize step2.glb step3.glb \
--texture-compress basisu \
--meshopt --weld --prune
--texture-compress basisu erkennt automatisch den Texturtyp: Farbtexturen (Albedo, Emissive) werden mit ETC1S kodiert, Datentexturen (Normal, Roughness, Metallic, AO) mit UASTC.
| Phase | Dateigröße | VRAM | Änderung |
|---|---|---|---|
| Schritt 2 | 30 MB | ~520 MB | — |
| Schritt 3 + KTX2 | 6 MB | ~70 MB | -24 MB Datei / -450 MB VRAM |
Dieser Schritt ist der Wendepunkt der gesamten Pipeline:
- Datei fällt von 30 MB auf 6 MB
- VRAM fällt von 520 MB auf ca. 70 MB – weil die 6 4096er-Texturen von „dekomprimierten Rohpixeln" auf Block-Komprimierung umgestellt werden, von ~87 MB auf ~11–14 MB pro Textur
Der VRAM sinkt um eine Größenordnung – das ist der entscheidende Faktor für Mobile-Tauglichkeit.
Schritt 4: (Optional) Geometrie-Simplifizierung
Wenn es noch kleiner sein soll und die Szene eine geringere Vertex-Präzision erlaubt, kann man die Geometrie vereinfachen.
gltf-transform optimize step3.glb final.glb \
--texture-compress basisu \
--meshopt \
--simplify --simplify-ratio 0.5 \
--weld --prune
--simplify-ratio 0.5 bedeutet: ca. 50 % der Vertices bleiben erhalten.
| Phase | Dateigröße | VRAM | Änderung |
|---|---|---|---|
| Schritt 3 | 6 MB | ~70 MB | — |
| Schritt 4 + Simplify 0.5 | 4,5 MB | ~70 MB | -1,5 MB (VRAM fast gleich) |
Simplifizierung spart vor allem Dateigröße, der VRAM bleibt nahezu unverändert. Der Preis: weniger Details – bei Nahaufnahmen sichtbar. Für E-Commerce-Produktseiten ist starke Vereinfachung meist nicht empfehlenswert, für Architektur/Großszenen dagegen ideal.
Gesamtübersicht der Effekte
Alle vier Schritte im Überblick (basierend auf dem Beispielmodell, Zahlen dienen der Veranschaulichung der Größenordnungen):
| Schritt | Dateigröße | VRAM | Kumulierte Reduktion |
|---|---|---|---|
| Baseline (float32 + PNG) | 50 MB | ~520 MB | — |
| + Aufräumen & Verschweißen | 45 MB | ~520 MB | -10 % |
| + MeshOpt-Vertices | 30 MB | ~520 MB | -40 % |
| + KTX2-Texturen | 6 MB | ~70 MB | -88 % Datei / -87 % VRAM |
| + Geometrie-Simplify (0.5) | 4,5 MB | ~70 MB | -91 % Datei |
Fazit: Die Textur-Komprimierung liefert den Löwenanteil bei Dateigröße und VRAM. Vertex-Komprimierung ist das i-Tüpfelchen, Textur-Komprimierung das Fundament. Das deckt sich exakt mit der Analyse aus Teil 1 – Texturen machen 80 % des Volumens aus, hier lohnt sich die Optimierung am meisten.
Die Ein-Befehl-Variante: All-in-One für Faule
Wer nicht Schritt für Schritt gehen will, kann alle Optimierungen auf einmal durchführen:
gltf-transform optimize model.glb model-final.glb \
--texture-compress basisu \
--meshopt \
--simplify --simplify-ratio 0.5 \
--weld --prune
Dieser eine Befehl = Aufräumen + Verschweißen + MeshOpt-Vertices + KTX2-Texturen + Geometrie-Simplifizierung. Für 90 % der Fälle reicht das. Die Einzelschritte dienen vor allem dem Verständnis und der Feinjustierung.
Keine Lust auf Setup? Online-Komprimierung mit Any3D
Die gltf-transform-Befehle und Skripte oben erfordern lokal Node.js, Toolchain-Setup und das Merken vieler Parameter. Any3Ds Online-Komprimierungstool macht das alles überflüssig:
- Kein Skript-Download, keine Umgebungseinrichtung – einfach die Webseite öffnen und loslegen
- Modell verlässt den Server nicht – die Verarbeitung erfolgt komplett lokal im Browser, deine Dateien bleiben auf deinem Gerät
- Visuelle Konfiguration – KTX2-Texturen, MeshOpt-Vertices, Geometrie-Simplifizierung per Schieberegler, mit Live-Vorschau
- Ein Klick, mehrere Versionen – Export der komprimierten Ergebnisse für Mobile / Desktop / VR-Plattformen
Wähle eine GLB-Datei, wähle die Zielplattform, klicke – und erhalte das komprimierte Modell. Dahinter steckt dieselbe Engine wie in der Kommandozeile (gltf-transform), aber ohne Einstiegshürde und ohne Terminal.
Häufige Stolperfallen – FAQ
Modell nach Komprimierung schwarz / Texturen werden nicht angezeigt
- In 99 % der Fälle ist es der Farbraum: Farbtexturen ohne sRGB. In Three.js:
texture.colorSpace = THREE.SRGBColorSpace. - Bei toktx:
--srgbfür Farbtexturen nicht vergessen.
Normalmap nach Komprimierung mit falschem Licht
- Normalmap wurde mit ETC1S kodiert – auf UASTC umstellen.
- Normalmap ist im DirectX-Stil (Grünkanal zeigt nach unten), die Engine erwartet OpenGL-Stil – G-Kanal muss geflippt werden.
Mobile lädt ewig beim ersten Screen
- Prüfen, ob der Draco-Decoder-WASM geladen wird (zusätzlicher Request). Auf Mobile besser MeshOpt verwenden.
- KTX2-Transcoder-Pfad falsch konfiguriert – Transkodierung schlägt fehl und fällt auf CPU-Dekompression zurück.
Datei nach Komprimierung größer als vorher
- Texturen zu klein (< 128 px): KTX2 lohnt sich nicht, Block-Komprimierung hat fixe Overheads.
- Modell wurde bereits komprimiert – erneutes Komprimieren bringt nichts (oder sogar Nachteile).
Modell nach Simplifizierung mit Löchern
--simplify-ratiozu niedrig – auf 0,7–0,8 erhöhen.- Simplifizierung funktioniert gut bei harten Oberflächen (Maschinen, Architektur), bei organischen Formen (Charaktere) entstehen leicht Löcher.
KTX2 lädt in manchen Browsern nicht
- Ältere Safari-/WebView-Versionen unterstützen es nicht. PNG/WebP-Fallback bereithalten oder das
fallback-Feld derKHR_texture_basisu-Extension für Ersatztexturen nutzen.
Spickzettel für die Serie
Die Essenz aller 6 Teile in einer Tabelle – zum Speichern empfohlen.
Volumenzusammensetzung
| Bestandteil | Anteil | Optimierungstool |
|---|---|---|
| Texturen | 70–85 % | KTX2 (größter Hebel) |
| Vertex-Daten | 10–20 % | MeshOpt / Quantisierung / Draco |
| Animationsdaten | 0–15 % | Weniger Keyframes / Komprimierung |
| Sonstiges | < 2 % | Aufräumen |
VRAM-Formel
Traditionelles Format: VRAM = Breite * Höhe * 4 Byte * 1,333 (mit Mipmaps)
KTX2-Block-Komprimierung: VRAM ≈ obige Formel / 4 (ETC1S) oder / 2 (UASTC)
Vertex-Komprimierung: Auswahl
| Szenario | Empfehlung |
|---|---|
| Null Abhängigkeiten, am einfachsten | Reine Quantisierung (KHR_mesh_quantization) |
| Web-Allrounder | MeshOpt |
| Maximale Kompressionsrate, Dekodierzeit ok | Draco |
| Mini-Apps / Paketgrößen-sensitiv | Reine Quantisierung / MeshOpt, Draco vermeiden |
Textur-Komprimierung: Auswahl
| Texturtyp | Empfohlene Kodierung |
|---|---|
| Albedo / Emissive (Farbe) | KTX2 ETC1S |
| Normal / Roughness / Metallic / AO (Daten) | KTX2 UASTC |
| Desktop-Web, Fokus auf Download-Speed | WebP / AVIF |
| Kleine Texturen (< 128px) | PNG beibehalten, kein KTX2 |
Ein-Befehl-Vorlage
# Gesamte Pipeline (Textur + Vertex + Simplify)
gltf-transform optimize model.glb model-final.glb \
--texture-compress basisu --meshopt \
--simplify --simplify-ratio 0.5 --weld --prune
Plattform-Spickzettel
| Plattform | Textur | Vertices |
|---|---|---|
| Desktop Web | WebP / KTX2 | MeshOpt |
| Mobile Web | KTX2 PFLICHT | MeshOpt |
| VR | KTX2 PFLICHT | MeshOpt + LOD |
| Mini-Apps | KTX2 / WebP | MeshOpt / Quantisierung |
| Große Szenen | KTX2 PFLICHT | MeshOpt + Draco + LOD |
Serienrückblick
In sechs Teilen haben wir die gesamte Kette durchlaufen:
- Warum 3D-Modelle so groß sind: Zusammensetzung und VRAM-Wahrheit verstehen
- Drei Methoden zur Vertex-Kompression: Quantisierung, MeshOpt, Draco
- Das Textur-VRAM-Problem: Warum PNG/JPG auf der GPU ineffizient sind
- KTX2 in der Praxis: ETC1S vs. UASTC, Toolchains und Engine-Integration
- Entscheidungsleitfaden: Die passende Strategie für jede Plattform
- Dieser Leitfaden: End-to-End-Pipeline von Blender bis zur Auslieferung
Die Kernbotschaft: Identifiziere zuerst den Engpass (Download / VRAM / Framerate), bevor du Werkzeuge wählst. Textur-Komprimierung bringt den größten Hebel, Vertex-Komprimierung rundet das Ergebnis ab.
Mit diesen Skripten und Übersichten lässt sich ein Modell reproduzierbar von 50 MB auf 5 MB und von 520 MB VRAM auf 70 MB reduzieren. Jetzt liegt es an der Umsetzung!