OBJ in GLTF umwandeln

Nahezu alles, was in der modernen 3D-Web-Pipeline nützlich ist, nimmt glTF als Eingabe. gltf-transform kürzt, verschweißt, sampelt neu und komprimiert es; der Khronos-Validator prüft es; three.js und Babylon.js lesen es ein; jeder Optimierungsdienst setzt es voraus. Ein OBJ steht außerhalb davon, und der erste Schritt, um eines in diese Welt zu bringen, ist eine Umwandlung, die ein Dokument erzeugt, das diese Werkzeuge akzeptieren.

Der Grund, an dieser Stelle .gltf statt .glb zu wählen, ist, dass die JSON-Form die ist, die sich lesen und ändern lässt. Ein GLB ist das Ergebnis am Ende der Pipeline, nachdem das Material stimmt und die Kompression gelaufen ist. Diese Seite ist für den Anfang gedacht, wo eine Datei im Editor öffnen zu können mehr wert ist als sie in einer einzigen Anfrage ausliefern zu können.

Für ein Ingenieurbüro, das ein CAD-Modell für eine Webvisualisierung aufbereitet, oder ein Fablab, das ein 3D-gedrucktes Bauteil im Browser zeigen will, ist genau das der übliche erste Schritt: Das OBJ kommt aus der Konstruktionssoftware, das glTF geht in Blender oder gltf-transform weiter, bevor am Ende ein GLB für die Website steht. Die Zwischenstation als lesbares JSON ist dabei kein Umweg, sondern der Punkt, an dem sich noch etwas ändern lässt, ohne die Geometrie neu zu exportieren.

Auch in der deutschen Maker- und Bastlerszene, in der 3D-Druck-Communities Modelle austauschen, taucht dasselbe Muster auf: Ein von einem CAD-Programm exportiertes OBJ soll in einer Weboberfläche für Community-Modelle landen, und ein bearbeitbares glTF dazwischen ist der Schritt, an dem sich Materialangaben nachträglich ergänzen lassen, die das OBJ selbst nicht mitbrachte.

Ein Asset-Block mit der Versionsangabe 2.0 und Quinvert als Generator, ein Szenenindex 0, eine Szene, die jeden Knoten auflistet, ein Knoten je Mesh, ein Mesh je OBJ-Gruppe, und je Mesh genau eine Primitive mit Modus 4, einem POSITION-Attribut und einem Indizes-Accessor. Danach folgen die Accessoren, die Buffer-Views und ein einzelner Puffer.

Das Dokument ist mit zwei Leerzeichen eingerückt formatiert, was es etwa ein Drittel größer macht als eine minifizierte Fassung und ohne Formatierungswerkzeug lesbar. Für ein Dokument, das gleich bearbeitet werden soll, ist das die richtige Voreinstellung; es zu minifizieren ist ein einzelner Befehl, das Rückgängigmachen einer unformatierten 40.000-Zeilen-JSON-Datei dagegen nicht.

glTF erlaubt drei Wege, Vertexdaten zu speichern: eine separate .bin-Datei, eine Base64-Daten-URI im uri-Feld des Puffers, oder den Binärblock einer GLB. Eine Umwandlung erzeugt eine einzelne Datei, also ist die Daten-URI die einzige Option, die das Ergebnis eigenständig hält, und genau die wird geschrieben.

Zwei Folgen ergeben sich daraus. Die Datei ist rund ein Drittel größer als dieselben Byte binär gespeichert, weil Base64 vier Zeichen je drei Byte kostet — für ein Arbeitsdokument akzeptabel, für eine Auslieferung verschwenderisch. Und jedes Werkzeug, das glTF liest, kommt damit zurecht: gltf-transform, der Validator und three.js lösen eingebettete Puffer ohne besondere Einstellung auf.

Das Dokument hat kein materials-Array, weil die MTL-Datei des OBJ nicht eingelesen wird. Es hinzuzufügen sind vier Zeilen: ein materials-Array mit einem Objekt, das einen pbrMetallicRoughness-Block mit einem vierteiligen baseColorFactor enthält, dazu eine material-Eigenschaft an der Primitive mit ihrem Index.

Damit steht in jedem glTF-Betrachter ein farbiges, korrekt beleuchtetes Modell, ohne dass die Geometrie berührt wird. Texturen sind eine größere Aufgabe, weil sie Bilder, Sampler, Texturen und — entscheidend — TEXCOORD_0-Daten brauchen, die diese Umwandlung nicht erzeugt hat. Hatte das OBJ UV-Koordinaten und werden sie gebraucht, ist der ehrliche Weg Blender statt eine Handbearbeitung.

Jede o- oder g-Zeile beginnt eine neue Gruppe, und jede Gruppe wird zu einem benannten Mesh. Dieser Name ist die einzige nicht-geometrische Information, die bei der Umwandlung erhalten bleibt, und in einem Dokument, das später bearbeitet wird, macht er den Unterschied zwischen dem gesuchten Teil finden und Knoten durchzählen.

