Open .obj scans with their .mtl material file
An OBJ file stores the geometry of a 3D scan as a plain-text list of vertices and faces. Colour usually lives outside it: a complete OBJ export is three files — the .obj itself, a .mtl material sidecar, and a texture image the .mtl names. An .obj sent alone carries geometry but no material, so the scan usually arrives grey.
Every file dropped on this page is read with the browser File API and rendered on your own machine. There is no upload endpoint, no account and no copy kept, which is why the page keeps working once the network is switched off.
Keep the whole export on the patient record
DodoDentist keeps intraoral scans, radiographs and CBCT exports on the patient record, with every file of a multi-file export stored as one study instead of three attachments that get separated in an inbox.
Try DodoDentist freeOBJ is the format a scan comes back in once it has been through any modelling step — exocad, Meshmixer and Blender all write it, and most laboratories send it. It is also, in practice, a three-file format. The .obj holds the geometry: a list of vertex coordinates, the faces that join them, and usually a normal and a texture coordinate for each corner. What it does not hold is a single colour value.
Colour lives in the other two files. A line near the top of the .obj reads mtllib followed by a filename, and that file — the material library, with the .mtl extension — defines one or more named materials. Each material has a diffuse colour, and normally a map_Kd line naming an image file: the colour photograph the scanner actually captured, which the texture coordinates in the .obj wrap onto the surface.
That is why "the scan" arriving as one attachment is the most common OBJ support question there is. The .obj on its own opens perfectly, rotates perfectly, and is the right shape down to the last micron — and it is grey, because the two files that carry its appearance were left behind on somebody else’s desktop. Nothing is corrupted and nothing needs re-scanning; two files need re-sending.
The .obj is the model: vertices, faces, normals and texture coordinates, all as readable text. The .mtl is a short list of materials, each with a colour and a pointer to an image. The image is the appearance itself, and it is usually the largest of the three — a full-arch colour texture is a several-megabyte JPEG or PNG, while the .mtl beside it is often under a kilobyte. Losing the .mtl loses the link between the other two even when both survive.
Ask for the folder, zipped, rather than for "the scan". The mtllib line stores a filename, not a path into anyone’s file system, so the .obj finds its material file only when the two sit in the same folder under the names the exporter gave them. Renaming the .obj is harmless; renaming the .mtl breaks the reference silently, and so does saving the texture image somewhere tidier. If the export has already been split up, the material file can be re-exported from the original scan in seconds — it is generated, not authored.
An intraoral scanner captures shape and colour at the same time, and the export format decides how much of that survives. STL keeps the shape and discards the colour entirely — it has no field for one, which is why an STL of a colour scan is always the plaster-cast view. PLY writes a colour on every vertex inside the same file, so it stays one file and the colour cannot be separated from it. OBJ pushes the appearance out into the material and texture files, which buys photographic detail and costs portability.
| Format | Where the colour lives | Files needed | Where it usually comes from |
|---|---|---|---|
| OBJ (.obj) | In a separate .mtl plus a texture image | Three, and they must stay together | Laboratories, exocad, Meshmixer, Blender |
| OBJ material (.mtl) | It is the colour definition, and holds no geometry | Meaningless on its own | Always beside an .obj |
| STL (.stl) | Nowhere — STL cannot carry it | One | Printing, aligner and model workflows |
| PLY (.ply) | One colour per vertex, inside the same file | One | Colour exports from the scanner |
For a scan that has to be emailed, PLY is usually the better export: one file, colour included, nothing to lose in transit. For a case where the surface detail matters — shade matching, a stain map, documenting a lesion — the photographic texture an OBJ carries holds far more than one colour per vertex, and the three files are worth zipping.
It is worth seeing the difference rather than reading about it. Open an .stl file to see geometry with no colour at all, or open a .ply file to see colour arriving in one file instead of three.
Both an intraoral scanner and an X-ray sensor are described as producing "the scan", and the files could hardly be less alike. Anything involving radiation writes DICOM: a picture plus a header describing the exposure, the device and the patient. Anything optical writes a mesh — a surface with no interior, no exposure data and no patient identity inside it.
Extensions make it worse rather than better. 3Shape names its own mesh cases with a .dcm extension, the DICOM extension, so a file named after a radiograph can be a scan of the arches. Files dropped here are identified by their contents instead, which is why an unexpected file gets named rather than refused. Open a .dcm radiograph instead.
The geometry is fully read: vertices, faces of any size, negative indices, supplied vertex normals, and the per-vertex red-green-blue values Medit, MeshLab and 3Shape append to the vertex lines. Where those values are present the model is shaded in the scanner’s own colour; where they are absent it is shaded in plaster tones, which is what a physical model of the same arch would look like.
The material file is read and reported rather than rendered. Dropping it alongside the .obj lists every material it declares, the diffuse colour of each one as a swatch, and every texture image it references — and, more usefully, names any referenced file that was not in the drop. That report is the thing worth having: it turns "the colour is missing" into a filename to ask for.
Because the colour is not in the .obj. An OBJ export keeps geometry in the .obj file, the material definitions in a separate .mtl file, and the actual colour photograph in a texture image the .mtl names. A scan emailed as a single .obj arrives with the shape and nothing else.
A .mtl is a small plain-text material library. It names one or more materials and gives each a diffuse colour and, usually, the filename of a texture image. It holds no geometry at all, which is why it cannot be opened as a model on its own and why a viewer that only accepts .obj files is not doing anything wrong.
Drop it onto this page, together with its .mtl and any texture image if you have them. The files are read by your browser and drawn on screen; nothing is uploaded and there is no signup. Selecting all of them at once is what lets the page tell you whether the export is complete.
No. The geometry is entirely inside the .obj, so the model rotates and zooms exactly the same without the material file. Only the colour depends on the .mtl and the texture image beside it.
In an mtllib line near the top of the .obj, which names the material file by filename and looks for it in the same folder. Renaming either file, or saving them to different folders, breaks that link silently. Keeping all three files together in one folder or one zip is what preserves it.
PLY when the file has to travel on its own, because PLY stores a colour on every vertex inside the single file and cannot be separated from it. OBJ when the texture resolution matters, because a photographic texture image holds far more detail than one colour per vertex — at the cost of being three files that have to stay together.
No. The files never leave your computer: they are read directly in the browser and rendered locally, and this page has no upload endpoint at all. Once the page has loaded it keeps working with the network switched off.
Yes, and an .stl, a .ply or a .dcm dropped here is identified and named rather than rejected with an error. The page reads the contents of a file rather than trusting its extension, which matters in dentistry because 3Shape writes its own mesh cases with a .dcm extension.