How many triangles does a part need? Budget by curvature, not size

You picked a quality setting, the converter is not asking for anything else, and the question underneath is whether the mesh it is about to write is fine enough for the print — or whether you are about to pay for smoothness a flat part cannot use. Every number on this page was measured on the machine that wrote it and re-run by npm test before the page was published.

The short answer

Budget triangles where the curvature is: flat faces are exact at any setting, curved faces are where the count moves, and the output's byte size — not the model's size — tells you what you got. A part with only flat faces costs exactly 12 triangles — six faces, two per face — at Draft, Normal and Fine alike, so on such a part the quality choice is free. Curved faces are the opposite: the same cone measures 286 triangles at Draft, 516 at Normal and 2,142 at Fine, a 7.5× spread produced by nothing but the tolerance choice. “Enough” is judged at the curved faces: convert once, then read the count back out of the file — a binary STL is 84 bytes of header plus 50 bytes per triangle, so (size − 84) ÷ 50 is the triangle count, and there is no rounding in that identity to hide a fault behind.

The budget: triangles are spent where curvature is

Three shapes cover the decision. Each row is the same file converted at the three shipped settings with this engine, and the last column is what the setting choice is worth on that shape:

Read the rows as a budget, not a menu. On the flat cube the setting changes nothing: flat faces are stored exactly, two triangles per face, and any count above 12 on such a part is spend with nothing to show for it. On the rounded cube only the rounded edges respond — 40 to 140 triangles — while the six flat faces keep their 12. On the cone everything responds, and Draft to Fine is a factor of 7.5. Underspending on a curved face is what shows up in the print as visible facets; overspending on a flat face is bytes for nothing. What the counts mean in bytes is drawn out on the file-size page.

The judgement, in four moves before the cut

1. Look at the part, not at the file. If the faces are all flat, Draft is the right answer and the choice costs nothing: 12 triangles, 684 bytes, at every setting. No setting can improve a planar face, because a plane is stored exactly.
2. Start curved parts at Normal. On the cone that is 516 triangles and, by the fixed identity, 25,884 bytes. Preview it at your print's layer height and judge the curved faces, not the flat ones — the flat faces cannot complain at any setting.
3. Still faceted on the curve? That is what Fine is for. The same cone at Fine is 2,142 triangles — 107,184 bytes, 7.5 times the Draft count of 286 — with the deviations tightened to 0.001 linear and 0.1 angular. On flat geometry Fine buys nothing; on curved geometry it is the tier that buys smoothness.
4. Collect what you paid for. (size − 84) ÷ 50 must return the count you expected; the identity has no rounding, so a mismatch is a real fault, not an artefact. That arithmetic is check 1 on the verification page.

Fine is not a guarantee: whichever deviation binds first decides

Each setting is a pair of numbers — a linear deviation and an angular one (Draft 0.02 and 0.5, Normal 0.005 and 0.3, Fine 0.001 and 0.1; these are this site's own choices, not a CAD standard, and npm test diffs them against the shipped engine). The pair interacts, and the count lands wherever the tighter constraint binds. On the cone at Fine's angular value, the linear number makes no difference at all: linear 0.02, 0.005 and 0.001 all give 2,142 triangles. Relax the angular value to 1.0 and the same three linear values give 186, 408 and 1,318 — tightening the linear deviation further adds nothing the angular constraint refuses. So “I set Fine, therefore I got the maximum” is not a promise this page can make: the count depends on which of the two numbers binds first, which the coupling grid on the workflow page measures cell by cell.

File size cannot tell you the count — in either direction

Two measurements to keep beside the budget. First, the input's size is unrelated to the output's count: the cone's STEP file is 9,391 bytes, and at Normal it writes a 25,884-byte STL, at Fine a 107,184-byte one. Second, the part's physical size is unrelated too: scale that same cone to 100× its size and the bounding box grows from 27.033 mm to 2,703.298 mm, while the triangle counts stay exactly 286, 516 and 2,142 at every setting — measured at both sizes on the workflow page. That is why choosing a quality tier by output file size runs backwards: size is the consequence of the count, never its cause. One of the three benchmark sites this project tracks prices its quality tiers as output file-size caps, which cannot tell you how many triangles a given part will get; the count answers to curvature and deviation, and you read it back from the bytes after the one cheap, local conversion.

Why the three benchmark sites cannot answer this

Of the three sites this project tracks — polyd.com, convert3d.org and imagetostl.com — none puts a triangle count or a deviation pair anywhere a converting reader can see one. polyd's converter page offers its three tiers as output file-size caps with a maximum-size label, which prices the file rather than the mesh. convert3d's STEP page is a two-row compatibility table with no quality dimension at all. imagetostl has no STEP-to-STL page to check — the STEP reference it does publish points readers at a desktop viewer instead. The cell they leave empty is the one this page occupies: a way to decide the triangle question before the cut and to verify it after, with measured numbers.

Where these numbers come from

• 12 at every setting (flat cube), 40 → 56 → 140 (rounded edges), 286 → 516 → 2,142 (cone) — counts from the live engine at the shipped presets, re-run on every test pass. The byte sizes are the same identity: 84 + 50 × 286 = 14,384, 84 + 50 × 516 = 25,884, 84 + 50 × 2,142 = 107,184.
• 9,391 bytes — the byte length of the cone sample file on disk, taken fresh by the suite each run.
• 27.033 mm → 2,703.298 mm with identical counts — the 100× scale experiment: the same cone converted at Normal at both sizes; not one triangle moved.
• 186 / 408 / 1,318 — the cone converted with the angular deviation relaxed to 1.0 at linear 0.02, 0.005 and 0.001; the suite re-measures those cells directly.

npm test

The command above re-runs every number on this page. The workflow page owns the six steps in order and the full cost table; the verification page owns the five checks, check 1 being the count from the bytes; and the converter is where the one cheap conversion runs — in your tab, with nothing uploaded.