Polygon File Format

aus Wikipedia, der freien Enzyklopädie
(Weitergeleitet von .ply)
Polygon File Format
Dateiendung: .ply
MIME-Type: text/plain
Magische Zahl: PLY
Entwickelt von: Greg Turk, Stanford University
Erstveröffentlichung: 1994[1]
Aktuelle Version: 1.0
Art: ASCII-Format/Binärdatei
Container für: 3D-Modelle


3D-Modelle

Das Polygon File Format (kurz PLY oder auch bekannt als Stanford Triangle Format) ist ein Dateiformat zur Speicherung dreidimensionaler Daten, das ursprünglich zur Verwendung mit 3D-Scannern konzipiert wurde.

Das Format zeichnet sich aus durch eine einfache Beschreibung einzelner Objekte als Listen von Polygonen. Für Vorder- und Rückseite eines Polygons können unterschiedliche Attribute definiert werden, wie zum Beispiel: Farbe, Transparenz, Oberflächen-Normalen, Textur-Koordinaten oder Konfidenz-Werte gemessener Daten.

Eine PLY-Datei kann im ASCII-Format oder als Binärdatei gespeichert werden.

Das Digital Michelangelo Project der Stanford University verwendete das PLY-Format für einen extrem hoch aufgelösten 3D-Scan von MichelangelosDavid“-Skulptur.[2]

Dateistruktur

Die Dateien beginnen mit einem Header, der die Elemente des Polygonnetzes und ihre Typen spezifiziert. Die auf den Header folgende Liste enthält Elemente wie Vertices, Dreiecke (Faces) und Kanten.

Sowohl in der ASCII- als auch in der Binär-Version der Datei besteht der Header immer aus ASCII-Zeichen, lediglich der numerische Teil der Datei wird unterschiedlich abgespeichert. Die erste Zeile des Headers besteht nur aus der Magischen Zahl:

ply

Die zweite Zeile spezifiziert das Format der Datei und sollte einer der folgenden entsprechen:

format ascii 1.0
format binary_little_endian 1.0
format binary_big_endian 1.0

Die Kennzeichnung 1.0 bezieht sich auf die Versionsnummer des verwendeten Standards. 1.0 ist allerdings die einzige derzeit verwendete Version.

Das Wort comment zu Beginn einer Zeile ermöglicht es, Kommentare einzufügen, alles Nachfolgende in der Zeile wird ignoriert:

comment Dies ist ein Kommentar!

Mit dem element Keyword beginnt die Beschreibung verwendeter Elemente, gefolgt von deren Anzahl.

Folgendes steht zum Beispiel in einer Datei, die 12 Vertices enthält, die jeweils als Zahlentripel aus (X,Y,Z) Floats definiert sind.

element vertex 12
property float x
property float y
property float z

Weitere property-Zeilen eines Elements könnten außerdem noch andere Daten wie beispielsweise Farbwerte beschreiben. Das sieht dann zum Beispiel so aus:

property uchar red
property uchar green
property uchar blue

Beachten Sie hierbei bitte, dass Farben typischerweise den Datentyp uchar (unsigned char, also Ganzzahlen mit dem Wertebereich von 0 bis 255) haben. Wenn Farben im Header erwähnt werden, enthält jede Zeile nicht nur das Zahlentripel (X,Y,Z) für die Vertexposition, sondern zusätzlich auch noch ein Zahlentripel für die Farben (R, G, B).

Für Datentypen bestehen zwei verschiedene Notationen, die wie oben als Skalare Variablen oder als Liste angegeben werden.

char, uchar, short, ushort, int, uint, float, double sind Datentypen, die für die Skalar-Notation verwendet werden können.

Für die Listen-Notation kann aus den rein numerischen Typen int8, uint8, int16, uint16, int32, uint32, float32, float64 gewählt werden.

Ein Objekt mit zehn Polygon Faces kann mit der Listen-Notation wie folgt beschrieben werden:

element face 10
property list uchar int vertex_indices

Mit dem Wort list wird der Beginn einer Liste signalisiert, erster Eintrag der Liste (in diesem Fall vom Type uchar) beinhaltet die Anzahl an Elementen der Liste. Alle folgenden Einträge sind vom Typ int.

Folgende Zeile schließt den Header ab und wird gefolgt vom eigentlichen Inhalt der Datei:

end_header

Beispiel

Folgendes beschreibt einen einfachen Würfel in einer PLY Datei im ASCII Format und stammt aus der originalen Dateistruktur Definition von Greg Turk.[1]

ply
format ascii 1.0						{ ascii/binary, format version number }
comment made by Greg Turk				{ comments keyword specified, like all lines }
comment this file is a cube
element vertex 8						{ define "vertex" element, 8 of them in file }
property float x						{ vertex contains float "x" coordinate }
property float y						{ y coordinate is also a vertex property }
property float z						{ z coordinate, too }
element face 6							{ there are 6 "face" elements in the file }
property list uchar int vertex_indices	{ "vertex_indices" is a list of ints }
end_header								{ delimits the end of the header }
0 0 0									{ start of vertex list }
0 0 1
0 1 1
0 1 0
1 0 0
1 0 1
1 1 1
1 1 0
4 0 1 2 3								{ start of face list }
4 7 6 5 4
4 0 4 5 1
4 1 5 6 2
4 2 6 7 3
4 3 7 4 0

ASCII- oder Binär-Format

In der ASCII-Version des Formats werden Vertices und Faces jeweils in einer Zeile beschrieben, Zahlenwerte werden durch Leerzeichen getrennt. Im Binär-Format werden die numerischen Werte einfach nur kompakter zusammengefasst, durch den im Header spezifizierten endian und gegebene Datentypen der property-Attribute können die Werte so weiterhin einzeln interpretiert werden. Die property list-Notation für Polygone sieht für beide Versionen vor, dass die erste Zahl die Vertex-Anzahl des Polygons angibt und die darauf folgende Liste dann die Vertex-Indexe aufreiht.

Entstehung

Das PLY-Format wurde Mitte der 1990er von Greg Turk und anderen unter der Leitung von Marc Levoy an der Stanford University entwickelt. Die grundlegende Struktur war inspiriert vom Wavefront-OBJ-Format, das aber nicht die gewünschte Flexibilität bot, diverse Zusatzinformationen oder Gruppierungen zu formulieren. Daraufhin wurden die property- und element-Keywords eingeführt, die die Beschreibung von Vertices, Polygonen, assoziierten Daten und anderen Gruppierungen generalisieren sollten.

Verwandte Dateiformate

Wissenschaftliche Software

für unstrukturierte Dreiecksgitter im PLY-Format:

Programmbibliotheken und Quelltexte

Datensammlungen

Einzelnachweise

  1. a b Greg Turk: The PLY Polygon File Format. (Nicht mehr online verfügbar.) Archiviert vom Original am 4. Dezember 2016; abgerufen am 5. Februar 2017.  Info: Der Archivlink wurde automatisch eingesetzt und noch nicht geprüft. Bitte prüfe Original- und Archivlink gemäß Anleitung und entferne dann diesen Hinweis.@1@2Vorlage:Webachiv/IABot/www.dcs.ed.ac.uk
  2. The Digital Michelangelo Project
  3. Hubert Mara and Bartosz Bogacz: Breaking the Code on Broken Tablets: The Learning Challenge for Annotated Cuneiform Script in Normalized 2D and 3D Datasets. In: Proceedings of the 15th International Conference on Document Analysis and Recognition (ICDAR). Sydney, Australien 2019.