GLB in GLTF umwandeln

Eine GLB-Datei ist eine geschlossene Kiste: binär, kompakt, für Renderer gebaut. Wer wissen will, wie viele Dreiecke ein Modell tatsächlich hat, wie die Netze heißen oder ob die Bounding Box plausibel ist, kann das aus einer GLB nicht mit einem Texteditor herauslesen. Genau dafür gibt es diese Seite — nicht, um ein Modell für eine Webseite vorzubereiten, sondern um es sich anzusehen.

Das betrifft in Deutschland nicht zuletzt Digitalisierungsprojekte: Museen und Bibliotheken, die 3D-Scans von Objekten in offenen Sammlungen wie der Deutschen Digitalen Bibliothek oder auf Wikimedia Commons ablegen, arbeiten dort mit glTF als lesbarem, dokumentierbarem Format. Eine GLB, die als Rohdatei aus einem Scanner kommt, muss vorher in eine Form gebracht werden, die sich prüfen und beschreiben lässt.

Ein reines Auspacken würde das Dokument unverändert lassen und nur die Puffer aus dem binären Container herauslösen — Materialien, Texturverweise und Animationskanäle blieben dabei vollständig erhalten. Das leistet diese Seite nicht.

Stattdessen liest sie ausschließlich die Geometrie aus der GLB — Eckpunkte und Dreiecksindizes — und baut daraus ein komplettes neues glTF-Dokument, mit einem Netz pro Primitive und einem Knoten pro Netz. Wer die Materialfarbe ändern und wieder speichern will, braucht ein anderes Werkzeug. Wer nur sehen will, was in der Datei steckt, ist hier richtig.

Beide sind glTF 2.0, dieselbe Spezifikation der Khronos Group. Eine .gltf-Datei ist JSON-Text, dessen Vertexdaten entweder in einer separaten .bin-Datei liegen oder als eingebettete Zeichenkette im JSON selbst. Eine .glb ist dasselbe JSON mit denselben Daten, nur zu einer einzigen Binärdatei zusammengeschnürt, hinter einem kurzen Kopfblock.

Am Modell selbst ändert der Wechsel zwischen den Endungen nichts — eigentlich. Genau deshalb ist es wichtig zu wissen, dass dieser Konverter das Modell tatsächlich neu aufbaut: Wer nur die Verpackung erwartet und den Inhalt bekommt neu zusammengesetzt, sollte das vorher wissen und nicht erst beim geöffneten Ergebnis merken.

Die Ausgabe ist immer eine einzelne Datei. Die Vertexdaten werden als Base64-Text direkt in das JSON eingebettet, es gibt also keine separate .bin-Datei, die beim Verschieben verloren gehen könnte, und keinen relativen Pfad, der brechen kann.

Der Preis dafür: Base64 kostet vier Zeichen für jeweils drei Byte Rohdaten, die eingebettete Geometrie wird also gut ein Drittel größer, als sie binär wäre, und das JSON selbst ist zusätzlich lesbar eingerückt. Für eine Datei, die man in einem Editor öffnet, ist das ein fairer Tausch. Für eine Datei, die eine Webseite ausliefern soll, ist es keiner — dafür bleibt die GLB die bessere Wahl.

Materialien, Texturen und deren UV-Koordinaten sind weg. Vertexnormalen, Vertexfarben und Tangenten sind weg. Skins, Gelenke, Morph Targets, Animationskanäle, Kameras und Lichter — alles weg. Auch jede Erweiterung, die die GLB deklariert, wird nicht übernommen.

Was bleibt, sind Eckpunktpositionen, Dreiecksindizes und die Namen der Netze. Das ist keine Schwäche des glTF-Formats, das all das problemlos tragen könnte — es ist eine bewusste Grenze dieses einen Werkzeugs, das Geometrie zwischen sechs sehr unterschiedlichen 3D-Formaten überträgt und sich dabei nur auf das einigt, was alle gemeinsam haben.

Eine glTF-Szene platziert häufig ein Netz mehrfach mit unterschiedlichen Transformationen — vier Räder, die auf ein gemeinsames Radnetz verweisen, ist das klassische Beispiel. Beim Umwandeln wird jede Knotentransformation direkt in die Eckpunktkoordinaten hineingerechnet, bevor sie geschrieben werden.

Die Form kommt dadurch korrekt heraus, die Struktur nicht: Aus vier Instanzen eines Rads werden vier eigenständige Netze mit vier Sätzen von Koordinaten an vier verschiedenen Stellen, statt eines einzigen Netzes, das viermal referenziert wird. Wer die Datei danach in einer Modellierungssoftware weiterbearbeiten will, sollte das wissen, bevor er die vier Räder mühsam getrennt bearbeitet.

Draco-komprimierte Geometrie wird mit einer benannten Fehlermeldung abgelehnt statt in eine kaputte Datei umgewandelt. Die Erweiterung KHR_draco_mesh_compression speichert die Vertexdaten in einem komprimierten Strom, für den ein eigener Decoder nötig wäre — der hier nicht mitgeliefert wird. Der Export ohne Draco-Kompression aus Blender oder einem vergleichbaren Werkzeug behebt das.

