CesiumGS/3d-tiles: the OGC 3D Tiles 1.1 specification and what adopting it costs

What 3D Tiles solves, and for whom

A city-scale photogrammetry capture, a CAD model of a single building, and a lidar point cloud have almost nothing in common at the file level. They have everything in common at the delivery level: each is too large to load at once, each needs to be drawn at several levels of detail, and each needs to be positioned in the same world coordinates as the others. 3D Tiles is the specification that gives those three dataset types one streaming container. The README describes it as an open specification for sharing, visualizing, fusing, and interacting with massive heterogenous 3D geospatial content across desktop, web, and mobile applications. The intended reader is not an end user. It is a data provider who has to publish a dataset, or an engine developer who has to consume one, and both need a format that survives contact with a viewer written by somebody else. The specification itself lives in the specification/ directory of this repository, and the extension registry in extensions/ is where additional capabilities are registered rather than folded into the core document.

The spatial hierarchy and how a tileset streams

The core mechanism is a tree. A tileset describes a spatial hierarchy of tiles, and each tile points at content that is loaded only when the viewer decides that tile is worth drawing. That is the whole trick: the client never holds the full dataset, it holds a tree of bounding volumes and fetches leaves as the camera moves. 3D Tiles borrows this from 3D graphics and builds the content layer on glTF, which is why the README says the format is designed for 3D rather than adapted from a 2D tiling scheme. Version 1.1 changed the content layer in a way that matters. glTF assets are now directly supported as tile contents, a tile can carry multiple contents, and implicit tiling schemes are supported so that a regular subdivision does not have to be written out tile by tile. Structured metadata can be attached to tilesets, tiles, tile content and tile content groups, which is what makes per-feature selection, querying, filtering and styling possible at runtime instead of being baked into geometry. The deprecations in 1.1 are the other half of that story: b3dm, i3dm, pnts and cmpt are deprecated in favour of glTF content, and tileset.properties is deprecated in favour of the metadata support. If you have a 1.0 pipeline, those four extensions and that one property are your migration surface.

Installing 3d-tiles: what there is to install

There is no package to install here. This repository is the specification document, the extension registry, the reference cards and the change history, not a runtime. The README points implementers at the 3D Tiles Resources page for the list of implementations, viewers, generators, data providers and demos, and at the Cesium community forum for questions about implementation or generating 3D Tiles. So the honest first step is to clone the specification and read it, which is what a provider or engine author actually does with this repository.

git clone https://github.com/CesiumGS/3d-tiles.git
cd 3d-tiles
ls specification extensions reference-cards

The listing above shows the specification directory, the extension registry and the reference cards. The reference cards are the part to read first if you are integrating a runtime rather than writing one: the README calls them approachable and concise guides to the main concepts, designed to help integrate 3D Tiles into runtime engines. They are shipped as 3d-tiles-reference-card.pdf and 3d-tiles-reference-card-1.1.pdf at the top level of the repository, so you can open them without building anything.

ls 3d-tiles-reference-card.pdf 3d-tiles-reference-card-1.1.pdf CHANGES.md

CHANGES.md is the file that documents what moved between 1.0 and 1.1. Read it before you read the specification, because the deprecations listed there decide which parts of the document still apply to the pipeline you already have.

3D Tiles 1.0 versus 1.1 versus the 2.0 draft

The version history in the README is unusually clear about what each release is. 3D Tiles 1.0 was submitted to the Open Geospatial Consortium and approved as an OGC Community Standard on 2018-12-14, with the specification text published as OGC document 18-053r2. That matters for procurement: 1.0 is the version with a standards body behind the document, and it is the version a conservative buyer will ask about. 3D Tiles 1.1 is the current work in this repository, released as 1.1 on 2023-06-05, and it is the version that adds metadata, glTF content, multiple contents per tile and implicit tiling while deprecating the four original tile formats and tileset.properties. 3D Tiles 2.0 is listed as currently in development, with a directory at next/2.0/. The practical consequence is a three-way split in the ecosystem: generators that emit b3dm and pnts, generators that emit glTF content, and consumers that support one, the other, or both. The README's own framing is that 1.1 is the version to adopt for new work, and the deprecation list is the reason.

Where 3D Tiles is the wrong tool

The specification is a streaming format for large geospatial datasets, and it is overkill for anything that is not one. A single building model, a product visualisation, a character asset: those are glTF problems, and glTF is the layer 3D Tiles is built on, so wrapping them in a tileset adds a hierarchy, a tileset JSON document and a runtime requirement without adding anything the viewer needed. The second wrong case is a team that has no generator. The repository is a specification; it does not convert your data. If nobody in your pipeline can produce a tileset, adopting 3D Tiles means writing or buying that step before you get any value from it. The third case is subtler and is a real cost of 1.1: the deprecations are not removals. b3dm, i3dm, pnts and cmpt still exist in the ecosystem, still ship in older viewers, and still appear in datasets that were generated years ago. A consumer that supports only glTF content will fail on those datasets, and a provider that moves to glTF content will lose viewers that never implemented it. The specification does not resolve that for you; it only tells you which way the format is going.

3D Tiles against i3s, and against plain glTF

The closest alternative in the geospatial world is i3s, Esri's Indexed 3D Scene layer specification, which solves the same streaming problem with a different scene layer model and is not built on glTF. The difference that matters in practice is the content layer: 3D Tiles 1.1 makes glTF the tile content, so any glTF tooling you already have is relevant, while i3s keeps its own layer structure. Choosing between them is usually an ecosystem question rather than a technical one, and the README's answer to it is the RESOURCES.md list, which is where the implementations, viewers and generators for 3D Tiles are catalogued. The other comparison, 3D Tiles against glTF, is not really a comparison at all: glTF is the payload and 3D Tiles is the delivery hierarchy around it. If your dataset fits in one glTF file, glTF wins on simplicity. If it does not fit in memory, the hierarchy is the point, and glTF alone gives you no answer for which part to load first.

Maintenance, licence and the cost of an upgrade

The repository's last push was on 2026-09-23, and it is not archived, so work is ongoing. The release cadence is not fast: 1.0 landed in 2018, 1.1 in 2023, and 2.0 is still in development in the next/2.0/ directory. That cadence is a feature of a specification rather than a defect, but it sets the upgrade budget. Between 1.0 and 1.1 the changes that cost real work are the move from the original tile formats to glTF content and the move from tileset.properties to structured metadata. Both are deprecations rather than removals, which means a 1.0 tileset does not break on day one, and a team can migrate one dataset at a time. The licence is the open question. The repository metadata does not state one, and the README does not either, so anyone who needs a licence identifier for a procurement or redistribution decision has to confirm it from the repository rather than from this page. The specification text itself was approved as an OGC Community Standard, which is a separate matter from the licence on the files in this repository.

Editorial conclusion

Adopt 3D Tiles if you need one streaming format that can hold photogrammetry, BIM, instanced features and point clouds in a single tileset and you are willing to run a generator and a runtime that both understand version 1.1. Do not adopt it if your content is a single small model that a plain glTF viewer already loads, or if your pipeline is still pinned to b3dm, i3dm, pnts or cmpt and you have not planned the migration. Before committing, read the specification directory for the 1.1 schema, check the RESOURCES.md list for a generator and a runtime that both support glTF tile content, and confirm which parts of the version 2.0 draft in next/2.0/ touch the tilesets you already ship.

Frequently asked questions

Official sources

1. CesiumGS/3d-tiles on GitHub
2. Issues
3. README
4. Releases