OBJ in GLB umwandeln

Kein Browser liest OBJ, und auch GLB nicht wirklich nativ — eine .glb-Datei direkt angesteuert wird heruntergeladen statt dargestellt. Der Unterschied liegt bei den Bibliotheken: three.js, Babylon.js und das model-viewer-Webkomponente nehmen GLB als bevorzugtes Eingabeformat und laden es in einem einzigen Zugriff, während OBJ ein Nebenlader ist, der zusätzlich die MTL-Datei und jede Textur einzeln nachladen muss.

Deutsche Museen, die Ausstellungsstücke als 3D-Scans online zeigen, und Industriekataloge deutscher Maschinenbauer, die ein Bauteil interaktiv auf der Produktseite drehbar machen wollen, stehen vor derselben praktischen Frage: nicht, welches Format der Browser irgendwie versteht, sondern welches die eingesetzte Laufzeitumgebung erwartet. Für alles, was nach 2018 veröffentlicht wurde, lautet die Antwort GLB, und auf einer Produktseite, bei der das Modell der eigentliche Inhalt ist, ist das Zusammenfassen mehrerer Anfragen in eine auf dem Handy ein spürbarer Unterschied.

Eine OBJ-Datei enthält selbst keine Materialien. Sie enthält eine mtllib-Zeile, die auf eine daneben liegende .mtl-Datei verweist, und usemtl-Zeilen, die zwischen deren Einträgen wechseln — und diese .mtl-Datei trägt die diffuse Farbe, die Glanzwerte und die Pfade zu den Texturbildern. Diese Umwandlung liest nur v-, o-, g- und f-Zeilen und ignoriert den Rest.

Die Folge ist eindeutig und lässt sich vorher einplanen: Die GLB-Datei enthält Geometrie und Gruppennamen, der Betrachter zeichnet sie mit seinem eigenen Standardmaterial. Soll das Modell mit Textur gezeigt werden, führt der Weg über Blender — OBJ mit MTL importieren, dann als glTF Binary exportieren, wobei die Bilder direkt in die GLB-Datei eingepackt werden. Diese Seite ist für den Fall gedacht, dass die Form die eigentliche Lieferung ist.

Ein glTF-2.0-Binary: zwölf Byte Header, ein JSON-Block, auf eine Vier-Byte-Grenze mit Leerzeichen aufgefüllt, danach ein binärer Block mit Nullen aufgefüllt. Im JSON: ein Mesh pro OBJ-Gruppe, ein Node pro Mesh, eine Szene, die alle auflistet, eine Asset-Version 2.0, und je Mesh ein float32-VEC3-Positions-Accessor sowie ein uint32-SCALAR-Index-Accessor.

Jeder Positions-Accessor trägt Minimum und Maximum. Das ist eine Vorgabe der Spezifikation und praktisch der Unterschied zwischen einem Modell, das beim Laden erscheint, und einem, das leer bleibt — model-viewer und three.js leiten daraus die anfängliche Kameraentfernung ab, und Dateien ohne diese Werte sind ein häufiger Grund für eine scheinbar leere Szene.

Der Reader beginnt bei jeder o- oder g-Zeile eine neue Gruppe, und der Writer erzeugt ein glTF-Mesh je Gruppe, jedes in einem eigenen Node mit eigenem Primitiv. Eine aus einem CAD-Programm exportierte OBJ-Datei mit einer Gruppe je Flächenpatch kann Hunderte solcher Gruppen enthalten, und die GLB-Datei bildet sie alle getreu als eigene Meshes ab.

Auf einer Seite ist das ein echter Kostenpunkt. Jedes Primitiv ist ein eigener Zeichenaufruf und eine eigene GPU-Pufferbindung, und ein paar hundert davon auf einem Mittelklasse-Handy sind genau dort, wo die Bildrate einbricht. Objekte vor dem Export in Blender zusammenzuführen, oder die g-Zeilen mit einem Texteditor zu entfernen, wenn die Gruppierung ohnehin keine Bedeutung trägt, ist eine Zwei-Minuten-Korrektur, die sich mehr auszahlt als das meiste, was danach kommt.

Es wird kein NORMAL-Attribut geschrieben. Die glTF-Spezifikation sagt für diesen Fall genau, was ein Betrachter zu tun hat: flache Flächennormalen berechnen. Eine in der Modellierungssoftware glatt aussehende Kugel erscheint im Browser deshalb mit jedem einzelnen Dreieck als sichtbarer Facette — was wie ein bewusster Low-Poly-Stil wirkt und meistens keiner ist.

