Convert PLY to 3MF

Both formats will get a scan into a slicer, and 3MF gets it there with more of the truth attached. It declares its unit in the model element, so the slicer does not fall back to a house convention. It stores each vertex once and references it from every triangle, where an STL repeats three full vertices per triangle. And it is an OPC package with a content-type map and a relationship file, which means a malformed one fails loudly rather than opening as something odd.

None of that changes the print. What it changes is the number of ways the job can go wrong between the scan and the plate, and with scanned geometry — which is already the least predictable input a slicer sees — that is worth having.

The 3MF written here always says unit="millimeter". The coordinates from the PLY are passed through with no scaling, because a PLY declares no unit and there is nothing to convert from. The conversion is therefore stating a fact about the file that the file never contained.

For a structured-light or laser scan that statement is usually correct: the device knows its own optical geometry and reports in millimetres. For a photogrammetry reconstruction from photographs it is usually meaningless, because that pipeline recovers shape up to an unknown scale factor — a 200 mm object can come out with coordinates in the single digits or the thousands. Put a ruler or a scale bar in the capture, or measure a known feature in MeshLab and scale before converting. A slicer that believes a wrong unit prints a wrong part.

This is the pair where the loss is most visible, because per-vertex colour is the entire reason scans are PLY files. The reader takes the x, y and z properties from each vertex element and steps over the rest — red, green, blue, alpha, normals, confidence, quality and anything custom — so that the stride stays correct, then discards them.

3MF is fully capable of holding colour: it has a base materials group, a colour group and a triangle-level property index, and multi-material printers use them. Nothing is written. If a colour print is the goal, the route is your slicer's own painting tools or a vendor pipeline that reads textured meshes, not this conversion.

If the PLY declares vertices and no faces, the conversion stops and says so. That is correct rather than restrictive: a slicer needs a closed surface to compute an inside and an outside, and a set of points has neither. There is no honest default for turning one into the other.

Reconstruction is the missing step and it belongs in a tool with a preview. MeshLab and CloudCompare both offer Poisson and ball-pivoting; the choice between them and the parameters you give them visibly change the result, which is exactly why a converter should not pick for you. Mesh first, inspect, then convert.

No welding is applied on this path. The STL and OBJ readers merge coincident vertices because those formats routinely arrive with duplicates; the PLY reader takes the vertex array and the face indices as the file states them, because a meshing step has already made those decisions deliberately.

So the vertex count in the 3MF matches the element vertex count in the PLY header, and the triangle count matches the face count. That makes verification easy and it also means the conversion cleans nothing up. Duplicate vertices, unreferenced vertices and split seams in the scan arrive intact, and if they were causing a manifold complaint they will keep causing it.

A scan has holes where the scanner had no line of sight: undercuts, the face the object was resting on, dark or specular surfaces that returned nothing. It usually also carries islands of background geometry and, where several passes were merged, self-intersections.

3MF expects a printable object to be a closed manifold volume, and nothing in this conversion checks or enforces that. The file will open in your slicer and the slicer will tell you what is wrong with it. Fixing it in advance — MeshLab's hole filling, Meshmixer's inspector, or Blender's 3D-Print Toolbox — is faster than iterating through slicer warnings, and it is the step most likely to decide whether the print succeeds.

The 3MF contains a single object in its resources section and a single item in its build section, positioned with no transform. A PLY has one surface and no way to say otherwise, so there is nothing to divide and nothing to place.

No name attribute is written either, so the slicer shows an unnamed object. If your scan does contain several disconnected shells — a scanned assembly, or a capture with background fragments still attached — Split to Parts after import finds them by connectivity, and that is also the fastest way to delete the fragments you did not want.

A ZIP with three entries: [Content_Types].xml mapping the .model and .rels extensions to their content types, _rels/.rels with one relationship pointing at the model, and 3D/3dmodel.model holding the geometry in the 3MF core namespace. That structure is what makes it an OPC package rather than a ZIP with an XML file in it, and a slicer given the model alone would reject the archive.

It is a model file, not a project. No print profile, no filament assignment, no plate layout, no thumbnail and no per-object settings, because those are slicer-specific extensions rather than geometry. Your slicer applies whatever profile you have selected and can save its own, much larger, project 3MF afterwards.

The order that saves time is: mesh the point cloud, delete the background islands, fill the holes, decimate to something a slicer can handle, scale against a known dimension, and only then convert. Every one of those is a scan problem rather than a format problem, and every one of them is easier in MeshLab or your scanner software than in a slicer.

The conversion itself runs entirely in your browser — no engine to download, nothing uploaded, a 100 MB ceiling — which matters when the scan is of a person, a client's object or a part somebody would rather not publish. The file that reaches your slicer never left the machine it was captured on.