How to export a 3D model: picking between GLB, glTF, OBJ, STL and FBX

Exporting looks like a menu choice and behaves like a pipeline decision. The format decides what the next application can read: geometry alone, geometry with materials and textures, a rigged character, or a printable solid. Pick the wrong one and the model arrives intact and still unusable.

This guide covers GLB and glTF, OBJ, STL and 3MF, and FBX, with the settings that cause real trouble: units, axes, Draco decoding, triangulation, and the FBX path when a generator does not offer it.

Pick the format from the destination tool, not the file size

Most export failures are not size problems. A GLB that opens cleanly in a browser viewer can be the wrong file for a slicer, and a 40 MB FBX that a game engine imports happily is useless to someone who wants to print. Ask which application opens the file next, and what it needs to see. Size matters second, and textures drive it rather than polygons: a 60k-triangle mesh is a few megabytes, while four 4K PBR maps can pass 40 MB. Match compression to the destination — Draco for web viewers, none for the printer.

GLB and glTF: PBR materials inside one binary file

glTF 2.0, maintained by the Khronos Group, is the closest thing to a standard real-time exchange format. GLB is its binary container: scene graph, geometry buffers, materials and images in one file, so nothing breaks when the asset is uploaded, emailed or served from a CDN. Blender, Unity, Godot, three.js and Babylon.js read it directly, Unreal wants a plugin or a recent importer, and most browser viewers treat GLB as the default download.

• A node hierarchy with named meshes and transforms, so parts stay separate
• PBR metallic-roughness materials: base colour, metallic, roughness, normal, occlusion, emissive
• Images embedded in the binary, so textures cannot go missing in transit
• Optional Draco-compressed geometry, smaller mesh data for a decode step on import

Draco compression shrinks geometry, not textures

Draco is a geometry compression extension, and it typically cuts mesh data to a fraction of its size — a real saving on polygon-heavy models. It does nothing for textures, so an asset whose weight sits in 4K maps barely shrinks. Two practical points: the importer needs a decoder, which Blender, three.js, Babylon.js and Unity's glTF importers ship and older tools do not, and Draco quantises vertex positions. That is invisible on screen but can move a surface further than a print tolerance allows, so keep an uncompressed copy for the slicer.

The split glTF form: .gltf, .bin and a texture folder

glTF also exists as separate files: a .gltf JSON file, a .bin buffer holding geometry, and loose images referenced by relative path. Awkward to move, pleasant to work with — a script can patch one material value or swap an albedo map without rewriting the asset, and a JSON diff shows exactly what changed between versions. The risk is fragility: move the .gltf without its companions and it still loads, but every surface turns grey and no error appears.

OBJ and MTL: the format that never argues

OBJ dates from the 1990s and still opens everywhere: geometry, UVs and normals in a plain text file, materials in a companion .mtl, textures separate. It is still the safest way to move raw geometry between DCC applications, because OBJ supports n-gons: quad topology survives a Blender or Maya round trip, while GLB and STL triangulate on export. What it cannot carry is a modern material. MTL is a loose specification, exporters write different subsets of it, and a packed roughness-metallic PBR setup generally does not survive. OBJ declares no units either, so a file exported as 1 unit = 1 m can arrive where it reads as centimetres.

STL and 3MF: units, triangle soup and the print bed

STL is the printing format: a list of triangles, each with a normal. No units, no colour, no material, no object names, no hierarchy — two parts that touch become one mesh you cannot select apart. Bambu Studio, OrcaSlicer, Cura and PrusaSlicer all read it, and print services ask for it by name. 3MF keeps the same geometry and adds what STL lacks: declared units, multiple objects, colour and material data, and a smaller zip container. For a plate with several parts or a colour change, send 3MF.

1. Fix the real-world size in millimetres, then measure the bounding box in the slicer: STL has no unit field, and a 1000x error is the classic mistake.
2. Check that the mesh is manifold; holes and non-manifold edges become missing shells or failed slices, so repair before blaming the printer.
3. Respect wall thickness: roughly 0.8–1.2 mm for FDM with a 0.4 mm nozzle, about 0.6–1.0 mm for resin parts.
4. Rotate the model so overhangs stay within roughly 45 degrees of vertical, or accept supports and the marks they leave.
5. Export binary STL, not ASCII, which stores the same mesh several times larger; switch to 3MF for multi-part plates.

FBX: the format you need once a rig is involved

FBX is Autodesk's interchange format and it still owns the rigged-asset pipeline. It is the only format here that routinely carries a skeleton, skin weights, blend shapes, keyframed animation, cameras and lights in one file, which is why Unity, Unreal and Maya teams ask for it by default. It is also proprietary and versioned: there is no public specification, compatibility is defined by the SDK, and your exporter version is part of the result.

Expect two recurring problems. Scale and axis: Autodesk tools default to centimetres, Blender writes metres, so an asset can arrive 100 times too large or on its side; the fix lives in the exporter's unit scale and forward/up settings, not in post-import rescaling. Materials: FBX stores texture references, sometimes as absolute paths, so textures vanish as soon as the folder moves. FBX is also rarely on the export list of a hosted AI 3D generator, which usually offers GLB, OBJ and STL. The realistic route is two steps: export GLB or OBJ, import into Blender, export FBX with the target engine's units and axis. GLB geometry arrives triangulated, so clean quads need retopology in a DCC tool first.

Where an AI 3D generator sits in the export chain

Open3DAI exports GLB, glTF, OBJ, STL, PLY and 3MF, and its format converters cover neighbouring formats; a REST API lets a team run export inside a build script. Multi-engine comparison is the more useful step before that: sending one prompt or image through the connected engines costs less than exporting several candidates and repairing them later. The boundary matters, though. Open3DAI does not rig, animate, retopologise or unwrap UVs, and it does not export FBX, so rigged delivery still passes through Blender or Maya. It also does not promise watertight, print-ready geometry: a mesh headed for a printer needs the same check as any other export.

Check the export before the file leaves your machine

• Re-import into an empty scene and read the outliner; missing parts are usually failed material or node references.
• Measure a dimension you know: a 100 mm cube must read 100 mm, not 10 or 1000.
• Turn textures on in the material preview; grey surfaces mean broken image paths, most often in OBJ, MTL or FBX.
• For engines, check polycount against the triangle budget, and decimate in Blender rather than inside the level.
• Weigh the file: a 4K PBR set can reach 30–60 MB while the mesh is a few megabytes, so cut textures first.

Run it yourself in Open3DAI

Send the same prompt or image to several engines, compare the meshes side by side, then export GLB, glTF, OBJ, STL, PLY or 3MF. Creating an account grants free credits and needs no card.