Benchmarks
Measurements we ran ourselves, published as data rather than as opinion. Each page states its result first, then the numbers, then exactly how they were produced and what they do not show.
Every figure on these pages is read straight out of the JSON the measurement script wrote, which is linked for download on each page. Nothing is transcribed by hand, so the table and the file cannot disagree. Where a measurement does not settle a question, the page says so rather than rounding the claim up.
The merge tolerance that decides whether an STL reads as watertight
Why do two tools disagree about whether the same STL is watertight?
STL stores every triangle as three independent vertices, so a 2,562 vertex icosphere is written out as 15,360 loose vertices forming 5,120 separate shells. Reading it back means guessing which of those coincide. When the coordinates are bit-identical, exact matching recovers all 2,562 and the mesh is watertight. Add vertex noise of 1e-06 mm and exact matching recovers almost nothing: it takes a merge tolerance of 0.1 mm, about 2.9 percent of the 3.459 mm shortest edge, before the mesh closes again. Two tools reporting differently on one file are usually not disagreeing about the file. They are using different tolerances.
Measured 2026-09-08Which 3D file formats record a unit of length, and which leave it to be guessed
Does a mesh file say what its numbers mean, and what breaks when it does not?
Of five mesh formats written from one 100 mm cube, only 3MF puts a unit in its bytes: the model part opens with unit="millimeter". STL, OBJ, PLY and GLB store a bare number and nothing else. glTF is a special case, because its specification declares the number to mean metres even though no field says so; a cube authored in millimetres therefore arrives 1000 times too large in tooling that follows the spec, and at the right size in a slicer that assumes millimetres. STL, OBJ and PLY have no such rule at all, so the importing program picks one.
Measured 2026-09-07What actually shrinks an STL file, and what each method costs in accuracy
Which methods reduce the size of an STL file, and how far does each one move the surface?
One change is free: rewriting an ASCII STL as binary takes the same 69,451 triangles from 19,744.8 KB to 3,391.2 KB, a 82.8 percent reduction with byte-identical geometry. Everything else costs accuracy. Decimating to 10 percent of the faces reaches 339.1 KB but moves the surface by a mean of 0.0162 mm. Draco compressed GLB is the smallest result at 46.9 KB while keeping every face, at a mean deviation of 0.0040 mm, but it is not an STL and no slicer will open it.
Measured 2026-08-31