Reference Formats
PLY
A simple, extensible format for storing 3D scanner and polygon-mesh data — vertices, faces, and arbitrary per-element properties like color or normals — in either ASCII or binary form.
Extension
.ply
Full name
Polygon File Format (Stanford Triangle Format)
Introduced
1994
Vendor
Stanford University Computer Graphics Laboratory (Greg Turk)
What is inside the container
A PLY file has a plain-text header declaring its elements (typically vertex and face) and the properties attached to each, followed by the actual data in either readable ASCII or compact little/big-endian binary. That declarative header is what makes it extensible: unlike OBJ, a PLY file can carry arbitrary custom per-vertex properties (RGB color, normals, scanner confidence values, curvature) without breaking compatibility, which is why it remains a default output format for 3D scanning and point-cloud tools.
How to open it
For archives
PLY is a reasonable long-term archival choice for scan-derived 3D data: its specification is simple, well-documented, and has been stable since 1994, and both ASCII and binary variants are widely supported by open-source tooling, so a DAM can store PLY masters without the vendor lock-in risk of a proprietary CAD format. For very large scanner point clouds, keep the binary variant for storage efficiency and generate a decimated preview mesh for browsing.
PLY came out of the Stanford Computer Graphics Laboratory in 1994, written by Greg Turk under Marc Levoy’s direction to solve a practical problem: the lab’s 3D scanners produced polygon meshes and point clouds with varying custom data — color, confidence scores, normals — and existing formats like Wavefront OBJ had no clean way to carry arbitrary per-vertex properties without a format revision each time. PLY’s header-driven “element and property” design solved that by letting any producer declare exactly what data each vertex or face carries, which is why it’s still called the Stanford Triangle Format and remains a default export for photogrammetry and LiDAR/3D-scanning software three decades later.
For a DAM, PLY shows up most often as raw output from 3D scanning, photogrammetry, or point-cloud capture workflows — heritage digitization, product scanning, reality-capture for AEC site documentation — before that data is cleaned up and converted into a game- or web-ready mesh format. Because PLY files can carry per-vertex color and be enormous (millions of points from a single scan), a DAM handling them typically needs to generate a decimated preview and extract basic stats (vertex/face count, bounding box) at ingest, rather than relying on a generic 3D thumbnailer to open the full-resolution file.
Frequently asked
What's the difference between ASCII and binary PLY files?
Both use the same header structure, but ASCII PLY stores data as human-readable text (larger, easier to inspect) while binary PLY stores it as raw little- or big-endian bytes (much smaller, faster to load) — most 3D scanning software defaults to binary for large datasets.
Why do 3D scanners typically output PLY instead of OBJ?
PLY's declarative header lets it carry arbitrary custom per-vertex properties — color, normals, scan confidence — that OBJ has no standard way to represent, which matters for scanner and photogrammetry pipelines that need more than just geometry.
Can PLY store point clouds without any faces, not just meshes?
Yes — a PLY file with only a vertex element and no face element is a valid point cloud, which is one reason it's a common interchange format between LiDAR/scanning tools and mesh-reconstruction software.
How should a DAM preview a very large PLY point cloud?
Generate a decimated or downsampled preview mesh at ingest time using a tool like Open3D or MeshLab, rather than attempting to render the full-resolution file (which can be millions of points) on every preview request.
Is PLY suitable for long-term archival of 3D scan data?
Yes — its specification has been stable and openly documented since 1994, with broad open-source tool support, making it a lower-risk archival choice than a proprietary scanner-specific format.
Does PLY support texture maps like a UV-mapped mesh format?
Not natively in the core spec the way OBJ/MTL does — PLY is built around per-vertex properties like color rather than UV-mapped external textures, though some tools add texture-coordinate extensions.
What software can convert PLY to a web-friendly format like glTF?
Blender, MeshLab, and command-line libraries such as Assimp or trimesh can all convert PLY meshes to glTF or OBJ for web viewing or game-engine use.
Where does the name 'Stanford Triangle Format' come from?
PLY was developed at the Stanford Computer Graphics Laboratory in the mid-1990s by Greg Turk for the lab's own 3D scanning research, so it's commonly called the Stanford Triangle Format alongside its formal name, the Polygon File Format.
Sources
- PLY (the Polygon File Format, also called the Stanford Triangle Format) originated at the Stanford Computer Graphics Laboratory around 1994, written by Greg Turk under Marc Levoy, to store 3D scanner data with arbitrary custom properties. checked 2026-08-07 — Library of Congress — Polygon File Format (PLY) Family
- PLY was designed with extensible element/property declarations because Wavefront OBJ lacked a standard way to represent arbitrary per-vertex data. checked 2026-08-07 — Wikipedia — PLY (file format)