GLTF in PLY umwandeln

PLY entstand 1994 in Stanford genau für diesen Zweck: ein Netz mit einer beliebigen, selbstbeschreibenden Liste von Eigenschaften je Punkt und Fläche, in einem Kopf, den ein Programm ohne Vorwissen lesen kann. Genau dieser Entwurf machte es zur Standardwährung von 3D-Scans, Photogrammetrie und wissenschaftlicher Geometriearbeit — CloudCompare, MeshLab, Open3D und trimesh behandeln es alle als erstklassige Eingabe.

glTF wurde für das andere Ende der Kette gebaut — ein fertiges Objekt über ein Netzwerk an einen Renderer auszuliefern. Seine Stärken sind genau das, was ein Messwerkzeug ignoriert: Materialdefinitionen, Texturpackung, Animation, Erweiterungsmechanismen. Manche dieser Analysewerkzeuge haben gar keinen glTF-Import, andere behandeln ihn als Nebensache. Umwandeln ist meist schneller, als dagegen anzukämpfen.

Er ist bewusst minimal: das Erkennungswort ply, dann format ascii 1.0, ein Kommentar mit dem Namen des Schreibers, eine element-vertex-Angabe mit der Punktzahl, drei property-float-Zeilen für x, y und z, eine element-face-Angabe mit der Flächenzahl, eine property-list-uchar-int-Zeile für vertex_indices, und end_header.

Das ist der am breitesten unterstützte PLY-Dialekt überhaupt. Eine uchar-Flächenzahl mit int-Indizes ist das, wovon fast jeder Leser bei Abkürzungen ausgeht, und float statt double bei den Koordinaten hält die Datei halb so groß, ohne dass für ein Netz dieser Art die zusätzliche Genauigkeit gebraucht würde. Wer gegen diese Ausgabe einen eigenen Parser schreibt, hat mit diesen sieben Zeilen den vollständigen Vertrag.

Jede Koordinate wird als Dezimaltext geschrieben, ein Punkt pro Zeile, ein Dreieck pro Zeile. Ein Punkt, der im glTF-Puffer zwölf Byte belegte, belegt hier zwanzig bis sechzig Zeichen — die PLY-Datei wird also mehrere Male größer als die Geometrie, aus der sie stammt. Ein Modell mit zwei Millionen Dreiecken ist als Text eine erhebliche Datei.

Der Ausgleich ist, dass nichts daran zweideutig bleibt. Binäres PLY kommt in Little-Endian- und Big-Endian-Varianten mit einer Eigenschaftsreihenfolge, die ein Leser aus dem Kopf rekonstruieren muss, und ein falscher Schluss dabei ergibt ein Netz, das wie Rauschen lädt. ASCII kann so nicht scheitern, und für eine Datei, die einmal in ein Analysewerkzeug geht, zählt die Sicherheit meist mehr als die Größe.

Eine PLY-Datei kennt ein Vertex-Element und ein Face-Element, keine Gruppe, kein Objekt, keinen Namen. Die Umwandlung fasst deshalb jedes aus der glTF-Szene gelesene Netz in einer gemeinsamen Liste zusammen und verschiebt dabei die Indizes jedes Netzes um die Zahl der bereits geschriebenen Punkte, damit die Dreiecke weiterhin auf die richtigen Stellen zeigen.

Die Geometrie bleibt unverändert, die Struktur ist weg. Ein aus zwölf benannten Teilen zusammengesetztes glTF-Modell wird zu einer Fläche aus zwölf unverbundenen Hüllen, und die Namen gehen mit der Struktur verloren. Zählen diese Unterteilungen für die nachfolgende Arbeit, ist OBJ das Ziel, das sie behält, und die Umwandlung nach OBJ kostet dabei sonst nichts, was PLY geliefert hätte.

Der meistgenannte Grund für PLY ist, dass es Rot-, Grün- und Blauwerte je Punkt speichern kann — genau so trägt ein Photogrammetrie-Scan sein Aussehen ohne eine eigene Textur. Das Format unterstützt das, und viele Leseprogramme erwarten es dort.

Diese Umwandlung schreibt keine. Farbe lebt in einem glTF-Modell in Materialien und Texturen, indiziert über UV-Koordinaten, und keines von beidem wird gelesen — es gibt keine Punktfarbe zu übertragen, selbst wenn die Quelle eine deklariert hätte, denn auch dieses Attribut wird nicht gelesen. Die Ausgabe ist eine farblose Oberfläche, was für eine Messung richtig und für eine Erhaltung des Erscheinungsbilds falsch ist.

