3D Print Version Control

Text version control doesn't work for meshes

Git, and every version control system built on it, works by diffing lines of text. That's fine for code and even for a slicer's .gcode or config files, but it falls apart the moment you point it at an STL, 3MF, or OBJ file. Binary mesh formats have no "lines" to diff — a single tweak to one dimension can reorder every triangle in the file, so Git sees a completely rewritten blob and can tell you nothing more useful than "this file changed." You end up back to opening both versions in a viewer and eyeballing them side by side, which is exactly the workflow every maker and CAD engineer already knows doesn't scale past two or three iterations.

What "version control" should mean for a printed part

For an iterative print workflow, useful version history answers a small, specific set of questions for every revision: what geometry was added or removed since the last version, how much the part's volume and bounding box changed, whether any wall got thinner than your printer can reliably produce, and whether the part still passes a printability check. That's a geometry problem, not a text-diff problem — which is why Meshdiff computes it directly from the mesh instead of trying to bolt version control onto a format it was never designed for.

How it works in an iterative workflow

• Upload each revision as you print and iterate — v1, v2, v3 — and every version keeps its own record rather than overwriting the last.
• See a real diff between any two versions, not just the most recent pair — volume delta, bounding-box change, hole and wall-thickness changes, and a printability gate (pass / warn / fail) computed fresh for that version.
• Keep a traceable history of what changed and when, so "why did we change the mounting hole diameter in v4" has an answer that doesn't depend on anyone's memory.
• Add team review when more than one person touches a part — pending, approved, or rejected status per version, with rejection reasons kept on record, so a part only becomes the version everyone builds on once someone has actually signed off.

Who this is for

Solo makers iterating on a design across a dozen prints benefit from a simple, chronological version history without needing to invent their own file-naming convention. Hardware startups and print farms get the same history plus an approval workflow, so a revision doesn't reach production tooling until it's been reviewed. Either way, the underlying need is the same: know exactly what changed, without re-deriving it by eye every time.

The comparison engine itself is free and requires no account — see the STL diff guide for how the underlying voxel diff works. Saved project history and team approvals are part of the Pro and Team plans.