Why the Same PLY File Opens in One Program and Not Another

A PLY file that opens perfectly in one program and fails in the next is not a broken file. It is usually a file whose contents are not what the second program assumed.

That is possible because PLY works differently from the formats around it. Its header is a schema, and each file writes its own.

What is a PLY file?

PLY stands for Polygon File Format, and it is also called the Stanford Triangle Format after the university where it was written in the mid 1990s to store the output of 3D scanners. Its defining design decision is that the format does not fix what a file contains. Instead, each file opens with a header that declares its own structure.

Here is a complete header, from a file we exported ourselves:

ply
format ascii 1.0
comment https://github.com/mikedh/trimesh
element vertex 8
property float x
property float y
property float z
property double s
property double t
element face 12
property list uchar int vertex_indices
end_header

Read it as a declaration. There are two elements, which are the kinds of thing in this file: eight vertices and twelve faces. Each vertex carries five properties, three coordinates plus s and t. Each face carries a list of vertex indices. After end_header, the data follows in exactly that order.

That is the whole idea, and everything else in this article follows from it. A format where the file declares its own schema can hold anything, and a reader can only handle the parts it was written to expect.

Why does the same .ply open in one program and not another?

Because the programs disagree about what a PLY is allowed to be, and the header is where that disagreement becomes visible. Four structural causes account for most of it, and all four are diagnosable from the header alone.

There is no face element. A PLY with only element vertex is a point cloud: coordinates with nothing connecting them. Point cloud tools open it happily, and mesh tools reject it, sometimes bluntly. SolidWorks states the rule outright in its documentation, that imported PLY files must have faces and that it cannot import PLY files with no faces. That is not a bug report, it is the specification of what the importer accepts.

The encoding is one the reader does not do. Support for binary_big_endian is noticeably thinner than for the other two. If a file opens in one tool and fails silently in another, the format line is worth checking before anything else.

There are properties the reader does not recognise. This is where PLY’s flexibility turns on you. Readers respond to unknown properties in three quite different ways: ignore them, drop them along with whatever else was on that element, or keep them as generic numeric fields. CloudCompare takes the third approach and exposes unknown floats as scalar fields you can visualise, which makes it a useful tool for inspecting a file nothing else will open.

The header promises more than the file delivers. Some exporters skip degenerate faces while writing and do not go back to correct the count in the header. A permissive C++ parser reads until the data ends and renders what it got. A strict reader in a browser tries to read the bytes the header promised, runs off the end of the buffer and throws a fatal error, giving you an empty scene for a file that opened fine elsewhere.

Is it a mesh, a point cloud, or a Gaussian splat?

The header decides, and a Gaussian splat PLY is unmistakable once you know what to look for. A Gaussian splat is a scene representation made of thousands or millions of translucent ellipsoids rather than a surface, produced by training against photographs, and the PLY format was adopted to carry it because a file that declares its own properties could be made to hold the parameters without changing anything.

The reference implementation writes these vertex properties, in this order:

Property	What it is
x, y, z	Position of the splat
nx, ny, nz	Normals, written but filled with zeros
f_dc_0 to f_dc_2	The base colour, as the constant term of a spherical harmonic
f_rest_0 onward	Higher order terms, giving colour that changes with viewing angle
opacity	How transparent the splat is
scale_0 to scale_2	The ellipsoid’s size along each axis, stored as logarithms
rot_0 to rot_3	Its orientation, as a quaternion

Two details in that table cause real trouble.

The normals are present and they are zero. The writer allocates the fields and fills them with zeros, so a mesh viewer that reads the file does not find missing normals, it finds normals pointing nowhere. Combined with the absence of any red, green or blue property, this is why opening a splat in a conventional viewer gives the widely reported result of a cloud of black dots in roughly the right shape.

The scales are logarithms, not lengths. The training code applies an exponential to recover the real size and stores the logarithm on the way out, for numerical reasons during training. Anything that reads scale_0 as a length and multiplies it will produce nonsense.

Is PLY really smaller than STL?

Yes, and by a margin that depends entirely on how dense the mesh is. This is worth pinning down because published figures vary a lot, and the variation is not noise.

We measured the same two formats on two objects, writing each from the same source geometry:

