Convert 3MF to OBJ

3MF is a printing format. PrusaSlicer, Cura, Bambu Studio and Microsoft 3D Builder all read and write it, and outside that circle support thins out quickly — plenty of modelling, CAD and rendering applications still have no importer for it at all, more than a decade after the 3MF Consortium published the specification.

OBJ has the opposite problem and the opposite virtue: it holds far less, and everything opens it. When somebody sends a part as a 3MF and it has to be modified, measured against a drawing, or dropped into a render, converting to OBJ is usually the shortest path to having it on screen.

A 3MF model element carries a unit attribute, and it is the only format in this set that states one. The converter reads it and scales the geometry into millimetres: micron by 0.001, centimetre by 10, inch by 25.4, foot by 304.8 and metre by 1000, with millimetre passing through unchanged.

So a bracket authored in inches at 2.5 units wide arrives in the OBJ as 63.5 units wide. That is the same object, described in millimetres, and it is the right answer because OBJ declares no unit and the printing and CAD worlds read unlabelled numbers as millimetres. It is also the one place in this category where the numbers you see afterwards are not the numbers you started with, which is worth knowing before you compare them against a drawing.

A 3MF separates what an object is from where it goes. The resources section holds the meshes; the build section holds items, each naming an object and optionally carrying a transform — twelve numbers describing a row-major four-by-three matrix with the last column implied.

OBJ has no equivalent, so each item's transform is applied to a copy of the object's vertices before writing. Parts land where the build section placed them. If the same object is referenced by several build items — the same spacer printed four times on one plate — you get four groups with four full copies of the geometry, because there is no other way to express it in a format without instancing.

An object with a name attribute keeps it, and that name becomes the o line of its group in the OBJ. On a multi-part print file that is the difference between importing six identifiable components and importing six anonymous shapes, and it is nearly the only non-geometric information that survives.

Objects with no name get a generated one so the grouping is still visible. Note that the direction matters: converting an OBJ to 3MF loses the names, because the 3MF writer emits objects with an id and no name attribute. The information flows out of 3MF and not back into it.

3MF is an OPC package — a ZIP with a content-type map and a relationships file, the same convention DOCX uses. A slicer project 3MF puts a great deal in there beyond the geometry: print profiles, filament assignments, per-object settings, modifier meshes, support enforcers, plate layout, a preview thumbnail, and vendor-specific XML in the vendor's own namespace.

The converter finds 3D/3dmodel.model, or failing that any entry ending in .model, and reads the geometry out of it. Everything else in the archive is ignored. That is the correct scope — none of it has a representation in an OBJ — but it means a converted project file is the shapes and nothing else, and the print setup stays behind in the 3MF you should keep.

3MF allows an object to be defined not by its own mesh but by a components element listing other objects, each with its own transform. It is how the format expresses an assembly built from reusable parts, and it is legal and used.

This converter reads the mesh element of each object and does not follow components. An object defined that way contributes no geometry, and if every object in the file is a component assembly the conversion ends with a message that no triangle geometry was found. If a converted file is missing parts you can see in your slicer, this is the first thing to check — re-exporting from the slicer usually flattens the assembly into plain meshes.

When a 3MF has a build section, only the objects its items reference are converted. An object sitting in resources that nothing builds is not written into the OBJ, which is deliberate: the build section is the file's statement of what is actually on the plate.

There is one fallback. A 3MF with resources and no build section at all — unusual but readable — has its objects converted anyway, since they are plainly the content and simply have no declared placement. Between those two rules, a converted OBJ contains what the 3MF said was being made, and a part that vanishes was a part the file did not claim.

3MF has a real material model: base material groups, colour groups, and a property index on each triangle so a single object can be multi-coloured. Multi-material printers use it and slicers write it. None of it is read here, and an OBJ has nowhere to put it — the converter writes no mtllib line and produces no .mtl file, so the geometry arrives materially blank.

This is the cost of a converter that carries geometry between six formats that agree on very little else. If a multi-material 3MF is being converted so somebody can re-colour it, the colours have to be re-authored at the far end. Keeping the original 3MF alongside the OBJ is the only way to preserve the assignment.

The file imports into Blender, MeshLab, Maya and everything else without configuration. It contains only o, v and f lines, so expect flat shading — no vn lines means face normals are computed on import — and no material.

The first thing worth checking is the size. The OBJ is in millimetres by construction, and modelling applications differ on what an unlabelled unit means: Blender treats one unit as a metre by default, so a 63.5 mm part appears as a 63.5-metre object unless the import scale is set. That is a display and scene-scale question rather than a conversion error, and reading one known dimension off the model settles it in ten seconds.