So konvertierst du glTF in GLB (3D-Modelle als einzelne Datei)
glTF vs. GLB: Was diese beiden Formate wirklich unterscheidet
Im Grunde sind glTF und GLB dasselbe. Sie werden durch dieselbe Spezifikation der Khronos Group definiert und teilen identische Datenstrukturen, die die gleichen PBR-Materialien, Animationen und Szenenhierarchien unterstützen. Der einzige wirkliche Unterschied ist die Verpackung. Ein standardmäßiges glTF-Asset ist eine ganze Sammlung von Dateien, die zusammenbleiben müssen. Du erhältst eine für Menschen lesbare .gltf-JSON-Datei, die die Szene, Materialien und Mesh-Topologie beschreibt. Daneben findest du eine oder mehrere .bin-Dateien, die die rohen Geometriedaten enthalten – Vertex-Positionen, Normalen, UVs und so weiter. Dann gibt es noch einen Ordner mit Texturbildern, normalerweise PNGs oder JPEGs. Ein mittelmäßig komplexes Charaktermodell könnte als character.gltf, character0.bin und einem textures/-Ordner mit zehn Bildern geliefert werden. Verlierst du eine dieser Dateien, wird das Modell einfach nicht geladen. GLB hingegen ist die binäre Container-Version. Es packt das JSON, die Binärdaten und alle Texturen sauber in eine einzige .glb-Datei. Alles wird durch einen winzigen 12-Byte-Header zusammengehalten, der eine magische Zahl (0x46546C67, was „glTF“ in ASCII ist), ein Versionsfeld (derzeit 2) und die Gesamtlänge der Datei enthält. Der Rest der Datei ist nur eine Abfolge von Daten-Chunks. Das macht eine GLB-Datei komplett eigenständig. Du kannst sie per E-Mail versenden, in einen webbasierten Produktkonfigurator ziehen oder einem Kunden übergeben, ohne dir Sorgen über fehlerhafte Pfade oder fehlende Texturen machen zu müssen. Die Dateigröße liegt fast immer innerhalb von 1–3 % des ursprünglichen Bundles, du zahlst für diesen immensen Komfort also praktisch keinen Aufpreis beim Speicherplatz.
Wann du glTF in GLB konvertieren solltest (und wann nicht)
Für die finale Auslieferung und das Deployment ist GLB bei mir immer der Standard. Die Einfachheit einer einzelnen, in sich geschlossenen Datei ist einfach zu gut, um darauf zu verzichten. Aber während der aktiven Entwicklung kann es tatsächlich die klügere Wahl sein, beim mehrteiligen glTF-Format zu bleiben. Der Nutzen von GLB ist am größten, wenn du ein Modell in einem Web-Viewer wie model-viewer, Babylon.js oder Three.js einsetzt. Eine einzige Abfrage ist immer besser als eine Kaskade von Netzwerkaufrufen für jede Binärdatei und Textur. Ein 4 MB großes GLB lädt auf einer mobilen Verbindung spürbar schneller als dasselbe Modell, das in eine 120 KB .gltf, eine 2,1 MB .bin und sechs Texturen mit insgesamt 1,8 MB aufgeteilt ist. Warum? Weil jede separate Datei einen eigenen HTTP-Roundtrip erfordert. Du solltest auch zu GLB konvertieren, wenn du Modelle an Kunden oder auf Marktplätzen verteilst; Plattformen wie der Unity Asset Store, Sketchfab und Apples AR-Quick-Look-Pipeline arbeiten alle nahtlos damit. Wo glänzt also das mehrteilige glTF? Bei der Erstellung von Inhalten. Wenn ein Texture Artist an einer 2K-Roughness-Map arbeitet, kann er einfach eine neue PNG-Datei in den Texturen-Ordner ziehen und die Ansicht aktualisieren. Das ist viel schneller, als jedes Mal das gesamte Asset neu zu packen. Dieselbe Logik gilt für automatisierte Build-Systeme. Wenn deine Pipeline eine Texturkomprimierung durchführt, um KTX2- oder Basis-Universal-Varianten zu erzeugen, ist es weitaus einfacher, mit einzelnen, losen Dateien zu arbeiten, als bei jedem Build ein GLB zu entpacken und neu zu packen. Und hier ist eine wichtige Einschränkung, die du im Hinterkopf behalten solltest: GLB kann designbedingt keine externen Texturen referenzieren. Wenn dein ursprüngliches glTF clever so eingerichtet war, dass es auf Texturen auf einem CDN verweist – ein Muster zum Teilen von Texturatlanten über mehrere Modelle hinweg –, wird eine Konvertierung in GLB lokale Kopien einbetten und dieses Muster der geteilten Ressourcen durchbrechen.
So konvertierst du glTF in GLB mit CocoConvert
Das browserbasierte Tool von CocoConvert ist der einfachste Weg, ein GLB zu erhalten, da keine Softwareinstallation erforderlich ist. Der gesamte Prozess funktioniert bei Dateien unter 100 MB clientseitig, was bedeutet, dass deine wertvollen Geometrie- und Texturdaten deinen Rechner gar nicht erst verlassen. Schritt 1 – Bereite deine Dateien vor. Ein glTF-Asset ist ein Gesamtpaket, also musst du alles zusammen hochladen. Der einzige Weg dazu ist, deine .gltf-Datei, alle zugehörigen .bin-Dateien und den gesamten Texturen-Ordner in ein einziges Archiv zu zippen. Es ist entscheidend, dass die interne Ordnerstruktur intakt bleibt. Die .gltf-Datei verlässt sich auf relative Pfade wie ./textures/baseColor.png, und der Konverter benötigt diese Pfade, damit sie innerhalb der Zip-Datei korrekt sind. Schritt 2 – Öffne den Konverter. Gehe zu /convert/gltf-to-glb und klicke entweder auf den Upload-Bereich oder ziehe deine .zip-Datei einfach auf die Seite. Das Tool ist clever genug, den glTF-Einstiegspunkt automatisch zu finden. Wenn dein Zip aus irgendeinem Grund mehrere .gltf-Dateien enthält (z. B. LOD-Varianten), erscheint ein Dropdown-Menü, damit du die richtige Datei als Stamm auswählen kannst. Schritt 3 – Überprüfe die Konvertierungsoptionen. CocoConvert bietet dir ein paar Einstellungen. „Texturen einbetten“ ist standardmäßig aktiviert, was genau das ist, was du für ein echtes Single-File-GLB willst. Wenn du dies deaktivieren würdest, würde die Ausgabe auf externe Textur-URIs verweisen, was den ganzen Zweck der Konvertierung zunichtemachen würde. Die andere Option ist „Buffer zusammenführen“. Mein Rat? Lass das aktiviert. Es fügt mehrere .bin-Dateien zu einem einzigen binären Chunk zusammen, was dem Standardverhalten von GLB entspricht. Schritt 4 – Download. Das war's. Die Konvertierung dauert normalerweise zwischen 5 und 20 Sekunden, abhängig von der Anzahl der Texturen und der Gesamtdateigröße. Du erhältst eine einzelne .glb-Datei, die sofort einsatzbereit ist.
Kommandozeilen-Alternative: gltf-pipeline für automatisierte Workflows
Wenn du Dutzende von Modellen als Teil einer Build-Pipeline konvertierst, ist die Nutzung einer Web-UI für jede einzelne Datei einfach nicht praktikabel. Für jede Art von automatisiertem Workflow ist das Node.js-Tool gltf-pipeline vom Cesium-Team die zuverlässigste Open-Source-Option, die es gibt. Zuerst installierst du es global mit npm: `npm install -g gltf-pipeline`. Die Konvertierung eines einzelnen Assets ist dann unkompliziert: `gltf-pipeline -i scene.gltf -o scene.glb`. Der -i-Flag verweist auf deine Eingabe-.gltf-Datei. Im Gegensatz zu einem Web-Tool findet gltf-pipeline die zugehörigen .bin-Dateien und Texturen automatisch im selben Verzeichnis, sodass nichts gezippt werden muss. Der -b-Flag (für --binary) wird impliziert, wenn dein Ausgabedateiname auf .glb endet, was eine nette Annehmlichkeit ist. Um ein ganzes Verzeichnis stapelweise zu verarbeiten, ist eine einfache Shell-Schleife dein bester Freund: `for f in models/*.gltf; do gltf-pipeline -i "$f" -o "${f%.gltf}.glb"; done`. Der äquivalente Befehl für Windows PowerShell lautet `Get-ChildItem -Filter *.gltf | ForEach-Object { gltf-pipeline -i $_.FullName -o ($_.FullName -replace '.gltf','.glb') }`. gltf-pipeline unterstützt auch die Draco-Mesh-Komprimierung mit dem Flag --draco.compressionLevel (Werte 0–10, Standard 7). Bei jedem Modell mit einem dichten Mesh solltest du das unbedingt aktivieren. Es kann die Geometriegröße um 60–80 % reduzieren. Ein 500.000-Polygon-Scan, der unkomprimiert 18 MB groß ist, kann mit Draco Level 7 auf etwa 4 MB schrumpfen. Die etwas längere Dekodierzeit im Browser ist es fast immer wert. Die einzige große Einschränkung des Tools ist, dass es keine Texturkomprimierung (KTX2/Basis) beherrscht. Dafür benötigst du einen separaten Schritt in deiner Pipeline mit einem Tool wie toktx oder basisu, entweder bevor oder nachdem du das GLB packst.
Validiere deine GLB-Ausgabe vor dem Deployment
Überspringe diesen Schritt nicht. Ein GLB, das in einem Viewer perfekt geöffnet wird, kann in einem anderen sang- und klanglos scheitern, wenn es nicht konforme Daten enthält. Mache die Validierung zu einem Standardteil deines Prozesses, bevor du ein konvertiertes Asset auslieferst. Der glTF-Validator von Khronos ist die einzige Quelle der Wahrheit. Du kannst ihn online unter validator.khronos.org verwenden – ziehe einfach dein .glb auf die Seite. Er gibt einen strukturierten JSON-Bericht aus, der Fehler, Warnungen und andere Informationen detailliert auflistet. Fehler sind Dealbreaker. Dinge wie nicht übereinstimmende `componentType`-Angaben bei Accessoren oder Buffer-Views, die die deklarierte Buffer-Länge überschreiten, führen dazu, dass die meisten Lader die Datei sofort ablehnen. Warnungen sind weniger schwerwiegend, aber dennoch lesenswert; eine häufige wie „MESH_PRIMITIVE_UNUSED_TEXCOORD“ bedeutet nur, dass du ein UV-Set hast, das von keinem Material verwendet wird. Für automatisierte Pipelines kannst du den Validator als Node-Paket installieren: `npm install -g gltf-validator`. Führe dann `gltf-validator scene.glb --stdout > report.json` aus und leite diesen Bericht in eine CI-Prüfung. Ein Build sollte definitiv fehlschlagen, wenn die Fehlerzahl größer als null ist. Über die reine Spezifikationskonformität hinaus solltest du immer eine visuelle Prüfung in mindestens zwei verschiedenen Renderern durchführen. Ich empfehle model-viewer (modelviewer.dev) und die Babylon.js Sandbox (sandbox.babylonjs.com). Sie verwenden unterschiedliche WebGL-Implementierungen und sind hervorragend darin, subtile Materialprobleme aufzudecken. Jeder, der schon einmal mit einer Normal Map gekämpft hat, die in seinem DCC-Tool gut aussah, aber im Web mysteriöserweise invertiert war, kennt diesen Schmerz. Die glTF-Spezifikation erfordert Normalen im OpenGL-Stil (Y-Achse nach oben), aber viele Tools exportieren standardmäßig im DirectX-Stil (Y-Achse nach unten). Wenn deine Beleuchtung wie invertierte Unebenheiten aussieht, invertiere den Grünkanal deiner Normal Map und konvertiere sie erneut.
Häufige Konvertierungsfehler und wie du sie behebst
Die meisten Fehler bei der Konvertierung von glTF zu GLB sind frustrierend, haben aber zum Glück unkomplizierte Lösungen. Hier sind die Probleme, die immer wieder auftreten. Fehlende Texturen in der Ausgabe: Das ist das Problem Nummer eins. Der Übeltäter ist fast immer, dass die URI-Pfade der Texturen in der .gltf-Datei während der Konvertierung nicht aufgelöst werden konnten. Um das zu debuggen, öffne deine .gltf-Datei in einem Texteditor und finde das `images`-Array. Du wirst Einträge wie `"uri": "textures/Material_baseColor.png"` sehen. Du musst sicherstellen, dass diese Dateien an genau diesem relativen Pfad in deinem Zip-Archiv oder Arbeitsverzeichnis existieren. Denke daran, dass Pfadtrennzeichen und Groß-/Kleinschreibung auf Servern eine Rolle spielen: `Textures/BaseColor.png` ist nicht dasselbe wie `textures/baseColor.png`. Zu große Ausgabedatei: Wenn dein GLB unerwartet groß ist, liegt die Ursache fast sicher bei deinen Texturen. Ein einziges 4096×4096 RGBA-PNG kann im Speicher 64 MB unkomprimiert belegen. Obwohl PNG selbst verlustfreie Komprimierung verwendet, bettet ein GLB einfach die rohen Bytes der PNG-Datei ein. Das bedeutet, deine 12 MB große PNG-Textur fügt dem GLB 12 MB hinzu. Für die Webnutzung solltest du ernsthaft in Erwägung ziehen, Texturen auf 2048×2048 herunterzurechnen (der visuelle Unterschied ist oft vernachlässigbar) oder eine KTX2-Komprimierung anzuwenden, bevor du das GLB packst. Animationen werden nicht abgespielt: Wenn dein ursprüngliches glTF Skelettanimationen hatte, diese aber im GLB verschwunden sind, bedeutet das wahrscheinlich, dass die Animationsdaten nie enthalten waren. Einige 3D-Exporteure schreiben Animationsdaten in eine separate .bin-Datei. Wenn diese Datei bei deiner Konvertierungseingabe gefehlt hat, sind die Animationsdaten einfach weg. Die Lösung ist, aus deinem 3D-Tool neu zu exportieren, sicherzustellen, dass alle Binärdaten in eine einzige .bin-Datei geschrieben werden, und dann die Konvertierung erneut durchzuführen. CocoConvert meldet in seinem Protokoll eine Warnung, wenn es referenzierte Dateien erkennt, die es in deinem Archiv nicht finden konnte. Überprüfe immer das Protokoll, bevor du herunterlädst.
Dateigröße, Performance und was du in echten Projekten erwarten kannst
Vergessen wir die Theorie. Konkrete Erwartungen sind besser als vage Versprechungen, also hier ist, wie der Konvertierungsprozess für einige typische Assets tatsächlich aussieht. Ein einfaches Möbelmodell – ein Mesh, zwei Materialien, vier 1K-Texturen – könnte als 3,2 MB großes, mehrteiliges glTF-Bundle beginnen. Nach der Konvertierung wird daraus ein 3,1 MB großes GLB. Diese leichte Größenreduzierung ergibt sich aus der Eliminierung von Leerraum im JSON und dem Zusammenführen von Buffer-Headern. Auf einem Desktop mit schneller Verbindung wirst du keinen Unterschied in der Ladezeit bemerken. Aber auf einer 4G-Mobilverbindung wird dieses einzelne GLB 300–500 ms früher mit dem Rendern beginnen, da der Overhead mehrerer HTTP-Anfragen vermieden wird. Stell dir nun einen komplexen Charakter mit Skelettanimation, 12 Materialien und 2K-Texturen vor. Dies könnte ein 28 MB großes glTF-Bundle sein. Als reines GLB sind es etwa 27,4 MB. Wenn du Draco-Komprimierung für die Geometrie hinzufügst, könnte es auf etwa 22 MB sinken. Aber wenn du zuerst die KTX2-Basis-Universal-Texturkomprimierung anwendest, könnte das endgültige GLB nur noch 9–11 MB groß sein. CocoConvert erledigt das grundlegende Verpacken von glTF zu GLB perfekt, wendet aber derzeit weder Draco noch KTX2 an. Für diese fortgeschrittenen Optimierungen musst du Tools wie gltf-pipeline und toktx in einem separaten Schritt verwenden. Für AR-Projekte ist die Dateigröße entscheidend. Apples AR Quick Look und Googles Scene Viewer haben beide dokumentierte Limits. Apple empfiehlt, GLBs unter 20 MB zu halten, um ein zuverlässiges Laden über ein mobiles Netzwerk zu gewährleisten. Googles harte Grenze liegt bei 200 MB, aber sie empfehlen, für eine gute Performance unter 15 MB zu bleiben. Wenn dein konvertiertes GLB über diesen Grenzwerten liegt, greife nicht sofort zu Werkzeugen zur Geometrievereinfachung. Dein erster und wirkungsvollster Schritt ist fast immer die Texturkomprimierung. Die Konvertierung selbst unter /convert/gltf-to-glb ist verlustfrei in Bezug auf die 3D-Daten – Geometrie, Materialien, Animationen und die Szenenhierarchie bleiben exakt erhalten. Was du reinsteckst, bekommst du auch wieder raus, nur eben neu verpackt für maximale Portabilität.