Convert PLY to OBJ

PLY is where scans live and OBJ is where modelling happens. Every sculpting and animation package reads OBJ without thinking about it; PLY support ranges from good, in Blender and MeshLab, to absent, in a fair number of the tools a studio pipeline actually contains. When a scan has to be retopologised, decimated by hand, sculpted on or used as a base mesh, the first step is usually a format change.

The conversion is a small one because the two formats are close in ambition. Both describe a surface as a list of vertices and a list of polygons over them, both are text, and both are old enough that everything reads them. What OBJ adds is grouping and a material reference; what PLY adds is arbitrary per-vertex properties. This conversion carries the geometry that they share.

A photogrammetry or structured-light scan stores its appearance as red, green and blue on each vertex. There is no texture, no UV layout and no image file — the colour is a property of the geometry, which is the whole reason PLY became the scanning format.

The OBJ this converter writes has v and f lines and nothing else: no vt coordinates, no mtllib reference, no accompanying .mtl. Even a hand-written material file could not hold per-vertex colour, because OBJ materials apply per face group. The practical workflow is to keep both files — do the geometry work from the OBJ, and take the colour off the PLY later by baking vertex colours to a texture in a tool that reads them.

A PLY file describes one vertex element and one face element. There is no notion of an object, a group or a part, and no name anywhere in the header for the surface itself. So the converter produces exactly one o group, and since there is no name to carry, it writes a generated one: mesh_1.

In Blender or Maya that is what appears in the outliner. On a single scan it is harmless; on a project where six scans are being combined it is a real nuisance, because every import produces an object with the same name. Rename on import, or rename the OBJ's single o line in a text editor before importing — it is the second line of the file.

This is a genuine difference between this pair and most of the others here. When an STL or an OBJ is read, coincident vertices are welded at six decimal places, because those formats routinely arrive with duplicates. When a PLY is read, its vertex array and its face indices are taken exactly as written.

That is the right behaviour for scanned data, which has already been meshed by software that made deliberate decisions about connectivity. It also means the conversion cannot clean anything up: if the scan carries duplicate vertices, unreferenced vertices or split seams, they arrive in the OBJ unchanged. The vertex count in the OBJ will match the element vertex count in the PLY header, which is a fast way to confirm the file converted the way you expected.

A PLY containing vertices and no faces is refused with a message explaining why. That file is a point cloud, which is what a scanner produces before anything meshes it, and turning points into a surface is reconstruction rather than conversion — an operation with parameters, a preview and a result somebody has to approve.

Do it where it belongs. MeshLab and CloudCompare both offer Poisson surface reconstruction and ball-pivoting; Open3D exposes both from Python; every scanner's own software has a meshing step. Convert the meshed output afterwards. A converter that silently reconstructed a surface would hand you a shape you never chose and no way to tell that it had.

PLY face lists can hold any number of indices, and meshing tools sometimes emit quads. Any face with more than three corners is fan-triangulated from its first index before being written, which is correct for convex polygons and can misbehave on concave ones.

Scan meshes are overwhelmingly triangles already, so this rarely applies. Where it does, note that the OBJ that comes out is triangles only — the writer emits three indices per f line and never reconstructs quads. If your retopology workflow wants a quad base mesh, that is something you build in the modelling application, not something a scan was ever going to provide.

A binary PLY stores a float32 coordinate in four bytes. The same number written into an OBJ takes eight to eighteen characters plus separators, so a text OBJ of a dense scan is several times the size of the file it came from, and a raw photogrammetry mesh of several million triangles produces a text file that will make an editor struggle.

Decimating first is almost always the right move, and it is a better decision made in MeshLab against the PLY than in your modelling application against the OBJ, because MeshLab's quadric edge collapse can be told to preserve boundaries and topology. Getting to a few hundred thousand triangles before conversion makes everything downstream faster and loses nothing a modeller will miss.

Expect a faceted surface. No vn lines are written, so flat face normals are computed on import; shade smooth or apply an auto-smooth angle and the scan looks like itself again. Expect no material, and assign one before anything else so the mesh is visible against the viewport.

Then the usual scan work: remove the stray islands the scanner picked up from the background, fill the holes where it could not see, and retopologise if the mesh has to be animated or subdivided. None of that is conversion work and none of it belongs in a converter — the point of this step is to get the geometry into the tool where those operations are one command each.

The OBJ is a derived file. It has the shape and none of the colour, none of the per-vertex confidence or quality values a scanner writes, and none of the normals if the PLY carried them. Every one of those is unrecoverable from the OBJ.

The pattern that works is to treat the PLY as the master and the OBJ as a working copy: model against the OBJ, and go back to the PLY whenever the appearance or the scanner metadata is needed. Both files stay on your machine either way — this conversion runs in the browser with nothing uploaded, which is worth knowing when the scan is of a client's object or a person.