Get3D Knowledge Center

02 3D Model Formats Explained

10 min read

When to Use OBJ, FBX, glTF, 3D Tiles, OSGB

Overview

If you work with 3D data, you have probably received a file that would not open. Or opened with missing textures. Or loaded at the wrong scale. Or had its animations broken. These are not bugs — they are symptoms of the format landscape.

A 3D file format is not just a file extension. Each format makes different trade-offs: what data it stores, how efficiently it stores it, and which tools can read it. Picking the wrong format for the job means hours of rework — or a client who cannot open what you delivered.

This article explains the five formats most relevant to geospatial 3D professionals: what each one actually is, what it is good for, what it is bad for, and most importantly, which one you should reach for in a given situation.

What a 3D Format Actually Stores

Before comparing formats, it helps to understand what they contain. A 3D file can store several layers of information — not all formats support all layers:

Data LayerWhat It IsWhich Formats Support It
GeometryThe shape — vertices, faces, edgesAll formats
MaterialsHow surfaces look — color, roughness, metalness, transparencyMost (OBJ only via separate MTL file)
TexturesImage maps wrapped onto surfacesMost (OBJ only via separate image files)
HierarchyParent-child relationships between objectsFBX, glTF, 3D Tiles (OBJ does not)
AnimationHow objects move over time — keyframes, skeletons, morph targetsFBX, glTF (OBJ does not)
GeoreferencingReal-world coordinates (latitude, longitude, altitude)Only 3D Tiles natively (others need metadata hacks)
MetadataAttributes per object — building ID, material type, capture date3D Tiles, glTF (OBJ does not)
Streaming / LODAbility to load progressively at different detail levelsOnly 3D Tiles

The Five Formats

OBJ — The Universal Fallback

Born: 1980s, Wavefront Technologies. Older than the web itself.

What it stores: Geometry only — vertices, normals, texture coordinates, and face definitions. All in plain text. Materials are stored in a separate .mtl file. Textures are separate image files.

What it does NOT store: Animation, hierarchy, scene structure, PBR materials, georeferencing, metadata, compression — essentially everything beyond bare geometry.

When to use it:

  • As a minimum-common-denominator interchange format when you don’t know what tool the recipient uses.
  • For quick export of a single static mesh.
  • When you need to inspect or debug geometry in a text editor.

When NOT to use it:

  • For web delivery (huge files, no streaming, no compression).
  • For any project involving animation or rigging.
  • For city-scale models (no LOD, no streaming, no georeferencing).
  • For final delivery to a client who expects a modern experience.

The reality: OBJ survives not because it is good, but because it is universal. Every 3D tool in existence can read and write OBJ. It is the “plain text file” of 3D — not efficient, not feature-rich, but it will always open.

FBX — The Animation Workhorse

Born: Late 1990s, Kaydara. Acquired by Autodesk in 2006.

What it stores: The most comprehensive single-file format. Geometry, materials with advanced properties, textures, scene hierarchy, cameras, lights, skeletal animation with rigging and skinning, morph targets (blend shapes), and multiple animation tracks. It is essentially a full scene description.

What makes it tricky: FBX is proprietary and closed-source. Autodesk controls the format and the SDK. Different versions of the FBX SDK can produce files that are not fully compatible with each other. Different tools implement FBX import/export with varying quality — a file exported from 3ds Max may import differently in Blender or Unity than the same file exported from Maya.

When to use it:

  • In animation pipelines where you need to move rigged characters with full animation data between tools.
  • When working with game engines (Unity, Unreal) that have mature FBX importers.
  • When you need to preserve the full scene graph with cameras, lights, and hierarchy.

When NOT to use it:

  • For web delivery (browsers cannot natively open FBX).
  • For simple static meshes where OBJ or glTF would be simpler and lighter.
  • For geospatial data (no native georeferencing).
  • For final delivery to non-technical clients (they probably cannot open it).

The reality: FBX is the format that real production pipelines run on, especially in games and film. But it is a production format, not a delivery format. The industry trend is toward keeping FBX inside the pipeline and exporting to glTF for distribution.

glTF / GLB — The “JPEG of 3D”

Born: 2015, Khronos Group (the same standards body behind OpenGL, Vulkan, and WebGL).

What it stores: Everything needed for runtime rendering in a single, efficient package. Geometry with compression, PBR materials (physically-based — metalness, roughness, normal maps), textures (optionally embedded or referenced), skeletal animation, morph targets, and scene hierarchy.

GLB vs glTF: glTF is a JSON file with separate binary and texture files. GLB is the binary form — everything packed into a single .glb file. For web delivery, always use GLB. The single-file packaging simplifies hosting and eliminates broken texture references.

Why it matters for the web: glTF was designed from the ground up for efficient transmission and GPU-friendly loading. The data layout is close to what the GPU needs — minimal parsing required. Modern browsers can load GLB natively. Essentially every web 3D framework support it as the preferred format.

When to use it:

  • Web 3D applications (the default, often the only sensible choice).
  • AR and VR experiences on web and mobile.
  • E-commerce product configurators and 3D viewers.
  • Final delivery format when you want a single, self-contained file.

