Getting a 3D model into AR: OBJ and STL to GLB

If you have a model from a CAD tool or a 3D printer workflow, it is probably an OBJ or an STL. Augmented-reality viewers — Android’s Scene Viewer, model-viewer on the web, Unity and three.js pipelines — want glTF, and specifically its single-file binary form, GLB.

What GLB is

glTF is a JSON description of a scene (meshes, materials, nodes) plus a binary buffer of vertex data. GLB packs both into one file so nothing can go missing. It is small, loads fast and is the format the AR ecosystem has standardised on.

What converts, and what does not

Convert Files carries the geometry: every vertex and triangle, with node transforms applied so the model sits where it should. It does not carry materials, textures or animations — an OBJ’s .mtl file and its texture images are not read. The result is a clean grey mesh, which is exactly what you want as a starting point for assigning your own material in a viewer or engine.

Units and scale

glTF is in metres. STL files are unitless and often exported in millimetres, so a 20 mm ring becomes a 20 m ring in AR. Check the scale in your viewer; most let you set it in one field. Convert Files does not rescale, because it cannot know which unit the source used.

Going the other way

GLB to STL is useful for printing a model that only exists as a glTF. Node transforms are baked in, so the printed part comes out at the pose you see in the viewer.

What each format actually carries

STL is the simplest: an unordered pile of triangles, with no colour, no texture, no material, no units and no scene structure. It exists because 3D printers need a watertight shape and nothing else. OBJ adds names, groups, texture coordinates and a reference to a separate .mtl file for materials, which in turn references image files — three files that must travel together and frequently do not. PLY comes out of 3D scanners and photogrammetry and usually carries per-vertex colour, which is a different thing from a texture.

glTF was designed for the opposite problem: shipping a finished scene to a viewer. It carries meshes, a node hierarchy, physically-based materials, textures, skins and animation, in JSON with binary buffers alongside. GLB is that same scene packed into one binary file, so there is nothing to lose in transit. This is why it has become the format AR asks for.

What AR viewers want

Android's Scene Viewer takes glTF and GLB. The web, via the model-viewer element and essentially every WebGL engine, takes GLB. Apple's Quick Look on iOS is the exception — it wants USDZ, a different lineage entirely, so an iOS-native AR experience needs that conversion separately. If you are publishing one file for the widest reach, GLB is the answer, with USDZ added for iOS if you need it.

Scale is where models go wrong

glTF defines its units as metres, Y-up, right-handed. STL has no unit convention at all, and the 3D printing world has simply agreed to treat the numbers as millimetres. The arithmetic follows: a model authored for printing usually arrives in an AR viewer a thousand times too large, and the first thing you see is the inside of a triangle. If your converted model appears vast, or vanishes entirely, scale is almost always why — not the conversion.

Materials, textures and what gets dropped

Converting up the chain adds nothing that was not there. An STL has no colour, so its GLB has no colour; you get clean geometry with a default material, which is the correct result rather than a failure. An OBJ's materials live in a .mtl file that is not read here, so geometry converts and materials do not. A PLY's per-vertex colours are kept where the target supports them.

Going the other way — GLB or glTF down to STL — deliberately throws away everything except the shape, which is exactly what a slicer wants.

Before you send it to a printer

Geometry that looks right in a viewer is not automatically printable. Slicers want a closed, manifold surface: no holes, no faces pointing the wrong way, no edges shared by three triangles. A model built for display often fails all three, because none of it matters when you are only ever looking at the outside. Convert first, then check in the slicer, and repair there rather than blaming the conversion.