Warum sind 3D-Modelle so groß?
Dein Modell wird heimlich dick
Du exportierst eine GLB-Datei, 10 MB, fühlt sich okay an. Auf dem Handy geöffnet – weißer Bildschirm, Ruckeln, oder sogar ein Absturz.
Am PC läuft es, auf dem Handy explodiert es. Das liegt nicht am Code, sondern an einer nicht-intuitiven Eigenschaft von 3D-Modellen: Sie sind auf der Festplatte und im VRAM komplett unterschiedlich groß.
Ein JPG-Bild ist auf der Festplatte vielleicht nur 200 KB. Aber die GPU kennt kein JPG, sie kennt nur rohe Pixel. Bevor es in den VRAM hochgeladen wird, wird das Bild komplett dekomprimiert. Eine 2048x2048-Textur frisst nach der Dekomprimierung etwa 22 MB VRAM. Wenn du 6 Texturen verwendest (Albedo, Normal, Roughness, Metallic, AO, Emissive), braucht ein einziges Material 132 MB.
Ein Handy hat vielleicht insgesamt nur 2-4 GB VRAM – ein Modell frisst mit seinen Texturen schon 3-6 %. Und wenn 10 Modelle in der Szene sind?
Zerlegt: Wo die Größe herkommt
Ein typisches GLB-Modell besteht hauptsächlich aus drei Teilen: Vertex-Daten, Textur-Maps sowie Metadaten und Animationen.
Schauen wir uns ein reales PBR-Modell an:
| Bestandteil | Inhalt | Typischer Anteil | Erklärung |
|---|---|---|---|
| Textur-Maps | Albedo, Normal, Roughness, Metallic, AO | 70-85 % | Fast immer der Größte |
| Vertex-Daten | Position, Normal, UV, Tangent, Farbe | 10-20 % | Abhängig von Komplexität |
| Animationsdaten | Bones, Skinning, Keyframes | 0-15 % | Nur bei Animationen |
| Sonstiges | Materialdefinition, Szenenstruktur, Kamera | < 2 % | Vernachlässigbar |
Textur-Maps machen etwa 80 % aus. Oft denkst du, du musst die Vertices optimieren, aber der wahre Platzfresser sind die Texturen.
"Kleine Festplatte" ≠ "Kleiner VRAM"
Das ist vielleicht der wichtigste Punkt, um 3D-Performance zu verstehen.
PNG und JPG sind für die Netzwerkübertragung gemacht – klein auf der Festplatte, schnell geladen. Aber die GPU kann sie nicht direkt verwenden; sie müssen erst vollständig in rohe Pixel dekomprimiert werden. Die Berechnung:
VRAM-Verbrauch = Breite * Höhe * 4 Bytes (RGBA) * 1,333 (mit Mipmaps)
Eine 4096x4096-RGBA-Textur:
| Kennzahl | Wert |
|---|---|
| PNG-Dateigröße | ~8 MB |
| JPG-Dateigröße | ~1,5 MB |
| VRAM-Verbrauch (mit Mipmaps) | ~87 MB |
1,5 MB JPG werden im VRAM zu 87 MB.
Was sind Mipmaps? Die GPU erzeugt für eine Textur eine Reihe von schrittweise verkleinerten Versionen, von der Originalgröße bis 1x1 Pixel, wobei jede Stufe die Hälfte der vorherigen ist. Das macht entfernte Objekte schneller und schärfer, kostet aber etwa 33 % mehr VRAM. Fast alle 3D-Anwendungen nutzen Mipmaps, also ist dieser Overhead Standard.
PNG/JPG sind also wie Vakuumbeutel für Reisen – klein und praktisch zum Transport, aber am Zielort musst du alles wieder aufblasen. Der Download ist schneller, aber der VRAM wird kein bisschen gespart.
Was passiert, wenn der VRAM nicht reicht?
Es erscheint kein Popup mit "Nicht genug VRAM". Die Realität ist schlimmer:
- Mobile Geräte: Weißer Bildschirm oder der Browser killt den Tab komplett
- VR-Headsets: Frame-Drops. In VR ist Ruckeln nicht "etwas laggy", es verursacht Übelkeit
- Desktop: Texturen flackern, werden degradiert, Rendering wird langsamer
Ein Entwickler auf Reddit baute eine WebXR-Galerie und stopfte 60 Stereobilder in eine Quest. Anfangs lief es, dann wurde es instabil bis zum Absturz. Er verbrachte Tage mit der Codesuche und merkte schließlich, dass er nie wirklich über VRAM nachgedacht hatte – er stopfte einfach ständig JPGs in die GPU.
Zwei Wege der Kompression
3D-Modellkompression geht hauptsächlich in zwei Richtungen:
Vertex-Kompression – Speichert Vertex-Koordinaten, Normalen, UVs und andere Geometriedaten kompakter. Zum Beispiel 32-Bit-Floats durch 16-Bit-Integer ersetzen (das nennt man Quantisierung). Repräsentative Lösungen: Draco, MeshOpt, KHR_mesh_quantization.
Textur-Kompression – Hält Texturen auch im VRAM komprimiert. Die GPU dekodiert einzelne Pixel beim Sampling in Echtzeit, fast ohne Performance-Verlust. Repräsentative Lösungen: KTX2 + Basis Universal.
| Vertex-Kompression | Textur-Kompression | |
|---|---|---|
| Was wird reduziert | Geometriedaten | Texturen |
| Typischer Effekt | 50-90 % kleiner | Festplatte -50-70 %, VRAM -75 % |
| Verlustbehaftet? | Ja, Präzision sinkt | Ja, Bildqualität sinkt |
| Geeignet für | Vertex-dichte Modelle | Fast alle PBR-Modelle |
| Details | Teil 2 | Teile 3 & 4 |
Ein häufiger Irrtum: Mit Draco die Vertices zu komprimieren und zu denken, alles ist gut. Aber Texturen machen 80 % der Modellgröße aus – wenn du die Vertices halbierst, sparst du vielleicht nur 10 % insgesamt. Du musst beide Seiten angehen.
Keine Methode passt für alle Szenarien
Das ist der Kernpunkt der gesamten Serie:
Verschiedene Plattformen, Geräte und Nutzungsszenarien erfordern unterschiedliche Kompressionsstrategien.
| Szenario | Primärer Engpass | Fokus |
|---|---|---|
| Desktop-Web-Showcase | Download-Geschwindigkeit | Dateigröße |
| Mobile Browser | VRAM | Textur-Kompression |
| VR-Headsets | VRAM + Framerate | Textur-Kompression + Vertex-Vereinfachung |
| Große Szenen | VRAM + Draw Calls | Umfassende Kompression + LOD |
Jeder weitere Teil wird nicht einfach sagen "Nutze X, fertig", sondern erklärt: Für welches Szenario X geeignet ist, wann es sogar schadet, und wann du besser Y verwendest.
Nächster Schritt
Dieser Teil hat das Problem klar gemacht. Im nächsten Teil wird es praktisch – wir lernen die drei Werkzeuge der Vertex-Kompression kennen: Quantisierung, MeshOpt und Draco.