Skip to main content
Most models reach us as more than one file, and uploading only the mesh produces a grey object with nothing to say why. This page covers what to include, what happens when something is missing, how scans differ, and the few things that do not survive conversion. For the format table and the upload button itself, see Objects.

​
Models that come as more than one file

An OBJ never stores its own materials. The colors and textures live in a companion .mtl file, which in turn points at image files. An FBX can embed its textures, but only if whoever exported it chose to. Upload a model without those companions and it converts successfully into a grey, untextured object. The geometry is correct and nothing errors, so it is easy to miss. To avoid it, hand over the whole model rather than the one file. The upload dialog accepts any of these:
  • Drag the model’s folder in. Usually the simplest, and it keeps the folder structure intact.
  • Select several files at once in the file picker.
  • Pick a .zip you have already made.
Everything is packaged together and unpacked on our side. Subfolders are preserved, because a .mtl locates its textures relative to its own position, so a textures/ folder has to stay where the model expects it.
If your exporter offers Embed Media for FBX, using it avoids the problem entirely: the textures travel inside the .fbx file and there is nothing separate to remember. OBJ has no equivalent.

​
Scans

A scan from photogrammetry or LiDAR is the one case where the advice above does not apply. Upload the .ply on its own. Scanners store color on the vertices themselves rather than in a material, so there is no .mtl, no texture folder, and nothing that can go missing. A scan that looks right in your scanning software will look right here. The trade is that color detail and mesh detail become the same thing. A scan carries millions of triangles because that is what it takes to hold the color, not because the shape needs them. Upload the scan at full density and let the platform reduce it: we derive lighter versions for you, and for a dense scan we bake its color into a texture image so the detail survives the reduction. Markings, labels, and painted text stay readable on a mesh far smaller than the original. Reducing a scan yourself before uploading is usually the wrong move. Decimating a vertex-colored mesh throws away the paint along with the triangles, and there is no way to recover it afterwards. Scans also arrive in whatever orientation the scanner recorded, which is often on their side. That is corrected once during review, in Object Approvals.

​
When files are missing

If a model references files that did not arrive, the object says so rather than quietly appearing grey. The warning names the files, and appears in the objects list, on the object’s detail page, and in the approvals queue. You can fix it without re-uploading: open the object in the approvals queue and drop the missing files onto the warning. The model reconverts in place and keeps its name, tags, packs, and approval state. Drag in a whole folder if it is easier; anything not needed is left alone. A missing .mtl is usually reported in two stages. Until that file arrives, nothing can know which images it references, so supplying it often reveals a second, shorter list of missing textures. That is expected rather than a fault.

​
What does not survive conversion

Everything is converted to GLB for the web and to USDZ for headsets, and a few material features have no equivalent in those formats:
  • Vertex color on a scan becomes a texture image. This is a gain rather than a loss, and it is why a reduced scan keeps its markings, but it does mean the converted model carries a material where the original had none.
  • Specular and Phong materials, common in older FBX exports, arrive as base color plus whatever texture maps carried over. Models authored with PBR materials convert faithfully.
  • Procedural or generated textures are not evaluated. Bake them to image files before exporting.