Plattform-Entscheidungen: Der Leitfaden zur Kompressionsauswahl
Die ersten vier Teile haben die Werkzeuge für Vertex- und Texturkompression vorgestellt. Aber Werkzeuge zu kennen ist eine Sache – welches man wann einsetzt, ist eine andere. Genau diese Frage beantwortet dieser Artikel – und zwar so, dass du danach direkt eine Entscheidung treffen kannst.
Nach der Lektüre solltest du beantworten können: Auf welcher Plattform läuft mein Projekt, ist der Engpass beim ersten Rendering der Download oder der Grafikspeicher, und welche Lösung passt für Texturen und Vertices?
Grundsatz: Szenario-getrieben, nicht Tool-getrieben
Der gesamte Artikel folgt einem einzigen Kernprinzip, das diese Serie immer wieder betont:
Es gibt keine „beste" Kompressionslösung, nur die Lösung, die am besten zum Szenario passt.
Drei Variablen beeinflussen die Wahl:
- Plattform/Gerät: Desktop-PC, mobiler Browser, VR-Headset, Mini-App – die Leistungsfähigkeit variiert enorm
- Nutzungsart: Einmalige Präsentation (Produktseite im E-Commerce) oder langes Eintauchen (VR-Spiel)
- Primärer Engpass: Ist der Download langsam, der Grafikspeicher knapp oder hakt das Dekodieren beim ersten Rendering?
Erst den Engpass klären, dann das Werkzeug wählen. Die folgende Matrix fasst diesen Ansatz konkret zusammen.
Kern-Entscheidungsmatrix: Plattform × Empfohlene Lösung
Das ist die wichtigste Tabelle des gesamten Artikels. Nach Plattform aufgeschlüsselt, mit Empfehlungen für Texturen und Vertices sowie Begründungen.
| Plattform / Szenario | Texturlösung | Vertexlösung | Hauptengpass | Wichtigste Begründung |
|---|---|---|---|---|
| Desktop-Web (PC-Browser) | KTX2 oder WebP | MeshOpt / Quantisierung | Downloadgeschwindigkeit | Grafikspeicher reichlich, Fokus auf kleine Dateien und schnelles Laden |
| Mobiles Web (Handy-Browser) | KTX2 (Pflicht) | MeshOpt | Grafikspeicher | Handy-Grafikspeicher knapp, Texturen müssen blockkomprimiert sein |
| WebXR / VR-Headset | KTX2 (Pflicht) | MeshOpt + LOD | Grafikspeicher + Framerate | Speicherüberlauf crasht, Frame-Drops verursachen Motion Sickness |
| WeChat Mini-App | KTX2 / WebP | MeshOpt / reine Quantisierung | Paketgröße + Kompatibilität | Paketgröße begrenzt, schwere Dekoder vermeiden |
| E-Commerce-Produktdarstellung | WebP (leicht) / KTX2 (präzise) | MeshOpt | Erst-Rendering-Geschwindigkeit | Sofortiges Laden gefordert, Volumen gegen Geschwindigkeit tauschen |
| Große Szenen / Digitaler Zwilling | KTX2 (Pflicht) | MeshOpt + Draco + LOD | Grafikspeicher + Draw Calls | Viele Texturen, große Modelle, alles muss komprimiert werden |
Ein paar Merksätze:
- Sobald der Grafikspeicher der Engpass ist, ist KTX2 Pflicht (Mobile, VR, große Szenen)
- Wenn der Download der Engpass ist und der Speicher reicht, ist WebP ausreichend (Desktop, E-Commerce)
- In paketgrößen-sensiblen Umgebungen wie Mini-Apps MeshOpt statt Draco bevorzugen – kleiner Dekoder, bessere Kompatibilität
- Draco nur bei sehr großen Modellen in Betracht ziehen – für die meisten mittleren und kleinen Modelle ist MeshOpt ausgewogener
Texturformate: Vollständiger Vergleich
Nur „KTX2 nehmen" reicht nicht. Alle Dimensionen der Texturformate im Überblick:
| Format | Dateigröße | Grafikspeicher | Upload-Geschwindigkeit | Kompatibilität | Bildqualität | Geeignete Szenarien |
|---|---|---|---|---|---|---|
| PNG | Groß | Groß (dekomprimiert) | Langsam | Sehr breit | Verlustfrei | Präzise Werte/Transparenz nötig, oder als Fallback für alte Plattformen |
| JPG | Sehr klein | Groß (dekomprimiert) | Langsam | Sehr breit | Verlustbehaftet | Farbtexturen, Netzwerk-Transfer priorisiert |
| WebP | Sehr klein | Groß (dekomprimiert) | Langsam | Relativ breit | Hoch | Desktop-Web, Downloadgeschwindigkeit im Fokus |
| AVIF | Noch kleiner | Groß (dekomprimiert) | Langsam | Progressiv | Hoch | Neue Plattformen, extreme Kompression |
| KTX2 (ETC1S) | Klein | Sehr klein | Schnell | Transkodierung nötig | Mittel (Farben reichen) | Farbtexturen, Mobile/VR |
| KTX2 (UASTC) | Mittel | Klein | Schnell | Transkodierung nötig | Hoch | Normal-/Daten-Texturen |
Beachte: Bei den ersten vier Zeilen (PNG/JPG/WebP/AVIF) ist der Grafikspeicher immer „Groß" – egal wie klein die Datei auf der Festplatte ist, im Speicher wird sie zurück in Original-Pixel dekomprimiert. Das ist die grundlegende Einschränkung traditioneller Formate.
Hybride Strategien sind üblich: Wichtige Farbtexturen als KTX2 für den Speicher, sekundäre Texturen (z. B. eine kleine Emissive-Map) als WebP für Einfachheit. Nicht alles muss KTX2 sein – nach Engpass verteilen.
Entscheidungs-Flussdiagramm: Schritt für Schritt wählen
Die Matrix ist das Ergebnis, das Flussdiagramm zeigt den Weg dorthin.
Wo läuft dein Projekt?
│
├─ Desktop-Web (Speicher reichlich)
│ └─ Ist das erste Rendering langsam?
│ ├─ Ja → WebP (oder AVIF) + MeshOpt [Downloadgeschwindigkeit im Fokus]
│ └─ Nein, aber viele Modelle → KTX2 + MeshOpt [Zukunftssicher]
│
├─ Mobiles Web / VR / Große Szenen (Speicher knapp)
│ └─ Texturen: KTX2 Pflicht (Farben ETC1S, Daten UASTC)
│ └─ Sehr dichte Vertex-Daten?
│ ├─ Ja → + Draco [Extremkompression, langsamere Dekodierung akzeptabel]
│ └─ Nein → + MeshOpt [Ausgewogen]
│
└─ Mini-App / Eingeschränkte Laufzeitumgebung
└─ Paketgröße sensibel?
├─ Ja → Reine Quantisierung oder MeshOpt + WebP [Kein/kleiner Dekoder]
└─ Okay → MeshOpt + KTX2 [Standardkombination]
Vertex- vs. Texturkompression: Wo investieren?
Häufige Frage: Budget begrenzt, was zuerst optimieren? Es hängt von der Modellzusammensetzung ab:
| Modellmerkmal | Investitionsschwerpunkt | Grund |
|---|---|---|
| PBR-Charakter/Produkt (viele Texturen) | Texturkompression | Texturen machen 80%+ aus, Vertex-Investition lohnt kaum |
| CAD-/Scan-Modelle (sehr dichte Vertices, wenige Texturen) | Vertexkompression | Vertices sind das Hauptvolumen |
| Animierte Charaktere (Skelett + Skinning) | Beides, aber Vertex vorrangig außer Draco | Animationsdaten brauchen auch Volumen, Draco unterstützt Animationen schwach |
| Architektur/Szenen (groß, mittlere Texturen) | Texturen + LOD | Texturen sparen Speicher, LOD spart Draw Calls |
Eine grobe Rendite-Reihenfolge: Textur-KTX2 > Vertex-MeshOpt/Quantisierung > Geometrie-Vereinfachung (LOD) > Vertex-Draco. Erst die hohen Renditen umsetzen.
Hybride Strategie: Wichtige Texturen KTX2, sekundäre WebP
Nicht jede Textur verdient KTX2. Ein typisches PBR-Material hat 5–6 Texturen – alle als KTX2 zu komprimieren ist aufwendig und manchmal unnötig.
Praktische Aufteilung:
- KTX2 Pflicht: Albedo (groß, Farben), Normal (präzisionssensibel), Roughness/Metallic (beeinflusst Beleuchtung)
- WebP/JPG möglich: Emissive (meist klein), AO (mittlere/niedrige Frequenzen), Detail-Normal (falls vorhanden)
Entscheidungskriterien: Ist die Textur groß, enthält sie hochfrequente Details, wird sie häufig abgetastet? Alles ja → KTX2; nichts davon → traditionelles Format reicht.
Automatisierte Auswahl: gltf-transform in einem Schritt
Der optimize-Befehl von gltf-transform ist der Alleskönner für die meisten Szenarien – er erkennt automatisch Texturtypen, komprimiert nach empfohlener Strategie und verarbeitet optional Vertices.
# Installation
npm install -g @gltf-transform/cli
# Standard-Optimierung: Texturen KTX2 + Vertices MeshOpt + Redundanz entfernen
gltf-transform optimize model.glb model-optimized.glb \
--texture-compress basisu \
--meshopt
Parameter-Erklärung:
| Parameter | Funktion | Standard |
|---|---|---|
--texture-compress basisu | Texturen als KTX2 (automatisch ETC1S/UASTC) | Aus |
--meshopt | MeshOpt-Kompression für Vertices | Aus |
--simplify | Geometrie-Vereinfachung (reduziert Vertices, verlustbehaftet) | Aus |
--weld | Doppelte Vertices zusammenführen | An |
--prune | Unbenutzte Knoten/Materialien entfernen | An |
Eine „Power-Kompression"-Kombination für Mobile:
gltf-transform optimize model.glb model-mobile.glb \
--texture-compress basisu \
--meshopt \
--simplify --simplify-ratio 0.5 \
--prune --weld
„Sanfte" Desktop-Kombination (Details erhalten, nur Texturen und Vertices komprimieren):
gltf-transform optimize model.glb model-desktop.glb \
--texture-compress webp \
--meshopt
Kein Skript schreiben wollen? Online-Kompression mit Any3D
Keine Lust, Node lokal zu installieren und Toolchains einzurichten? Any3D Online-Kompression arbeitet direkt im Browser – GLB auswählen, Parameter je nach Plattform (Mobile/Desktop/VR) visuell einstellen, das Modell verlässt den Rechner nicht (komplett lokale Verarbeitung), und mit einem Klick die komprimierte Version exportieren. Die Basis ist dieselbe wie bei gltf-transform, aber ohne Einstiegshürde. Der nächste Teil zur End-to-End-Praxis führt den kompletten Ablauf zusammen.
Ein-Satz-Merksätze
- Grafikspeicher ist der Engpass → KTX2, keine Alternative
- Download ist der Engpass, Speicher reicht → WebP/AVIF reicht auch
- Dekodergröße ist sensibel → MeshOpt > reine Quantisierung > Draco
- Sehr große Modelle → erst dann Draco in Betracht ziehen
- Unsicher →
gltf-transform optimizeeinmal ausführen, bei Fehlern nachjustieren
Nächste Schritte
Der Auswahlrahmen steht. Der letzte Teil schließt ab: Ausgehend von einem echten Modell den kompletten Ablauf von Blender-Export über Texturkompression, Vertexkompression bis zum Engine-Laden durchgehen, inklusive vollständigem Automatisierungsskript und Schnellreferenz-Tabelle der Serie.