PLY in OBJ umwandeln

Ein Landesamt für Denkmalpflege oder ein Vermessungsbüro, das eine Fassade oder ein Portal per Streifenlicht- oder Photogrammetrie-Scan dokumentiert, liefert das Ergebnis fast immer als PLY: eine Punktwolke mit Farbinformation je Eckpunkt, gefolgt von einer vermaschten Oberfläche. Für die reine Dokumentation reicht das. Für alles, was danach kommt — ein Ausstellungsmodell, eine Rekonstruktion für die Bauforschung, eine Vorlage zum Retopologisieren —, verlangt die Software OBJ.

Der Grund liegt nicht am Format selbst, sondern an der Werkzeugkette. Jede Modellierungs- und Sculpting-Anwendung liest OBJ ohne nachzudenken; die PLY-Unterstützung reicht von gut, in Blender und MeshLab, bis nicht vorhanden, in einem guten Teil dessen, was ein Ausstellungshaus oder ein Ingenieurbüro tatsächlich im Einsatz hat.

Beide Formate beschreiben eine Fläche als Liste von Eckpunkten über einer Liste von Dreiecken, beide sind Textformate, und beide sind alt genug, dass praktisch alles sie liest. Was OBJ zusätzlich mitbringt, ist Gruppierung und ein Materialverweis; was PLY zusätzlich mitbringt, sind beliebige Eigenschaften je Eckpunkt — allen voran die Farbe, die eine Punktwolke überhaupt erst zu einem Aufmaß macht.

Diese Umwandlung überträgt genau das, was beide Formate gemeinsam haben: die reine Geometrie. Alles, was PLY zusätzlich trägt, bleibt in der PLY-Datei zurück, weil OBJ dafür schlicht kein Feld hat.

Ein photogrammetrischer oder Streifenlicht-Scan speichert seine Erscheinung als Rot-, Grün- und Blauwert an jedem Eckpunkt. Es gibt keine Textur, kein UV-Layout und keine Bilddatei — die Farbe ist eine Eigenschaft der Geometrie selbst, und genau das hat PLY überhaupt erst zum bevorzugten Scanformat gemacht.

Das hier erzeugte OBJ enthält nur v- und f-Zeilen, sonst nichts: keine vt-Koordinaten, kein mtllib-Verweis, keine begleitende .mtl. Selbst eine von Hand geschriebene Materialdatei könnte keine Vertexfarbe tragen, weil OBJ-Materialien nur je Flächengruppe gelten. Der praktische Weg ist, beide Dateien zu behalten — die Geometriearbeit am OBJ ausführen und die Farbe später aus der PLY in eine Textur backen, mit einem Werkzeug, das Vertexfarben liest.

Eine PLY-Datei beschreibt genau ein Vertex-Element und genau ein Face-Element. Es gibt darin weder den Begriff eines Objekts noch einer Gruppe, und im Kopfbereich steht nirgends ein Name für die Fläche selbst. Der Konverter erzeugt deshalb exakt eine o-Gruppe, und da es keinen Namen zu übernehmen gibt, schreibt er einen erzeugten: mesh_1.

In Blender oder Maya erscheint genau das im Outliner. Bei einem einzelnen Bauwerksscan ist das folgenlos; bei einem Projekt, das sechs Scans einer Kirche oder eines Portals zusammenführt, wird es lästig, weil jeder Import ein Objekt mit demselben Namen erzeugt. Beim Import umbenennen, oder die einzelne o-Zeile im Texteditor ändern, bevor der Import läuft — sie steht als zweite Zeile der Datei.

Das ist ein echter Unterschied zu den meisten anderen Paaren hier. Wird eine STL oder ein OBJ eingelesen, werden zusammenfallende Eckpunkte auf sechs Nachkommastellen verschmolzen, weil solche Dateien regelmäßig mit Duplikaten ankommen. Wird eine PLY eingelesen, werden ihr Eckpunkt-Array und ihre Face-Indizes exakt so übernommen, wie sie geschrieben stehen.

Das ist für gescannte Daten das richtige Verhalten, weil die Vermaschungssoftware bereits bewusste Entscheidungen über die Verbindungen getroffen hat. Es heißt auch, dass die Umwandlung nichts glättet: Trägt der Scan doppelte Eckpunkte, unreferenzierte Punkte oder aufgetrennte Nähte, kommen sie unverändert im OBJ an. Die Eckpunktzahl im OBJ stimmt dann exakt mit der Vertex-Anzahl im PLY-Kopf überein — ein schneller Weg zu bestätigen, dass die Umwandlung getan hat, was erwartet wurde.

Eine PLY-Datei mit Eckpunkten und ohne Flächen wird mit einer erklärenden Meldung abgelehnt. Diese Datei ist eine Punktwolke, also das, was der Scanner liefert, bevor überhaupt etwas vermascht wurde, und aus Punkten eine Fläche zu machen, ist Rekonstruktion und keine Umwandlung — ein Vorgang mit Parametern, einer Vorschau und einem Ergebnis, das jemand freigeben muss.

Das gehört an die Stelle, wo es hingehört. MeshLab und CloudCompare bieten beide Poisson-Rekonstruktion und Ball-Pivoting an, Open3D stellt beides aus Python zur Verfügung, und jede Scanner-Software hat einen eigenen Vermaschungsschritt. Erst danach umwandeln. Ein Konverter, der eine Fläche still rekonstruiert, würde eine Form liefern, die niemand ausgewählt hat, ohne dass jemand es merken könnte.

