GLB in PLY umwandeln

In der Vermessung und Digitalisierung von Kulturgut hat sich GLB als Auslieferungsformat durchgesetzt: ein Landesamt für Denkmalpflege oder ein Museum photogrammetrisch erfasst ein Objekt, packt Geometrie und Textur in eine einzige Datei und veröffentlicht sie über Sketchfab oder eine eigene Viewer-Seite, wo sie im Browser betrachtet werden kann. Für die eigentliche Vermessungsarbeit — Volumenberechnung, Vergleich zweier Aufnahmen desselben Objekts, Punktwolkenanalyse — will die Fachsoftware aber PLY, weil trimesh, Open3D, MeshLab und CloudCompare dieses Format als Grundzustand behandeln.

Wer aus einer solchen Sammlung arbeitet, konvertiert deshalb selten aus Neugier, sondern weil das nächste Werkzeug in der Kette nichts anderes liest. Was dabei zählt, ist nicht Treue zum Ausgangsbild — niemand rendert diese Datei mehr — sondern genau zu wissen, was der Loader gleich zu sehen bekommt: wie viele Eckpunkte, ob die Fläche aus einem Stück besteht, ob die Datei fünf oder fünfzig Megabyte groß wird.

PLY kennt genau einen Eckpunktblock und genau einen Flächenblock. Es hat kein Konzept für ein Objekt, eine Gruppe oder einen Namen, also wird ein GLB mit Körper, Deckel und Griff verschmolzen: Die Eckpunktlisten werden aneinandergehängt, und die Flächenindizes jedes Netzes werden um die Zahl der bereits geschriebenen Eckpunkte verschoben.

Die Geometrie bleibt identisch, die Struktur ist weg. Eine Analyse zusammenhängender Komponenten findet die drei Teile trotzdem noch — trimesh.Mesh.split() und MeshLabs Split in Connected Components funktionieren am Ergebnis —, aber die Namen kommen nicht zurück, und zwei Teile, die sich berührten, sind jetzt benachbarte Bereiche einer Fläche statt zweier Objekte. Wenn die Teileidentität wichtig ist, ist OBJ das Format hier, das sie behält.

Der Kopf lautet immer format ascii 1.0. Es gibt keine Binäroption und keine Einstellung dafür, also wird jede Koordinate als Dezimalzahl geschrieben und jede Fläche als Zeile, die mit der Zahl 3 beginnt. PLY ist als Text oder binär definiert, und dieser Konverter schreibt nur die erste Form — wissenswert, denn Formatübersichten, auch die dieser Website, PLY als Binärformat beschreiben.

In der Praxis heißt das, dass die Datei ein Vielfaches der binären Entsprechung wiegt: Eine float32-Koordinate belegt gepackt vier Byte und als ausgeschriebener Text zehn bis fünfzehn Zeichen. Alles kann sie lesen, head -20 zeigt den Kopf, und ein Diff zwischen zwei Exporten ist aussagekräftig. Wird die Binärform gebraucht, schreiben MeshLab und trimesh sie, und ein erneutes Speichern erledigt die Umwandlung.

Manche Quellen auf dieser Seite werden beim Einlesen verschweißt — eine STL speichert je Dreieck drei unabhängige Eckpunkte und würde sonst eine viermal zu große Datei ergeben. Ein GLB nicht: Seine Geometrie ist bereits ein indizierter Eckpunktpuffer, sodass Positionen und Indexfeld unverändert übernommen werden.

Das bedeutet, die Eckpunktzahl in der PLY-Datei stimmt mit den Zähler-Angaben der Quelle überein, was genau richtig ist, wenn die Umwandlung ein Schritt in einer Messung ist und keine Auslieferung. Es bedeutet auch, dass Duplikate aus der Quelle erhalten bleiben — eine UV-Naht teilt in jedem glTF-Exporter einen Eckpunkt in zwei deckungsgleiche Kopien, und diese Kopien landen auch in der PLY-Datei. Braucht ein Algorithmus einen wasserdichten Index, muss mit einer Toleranz in der Bibliothek verschweißt werden, statt zu erwarten, dass die Umwandlung das schon erledigt hat.

Neun Zeilen und nicht mehr: das Erkennungswort, das Format, ein Kommentar zum Erzeuger, das Eckpunktelement mit seiner Zahl und drei Fließkommaeigenschaften, das Flächenelement mit seiner Zahl und einer property list uchar int vertex_indices, und end_header. Die beiden Zählwerte vom Kopf der Datei abzulesen ist die schnellste verfügbare Dreieck- und Eckpunktzählung, ganz ohne Bibliothek.

