Convert 3MF to PLY

There is a distinct job that is not printing and not modelling: finding out whether a part is what it is supposed to be. Is the wall actually 1.6 mm where the drawing says so. What volume of material will this consume. Does the supplier’s file match the geometry that was signed off. How far has a printed part drifted from the model, once you have scanned it back.

None of that happens in a slicer, and it happens naturally in MeshLab, CloudCompare, Open3D and trimesh — all of which treat PLY as the format that needs no explanation. So the conversion is a step in a measurement rather than a delivery, and the questions worth answering here are about fidelity of numbers rather than about appearance.

PLY records no unit. Neither does STL, OBJ or glTF. A scan from one device is in millimetres, from another in metres, and a mesh from a modelling package is in whatever the artist was thinking in — so a volume computed on a typical PLY is a number whose unit you have to establish separately.

A 3MF is the exception, because the format requires the model element to declare one: micron, millimetre, centimetre, inch, foot or metre. The reader resolves it, multiplying by 25.4 for inches and by 1000 for metres, so the PLY that comes out is in millimetres whatever the source said. MeshLab’s reported volume is then cubic millimetres and its measured distances are millimetres, without a conversion factor written on a sticky note.

Some sources on this site are welded on the way in, because an STL stores three unshared vertices per triangle and would otherwise produce absurd files. A 3MF stores an indexed vertex list already, so nothing is welded and nothing is renumbered within an object — the positions and the triangle indices come across as the file had them.

That is exactly the property a comparison needs. If the source reports 48,212 vertices, the PLY header says 48,212, and a difference is a real difference rather than an artefact of the conversion. It also means any duplicate vertices the authoring tool left in place are still there, which is worth knowing before running an algorithm that assumes a clean manifold — merge with an explicit tolerance in your tool rather than assuming it has been done.

A 3MF separates what an object is from where it goes: the resources section holds the meshes, and the build section places each one with a transform. The reader applies those transforms to the vertices, because PLY has no way to express a placement.

The consequence is a measurement trap worth naming. The coordinates in the PLY are plate coordinates, not part coordinates, so a part arranged at the back left of a 256 mm bed sits nowhere near the origin and its bounding box is correct while its position is meaningless as a description of the part. For volume, area and thickness that does not matter. For registration against a scan, or for comparing two exports of the same part, translate each mesh to its own centroid first — `mesh.apply_translation(-mesh.centroid)` in trimesh — or the alignment step starts from a hundred-millimetre offset it has to discover.

PLY holds a single vertex list and a single face list. A 3MF holding three named objects, or one object placed five times, therefore produces one surface with the vertex lists concatenated and the face indices offset accordingly.

The geometry is intact and the identity is gone: no names, no object boundaries, no per-object metadata. Connected-component analysis recovers the pieces — MeshLab’s Split in Connected Components and `trimesh.Mesh.split()` both do it — but a volume computed on the merged file is the total across everything on the plate, which is the wrong answer to "how much material is this part". Convert one object at a time if the numbers are per-part, by deleting the others in a slicer and re-saving.

A 3MF object may be defined as an assembly — a list of `<components>` referencing other objects, each with its own transform — rather than as a mesh. The reader resolves those references recursively and multiplies each transform into the one above it, so a part nested two levels down lands where the file says it goes rather than at the origin.

That was not always the case, and the failure it replaced is worth naming because it was silent. Walking mesh elements only meant the build item named an object with no geometry of its own, the model came out empty, and the fallback then emitted the part objects at the origin with every placement lost — a two-part assembly arriving as two overlapping parts. Today a file that yields no triangles anywhere raises "No triangle geometry was found in this 3MF" instead, and a component chain that references itself is cut rather than followed into a stack overflow.

The header always reads `format ascii 1.0`. There is no binary option, so every coordinate is written as decimal digits and every face as a line beginning with 3. Format summaries — including this site’s — describe PLY as a binary format, and that is true of the specification and not of what comes out of here.

The size difference is substantial: a packed float32 coordinate is four bytes and its written form is ten to fifteen characters. A 3MF is compressed XML, so a package of a few megabytes routinely expands into a PLY several times larger. Everything reads the result and `head -20` shows you the header, which is a fair trade for a file you are about to load into an analysis tool anyway. If you need it packed, MeshLab and trimesh both write binary PLY on re-save.

Colour groups, base materials, per-triangle property assignments, object names, print settings, support enforcers, modifier meshes, the printer profile, the plate definition, the thumbnail and every scrap of slicer metadata. None of it is read, and the PLY declares only x, y and z properties with no colour, normals or texture coordinates.

For measurement that is mostly irrelevant — you are asking about geometry — with one exception worth flagging. If the part is multi-material, the boundary between materials is expressed as triangle property assignments, and after conversion there is no way to tell one region from another. Measuring the volume of the flexible section alone is a question this file cannot answer.

MeshLab’s Compute Geometric Measures gives surface area, volume, the bounding box and the centre of mass in one pass, and its topological measures report the number of connected components, boundary edges and non-manifold edges — which together answer both "how much material" and "is this actually a solid". Its Distance from Reference Mesh compares two meshes vertex by vertex and produces a coloured error map.

CloudCompare is the better tool when one side is a scan: its cloud-to-mesh distance takes the scanned points and the converted PLY and reports signed distances with a histogram, which is the standard way to show that a printed part is 0.3 mm undersize across one face. Both of those numbers are in millimetres, because the 3MF said so, and that is the whole reason this conversion is worth doing rather than exporting an STL.

In this browser tab. The archive is decompressed and the model XML parsed by JavaScript running in the page, with no WebAssembly module to fetch, no upload, no account and no daily allowance. The network tab during a conversion is how to confirm it.

Print files are frequently somebody else’s intellectual property — a customer’s part, a supplier’s geometry, a component under a non-disclosure agreement — and the quality-assurance job on this page is exactly the situation where that is true. A conversion that never sends the file is the only version of this workflow that does not need a conversation with somebody about it.