Zwei saubere Lösungen gibt es dafür. In three.js computeVertexNormals auf der geladenen Geometrie aufrufen, was die Flächennormalen je Eckpunkt mittelt und ein sauber verschweißtes Mesh braucht — was hier der Fall ist, weil Positionen beim Umwandeln auf sechs Nachkommastellen zusammengeführt werden. Oder den Normalen-Durchgang schon in Blender machen und von dort als glTF exportieren, was gleich auch die Materialien mitbringt.

glTF legt beides fest. Es ist rechtshändig, Y-Achse nach oben, und die lineare Einheit ist der Meter. Eine OBJ-Datei legt keines von beidem fest — sie ist eine Zahlenliste ohne Header, ohne Einheit und ohne Achsenkonvention, und jedes Programm, das eine schreibt, hat dabei seine eigene Gewohnheit.

Diese Umwandlung nimmt keine Anpassung vor, also entsteht aus einer Z-oben-OBJ-Datei eine GLB-Datei, deren Modell auf dem Rücken liegt, und aus einer in Zentimetern gedachten OBJ-Datei eine zweihundert Meter hohe. Beides lässt sich mühelos beheben, sobald man weiß, welcher Fall vorliegt — eine Drehung um minus 90 Grad um die X-Achse, und eine einheitliche Skalierung —, und beides fällt erst beim Laden der Datei auf. Der Begrenzungsrahmen gegen eine bekannte Abmessung geprüft ist die schnellste Diagnose.

Flächen mit mehr als drei Ecken werden vom ersten Eckpunkt aus fächerförmig trianguliert, was für die üblichen konvexen Vierecke und n-Ecke korrekt ist und bei einer konkaven Fläche überlappende Dreiecke erzeugen kann. Negative Face-Indizes, die vom zuletzt gelesenen Eckpunkt rückwärts zählen, werden schon beim Einlesen aufgelöst, weil ihre Bedeutung von der Position in der Datei abhängt.

Die Positionen werden anschließend verschweißt: auf sechs Nachkommastellen abgeglichen, sodass eine in zwanzig Dreiecken auftauchende Koordinate nur einmal gespeichert und zwanzigmal referenziert wird. Das verkleinert den Puffer und gibt dem Browser gleichzeitig ein Mesh mit echter Nachbarschaft, was erst computeVertexNormals eine glatte statt der flachen Schattierung liefern lässt.

Zwölf Byte je Eckpunkt für die Positionen und zwölf Byte je Dreieck für die Indizes, dazu ein kleiner JSON-Header. Ein Modell mit 200.000 Dreiecken und 100.000 Eckpunkten liegt damit bei rund 3,6 MB, unkomprimiert. Die Indizes sind ausnahmslos uint32, was unterhalb von 65.535 Eckpunkten zwei Byte mehr kostet als nötig, aber eine Bedingung erspart, die sich sonst an einer Schwelle unbemerkt anders verhalten würde.

Ist diese Größe für die Seite zu viel, liegt die Antwort vor und nach dieser Umwandlung, nicht in ihr: das Mesh in Blender oder MeshLab vorher reduzieren, und anschließend gltf-transform für Draco- oder Meshopt-Kompression einsetzen — wobei zu bedenken bleibt, dass der Browser dafür einen passenden Decoder mitladen muss, was auf einer Seite mit nur einem Modell wiederum eine eigene Kosten hat.

Braucht das Modell seine Texturen, führt der Weg über Blender, damit MTL-Datei und Bilder mitkommen. Hat das Modell eine halbe Million Dreiecke, wird vorher reduziert statt es einfach hochzuladen und zu hoffen. Muss es glatt wirken, wird das Normalen-Problem im Betrachter oder im Exportprogramm gelöst, denn diese Seite liefert dafür keine Abhilfe.

Wofür diese Seite gut ist, ist der ehrliche Mittelfall: eine saubere OBJ-Datei eines Bauteils, eines Requisits oder eines Scans, der auf einer Seite als Form erscheinen soll, in einer Datei, ohne das Modell irgendwohin hochzuladen. Diese Umwandlung läuft vollständig im Browser, ohne Engine zum Herunterladen und mit einer Obergrenze von 100 MB, und liefert eine Datei, die jeder aktuelle Web-Betrachter annimmt.

Das Verschweißen, Indizieren und Verpacken zur GLB-Datei geschieht vollständig im Browser-Tab. Gerade bei Werkstückgeometrie mit gewerblichem Wert — ein noch unveröffentlichtes Bauteil, ein Prototyp, ein Kundenauftrag — ist das keine Nebensache: Es gibt keinen Moment, an dem die Geometrie einen fremden Server erreicht.

Der Netzwerktab der Entwicklertools bestätigt das während der Umwandlung, und die Datei bleibt bis 100 MB ohne Konto und ohne Warteschlange nutzbar — was für ein einzelnes 3D-Modell in aller Regel mehr als genug ist.