Was der Kopf nicht verrät, ist alles Übrige. Keine Farbeigenschaften, keine Normalen, keine Texturkoordinaten, keine Kommentare mit Maßeinheit oder Herkunft, keine benutzerdefinierten Elemente. Wer diese Datei lädt, lernt die Geometrie und nichts über ihre Herkunft — gut für einen Verarbeitungsschritt, schlecht für ein Archiv. Deshalb das GLB behalten.

PLY wird gerade wegen der Fähigkeit zu Farbe je Eckpunkt gewählt, weshalb Scanner das Format schreiben. Ein GLB hat dazu oft etwas zu bieten: ein COLOR_0-Eckpunktattribut oder, häufiger, eine Grundfarbtextur mit UV-Koordinaten. Nichts davon wird gelesen, der Schreiber gibt nur x, y und z aus.

Das Ergebnis ist also Geometrie ohne Erscheinungsbild, und geht es gerade um das Erscheinungsbild — der Vergleich zweier Scans, die Prüfung einer Erfassung, die Bewertung eines Textur-Bakes —, ist das der falsche Weg, und die Antwort ist eine Bibliothek, die beide Attribute liest. trimesh.load(datei.glb) liefert Optik und Netz zugleich und exportiert direkt eine gefärbte PLY-Datei. Für reine Geometriearbeit spielt das keine Rolle, und die schlichte Datei ist kleiner.

Der Konverter läuft den Szenengraphen von der Standardszene aus ab, verrechnet jede Knotenmatrix mit ihrem Elternknoten und wendet das Ergebnis vor dem Schreiben an. Ein GLB, das ein Netz an vier Positionen platziert hat, erzeugt also vier Eckpunktsätze an vier Orten statt eines Netzes und vier Matrizen.

Das ist das richtige Verhalten, denn PLY hat keine Möglichkeit, eine Instanz auszudrücken, und lohnt sich zu bedenken, wenn Zahlen falsch wirken. Eine an der PLY-Datei berechnete Umgebungsbox umfasst die ganze zusammengesetzte Szene, nicht das Ausgangsnetz, und ein Modell, dessen Szenenwurzel der Autor verschoben gelassen hat, landet weit vom Ursprung entfernt. Beides sind Eigenschaften des GLB, nicht der Umwandlung, und beides ist einen mesh.apply_translation(-mesh.centroid) davon entfernt, behoben zu sein.

Weder GLB noch PLY trägt eine Einheit. glTF wird der Konvention nach so gestaltet, als sei eine Einheit ein Meter; PLY macht gar keine Aussage, und die Scanner, die es schreiben, arbeiten meist in Millimetern. In der Umwandlung wird nichts davon abgeglichen, und nichts könnte es.

Für eine Messkette ist das eine echte Gefahr, keine Fußnote — ein an unbezeichneten Koordinaten berechnetes Volumen ist eine Zahl ohne Einheit. Den Faktor einmal an einem prüfbaren Maß der Quelle festlegen und neben dem Datensatz vermerken. Kommt die Sammlung aus einem einzigen Erzeuger, ist der Faktor meist konstant über die ganze Sammlung, was daraus eine einmalige Fünf-Minuten-Aufgabe macht statt einer Frage je Datei.

Ein Ordner wandelt hier in einem Durchgang und kommt als ZIP zurück, was für einige Dutzend Dateien vernünftig ist und für Tausende nicht. Die kostenlose Grenze liegt bei 100 MB je Datei und die Arbeit läuft in einem Browsertab, sodass eine große Sammlung langsam wird und, wichtiger, unwiederholbar bleibt — nichts davon ist in einem Skript festgehalten.

Für alles, was mehr als einmal läuft, ist trimesh.load(pfad, force='mesh').export(ziel) zwei Zeilen, liest GLB nativ, behält Eckpunktfarben, wenn danach gefragt wird, und schreibt binäre PLY-Dateien. Diese Seite lohnt sich für das, worin sie gut ist: drei Dateien von Hand umwandeln, um zu sehen, wie die Geometrie tatsächlich aussieht, bevor entschieden wird, wie die übrigen dreitausend verarbeitet werden.

In diesem Browsertab. Die Umwandlung ist reines JavaScript ohne WebAssembly-Modul zum Herunterladen, nichts wird hochgeladen, es gibt kein Konto und kein Tageskontingent, und der Netzwerktab zeigt während der Umwandlung nichts, was das Gerät verlässt.

Das lohnt sich zu prüfen statt zu glauben, und es zählt hier aus zwei überschneidenden Gründen: Forschungsdatensätze kommen oft mit Weiterverbreitungsbedingungen, und ein gescanntes oder erfasstes Modell eines realen Objekts kann selbst eine Preisgabe sein — etwa bei einem noch nicht veröffentlichten Fund. Keine der beiden Fragen stellt sich, wenn die Datei das Gerät nie verlässt.