Convert STL to PLY

Every other pair in this set gives something up. glTF loses its materials, OBJ loses its MTL, 3MF loses its colour. STL to PLY loses the face normals, and those are computed from the winding order by every reader that needs them and are notoriously wrong in files produced by careless exporters, which is why several slicers ignore the stored value entirely.

Everything else survives because there was nothing else. An STL is a list of triangles with no colour, no units, no names, no parts and no attributes. A PLY written with x, y and z and a face list holds exactly that. The two formats agree on what a model is, which is a rare thing in this category.

CloudCompare, MeshLab, Open3D and trimesh all take PLY as a first-class input, because Stanford designed it in 1994 for exactly this kind of work: a self-describing header listing whatever per-vertex and per-face properties a research tool happens to need. Scanning and photogrammetry standardised on it for the same reason.

They also read STL, and that is where the trouble starts rather than ends. An STL loads, displays and looks correct while being topologically useless — see the next section. Converting is not about getting the file open; it is about getting a mesh whose connectivity the algorithms can rely on.

STL stores three independent vertices for every triangle. A cube is thirty-six vertex records for eight positions. Load that into a mesh tool and ask whether the surface is closed and it will tell you every single edge is a boundary edge, because no two triangles share a vertex — even though the shape has no holes at all.

The conversion rounds coordinates to six decimal places, uses that as a key, and collapses every corner at the same position into one shared vertex referenced by all its triangles. Six places is far below any tolerance a physical part cares about and far above the last-bit disagreement two adjacent triangles have in a float. Afterwards, manifold checks, normal estimation, curvature, decimation, smoothing and hole filling all operate on real adjacency.

The header is the conservative one: ply, format ascii 1.0, a comment naming the writer, an element vertex declaration with three property float lines for x, y and z, an element face declaration with one property list uchar int vertex_indices line, and end_header. Then one line per vertex and one line per triangle.

Nothing else is declared — no normals, no colour, no confidence, no quality, no custom properties. That is deliberate: a header that promises a property the file cannot fill is worse than a short one, and every reader that handles PLY at all handles this dialect. If your pipeline expects specific properties, MeshLab can add them after import rather than the converter guessing at them.

Each fifty-byte triangle record in a binary STL begins with twelve bytes of face normal. Those twelve bytes are skipped. The information they hold is fully determined by the order of the three vertices, so recomputing it is exact rather than approximate.

This is not a shortcut taken for convenience. Stored STL normals disagree with the winding often enough that several slicers and mesh tools discard them as a matter of policy, precisely because so many writers get the sign or the normalisation wrong. Recomputing from the winding gives one consistent answer, and a mesh whose winding is inconsistent is a defect you want to see rather than one you want papered over by a stored value.

Every coordinate is written as decimal text, one vertex per line, and every triangle as a leading 3 followed by three indices. A vertex that was twelve bytes of binary becomes twenty to sixty characters. Against that, the welding has already removed roughly five sixths of the vertex records an STL carried.

The two effects partly cancel and the outcome is model-dependent. What is predictable is the STL side: exactly 84 + 50n bytes for n triangles, so a two-million-triangle scan-derived mesh is 100 MB before conversion and is worth decimating first. If the resulting PLY is unwieldy, saving it back out of MeshLab as binary_little_endian is a one-step fix.

The most common reason this conversion happens is deviation analysis: a part was printed or machined from an STL, then scanned, and somebody needs the difference. CloudCompare's cloud-to-mesh distance wants the reference as a mesh with faces, which is what this produces, and the scan as points, which is what the scanner produced.

Two practicalities. The two datasets have to be aligned first — a coarse point-pair pick followed by ICP is the standard route — and they have to share a scale, which neither format declares. If the scan is in millimetres and the STL was exported in inches, the alignment will converge on something plausible and wrong, so check a known dimension on both before trusting a colour map.

PLY is the format 3D scans arrive in because it carries per-vertex colour, and that is what makes a photogrammetry mesh look like the object it came from. None of that appears here, because an STL had no colour to give.

The unofficial exception is worth naming: a handful of tools encode a fifteen-bit colour into the two attribute bytes at the end of each STL triangle record, in two mutually incompatible conventions. Those bytes are not read. There is no way to tell which convention a file used, and guessing would put wrong colours on a mesh somebody is about to measure.

If the destination is a slicer or a print bureau, do not convert — they want STL or 3MF, and PLY support in that world is uneven. If the destination is a browser viewer, glTF is the right target and PLY is the wrong one.

Convert when the next step is an algorithm: a distance computation, a decimation, a remesh, a hole fill, a volume or surface area, an alignment against scanned data. The whole value of the step is the welding and the format the tool expects, and it runs entirely in your browser with no upload, which matters when the reference geometry is somebody's unreleased part.