How browser based 3D conversion works
The interesting claim this site makes is not that it converts 3D files, it is that no server is involved. Here is what makes that possible.
Three kernels, one scene graph
Every conversion funnels through a single in-memory representation: a three.js scene graph of meshes with materials. Reading a file means producing that graph, writing a file means walking it.
- Mesh and scene formats such as STL, OBJ, PLY, glTF, FBX, DAE, 3MF and VRML are read by three.js loaders.
- STEP, IGES and BREP are read by Open CASCADE compiled to WebAssembly. The kernel evaluates the exact surfaces and hands back a tessellation, which is the only representation a viewer can draw anyway.
- Anything more exotic goes through Assimp, also WebAssembly, which converts to glTF internally and then joins the same path.
Because the middle of the pipeline is one shape, adding a format means writing one reader or one writer, not one converter per pair.
Why a worker thread matters
Parsing a 200 MB binary STL takes seconds and allocates a lot. Doing that on the main thread freezes the page, including the progress indicator that is supposed to reassure you. So the whole pipeline lives in a module worker and communicates through Comlink, with the resulting buffers transferred rather than copied.
One consequence is worth knowing: a worker has no DOM. three.js loads textures by creating an img element,
which does not exist there. The fix is small, replacing the image loader with one built on
createImageBitmap, and it keeps texture bearing formats working off the main thread.
Writing formats nobody has a library for
Readers are mostly available off the shelf. Writers are not. three.js can write STL, OBJ, PLY, glTF and USDZ, and that is the end of the list. Everything else on this site is written from scratch:
- 3MF, as an OPC package built with fflate: content types, a relationship part and the model XML, with vertex colours mapped onto the material extension's colour groups.
- COLLADA, as XML with one geometry, effect and node per mesh.
- DXF, as
3DFACEentities so CAD and CAM tools that never learned mesh formats can still read the surface. - STEP, as a faceted AP214 surface model, which is the part worth explaining.
The STEP writer
Each triangle becomes a FACE_SURFACE whose geometry is a PLANE and whose boundary is a POLY_LOOP of
three points. The faces go into an OPEN_SHELL, the shells into a SHELL_BASED_SURFACE_MODEL, and that is
wrapped in a MANIFOLD_SURFACE_SHAPE_REPRESENTATION with the usual product and unit preamble.
Two details keep the output usable. Cartesian points and directions are deduplicated through a hash of their formatted coordinates, which cuts the file by roughly a third on a typical mesh. And there is a hard triangle limit, because a planar face costs an order of magnitude more bytes than a triangle in STL, so an unconstrained scan would produce a file no CAD system wants to open.
The whole thing is verified by reading the output back through Open CASCADE, which is a satisfying property of building on a real kernel: the writer is checked by an independent implementation on every build.
What the browser cannot do
Not everything fits. Binary FBX is proprietary and undocumented enough that writing it is not worth the risk of producing files Maya rejects. Native formats such as DWG, SKP and SLDPRT need vendor libraries that have no open builds. Draco compression needs an encoder module that does not ship in a browser friendly form, so compression uses meshopt instead. And single image 3D reconstruction needs a GPU sized model, not a WebAssembly kernel.
Being explicit about those gaps is more useful than a format list that quietly fails on upload.