Primitiven, die keine Dreieckslisten sind, werden dagegen still übersprungen statt fehlerhaft übernommen. Eine GLB, die nur aus Liniengeometrie besteht — etwa ein Drahtgitter-Overlay oder ein Debug-Pfad —, liefert die zutreffende Meldung, dass keine Dreiecksgeometrie gefunden wurde.

Im Ergebnis beantwortet das accessors-Array die meisten Fragen, wegen derer man überhaupt umwandelt. Jedes Netz bekommt einen Accessor für die Positionen und einen für die Indizes; die Anzahl der Indizes geteilt durch drei ist die Dreieckszahl, und die Vertexzahl steht direkt am Positions-Accessor.

Der POSITION-Accessor führt außerdem Minimum und Maximum, was die Spezifikation vorschreibt und was Betrachter zum Einpassen der Kamera nutzen. Diese sechs Zahlen sind die Bounding Box — und der schnellste Weg herauszufinden, dass ein zugeschicktes Modell tausendmal zu groß ist oder weit vom Ursprung entfernt liegt. Die Netznamen aus der Quelldatei bleiben erhalten, sodass ein mehrteiliges Modell lesbar bleibt.

Geht das Modell auf eine Webseite, sollte die GLB unangetastet bleiben: Sie ist kleiner, kommt in einer einzigen Anfrage aus, und three.js, Babylon.js und model-viewer laden sie direkt. Eine Umwandlung in glTF macht die Datei größer und entfernt zusätzlich alle Materialien, die das Modell überhaupt zeigenswert gemacht haben.

Wer stattdessen etwas ändern und wieder speichern möchte, greift zu gltf-transform oder dem glTF-Export von Blender. Diese Seite ist die schnelle Antwort auf „Was ist eigentlich in dieser Datei drin", nicht auf „Wie liefere ich dieses Modell aus" — und beide Fragen sauber getrennt zu halten, ist nützlicher als eine Seite, die suggeriert, jede GLB müsste zu glTF werden.

Die gesamte Umwandlung läuft als reines JavaScript direkt im Browser — kein WebAssembly-Modul wird nachgeladen, keine Datei verlässt das Gerät, es gibt keine Warteschlange. Die freie Obergrenze liegt bei 100 MB, was für eine GLB, die für das Web gedacht war, sehr großzügig ist.

Weil der Puffer als Base64 in eingerücktes JSON eingebettet wird, ist die glTF-Datei danach fast immer größer als die GLB, aus der sie stammt — auch ohne die entfernten Materialien und Texturen. Eine 12-MB-GLB, deren Geometrie 9 MB davon ausmacht, landet als glTF wieder bei rund 12 MB, nur eben ohne jede Textur.

Weil das JSON eingerückt und lesbar geschrieben wird, eignet sich das Ergebnis auch als Grundlage für einen Textvergleich: Zwei Exportstände desselben Modells — vor und nach einer Änderung in der Modellierungssoftware — lassen sich beide in glTF umwandeln und dann mit einem gewöhnlichen Diff-Werkzeug gegeneinanderhalten.

Wichtig dabei: Ein solcher Vergleich zeigt nur Unterschiede in der Geometrie, weil nur die Geometrie in beide Dateien einfließt. Eine reine Materialänderung, die keine Vertexposition verschiebt, macht sich im Diff nicht bemerkbar — dafür bräuchte man einen Vergleich auf Ebene der Originaldateien, nicht der hier erzeugten glTF.

Eine glTF, die hier entstanden ist, lässt sich anschließend wieder zu einer GLB packen. Das ist aber kein Rückgängigmachen der ersten Umwandlung, sondern derselbe Vorgang in die andere Richtung: Auch dabei wird nur die Geometrie gelesen und ein neues Dokument gebaut — Materialien, Texturen und Animation, die schon beim ersten Schritt verschwunden sind, kommen dabei nicht zurück, weil sie in der Zwischendatei nie gestanden haben.

Wer testen will, ob eine Rundreise verlustfrei ist, sollte dieses Werkzeug also nicht als Prüfstein benutzen. Ein echter Rundreisetest — GLB zu glTF und wieder zurück, am Ende identisch mit dem Original — funktioniert nur mit einem Werkzeug wie gltf-pipeline, das tatsächlich nur umpackt, statt aus den Dreiecken ein neues Modell zu bauen.

Ein ganzer Ordner voller GLB-Dateien lässt sich in einem Zug ablegen; jede wird unabhängig zu ihrer eigenen glTF-Datei umgewandelt, und das Ergebnis kommt gesammelt als ein ZIP zurück. Praktisch ist das vor allem für eine schnelle Sichtprüfung eines Asset-Ordners — etwa nach einer Blender-Export-Charge, bei der man wissen will, ob alle Dateien plausible Dreieckszahlen und Bounding Boxes haben, ohne jede einzeln von Hand zu öffnen.

Das Sammel-ZIP wird von einem eigenen, im Haus geschriebenen Baustein zusammengestellt, der Dateinamen konsequent als UTF-8 schreibt, damit Umlaute oder Sonderzeichen im Dateinamen nicht als Mojibake ankommen. Tragen zwei Ausgabedateien im selben Stapel denselben Namen, wird die zweite durchnummeriert statt überschrieben.