Verschiedene Plattformen, verschiedene Schicksale: Ein Kompressions-Auswahlleitfaden
Die vorherigen vier Artikel behandelten die Werkzeuge der Vertex- und Texturkompression. Aber zu wissen, wie man die Werkzeuge benutzt, ist das eine; welches einzusetzen und in welchem Szenario ist eine andere. Dieser Artikel beantwortet das – und zielt darauf, dass Sie sofort entscheiden können, wenn Sie fertig gelesen haben.
Nach diesem Artikel sollten Sie antworten können: Auf welcher Plattform läuft mein Projekt, ist der First-Paint-Flaschenhals Download oder VRAM, und welches Schema sollen Texturen bzw. Vertices jeweils nutzen.
Kurs setzen: szenariengetrieben, nicht werkzeuggetrieben
Der ganze Artikel hat ein Kernprinzip, das die Serie immer wieder betont:
Es gibt kein „bestes" Kompressionsschema – nur das „zum Szenario am besten passende".
Drei Variablen, die die Wahl treiben:
- Plattform/Gerät: Desktop-PC, Mobil-Browser, VR-Headset, Mini Program – radikal unterschiedliche Fähigkeiten
- Nutzung: einmalige Darstellung (E-Commerce-Produktseite) oder langes Eintauchen (VR-Spiel)
- Primärer Flaschenhals: langsamer Download, unzureichender VRAM oder Decode, das den First Paint blockiert
Den Flaschenhals zuerst durchdenken, dann zurückkommen und Werkzeuge wählen. Die Matrix unten friert dieses Denken ein.
Kern-Entscheidungsmatrix: Plattform × empfohlenes Schema
Das ist die wichtigste Tabelle des Artikels. Nach Plattform gibt sie das empfohlene Schema für Textur und Vertex samt Gründen.
| Plattform / Szenario | Textur-Schema | Vertex-Schema | Haupt-Flaschenhals | Schlüssel-Grund |
|---|---|---|---|---|
| Desktop-Web (PC-Browser) | KTX2 oder WebP | MeshOpt / Quantisierung | Download-Geschwindigkeit | VRAM üppig; Fokus auf kleine Dateien, schnelles Laden |
| Mobil-Web (Handy-Browser) | KTX2 (Pflicht) | MeshOpt | VRAM | Handy-VRAM ist knapp; Texturen müssen blockkomprimiert sein |
| WebXR / VR-Headset | KTX2 (Pflicht) | MeshOpt + LOD | VRAM + Framerate | VRAM-Sprengung crash; Framedrop verursacht Übelkeit |
| WeChat Mini Program | KTX2 / WebP | MeshOpt / reine Quant. | Paket + Kompatibilität | Paketgröße begrenzt; schwere Decoder vermeiden |
| E-Commerce-Produkt-Demo | WebP (leicht) / KTX2 (präzise) | MeshOpt | First-Paint-Geschw. | Verlangt sofortiges Öffnen; Größe gegen Geschwindigkeit |
| Große Szenen / Digitaler Zwilling | KTX2 (Pflicht) | MeshOpt + Draco + LOD | VRAM + Draw-Calls | Viele Texturen, große Modelle; auf allen Ebenen komprimieren |
Einige Urteile, die sich merken lohnen:
- Sobald VRAM der Flaschenhals ist, ist KTX2 Pflicht (Mobil, VR, große Szenen)
- Download ist der Flaschenhals und VRAM üppig → WebP reicht (Desktop, E-Commerce)
- Für paketempfindliche Umgebungen wie Mini Programs MeshOpt über Draco bevorzugen – kleiner Decoder, bessere Kompatibilität
- Draco nur bei sehr großen Modellen erwägen; für die allermeisten klein-mittel Modelle ist MeshOpt ausgewogener
Texturformate über alle Dimensionen verglichen
„KTX2 verwenden" allein reicht nicht. Für die Texturformate alle Dimensionen ausbreiten:
| Format | Dateigröße | VRAM-Nutzung | Upload-Geschw. | Kompatibilität | Qualität | Einsatz |
|---|---|---|---|---|---|---|
| PNG | Groß | Groß (nach Dekomp.) | Langsam | Sehr breit | Verlustfrei | Exakte Werte/Alpha nötig oder Legacy-Fallback |
| JPG | Winzig | Groß (nach Dekomp.) | Langsam | Sehr breit | Verlustbehaftet | Farb-Maps, netzwerkfirst |
| WebP | Sehr klein | Groß (nach Dekomp.) | Langsam | Ziemlich breit | Hoch | Desktop-Web, Download-Geschwindigkeit |
| AVIF | Noch kleiner | Groß (nach Dekomp.) | Langsam | Fortschreitend | Hoch | Neue Plattformen, extreme Kompression |
| KTX2 (ETC1S) | Klein | Winzig | Schnell | Transcode nötig | Mittel (Farbe ok) | Farb-Maps, Mobil/VR |
| KTX2 (UASTC) | Mittel | Klein | Schnell | Transcode nötig | Hoch | Normal/Daten-Maps |
Beachten Sie die ersten drei Zeilen (PNG/JPG/WebP/AVIF) mit VRAM „groß" – egal wie klein auf der Festplatte, im VRAM dekomprimieren alle zu Rohpixeln. Das ist die fundamentale Grenze traditioneller Formate.
Eine Mischstrategie ist verbreitet: Schlüssel-Farb-Maps per KTX2 für den VRAM; sekundäre Maps (z. B. ein kleines emissive) per WebP für Bequemlichkeit. Sie müssen nicht alles auf KTX2 setzen; nach Flaschenhals zuteilen.
Entscheidungs-Flussdiagramm: Schritt für Schritt wählen
Die Matrix ist das Ergebnis; das Flussdiagramm zeigt, wie man dahin gelangt.
Wo läuft Ihr Projekt?
│
├─ Desktop-Web (üppiger VRAM)
│ └─ First Paint langsam?
│ ├─ Ja → WebP (oder AVIF) + MeshOpt [Download-Geschwindigkeit]
│ └─ Nein, aber viele Modelle → KTX2 + MeshOpt [Puffer für die Zukunft]
│
├─ Mobil-Web / VR / große Szenen (knapper VRAM)
│ └─ Texturen zwingend KTX2 (Farbe ETC1S, Daten UASTC)
│ └─ Vertices super-dicht?
│ ├─ Ja → + Draco [Max-Verhältnis, langsames Decode tolerierbar]
│ └─ Nein → + MeshOpt [ausgewogen]
│
└─ Mini Program / eingeschränkte Laufzeit
└─ Paketempfindlich?
├─ Ja → reine Quantisierung oder MeshOpt + WebP [null/kleiner Decoder]
└─ Ok → MeshOpt + KTX2 [Standard-Kombo]
Vertex- vs. Texturkompression: wohin investieren
Häufige Frage: Budget begrenzt, was zuerst optimieren? Auf die Modellzusammensetzung schauen:
| Modellmerkmal | Investitionsschwerpunkt | Grund |
|---|---|---|
| PBR-Charakter/Produkt (viele Maps) | Texturkompression | Texturen 80 %+; niedrige Vertex-ROI |
| CAD/Scan-Modell (super-dichte Vertices, wenige Maps) | Vertex-Kompression | Vertices sind der Hauptanteil |
| Animationscharakter (Skelett + Skinning) | In beides, aber jenseits Draco Vertex-priorisiert | Animationsdaten kosten auch; Draco schwach bei Animation |
| Gebäude/Szene (groß, mittelgroße Maps) | Textur + LOD | Texturen sparen VRAM; LOD spart Draw-Calls |
Eine grobe Rendite-Rangliste: Textur-KTX2 > Vertex-MeshOpt/Quantisierung > Geometrie-Vereinfachung (LOD) > Vertex-Draco. Das Renditestarke zuerst.
Mischstrategie: Schlüssel-Maps KTX2, sekundäre WebP
Nicht jede Map ist KTX2-komprimierungswürdig. Ein typisches PBR-Material hat 5-6 Maps; alle auf KTX2 zu setzen, bedeutet viel Engineering und ist manchmal unnötig.
Praktische Aufteilung:
- Pflicht-KTX2: albedo (groß, Farbe), normal (präzisionsempfindlich), roughness/metallic (beeinflussen Beleuchtung)
- WebP/JPG möglich: emissive (meist klein), AO (mittelniederfrequent), Detail-Normale (falls vorhanden)
Kriterium: Ist die Map groß, hochfrequent detailliert, wird sie häufig gesampelt? Alle drei → KTX2; keiner → traditionelles Format ist einfacher.
Automatisierte Auswahl: gltf-transform macht es in einem Abwasch
Der optimize-Befehl von gltf-transform ist die Silberkugel für die meisten Szenarien – er erkennt Texturtypen automatisch, komprimiert Texturen nach empfohlener Strategie und behandelt optional Vertices.
# Installieren
npm install -g @gltf-transform/cli
# Standard-Optimierung: Textur-KTX2 + Vertex-MeshOpt + Dedup
gltf-transform optimize model.glb model-optimized.glb \
--texture-compress basisu \
--meshopt
Parameter-Referenz:
| Parameter | Wirkung | Standard |
|---|---|---|
--texture-compress basisu | Texturen zu KTX2 komprimieren (auto ETC1S/UASTC) | Aus |
--meshopt | MeshOpt-Vertex-Kompression aktivieren | Aus |
--simplify | Geometrie-Vereinfachung (reduziert Vertices, verlustbehaftet) | Aus |
--weld | Doppelte Vertices verschmelzen | An |
--prune | Ungenutzte Knoten/Materialien entfernen | An |
Eine „starke Kompression"-Kombo für Mobil:
gltf-transform optimize model.glb model-mobile.glb \
--texture-compress basisu \
--meshopt \
--simplify --simplify-ratio 0.5 \
--prune --weld
Eine „sanfte" Desktop-Kombo (Detail bewahren, nur Texturen und Vertices komprimieren):
gltf-transform optimize model.glb model-desktop.glb \
--texture-compress webp \
--meshopt
Als wiederverwendbares Skript verpacken
Obiges in ein Skript kapseln, das pro Plattform eine Version ausgibt:
// compress.mjs — verschiedene komprimierte Versionen je Ziel ausgeben
import { optimize } from "@gltf-transform/functions";
import { NodeIO } from "@gltf-transform/core";
import { KHRONOS_EXTENSIONS } from "@gltf-transform/extensions";
const io = new NodeIO().registerExtensions(KHRONOS_EXTENSIONS);
const targets = {
// Mobil: KTX2 + MeshOpt + Vereinfachung
mobile: { texture: "basisu", meshopt: true, simplify: 0.5 },
// VR: KTX2 + MeshOpt, keine Vereinfachung (Nahansicht in VR)
vr: { texture: "basisu", meshopt: true, simplify: null },
// Desktop: WebP + MeshOpt, sanft
desktop: { texture: "webp", meshopt: true, simplify: null },
};
const input = process.argv[2];
const doc = await io.read(input);
for (const [name, cfg] of Object.entries(targets)) {
const out = doc.clone(); // unabhängige Kopie je Ziel
await optimize(out, {
textureCompression: cfg.texture,
meshCompression: cfg.meshopt ? "meshopt" : null,
simplify: cfg.simplify != null ? { ratio: cfg.simplify } : null,
});
await io.write(`model-${name}.glb`, out);
console.log(`✓ model-${name}.glb`);
}
node compress.mjs model.glb
# Gibt model-mobile.glb / model-vr.glb / model-desktop.glb aus
Zur Laufzeit die passende Version pro Gerät laden (per UA oder WebGL-Fähigkeitserkennung unterscheiden) für das beste First-Paint-Erlebnis. Der nächste Artikel verbindet das vollständig im End-to-End-Walkthrough.
Einzeiler-Spickzettel
- VRAM ist der Flaschenhals → KTX2, keine Wahl
- Download ist der Flaschenhals, VRAM üppig → WebP/AVIF auch ok
- Empfindlich für Decoder-Größe → MeshOpt > reine Quantisierung > Draco
- Sehr große Modelle → erst dann Draco erwägen
- Unsicher →
gltf-transform optimizeeinmal laufen lassen; bei Fehler anpassen
Nächster Schritt
Der Auswahl-Rahmen steht. Der letzte Artikel schließt ab: Ausgehend von einem realen Modell den ganzen Abllauf von Blender-Export, Texturkompression, Vertex-Kompression und Engine-Laden gehen, mit einem vollständigen Automatisierungs-Skript und einem Serien-Spickzettel.