GLTF in GLB umwandeln

Ein Möbelhaus oder ein Einrichtungsshop, der eine Augmented-Reality-Vorschau für ein Produkt einbaut, stößt fast immer auf dieselbe Anforderung: Das Upload-Formular der Plattform — ein Shopsystem, ein AR-Viewer-Baustein, model-viewer auf der eigenen Produktseite — nimmt genau eine Datei an, keinen Ordner. Kommt das 3D-Modell aus einem CAD-Export oder einer Modellierungs-Software als .gltf, liegt daneben aber häufig eine zweite Datei mit den eigentlichen Geometriedaten, und schon bricht der Upload ab, weil der relative Pfad zur .bin-Datei beim Hochladen verlorengeht.

Diese Umwandlung packt beides in eine einzige binäre GLB-Datei — vorausgesetzt, das glTF trägt seine Geometrie bereits vollständig in sich selbst. Genau das ist die Bedingung, die diese Seite zuerst klärt, denn die Hälfte aller .gltf-Dateien im Umlauf erfüllt sie nicht, und das lohnt sich vor dem Hochladen zu wissen statt danach.

Es gibt zwei Arten von .gltf, und nur eine funktioniert hier. Die Datei in einem Texteditor öffnen und nach dem Feld „buffers" gegen Ende suchen. Beginnt der uri-Wert mit data:application/octet-stream;base64, liegt jeder Eckpunkt des Modells in dieser einen Datei, und die Umwandlung läuft. Steht dort stattdessen etwas wie scene.bin, liegt die Geometrie in einer zweiten Datei, die ein Ein-Datei-Umwandler nie zu sehen bekommt.

Diese zweite Form ist die häufigere, weil sie der Standardexport der meisten Werkzeuge ist. Wird eine solche Datei hier abgelegt, kommt eine klare Meldung statt eines leeren Modells, die auf die fehlende .bin-Datei verweist. Die meisten Exportwerkzeuge — Blender eingeschlossen — bieten dafür eine Option, den Puffer beim Export einzubetten statt ihn auszulagern, oder man exportiert direkt als .glb, was dieselbe Software fast immer ebenfalls kann.

Ein glTF mit externen Ressourcen ist ein kleines Geflecht aus Dateien, zusammengehalten durch relative Pfade: das JSON, eine .bin-Datei, ein Bild je Textur. Jeder dieser Pfade ist eine Gelegenheit für das Modell zu brechen. Wird das JSON ohne seine Nachbarn verschoben, lädt nichts. Wird es über ein CDN mit anderer Verzeichnisstruktur ausgeliefert, meldet die Puffer-Anfrage einen 404-Fehler.

Eine GLB-Datei kennt keine dieser Fehlerarten, weil es nichts zu verlieren gibt. Sie ist zudem eine einzelne HTTP-Anfrage statt mehrerer, was auf einer Produktseite zählt, auf der das Modell der eigentliche Grund für den Besuch ist. Diese Eigenschaft ist der ganze Grund, warum der binäre Container in glTF 2.0 von Anfang an neben der JSON-Form spezifiziert wurde und nicht erst nachträglich angeflanscht ist.

Herauskommt ein glTF-2.0-Binärformat: ein zwölf Byte langer Kopf, dessen Signatur glTF lautet, gefolgt von Versionsnummer und Gesamtlänge, dann ein JSON-Abschnitt, dann ein Binärabschnitt. Der JSON-Abschnitt wird mit Leerzeichen auf eine Vier-Byte-Grenze aufgefüllt, der Binärabschnitt mit Nullbytes — eine Vorgabe der Spezifikation, keine bloße Konvention, und mehrere Loader lehnen eine anders aufgefüllte Datei ab.

Im Inneren werden Eckpunktpositionen ausnahmslos als Float32 in einem VEC3-Accessor geschrieben, Dreiecksindizes als Uint32 in einem SCALAR-Accessor. Ein schmalerer Indextyp würde bei kleinen Modellen ein paar Kilobyte sparen und bräuchte dafür eine Bedingung, die bei 65.535 Eckpunkten still das Verhalten ändert — ein schlechter Tausch für einen Umwandler. Jeder Positions-Accessor trägt Minimum und Maximum, wie es die Spezifikation verlangt, damit ein Viewer das Modell einrahmt statt bei einem Zoom ins Leere zu starten.

Diese Umwandlung bewegt Geometrie. Ein glTF, das ein Metallic-Roughness-Material mit einer Grundfarbtextur, einer Normal Map und einer Emissive Map deklariert, wird zu einer GLB-Datei mit Eckpunktpositionen, Dreiecksindizes und Netznamen — der Materialblock, die Bilder, die Sampler und die Texturkoordinaten werden schlicht nicht geschrieben.

Das lohnt sich gegen den eigenen Anlass abzuwägen. Sollte das Ergebnis ein ausstellungsfertiges Modell mit eingebetteten Texturen sein, leistet diese Seite das nicht — dafür sind gltf-transform oder der Blender-Export der richtige Weg. Ging es dagegen darum, aus einem eigenständigen JSON ein einzelnes binäres Artefakt zu bekommen — für einen Größentest, eine reine Geometrie-Vorschau, einen Platzhalter in einer Szene —, ist das Ergebnis genau richtig und deutlich kleiner.

