GLB in OBJ umwandeln

In vielen mittelständischen Konstruktionsbüros und Maschinenbaubetrieben laufen CAD-Importer und Prüfwerkzeuge, die seit Jahren nicht aktualisiert wurden — nicht aus Nachlässigkeit, sondern weil ein einmal zertifizierter Arbeitsablauf in der Fertigung nicht ohne Grund angefasst wird. Ein GLB aus einem modernen Web-Konfigurator oder einer 3D-Druck-Vorschau kommt dort schlicht nicht an, weil der Importer glTF gar nicht kennt.

OBJ dagegen liest praktisch jede Software, die seit 1992 mit dreidimensionaler Geometrie zu tun hatte. Diese Umwandlung überbrückt genau diese Lücke — nicht, indem sie das GLB irgendwie kompatibel macht, sondern indem sie auf das Kleinste reduziert, was beide Seiten verstehen: Punkte und die Dreiecke dazwischen.

Ein GLB ist eine ganze Szene: eine Knotenhierarchie, Materialien, Texturen, mitunter Animation und Kameras. Eine OBJ ist eine Liste von Punkten, gefolgt von einer Liste der Dreiecke zwischen ihnen, plus ein Verweis auf eine separate Materialdatei. Alles, was keine reine Geometrie ist, muss irgendwo anders unterkommen — und tut das bei dieser Umwandlung nicht.

Das ist kein Qualitätsverlust im herkömmlichen Sinn, sondern ein Wechsel der Kategorie: von einer Szenenbeschreibung zu einer reinen Formbeschreibung. Wer das vorher weiß, plant die Nachbearbeitung ein, statt sich später über eine grau erscheinende Fläche zu wundern.

Eine OBJ trägt Materialien nie selbst, sondern verweist über eine mtllib-Zeile auf eine begleitende .mtl-Datei mit Farbe, Glanzgrad und Texturpfaden. Diese Umwandlung schreibt weder diese Zeile noch die Datei, weil Materialien aus dem GLB gar nicht erst gelesen werden — es gibt also nichts, das sich in eine Materialdatei übertragen ließe.

Eine erfundene Materialdatei mit plausibel wirkenden Standardwerten wäre die schlechtere Lösung: Sie würde vorgaukeln, das Material stamme aus der Quelle, obwohl es das nicht tut. Das Importwerkzeug am Ziel weist deshalb sein eigenes Standardgrau zu, und das Material wird dort neu vergeben — meist ohnehin nötig, weil ein CAD-System eigene Materialdefinitionen mit anderen Kennwerten erwartet.

Jeder Meshname aus dem GLB wird als eigene o-Gruppe in die OBJ geschrieben. Ein Modell aus benannten Komponenten — Gehäuse, Halterung, Deckel — kommt deshalb auch als drei benannte Objekte an und nicht als eine verschmolzene Form. Bei einer Baugruppe mit mehreren Bauteilen ist das oft der entscheidende Unterschied zwischen einem verwertbaren Import und einem, den man von Hand wieder zerlegen muss.

Für einen geometrieorientierten Import sind diese Namen fast die einzige übrig gebliebene semantische Information. Wer weiß, dass die Weiterverwendung in einer CAD-Umgebung ansteht, sollte die Bauteile schon beim Export aus dem Ursprungswerkzeug sinnvoll benennen — danach lässt sich diese Zuordnung nicht mehr rekonstruieren.

glTF kann ein Bauteil, etwa eine Schraube, mehrfach in der Szene platzieren, indem verschiedene Knoten dieselbe Geometrie mit unterschiedlichen Transformationen referenzieren. OBJ kennt so eine Instanzierung nicht. Die Umwandlung löst das auf, indem jede Knotentransformation direkt in die Punktkoordinaten eingerechnet wird, bevor sie geschrieben werden.

Eine sechzigfach instanzierte Schraube wird dadurch zu sechzig vollständigen Kopien der Geometrie in der OBJ-Datei, jede an ihrer eigenen Position. Das Modell sieht danach korrekt aus — anders lässt sich die Korrektheit ohne Instanzierung gar nicht erreichen —, aber die Datei wächst an dieser Stelle entsprechend an. Erlaubt das Zielprogramm eigene Instanzierung, lohnt es sich, diese nach dem Import wieder von Hand aufzubauen.

Die Koordinatenwerte werden unverändert übernommen, in der Genauigkeit, mit der JavaScript sie ausgibt. Das ist technisch korrekt und trotzdem eine Falle, weil beide Formate unterschiedliche Vorstellungen davon haben, wofür eine Zahl steht.