Eine Gruppe ohne Namen in der Quelle bleibt auch in der Ausgabe ohne Namen. Das Mesh wird ohne name-Eigenschaft geschrieben, und der referenzierende Knoten trägt nur den Mesh-Index — alles Nachgelagerte muss sich selbst eine Bezeichnung ausdenken. Soll das glTF später von Hand gelesen oder bearbeitet werden, lohnt es sich, die Gruppen bereits im OBJ zu benennen — eine Textänderung dort ist einfacher, als später anonyme Meshes im JSON zu unterscheiden.

Die Ausgabe ist gegen die Teile der Spezifikation geschrieben, die Validatoren tatsächlich prüfen. Buffer-Views sind so aufgefüllt, dass jeder Accessor-Byte-Offset ein Vielfaches der Komponentengröße ist — eine Pflicht und keine Höflichkeit, und eine häufige Fehlerquelle in handgeschriebenen Schreibern. Jeder POSITION-Accessor trägt min und max, was vorgeschrieben ist und von Betrachtungsprogrammen genutzt wird, um das Modell einzurahmen.

Ein Stride von null wird als dicht gepackt behandelt statt als Stride in Größe des Elements, wie es die Spezifikation vorsieht und was mehrere Leser in die falsche Richtung interpretieren. Läuft man den Khronos-glTF-Validator über das Ergebnis, ist das interessante an der Ausgabe kein Fehler, sondern die Hinweismeldung, dass die Meshes keine Normalen haben — das stimmt, und die Spezifikation behandelt das ausdrücklich, indem sie Betrachtern vorschreibt, flache Normalen selbst zu berechnen.

Flächen mit vier oder mehr Ecken werden vom ersten Eckpunkt aus fächerförmig trianguliert. Das ist korrekt für konvexe Vierecke und N-Ecke, was diese Dateien in der Praxis meist enthalten, kann aber bei konkaven Flächen zu überlappenden Dreiecken führen — wichtig zu wissen, wenn das eigene OBJ aus einem Werkzeug stammt, das komplexe Polygone erzeugt.

Negative Flächenindizes werden beim Einlesen aufgelöst, weil sie rückwärts vom zuletzt gelesenen Vertex zählen und sich nicht außer der Reihe interpretieren lassen. Anschließend werden Vertices je Gruppe mit sechs Nachkommastellen verschweißt, sodass eine Gruppe, die nur zwölf von viertausend Vertices einer Datei referenziert, im glTF auch nur zwölf trägt statt viertausend.

Base64-Aufblähung des Puffers, dazu formatiertes JSON drumherum. Bei einem reinen Geometriemodell dominiert der Puffer, weshalb etwa ein Drittel mehr Byte als beim gleichen Modell als GLB zu erwarten sind, noch vor jeder Kompression.

Das ist der richtige Tausch an dieser Stelle einer Pipeline und der falsche an ihrem Ende. Der übliche Ablauf lautet: hier zu glTF umwandeln, bearbeiten oder weiterverarbeiten, dann das GLB als endgültiges Ergebnis erzeugen — entweder durch Rückumwandlung oder indem gltf-transform es schreibt, was auch der richtige Ort für Draco- oder Meshopt-Kompression ist.

Passiert zwischen Umwandlung und Auslieferung nichts weiter mit der Datei, führt der Weg direkt zu GLB. Es ist kleiner, es ist eine einzige Anfrage, und die Bearbeitbarkeit, für die man mit den zusätzlichen Byte bezahlt, ist nichts wert, wenn niemand die Datei öffnet.

Für glTF entscheidet man sich, wenn ein nächster Schritt folgt: ein Material soll ergänzt, ein Validator soll zufrieden gestellt, ein Transform-Durchgang soll ausgeführt werden, oder ein Repository, in dem eine Textdatei einen Diff zeigt und eine Binärdatei keinen. Beide Umwandlungen laufen vollständig im Browser, ohne ein Modul nachzuladen, die Wahl kostet also nichts außer der Dateiendung.

Einlesen des OBJ, Verschweißen der Vertices, Indizierung und das Schreiben als glTF-JSON laufen vollständig im Browser. Für ein Bauteil, das unter einer Geheimhaltungsvereinbarung steht — ein noch unveröffentlichtes Produkt aus der Konstruktion, ein Kundenauftrag —, ist das mehr als eine Randnotiz: Es gibt keinen Moment, in dem die Geometrie außerhalb des eigenen Rechners existiert.

Der Netzwerktab der Entwicklerwerkzeuge zeigt während einer Umwandlung keine Anfrage, die Modelldaten enthält — das lässt sich in wenigen Sekunden selbst nachprüfen, statt es nur zu glauben.