STL in PLY umwandeln

Jede andere Umwandlung in dieser 3D-Gruppe gibt etwas auf. glTF verliert seine Materialien, OBJ sein MTL, 3MF seine Farbe. STL zu PLY verliert die gespeicherten Flächennormalen — und die lassen sich aus der Reihenfolge der drei Eckpunkte jedes Dreiecks exakt neu berechnen und sind in Dateien nachlässiger Exportprogramme ohnehin oft falsch. Genau deshalb ignorieren mehrere Slicer den gespeicherten Wert grundsätzlich.

Alles andere bleibt erhalten, weil es nichts weiter gab, das verloren gehen könnte. Ein STL ist eine Liste von Dreiecken ohne Farbe, ohne Einheit, ohne Namen, ohne Teile und ohne Attribute. Ein mit x, y, z und einer Flächenliste geschriebenes PLY hält genau das. Beide Formate sind sich einig darüber, was ein Modell ist — das ist in dieser Kategorie selten.

CloudCompare, MeshLab, Open3D und trimesh nehmen PLY alle als vollwertige Eingabe, weil Stanford das Format 1994 genau für diese Art von Arbeit entworfen hat: ein selbstbeschreibender Header, der beliebige Eigenschaften pro Eckpunkt und Fläche auflistet, die ein Forschungswerkzeug gerade braucht. Scanning und Photogrammetrie haben sich aus demselben Grund darauf festgelegt.

Sie lesen auch STL, und genau dort beginnt das Problem statt zu enden. Eine STL-Datei lädt, zeigt sich korrekt an und ist dabei topologisch unbrauchbar — siehe den nächsten Abschnitt. Die Umwandlung geht also nicht darum, die Datei überhaupt zu öffnen, sondern darum, ein Mesh zu bekommen, dessen Nachbarschaftsbeziehungen die Algorithmen wirklich nutzen können.

STL speichert für jedes Dreieck drei eigenständige Eckpunkte. Ein Würfel besteht so aus sechsunddreißig Eckpunkt-Einträgen für nur acht tatsächliche Positionen. Lädt man das in ein Mesh-Werkzeug und fragt, ob die Oberfläche geschlossen ist, meldet es jede einzelne Kante als Randkante — weil sich keine zwei Dreiecke einen Eckpunkt teilen, obwohl die Form überhaupt kein Loch hat.

Die Umwandlung rundet Koordinaten auf sechs Nachkommastellen, nutzt das Ergebnis als Schlüssel und fasst jede Ecke an derselben Position zu einem einzigen, von allen zugehörigen Dreiecken referenzierten Eckpunkt zusammen. Sechs Stellen liegen weit unter jeder Toleranz, die ein physisches Bauteil kennt, und weit über der Abweichung im letzten Bit, mit der zwei benachbarte Dreiecke in Gleitkommazahlen ohnehin schon uneins sind. Danach arbeiten Geschlossenheitsprüfung, Normalenschätzung, Krümmung, Vereinfachung, Glättung und Lochfüllung mit echter Nachbarschaft.

Der Header ist der zurückhaltende: ply, format ascii 1.0, ein Kommentar mit dem Namen des Schreibers, eine element-vertex-Deklaration mit drei property-float-Zeilen für x, y und z, eine element-face-Deklaration mit einer property-list-uchar-int-vertex_indices-Zeile, und end_header. Danach eine Zeile pro Eckpunkt und eine pro Dreieck.

Sonst wird nichts deklariert — keine Normalen, keine Farbe, keine Konfidenz, keine Qualität, keine eigenen Eigenschaften. Das ist Absicht: ein Header, der eine Eigenschaft verspricht, die die Datei nicht füllen kann, ist schlimmer als ein kurzer, und jedes Werkzeug, das PLY überhaupt liest, kommt mit diesem Dialekt zurecht. Wer bestimmte Eigenschaften braucht, kann sie in MeshLab nach dem Import ergänzen, statt sie hier raten zu lassen.

Jeder fünfzig Byte lange Dreieckseintrag in einer binären STL beginnt mit zwölf Byte Flächennormale. Diese zwölf Byte werden übersprungen. Was sie enthalten, ist durch die Reihenfolge der drei Eckpunkte vollständig festgelegt, sodass eine Neuberechnung exakt statt näherungsweise ist.

