Methodology and data
This page documents how cadtomesh converts a file, what the four presets actually change, which claims on this site were checked against the shipped code and the format specifications, and what the converter does not claim to do.
What runs where
The browser build reads 28 input formats and writes 8 output formats. Different format families go through different engines:
| Format family | Engine | Notes |
|---|---|---|
| STEP, IGES, BREP | OpenCascade via occt-import-js (WebAssembly) | Exact B-rep geometry. Curved faces are tessellated at the selected preset. |
| IFC | web-ifc 0.0.78 (WebAssembly) | Usually already triangulated in the file, so the preset has no effect on IFC geometry. |
| Mesh formats | three.js loaders and exporters | STL, OBJ, PLY, GLB, glTF, 3MF, FBX, DAE, 3DS, AMF, USDZ, KMZ, LWO, VTK, XYZ, OFF and others. |
The Windows app uses the same OpenCascade kernel natively. It reads 28 formats and writes 15; the extra outputs are STEP, IGES and BREP export plus DXF and other formats the browser build does not write. It is not a more accurate version of the website: the tessellation rules are the same.
What the four presets change
STEP, IGES and BREP are exact boundary representations, so the kernel needs a tolerance to decide how finely a curved face should be split into triangles. cadtomesh exposes two values per preset: a linear deflection (the maximum chordal deviation, in model units) and an angular deflection (in radians). The values below are the ones in the shipped engine, not marketing labels:
| Preset | Linear deflection | Angular deflection | Typical effect |
|---|---|---|---|
| Draft | 0.5 | 0.6 | Fewest triangles, fastest, visibly faceted curves. |
| Balanced (default) | 0.1 | 0.35 | General-purpose preview and printing. |
| Fine | 0.04 | 0.2 | Smoother curves, larger file. |
| Maximum | 0.01 | 0.1 | Closest to the exact surface, largest file and slowest. |
A tighter tolerance produces more triangles, and binary STL charges a fixed 50 bytes per triangle, so file size grows roughly in proportion to the triangle count. There is no per-face adjustment: one preset governs the whole model.
What is verified, and how
Every technical statement on a conversion page is traceable to one of three things: the shipped JavaScript, the format specification, or a direct byte-level check. Examples:
- Binary STL layout. An 80-byte header, a 32-bit unsigned facet count, then 50 bytes per facet: twelve 32-bit floats for the normal and three vertices, plus a two-byte attribute word. The exporter writes that layout directly.
- No unit conversion. STL has no unit field, and the exporter writes the source coordinates as 32-bit floats. An inch-authored STEP therefore prints 25.4 times too small when a slicer assumes millimetres.
- No assembly tree. STL is written as a single triangle soup. GLB and glTF keep one node per source part with transforms baked into the vertex coordinates, but part names, product definitions and IFC property sets are not written to the output.
- Colour and material limits. Binary STL has no colour channel, and OBJ needs a separate MTL file that this converter does not write. STEP part colours do reach GLB as base-colour materials, and a GLB base-colour texture reaches USDZ; metallic, roughness and normal maps do not.
The same facts appear in the FAQ schema on each conversion page, and the schema is generated from the same data as the visible text, so the two cannot drift apart.
What is not claimed
- Conversion is lossy. Curved surfaces become triangles, and a finer preset narrows but never removes the deviation.
- A watertight, manifold shell is not certified. Tessellation is done face by face, so adjacent patches can leave sub-micron cracks.
- Exact B-rep geometry is not reconstructed in the browser. The desktop app can write STEP, IGES and BREP, but that is an export of the kernel's geometry, not a recovery of the original feature tree.
- File size is limited by the memory of the tab or the machine, not by a server quota. Very large assemblies may fail to load.
- The website does not preserve design history, constraints, parametric dimensions or PMI annotations.
Privacy and network requests
The file you open is read into the page and never uploaded. The only request tied to a conversion is a POST /api/stats/r carrying the byte size of the finished file, used for the site-wide counter; it contains no file name, no content and no identifier.
IFC is the one format with an extra dependency: the web-ifc library is fetched from jsDelivr the first time an IFC file is converted. Every other format uses libraries served from this domain.
The site uses Cloudflare Web Analytics, a cookieless page-view counter. It records the page URL, referrer, country and basic device/browser information; it does not set cookies, does not fingerprint visitors and is not used for advertising. The privacy policy lists every request in detail.
Standards and sources
These are the specifications and project documents behind the format claims on this site:
| Format | Reference |
|---|---|
| STEP | ISO 10303-21:2016 — clear-text encoding of the exchange structure |
| IFC | buildingSMART IFC 4.3 and web-ifc |
| 3MF | 3MF Consortium specification |
| glTF / GLB | Khronos glTF 2.0 specification |
| COLLADA (DAE) | Khronos COLLADA |
| FBX | Autodesk FBX SDK documentation |
| USDZ | Apple Quick Look / USDZ |
| CAD kernel | OpenCascade documentation |
| Mesh loaders and exporters | three.js documentation |
STL, OBJ and PLY have no formal ISO specification; their behaviour is defined by the de facto layouts implemented in the three.js loaders and exporters, which is what the site documents.
Change log
Format support, fixes and page changes are recorded on the change log.
Corrections. If a statement on this site is wrong about a format, email [email protected] with the page URL. Corrections take priority over marketing copy.