Animationskanäle und -sampler werden nicht gelesen, Skins und Gelenkhierarchien werden nicht gelesen, Kameras und Lichter werden nicht gelesen. Eine geriggte und animierte Figur kommt in der GLB-Datei als starre Geometrie der Pose an, die die Eckpunktdaten gerade beschreiben, ohne jede Möglichkeit, sie zu bewegen.

Für ein statisches Möbelstück, ein architektonisches Element oder ein gescanntes Objekt kostet das nichts, weil es nichts zu verlieren gab. Für eine Figur oder einen Mechanismus ist es das ganze Modell. Es gibt hier kein Teilergebnis und keine Einstellung, die das ändert — die ehrliche Empfehlung ist, den Inhalt des eigenen glTF vor der Umwandlung zu prüfen statt danach.

Die Quellszene wird von ihrem Standardszenen-Index aus durchlaufen, und jede Knotenmatrix wird mit der ihres Elternknotens verrechnet, bevor die Eckpunkte damit transformiert werden. Knoten, die über separate Translations-, Rotations- und Skalierungswerte beschrieben sind, werden zunächst in eine Matrix umgerechnet, in der von glTF definierten Quaternion-Form, sodass beide Schreibweisen am selben Ergebnis landen.

Die entstehende GLB-Datei hat eine flache Struktur: eine Szene, ein Knoten je Netz, keine Elternschaft, keine Wiederverwendung. Ein Modell, dessen glTF eine einzelne Schraube vierzigmal über die Hierarchie platzierte, wird zu vierzig Netzen mit vierzig Kopien der Eckpunktdaten. Das Bild bleibt identisch, die Datei wird größer — der Tausch, den jedes Format ohne Instanzierung erzwingt.

Draco-komprimierte Geometrie bricht mit einer Meldung ab, die Draco ausdrücklich nennt. KHR_draco_mesh_compression ersetzt die gewöhnlichen Bufferviews durch einen komprimierten Datenstrom, und das Dekodieren bräuchte eine Bibliothek, die hier nicht enthalten ist. Der erneute Export ohne Draco ist in Blender eine Checkbox und in gltf-transform ein Schalter.

Geometrie, die als Dreiecksstreifen, -fächer, Linien oder Punkte gespeichert ist, wird übersprungen statt umgewandelt, weil nur Modus 4 in glTF eine Dreiecksliste ist. Eine Datei, die ausschließlich so etwas enthält, endet mit einer Meldung, dass keine Dreiecksgeometrie gefunden wurde. Eine fehlerhafte JSON-Datei — meist Folge eines abgebrochenen Downloads — wird als nicht lesbar gemeldet statt in etwas Willkürliches umgewandelt zu werden.

Ein eingebettetes glTF speichert seinen Puffer als Base64, was für je drei Byte vier Zeichen kostet. Dieselbe Geometrie in einen GLB-Binärabschnitt zu verschieben entfernt diesen Aufschlag, ein self-contained glTF schrumpft beim Umwandeln also meist um ungefähr ein Viertel, noch bevor sonst etwas eingerechnet wird.

Danach zieht sich alles ab, was der Umwandler nicht überträgt. Bestand das Volumen des Modells vor allem aus Texturen, kann die GLB-Datei ein kleiner Bruchteil des Originals sein und entsprechend kahl. Ein sinnvoller Test nach der Umwandlung ist die Dreieckszahl: Die Zahl der Indexeinträge geteilt durch drei sollte mit dem übereinstimmen, was das eigene Werkzeug gemeldet hat — stimmt sie nicht, enthielt die Quelle Geometrie in einer Form, die übersprungen wurde.

Nirgendwo anders als auf dem eigenen Gerät. Dieses Paar läuft als gewöhnliches JavaScript in der Seite, ohne WebAssembly-Modul zum Nachladen und ohne Anfrage, die das Modell trägt. Das Einlesen, das Verrechnen der Transformationen und der binäre Zusammenbau geschehen alle auf dem eigenen Rechner, weshalb es keine Warteschlange und keine Wartezeit je Datei gibt.

Die freie Obergrenze liegt bei 100 MB, und ein self-contained glTF ist unter den hier verarbeiteten Formaten das eine, das dieser Grenze am ehesten nahekommt, weil Base64 dieselbe Geometrie so aufgebläht speichert wie kein anderer Weg. Wer dieser Grenze nahekommt, ist meist besser bedient, GLB direkt aus dem Werkzeug zu exportieren, das das Modell erzeugt hat.

Ein Shop mit dutzenden Produkten exportiert selten ein Modell nach dem anderen von Hand. Liegen mehrere self-contained .gltf-Dateien in einem Ordner, lassen sich alle gemeinsam ablegen — jede wird für sich geprüft und umgewandelt, und die fertigen GLB-Dateien kommen als eine ZIP-Datei zurück, statt jede einzeln hoch- und wieder heruntergeladen werden zu müssen.

Weil das Ganze im Browser läuft, gibt es dabei weder eine Warteschlange noch ein Tageskontingent. Enthält der Ordner eine Mischung aus self-contained Dateien und solchen mit externer .bin-Datei, werden nur die Erstgenannten umgewandelt, die anderen mit der bekannten Meldung übersprungen — ein guter Anlass, vor einem großen Katalog-Export einmal zu prüfen, mit welcher Einstellung das Ausgangswerkzeug Puffer tatsächlich einbettet.