Every game dev has hit this wall: you export a model, drop it into the engine, and something is missing — the rig didn't come through, the textures turned gray, or the file won't even open on a client's phone. That's rarely a bug. It's a mismatch between what the source format actually stores and what your target engine expects. Picking the right game ready 3d file formats — GLB, FBX, OBJ, or USDZ — before you export saves hours of "why is this broken" debugging later.
bunpav's take: format choice is not a formality, it's an engineering decision. GLB, FBX, OBJ, and USDZ are not interchangeable containers for the same data — each one stores a different subset of mesh, material, and animation information, and picking wrong means silently losing something on import. This guide breaks down what each format actually carries, verified against the Khronos Group's glTF specification, Unity's and Unreal's official import docs, and Apple's AR Quick Look documentation, then gives you a decision framework for choosing per asset.
TL;DR: which format for which job?
| Question | Direct answer |
|---|---|
| Which format for Unity? | GLB for PBR props and environment art; FBX for rigged, animated characters |
| Which format for Unreal? | Same split — GLB/glTF for static PBR meshes, FBX for complex skeletal rigs |
| Which format for AR/iOS previews? | USDZ — required for native AR Quick Look on iOS, iPadOS, macOS, and visionOS |
| Which format for simple static props? | OBJ works, but you lose animation and get inconsistent material support |
| Which format for 3D printing? | STL — geometry only, no materials, no rig, not a game-engine format at all |
| Can one export cover everything? | No single format covers rigging, PBR, and AR delivery equally well — pick per use case |
What does each format actually store?
The differences that break your pipeline are almost never about polygon count — they're about which of these four data layers a format is built to carry: raw mesh and UVs, PBR material definitions, skeletal rig and animation data, and scene/node hierarchy.
| Format | What it stores | Best engine/tool fit | Typical use case | Honest limitation |
|---|---|---|---|---|
| GLB | Mesh, UVs, metallic-roughness PBR materials, skins/animation, full scene hierarchy — packed into one binary file | Unity, Unreal, web/AR viewers, Three.js | Static or lightly rigged PBR props, environment art, web-embedded 3D | Rigging tooling is less mature than FBX for very complex animation rigs |
| FBX | Mesh, UVs, materials (quality varies by exporting DCC), skeletal skins, blend shapes, baked animation, full hierarchy | Maya, 3ds Max, Blender | Unity, Unreal for characters | Rigged, animated characters and complex mocap pipelines | Proprietary Autodesk format; version mismatches between exporters and importers cause breakage |
| OBJ | Mesh and UVs only, plus an optional MTL file for basic (non-PBR) materials | Nearly every 3D tool as a lowest-common-denominator exchange | Simple static props with no animation | No rig/animation support at all; no official PBR material standard |
| USDZ | USD scene description (mesh, materials, object/camera/skeleton animation) bundled with textures and audio into one archive | Apple AR Quick Look (iOS, iPadOS, macOS, visionOS Safari/Messages/Files) | iOS/Apple AR product previews and marketing demos | Effectively an Apple-ecosystem format; limited relevance inside Unity/Unreal projects |
| STL | Raw triangle mesh and surface normals only | Slicer software for 3D printers | Physical prototypes, tabletop miniatures | No color, no UVs, no materials, no rig — not a game-engine format |
Mesh geometry and UVs
Every format here — GLB, FBX, OBJ, USDZ, and STL — can store basic triangle geometry and vertex positions. UV coordinates (needed to map a texture onto a mesh) are supported by GLB, FBX, OBJ, and USDZ. STL is the outlier: it stores raw triangles with surface normals and nothing else, which is exactly why it's a 3D-printing format and not a game-asset format.
Materials and PBR textures
This is where OBJ starts to lag. GLB was designed around the Khronos Group's own metallic-roughness PBR model as a first-class citizen of the glTF 2.0 specification — base color, metallic, roughness, normal, occlusion, and emissive maps all have defined slots. FBX also carries PBR-style material data, though its material representation depends heavily on which DCC tool exported it, since Autodesk's FBX SDK predates the PBR era and different tools bolt PBR channels on differently.
OBJ's companion .mtl file, by contrast, was built for 1990s Phong shading — it has no native concept of a roughness or metalness map. A community PBR extension (from Clara.io, later adopted by Blender and tinyobjloader) added Pr, Pm, and similar parameters, but it's not part of the official Wavefront spec and support is inconsistent. USDZ inherits Pixar's USD material system, which supports PBR shading, though tools vary in how cleanly they round-trip it.
Skeletal rig and animation
FBX has historically been the format most DCC tools and engines trust for skeletons, blend shapes, and baked animation clips — the long-standing interchange format between Maya, 3ds Max, Blender, and every major engine, since rigging vendors have tested against it for two decades. glTF 2.0 also supports skins, morph targets, and keyframe animation natively per the Khronos spec, and both Unity and Unreal import glTF skeletal data — but FBX pipelines remain more mature since more mocap tooling targets FBX first. OBJ has no animation or rig support at all. USD/USDZ supports object, camera, and skeleton animation, though Apple's Quick Look viewer only plays simple sequences rather than full runtime rigs.
Scene hierarchy
FBX, glTF/GLB, and USDZ all preserve a full scene graph — parent-child node relationships, multiple objects, cameras, and lights in one file. OBJ is essentially a flat mesh dump; if a source file has multiple objects, OBJ can group them, but there's no real hierarchy or transform nesting the way FBX and glTF represent it.
GLB vs FBX: what's the real difference for game engines?
GLB is the binary-packaged version of glTF, the Khronos Group's open, royalty-free "runtime 3D asset delivery" format — Khronos itself has described it as the "JPEG of 3D", meaning a compact, standardized format meant to be consumed directly by engines and browsers rather than edited. glTF 2.0 became an ISO/IEC international standard in 2022, which is part of why it has become the modern default for web viewers, AR platforms, and increasingly game engines.
FBX is Autodesk's proprietary interchange format, originally built by Kaydara and acquired by Autodesk in 2006. It remains, according to Unity's own model file formats documentation, one of the natively supported formats Unity recommends for production pipelines, and Epic's Unreal Engine documentation still treats FBX as the primary path for skeletal meshes with rigged, animated characters.
The practical trade-off: GLB is open, self-contained, smaller on disk, and increasingly the cleaner choice for static PBR props since it bundles geometry, materials, and textures into a single file with no external dependencies. FBX carries more mature tooling around bones, blend shapes, and complex animation graphs, but it's a closed, versioned format controlled by Autodesk — which occasionally causes version-mismatch headaches between older DCC exports and newer engine importers.
Is OBJ still worth using for game assets?
OBJ earns a place in a game pipeline for one job: simple, static, non-animated geometry — a rock, a crate, a piece of architectural trim. It's old (the Wavefront format dates to the 1980s), it's plain text (or a binary variant), and nearly every 3D tool on Earth can read and write it, which makes it a reliable lowest-common-denominator for geometry exchange.
Where OBJ falls short for modern game assets is exactly the material and animation gap covered above: no native PBR material standard, and zero rigging or animation support. If your asset needs a skeleton, blend shapes, or even a clean metallic-roughness texture set without manual re-linking in the engine, OBJ is the wrong export target. Treat it as a geometry-only fallback, not a first choice.
What is USDZ, and when do you actually need it?
USDZ is a zero-compression, uncompressed-archive package built around Pixar's open source Universal Scene Description (USD) format. Per Apple's own AR Quick Look documentation and Quick Look Gallery, USDZ is the file format required to trigger Apple's native, system-level AR viewer — the one built into Safari, Messages, Files, and Mail on iOS, iPadOS, macOS, and visionOS — without building a custom app. A single USDZ archive bundles the USD scene description alongside its textures and audio, so the whole model travels as one file a user can tap and preview in AR with zero extra software.
The catch is scope: USDZ is essentially an Apple-ecosystem delivery format. It matters enormously if you're shipping a product-preview or AR marketing experience for iOS users, and it matters far less inside Unity or Unreal, where GLB and FBX do the heavy lifting. If a game project has zero AR/iOS-preview requirement, USDZ can usually stay out of the export list entirely.
Best 3D file format for Unity vs Unreal — does it actually differ?
Not by much, and that convergence is itself the useful takeaway. Both engines natively import FBX, OBJ, and glTF/GLB — Unity documents all three in its model formats manual, and Unreal added native glTF import (alongside its long-standing FBX and OBJ support) through the Interchange framework, per Epic's glTF import docs. In both engines, the same general rule holds:
- Rigged, animated characters → FBX, because rigging and animation tooling around it is the most mature on both sides.
- Static, PBR-textured props and environment pieces → GLB, because it's self-contained, smaller, and standardized.
- Quick geometry checks with no animation → OBJ works, but expect to relink materials by hand.
The nuance is tooling maturity, not incompatibility: Unreal's Interchange framework (UE 5.4+) unifies FBX, glTF, and OBJ import under one system, while Unity's importer has separately matured FBX and glTF support over multiple releases. Neither engine forces one format across a whole project — most pipelines mix FBX for characters and GLB for props.
Where does STL fit in a game dev pipeline?
Mostly, it doesn't — and that's worth saying plainly instead of glossing over it. STL is a 3D-printing format: it stores watertight triangle geometry and surface normals, nothing else. No UVs, no materials, no color, no rig, no animation. It's the right format if you're sending a model to a 3D printer for a physical prototype or a tabletop miniature, and the wrong format for literally anything that needs to render with texture or move in an engine. If a text-to-3D or image-to-3D tool offers STL export alongside GLB/FBX/OBJ/USDZ, that's a bonus for makers and hobbyists, not a game-asset option.
Choosing game-ready 3D file formats: a decision checklist
- Does the asset need a skeleton or animation? If yes, export FBX (or glTF/GLB if your engine's glTF skinning support is confirmed solid for your version). If no, GLB or OBJ are both viable.
- Does the asset need PBR materials to survive import cleanly? Choose GLB — its metallic-roughness workflow is standardized in the glTF 2.0 spec, so materials tend to import consistently rather than needing manual re-linking.
- Is this headed to Unity or Unreal specifically? Both import FBX, OBJ, and GLB natively — pick FBX for rigs, GLB for props, and treat OBJ as a static-geometry fallback only.
- Does anyone need to preview this in AR on an iPhone or iPad without a custom app? Export USDZ specifically for that path; don't bother otherwise.
- Is this going to a 3D printer, not an engine? Export STL and stop worrying about materials or rigs entirely.
- When in doubt, export more than one. Disk space is cheap; re-exporting from a lost source file is not. bunpav generates GLB, FBX, OBJ, USDZ, and STL from a single text prompt or photo for exactly this reason — so you're not locked into re-running a generation just because the target changed from "Unity prop" to "iOS AR demo."
Related reading
- AI-Generated 3D Models in Unity and Unreal: What Actually Survives the Import
- Text-to-3D AI: How to Turn a Prompt Into a Game-Ready Model
- Image-to-3D: Turn a Single Photo Into a Textured 3D Model
- Auto-Rigging Explained: How AI Adds a Skeleton to a 3D Character in Seconds
- The Game Jam 3D Asset Pipeline: Generate, Rig, and Export in Under an Hour
- Text-to-3D AI Tools Compared: Meshy, Tripo, Rodin, and bunpav in 2026
- glTF — Runtime 3D Asset Delivery (Khronos Group)
- Unity Manual: Model File Formats Reference
- Unreal Engine: Importing glTF Files
- Apple Developer: Previewing a Model with AR Quick Look
If you're generating meshes with bunpav instead of modeling from scratch, exports to GLB, FBX, OBJ, USDZ, and STL are all available from the same generation, so you can pick the right format per destination without regenerating the asset.
Format support details reflect Khronos, Unity, Unreal, and Apple documentation as of July 17, 2026. Engine importers change between releases — always confirm current behavior against your specific engine version before locking a pipeline decision.