Object	Faces	STL	PLY	PLY smaller by
Icosphere	5,120	64,084 bytes	24,560 bytes	61.7 per cent
Box	12	684 bytes	628 bytes	8.2 per cent

The mechanism explains the spread. STL has no way to record that two triangles share a corner, so it writes out three full coordinate triples for every triangle, and a vertex used by six triangles is stored six times. PLY stores each vertex once and refers to it by index. The saving is therefore proportional to how many triangles meet at the average vertex, which rises with mesh density and is near zero on a box where the header is most of the file.

A published comparison of intraoral scan files in dental research reports PLY at up to 62 per cent smaller than STL, which is close to our dense case and unsurprising, since intraoral scans are dense meshes. The number is real. It is a fact about dense meshes rather than a fact about the two formats, and quoting it for a coarse model would be wrong by a factor of seven.

Full results, method and limitations: Where a watertight model stops being watertight when it changes format. The raw output is published as JSON, produced by scripts/measure-watertight-conversion.py.

The same property has a second consequence that matters more than file size: because STL discards vertex sharing, any reader has to reconstruct it, and different readers reconstruct it differently. That is the subject of what “same vertex” means in an STL, and it is the reason a file can be watertight in one program and full of holes in the next.

Why do the colours come out wrong?

Two separate causes, and they produce different symptoms.

The channels are named something else. The conventional property names are red, green and blue. Some photogrammetry software writes diffuse_red, diffuse_green and diffuse_blue instead. Readers that search for the standard names find nothing, and what happens next depends on the reader: some leave the colour array empty and show a colourless model, and others have been reported to render the whole object in a flat yellow. The fix is to edit the property names in the header, which is trivial for an ASCII file and needs a small script for a binary one.

The colour space is assumed rather than declared. PLY stores an unsigned byte from 0 to 255 per channel and says nothing about what those numbers mean. Scanning software generally writes sRGB values. A reader that treats them as linear will render the model noticeably darker and less saturated. Nothing is lost and nothing is corrupt; the numbers are simply being interpreted against a different curve than the one they were written with.

Both of these are the same underlying issue as the encoding question above. PLY declares structure and not meaning, and meaning is where readers diverge.

Can a PLY carry a texture image?

Not in any standard way, and the workarounds do not agree with each other. The specification defines no mechanism for applying a 2D image to geometry, so two conventions grew up independently:

• A TextureFile comment. The header carries a comment naming an external image, and vertices carry texture_u and texture_v properties. This comes from the VCGLib lineage and is used by MeshLab and several research pipelines. Readers that ignore comments, which is most of them, see an untextured mesh.
• Per-vertex s and t properties. No comment, no image reference, just UV coordinates on each vertex. This is what Blender and trimesh write, and you can see it in the header at the top of this article: property double s and property double t with no mention of an image anywhere.

Neither convention travels. The second one cannot, since the file never names an image at all. And storing UVs per vertex rather than per face corner breaks down at a UV seam, where one vertex needs two different texture coordinates and can only hold one.

When we exported a textured model to five formats and reloaded each, the PLY came back with no texture even without moving the file, which is the honest summary: a PLY is an excellent carrier for per-vertex colour and a poor one for image textures. If a texture has to survive, that is what OBJ with its companion MTL file or a self contained GLB are for.

Full results, method and limitations: What happens to a texture when only the model file is sent on. The raw output is published as JSON, produced by scripts/measure-texture-survival.py.

Where PLY fits

Use PLY when the per-vertex data is the point: scan colour, normals, confidence values, classification labels, anything measured at each point rather than painted across a surface. It is the natural archive format for a capture, and converting it to STL for printing throws that data away, which is fine as long as you keep the PLY.

That conversion is also where the harder question starts. A scan is not a solid, and turning one into something a slicer will accept means deciding whether to patch it or regenerate it, which is a different decision from the one most repair tools present. That is worked through in when a broken mesh is worth repairing.

Use something else when you need a textured asset to arrive intact somewhere, or when the destination is a slicer that only wants a closed surface. The trade-offs between the mesh formats are laid out in OBJ against STL, and if you just want to know which program reads what, our format compatibility table is generated from the tool directory.

And if a PLY will not open: read the header first. It is three lines of work and it is nearly always the answer.