glTF definiert seine Längeneinheit als Meter, sodass ein maßstäblich modellierter Stuhl Koordinaten um 0,9 herum trägt. OBJ deklariert überhaupt keine Einheit, und jedes Importwerkzeug trifft seine eigene Annahme — häufig Meter in Blender, häufig Zentimeter oder Zoll in älterer CAD-Software. Ein Blick auf den bekannten Maßstab eines Bauteils nach dem Import ist die einzige verlässliche Prüfung, und sie kostet nur einen einzigen Vergleich.

Die OBJ enthält ausschließlich Punkt- und Flächenzeilen, keine Normalenvektoren. Jedes Importprogramm berechnet daraus flache Flächennormalen, und eine ursprünglich runde Fläche zeigt sich dadurch als das, was sie technisch ist: eine in Dreiecke zerlegte Polygonschale.

In Blender behebt „Shade Smooth" das mit einem Klick, in Fusion 360 oder einer CAD-Umgebung meist eine automatische Kantenglättung über einen einstellbaren Winkel. Eine facettierte Ansicht direkt nach dem Import ist deshalb kein Fehler der Datei, sondern der erwartete Ausgangszustand.

glTF speichert je Punkt genau eine UV-Koordinate und eine Normale. Ein Punkt auf einer Texturnaht oder einer harten Kante muss deshalb schon in der Quelle als zwei oder drei Kopien an derselben Position vorliegen, damit die unterschiedlichen Attribute überhaupt möglich sind. Diese Kopien landen unverändert in der OBJ, während der Grund für ihre Existenz — die abweichenden Attribute — dort nicht mehr existiert.

Ein geschlossenes Modell kann dadurch nach dem Import Randkanten entlang seiner ursprünglichen Nähte melden, obwohl es geometrisch geschlossen ist. „Merge by Distance" in Blender oder eine vergleichbare Funktion in einem CAD-Reparaturwerkzeug löst das in einem Arbeitsschritt.

Liest das Zielprogramm glTF, sollte gar nicht erst umgewandelt werden. Blender, Unity, Unreal, der Windows 3D Viewer und viele moderne Web-Viewer öffnen ein GLB mit intaktem Material, und der Umweg über OBJ kostet dann alles davon, ohne etwas zu gewinnen.

Sinnvoll ist die Umwandlung, wenn das Ziel glTF wirklich nicht lesen kann — oder wenn ausdrücklich eine Textdatei gewünscht ist, die sich mit einem einfachen Editor öffnen, durchsuchen oder mit einem Diff-Werkzeug vergleichen lässt. Genau diese Lesbarkeit, nicht die Detailtreue, ist der verbliebene Vorteil von OBJ gegenüber jedem jüngeren Format.

Der GLB-Indexpuffer läuft unverändert durch. glTF speichert Dreiecke bereits als Indizes in ein gemeinsames Punktfeld, es gibt also nichts zu rekonstruieren: Jeder Eintrag des Accessors wird zu einer v-Zeile in derselben Reihenfolge, jeder Index zu einem f-Eintrag, der darauf zeigt. Nichts wird zusammengeführt — das Verschmelzen naheliegender Koordinaten passiert bei dieser Umwandlung an keiner Stelle, anders als beim Lesen von STL oder OBJ, wo doppelte Punkte die Regel sind.

Die OBJ-Indexzählung beginnt außerdem bei eins statt bei null und läuft über die gesamte Datei durch statt bei jeder Gruppe neu zu starten — genau die Stelle, an der selbstgeschriebene Parser am häufigsten stolpern. Die Umwandlung verfolgt diesen Versatz beim Durchlaufen der Meshes selbst mit, sodass ein zweites Objekt, das auf seinen eigenen ersten Punkt verweist, mit dem korrekt aufaddierten Gesamtwert geschrieben wird.

Die Umrechnung von Szene zu Geometrie findet vollständig auf dem eigenen Rechner statt, ohne dass das Modell irgendwohin übertragen wird — relevant bei Konstruktionsdaten, die einer Geheimhaltungsvereinbarung oder einem Kundenprojekt unterliegen und die keine fremde Serverinfrastruktur durchlaufen sollen.

Das lässt sich mit den Bordmitteln des Browsers selbst prüfen: Entwicklertools öffnen, den Netzwerk-Tab beobachten und ein Modell umwandeln, oder die Verbindung trennen und sehen, dass die Umwandlung trotzdem fertig wird.