Das ist keine Abkürzung aus Bequemlichkeit. Gespeicherte STL-Normalen widersprechen der tatsächlichen Wicklung so häufig, dass mehrere Slicer und Mesh-Werkzeuge sie grundsätzlich verwerfen — zu viele Schreibprogramme vertauschen das Vorzeichen oder normalisieren falsch. Die Neuberechnung aus der Wicklung liefert eine einzige konsistente Antwort, und ein Mesh mit uneinheitlicher Wicklung ist ein Defekt, den man sehen will, nicht einen, der durch einen gespeicherten Wert überdeckt wird.

Jede Koordinate wird als Dezimaltext geschrieben, ein Eckpunkt pro Zeile, jedes Dreieck als führende 3 gefolgt von drei Indizes. Ein Eckpunkt, der zwölf Byte binär war, wird zu zwanzig bis sechzig Zeichen. Dagegen steht, dass das Verschweißen bereits rund fünf Sechstel der Eckpunkt-Einträge entfernt hat, die ein STL ursprünglich trug.

Beide Effekte heben sich teilweise auf, und das Ergebnis hängt vom konkreten Modell ab. Verlässlich vorhersagbar ist die STL-Seite: genau 84 + 50n Byte für n Dreiecke, sodass ein aus einem Scan gewonnenes Mesh mit zwei Millionen Dreiecken schon vor der Umwandlung 100 MB groß ist und sich eine Vereinfachung davor lohnt. Wird die entstandene PLY-Datei zu unhandlich, ist ein erneutes Speichern aus MeshLab als binary_little_endian ein einzelner Schritt.

Der häufigste Anlass für diese Umwandlung ist die Abweichungsanalyse: Ein Teil wurde nach einem STL gedruckt oder gefräst, anschließend gescannt, und jemand braucht den Unterschied. CloudCompares Cloud-to-Mesh-Abstand will die Referenz als Mesh mit Flächen — genau das entsteht hier —, und den Scan als Punktwolke, was der Scanner ohnehin liefert.

Zwei Dinge sind dabei praktisch zu beachten. Beide Datensätze müssen vorher ausgerichtet werden — eine grobe Auswahl korrespondierender Punkte gefolgt von ICP ist der übliche Weg —, und sie müssen sich einen Maßstab teilen, den keines der beiden Formate deklariert. Liegt der Scan in Millimetern vor und war das STL in Zoll exportiert, konvergiert die Ausrichtung auf etwas Plausibles und Falsches. Eine bekannte Abmessung an beiden vorab zu prüfen ist deshalb sinnvoller, als einer Farbkarte blind zu vertrauen.

PLY ist das Format, in dem 3D-Scans ankommen, weil es Farbe pro Eckpunkt trägt — genau das lässt ein photogrammetrisches Mesh wie das aufgenommene Objekt aussehen. Hier taucht davon nichts auf, weil ein STL keine Farbe zu geben hatte.

Die inoffizielle Ausnahme sei genannt: Eine Handvoll Werkzeuge kodiert eine fünfzehn Bit tiefe Farbe in die beiden Attributbytes am Ende jedes STL-Dreieckseintrags, in zwei zueinander inkompatiblen Konventionen. Diese Bytes werden nicht gelesen. Es lässt sich nicht feststellen, welche Konvention eine Datei verwendet hat, und zu raten würde falsche Farben auf ein Mesh legen, das gerade vermessen werden soll.

Geht es an einen Slicer oder eine Druckerei, nicht umwandeln — die wollen STL oder 3MF, und die PLY-Unterstützung ist dort uneinheitlich. Geht es an einen Browser-Viewer, ist glTF das richtige Ziel und PLY das falsche.

Umwandeln lohnt sich, wenn der nächste Schritt ein Algorithmus ist: eine Abstandsberechnung, eine Vereinfachung, ein Remeshing, eine Lochfüllung, eine Volumen- oder Flächenberechnung, eine Ausrichtung gegen Scandaten. Der ganze Wert des Schritts liegt im Verschweißen und im Format, das das Werkzeug erwartet, und alles läuft im Browser ohne Upload — was zählt, wenn die Referenzgeometrie das unveröffentlichte Bauteil von jemandem ist.