Die Szene wird von ihrer Standardszene aus durchlaufen, jede Knotenmatrix mit der ihres übergeordneten Knotens multipliziert, und die entstehende Weltmatrix auf die Punkte angewendet. Knoten, die mit getrennter Verschiebung, Rotation und Skalierung angelegt wurden, werden dabei zuerst zu einer Matrix zusammengesetzt, nach der Quaternionen-Konvention, die glTF vorschreibt.

Das vor dem Zusammenführen zu tun, macht das Zusammenführen erst sicher. Blieben Transformationen unangewendet, würde das Zusammenlegen mehrerer Netze in eine Liste jedes Teil am Ursprung stapeln und eine Form ergeben, die mit dem Modell nichts mehr zu tun hat. Weil zuerst eingerechnet wird, sind die Zahlen, die anschließend in CloudCompare gemessen werden, die Zahlen, die die glTF-Szene tatsächlich beschrieb.

Einen Indexpuffer, unverändert übernommen. glTF speichert Dreiecke als Indizes in ein gemeinsames Positionsarray, und die Umwandlung erhält diese Struktur Element für Element, statt sie neu aufzubauen — auf diesem Weg wird nichts verschweißt, weil nichts zu reparieren ist. Eine STL-Datei, die am selben Ziel ankommt, müsste erst verschweißt werden, weil sie für jedes Dreieck drei unverbundene Punkte speichert.

Dieser Unterschied entscheidet, ob die anstehende Analyse überhaupt aussagekräftig ist. Prüfungen auf geschlossene Volumen, Normalenschätzung, Krümmung, geodätische Distanz, Laplace-Glättung und Vereinfachung setzen alle Konnektivität voraus. Die eine Ausnahme, die sich lohnt, in MeshLab im Kopf zu behalten: Exportprogramme trennen Punkte an UV- und Normalen-Nähten, und diese Duplikate überstehen die Umwandlung als eigene Einträge an identischen Koordinaten — ein Merge-Close-Vertices-Durchlauf vor einer topologischen Prüfung ist deshalb eine sinnvolle Gewohnheit.

Eine .gltf-Datei, deren Geometrie in einer separaten .bin-Datei liegt, lässt sich nicht lesen, weil eine Umwandlung mit einer Datei die zweite Datei nie sieht — die Meldung sagt das und schlägt die .glb-Version vor, die alles in einem Container hält. Eine Datei mit KHR_draco_mesh_compression stoppt mit einer Meldung, die Draco nennt, dessen Decoder hier nicht mitgeliefert wird.

Primitiven, die keine Dreieckslisten sind, werden übersprungen. glTF-Modus 4 sind Dreiecke; Streifen, Fächer, Linien und Punkte sind keine Oberflächen, die diese Umwandlung in Flächen verwandeln kann, und eine Datei, die nur solche enthält, meldet, dass keine Dreiecksgeometrie gefunden wurde, statt eine leere PLY-Datei zu erzeugen, die zwei Schritte später in der Analyse still versagt.

Soll das Modell betrachtet statt vermessen werden, ist PLY ein schlechtes Ziel: keine Materialien, keine Texturen, keine Struktur, dafür eine deutlich größere Datei. Das glTF-Modell behalten, oder nach OBJ umwandeln, wenn der Betrachter älter ist.

PLY verdient seinen Platz, wenn der nächste Schritt ein Geometriealgorithmus ist — Vereinfachung, Neuvernetzung, Lückenfüllung, Ausrichtung gegen einen Scan, eine Volumen- oder Oberflächenmessung, ein Hausdorff-Abstand zwischen zwei Versionen desselben Teils. Für diese Arbeit sind die Flachheit und die fehlende Farbe unerheblich, und das Netz im Format zu haben, für das das Werkzeug gebaut wurde, zählt mehr als alles, was die Umwandlung verwirft.

Das glTF wird gelesen, die Szene durchlaufen, die Matrizen eingerechnet, die Netze zusammengeführt und der PLY-Text geschrieben, alles als JavaScript im eigenen Browser — die Datei verlässt den Rechner nicht. Die kostenlose Nutzung erlaubt bis zu 100 MB je Datei, und die frühere Grenze ist meist der Arbeitsspeicher des Tabs selbst, weil ein ASCII-PLY vollständig aufgebaut wird, bevor der Download beginnt.

Bei Aufmaßdaten ist das kein Komfortmerkmal. Der Scan eines Baudenkmals, das Modell eines Bauteils vor einer Restaurierung oder die Geometrie eines noch nicht vorgestellten Produkts kommt oft mit Auflagen, wo sie gespeichert werden darf, und ein Hochladen bei einem beliebigen Webkonverter ist genau die Übertragung, die solche Auflagen verhindern sollen. Nachprüfen lässt sich das im Netzwerk-Reiter während einer Umwandlung, schneller als eine Erlaubnis per E-Mail einzuholen.