When NOT to use it:

  • For city-scale streaming (use 3D Tiles instead — a single GLB of an entire city will crash the browser).
  • For complex DCC pipelines where you need to preserve editing history (keep your native format).
  • When you need wide compatibility with older CAD tools (some still lack glTF export).

The reality: glTF is eating the web 3D world. It is not the most feature-rich format — FBX can store more types of data — but it is the most efficient format for getting 3D content to a screen quickly. If your 3D content is destined for a browser, start with glTF.

3D Tiles — The Streaming Giant

Born: 2016, Cesium. Ratified as OGC Community Standard in 2019 (v1.0), updated to 1.1 in 2023.

What it actually is: 3D Tiles is not a single file. It is a streaming specification — a folder structure containing a root tileset.json plus hundreds or thousands of individual tile files. The tiles can be in various formats: .b3dm (batched 3D models), .i3dm (instanced models), .pnts (point clouds), or plain .glb files (in 1.1).

The key concept : The tileset.json describes a spatial hierarchy. When a viewer loads a 3D Tiles dataset, it reads this index and fetches only the tiles that are visible at the current camera position and detail level. As the user zooms or pans, new tiles stream in. This is fundamentally different from a single file that must be fully downloaded before anything renders.

Why it matters for geospatial work: 3D Tiles is the only format in this list that supports georeferencing natively. Tiles are positioned in real-world coordinates. This means a building in a 3D Tiles dataset sits at its actual latitude, longitude, and altitude — essential for GIS integration.

When to use it:

  • City-scale and region-scale 3D models (anything beyond a few city blocks).
  • Drone and aerial survey data (photogrammetry outputs tiled for web streaming)
  • LiDAR point clouds for web visualization.
  • Any geospatial 3D application where users need to navigate freely across large areas.

When NOT to use it:

  • For individual assets, single buildings, or small objects (a single GLB is simpler and sufficient).
  • When the end user does not have an internet connection (streaming requires network access).
  • When your viewer does not support 3D Tiles (most general-purpose 3D viewers don’t — you need a geospatial engine like CesiumJS).

OSGB

Born: OSGB is the binary serialization format of OpenSceneGraph (OSG), an open-source 3D graphics toolkit first released in 1998 and used globally for visual simulation, virtual reality, game development, aerospace, and scientific visualization. The .osgb extension was introduced around OSG 2.9 (2010) as part of a new extensible serializer system, replacing the older .ive binary format.

What it stores: OSGB stores a complete scene graph — a tree of nodes representing an entire 3D scene — in a single compact binary file. Unlike simple mesh formats (OBJ, glTF for a single model), OSGB can represent whole scenes with spatial organization built in.

When to use it:

  • When your photogrammetry pipeline outputs OSGB natively (Get3D, ContextCapture) — keeping it as the source format preserves the original tile structure and avoids unnecessary conversion artifacts.
  • When your viewer stack is OSG-based (osgEarth, Get3D Viewer).
  • When you need the highest-fidelity local rendering performance on desktop.

When NOT to use it:

  • For web delivery.
  • For cross-platform projects involving mobile, WebGL, or non-C++ environments.
  • When your team uses primarily non-OSG tools (Unreal, Unity, Blender — none support OSGB natively).
  • For individual models or non-geospatial content.

The reality: OSGB and 3D Tiles are not competitors — they occupy different stages of the same pipeline. OSGB is the source and internal processing format generated by oblique photogrammetry software, optimized for desktop rendering. 3D Tiles is the distribution and web format, optimized for browser-based streaming. A typical production workflow is: raw imagery → photogrammetry tool → OSGB tile set → conversion tool → 3D Tiles → web viewer.

Decision Framework: Which Format When?

Here is a question-by-question decision process:

1. Is your data geospatial (real-world coordinates, maps)?

  • YES, and it’s larger than a few city blocks → 3D Tiles for web delivery; keep OSGB as the source format if your photogrammetry pipeline outputs it natively.
  • YES, but it’s a single building or small site → 3D Tiles or glTF, depending on whether you need streaming.
  • NO → Continue to question 2.

2. Is this destined for a web browser?

  • YES → glTF / GLB for individual assets, 3D Tiles for streaming scenes.
  • NO → Continue to question 3.

3. Does it involve character animation, rigging, or complex scene hierarchy?

  • YES → FBX (for production pipeline) or glTF (for final delivery).
  • NO → Continue to question 4.

4. Do you just need universal compatibility and the file is a simple static mesh?

  • YES → OBJ is fine, but consider glTF for a lighter, more modern alternative.
  • NO → Reconsider your format choice — you might be overcomplicating things.

Where Get3D Fits

Get3D’s processing pipeline outputs data in formats designed for the modern web:

Mesh output. Get3D Mapper produces textured mesh models that can be tiled into 3D Tiles for web streaming. The content-aware light weighting ensures the mesh is optimized for web delivery from the start — geometry is simplified intelligently rather than uniformly, preserving architectural edges while reducing detail where it is not needed.

3DGS output. For projects where photorealism is the priority, Get3D outputs 3D Gaussian Splatting data. This can be converted for use in platforms that support the .splat or .ply formats.

Source: Get3D Knowledge Center

Graph View