PLY-Facelisten können eine beliebige Anzahl von Indizes tragen, und Vermaschungssoftware erzeugt gelegentlich Vierecke. Jede Fläche mit mehr als drei Ecken wird vor dem Schreiben von ihrem ersten Index aus fächerförmig trianguliert, was bei konvexen Flächen korrekt ist und bei konkaven Flächen fehlgehen kann.

Scan-Vermaschungen bestehen ganz überwiegend schon aus Dreiecken, sodass dies selten greift. Wo es doch vorkommt: Das entstehende OBJ ist ausschließlich Dreiecke — der Schreiber gibt je f-Zeile drei Indizes aus und rekonstruiert nie Vierecke. Braucht die Retopologie ein Viereck-Basisnetz, entsteht das in der Modellierungssoftware, nicht in einem Scan, der es nie geliefert hat.

Eine binäre PLY speichert eine Float32-Koordinate in vier Byte. Dieselbe Zahl als OBJ geschrieben braucht acht bis achtzehn Zeichen plus Trennzeichen, ein Text-OBJ eines dichten Scans ist also ein Vielfaches der Ausgangsdatei — eine unbearbeitete Photogrammetrie-Vermaschung mit mehreren Millionen Dreiecken erzeugt eine Textdatei, an der ein gewöhnlicher Editor scheitert.

Vorher zu dezimieren ist fast immer die bessere Entscheidung, und sie lässt sich in MeshLab gegen die PLY besser treffen als hinterher gegen das OBJ in der Modellierungssoftware, weil MeshLabs quadric edge collapse gezielt Ränder und Topologie erhalten kann. Auf einige Hunderttausend Dreiecke vor der Umwandlung zu kommen, macht alles Folgende schneller und kostet nichts, was eine Modellierung ohnehin bräuchte.

Zu erwarten ist eine facettierte Oberfläche. Es werden keine vn-Zeilen geschrieben, deshalb berechnet die Anwendung beim Import flache Flächen-Normalen; Smooth Shading oder ein Auto-Smooth-Winkel bringt den Scan wieder zu seinem gewohnten Aussehen zurück. Zu erwarten ist auch kein Material — eines zuzuweisen, ist der erste sinnvolle Schritt, damit die Fläche im Viewport überhaupt sichtbar wird.

Danach folgt die übliche Scan-Nacharbeit: streunende Inseln entfernen, die der Scanner vom Hintergrund mitgenommen hat, Löcher schließen, wo er nicht hinsah, und retopologisieren, wenn das Modell animiert oder unterteilt werden soll. Nichts davon ist Umwandlungsarbeit und gehört auch nicht in einen Konverter — der Sinn dieses Schritts ist, die Geometrie überhaupt erst in das Werkzeug zu bringen, in dem all das ein einzelner Befehl ist.

Ein einzelner Scan erfasst selten ein ganzes Bauteil — ein Kirchenportal wird üblicherweise von mehreren Standpunkten aus aufgenommen, weil Tiefen, Nischen und Verzierungen sich aus einem einzigen Blickwinkel nicht erschließen. Jeder dieser Teilscans kommt als eigene PLY-Datei mit eigenem Koordinatensystem an, und die Ausrichtung zueinander geschieht meist in der Scan-Software selbst, bevor überhaupt eine OBJ-Datei entsteht.

Werden die einzelnen Teile erst nach der Umwandlung in Blender zusammengesetzt, hilft es, jeden Import sofort umzubenennen, bevor der nächste hinzukommt — sechs Objekte namens mesh_1 im selben Outliner sind sonst kaum auseinanderzuhalten, gerade wenn zwischen dem Import des ersten und des letzten Teils mehrere Tage liegen und die Reihenfolge nicht mehr präsent ist.

Wenn ein Museum oder eine Denkmalpflegebehörde einen Scan für eine Rekonstruktion oder ein Ausstellungsmodell weitergibt, geht es der Empfängerin selten um den Scan als Beleg, sondern um die Form, die er zeigt. Ein 3D-Druck-Dienstleister oder ein Modellbauer für ein Anschauungsmodell will eine Datei, die seine Software ohne Umweg öffnet — genau die Rolle, die dieses OBJ übernimmt.

Die Farbdaten der PLY spielen für diesen Anwendungsfall meist keine Rolle, weil ein physisches Modell ohnehin bemalt oder mit einer eigenen Oberfläche versehen wird. Das ist einer der Fälle, in denen der Verlust der Vertexfarbe nicht bedauert werden muss, sondern schlicht folgenlos bleibt.

Das OBJ ist eine abgeleitete Datei. Es hat die Form und keine der Farben, keine der Konfidenz- oder Qualitätswerte je Eckpunkt, die ein Scanner schreibt, und keine der Normalen, falls die PLY welche trug. Jedes davon ist aus dem OBJ nicht wiederherstellbar.

Bewährt hat sich, die PLY als Master und das OBJ als Arbeitskopie zu behandeln: gegen das OBJ modellieren, für Erscheinung oder Scanner-Metadaten wieder in die PLY schauen. Beide Dateien bleiben ohnehin auf dem eigenen Rechner — diese Umwandlung läuft im Browser, ohne dass etwas hochgeladen wird, was bei einem Scan eines Kulturdenkmals oder eines Kundenobjekts nicht nur bequem, sondern häufig ausdrücklich verlangt ist.