3D Tiles 1.1: What's New for Surveyors

3D Tiles 1.0 was ratified by the Open Geospatial Consortium in 2019. Version 1.1 was approved in 2023 and is now the current OGC standard. Most tools are still emitting 1.0-style tilesets, but 1.1 is the direction the ecosystem is moving and it changes how large scenes get authored, stored, and queried.

Here’s what actually changed and what matters if you’re producing tilesets from drone, LiDAR, or photogrammetry pipelines.

Background: where 3D Tiles came from

3D Tiles was developed by Cesium starting around 2015 to solve a problem GIS already had — streaming massive geospatial data into a browser — for 3D. Version 1.0 became an OGC Community Standard in 2019. It defined a tileset.json hierarchy with .b3dm, .pnts, .i3dm, and .cmpt tile content formats, a quadtree/octree spatial subdivision, and the screen-space-error metric that decides when to refine to higher-LOD tiles.

That spec shipped a huge amount of capability. It also accumulated friction. Authoring a billion-point LiDAR dataset meant generating millions of individual tile files plus the tileset.json metadata that explicitly listed every one of them. Adding per-feature attributes (classification codes, intensity values, attribute tables) was awkward. Combining different content types in the same tile was clumsy.

Version 1.1 addresses those frictions. For a primer on the underlying format, see our 3D Tiles explainer.

What’s new in 1.1

Implicit tiling

The biggest change. In 1.0, every tile had to be listed explicitly in tileset.json with its bounding volume, geometric error, and content URI. A tileset with a million tiles meant a million entries in the manifest — typically split across nested external tilesets, but still explicit metadata for every node.

In 1.1, implicit tiling lets you declare a quadtree or octree once, with a subdivision scheme and a maximum level, and the viewer computes tile URIs procedurally:

content/{level}/{x}/{y}.glb       # quadtree (2D)
content/{level}/{x}/{y}/{z}.glb   # octree (3D)

Result: the tileset.json drops from megabytes to a few hundred bytes. Authoring tools don’t have to emit explicit node entries — just dump tile files into a predictable folder structure. Viewers fetch tiles by computing URIs from the camera frustum rather than walking a JSON tree.

For surveyors: large LiDAR tilesets generate faster and the tileset.json stops being a bottleneck on page load. A 200,000-tile photogrammetry capture used to take 5 – 10 seconds just to load the tileset manifest before any tiles rendered. With implicit tiling, that’s effectively zero.

3DTILES_metadata: per-feature attributes

3D Tiles 1.0 didn’t have a clean way to attach arbitrary metadata to tiles or features. You could embed batch tables in .b3dm files, but querying them required loading the tile content first.

3D Tiles 1.1 adds a proper metadata system with three scopes:

• Tileset metadata — properties about the whole dataset (capture date, sensor, CRS, surveyor)
• Group metadata — shared across multiple tiles (a building, a survey region)
• Tile metadata — per-tile properties (point count, bounding info, classification stats)

Plus per-feature metadata via glTF’s EXT_mesh_features and EXT_structural_metadata extensions. Each point in a point cloud, or each feature in a mesh, can now carry an arbitrary set of attributes (classification, intensity, return number, scan angle, source surveyor) queryable from the viewer without loading additional files.

For surveyors: this is how you finally expose LiDAR classification codes, photogrammetry source-image references, or asset IDs in the browser viewer. Clients can click a point and see “ground return, intensity 142, scanned 2026-04-12” without round-tripping to a separate database.

Multiple content per tile

In 1.0, a tile contained one piece of content. If you wanted to combine a mesh and a point cloud at the same location, you used a composite (.cmpt) format that bundled them — clunky and only partially supported.

In 1.1, a tile can declare multiple content entries directly:

"contents": [
  { "uri": "mesh.glb" },
  { "uri": "points.glb" }
]

Both load and render together. Useful for hybrid deliverables — for example, a photogrammetry mesh of a building with a registered point cloud of interior details, both at the same tile location. The viewer treats them as one logical tile but can apply different styling to each.

Better instancing via EXT_mesh_gpu_instancing

3D Tiles 1.0 had .i3dm for instanced models — repeating objects like trees, lamp posts, or survey markers placed at many positions. It worked but was a separate format with its own quirks.

3D Tiles 1.1 deprecates .i3dm in favour of glTF’s EXT_mesh_gpu_instancing extension. Instanced geometry now lives inside regular .glb tile content, using the standard GPU instancing path. Result: instancing is faster, integrates cleanly with the glTF tooling ecosystem, and uses one fewer format.

For surveyors producing tilesets with thousands of repeating objects (asset inventories, vegetation surveys, infrastructure catalogues), the instancing rendering is noticeably faster.

Subtree files for huge scenes

Implicit tiling needs a way to tell the viewer which tiles in the conceptual quadtree/octree actually exist (you don’t want to generate empty tiles for the ocean or for sparse LiDAR areas). 1.1 introduces subtree files — binary files that encode the availability of tiles and content in a subtree of the implicit hierarchy.

A single subtree file can describe the availability of millions of tiles in a few kilobytes. The viewer fetches subtree files as it traverses the hierarchy, then uses them to decide which implicit tile URIs to request.

For surveyors: this matters at the scale of regional or national datasets. A continental LiDAR dataset with sparse coverage outside populated areas used to require explicit listing of every existing tile. With subtree files, the same dataset describes its availability in a compact binary format that streams as the viewer needs it.

glTF as the primary tile content format

3D Tiles 1.0 had .b3dm (Batched 3D Model — a glTF wrapped in a custom header with a feature table), .pnts (Point Cloud — a custom binary), .i3dm, and .cmpt. Four formats, four parsers.

3D Tiles 1.1 makes plain .glb (binary glTF) the recommended tile content format. Meshes, points, and instanced models all live in .glb files using glTF extensions:

• Meshes — standard glTF
• Points — EXT_mesh_primitive_point (or KHR_points in some implementations)
• Instances — EXT_mesh_gpu_instancing
• Metadata — EXT_structural_metadata, EXT_mesh_features

.b3dm, .pnts, and .i3dm are deprecated but still supported by viewers for backwards compatibility. New tooling should emit .glb tiles.

For surveyors: the practical effect is fewer format conversions in your pipeline. A glTF you exported for browser display can be tiled directly without re-encoding into .b3dm.

Compatibility

CesiumJS has supported 3D Tiles 1.1 features incrementally since version 1.99 (late 2022), with full implicit tiling and metadata support stable from CesiumJS 1.107 onwards (2023). Three.js loaders via the NASA-AMMOS 3DTilesRendererJS library support most of 1.1 as of 2024.

Most viewers handle both 1.0 and 1.1 tilesets. The asset.version field in tileset.json declares which spec version was used, and viewers branch accordingly. There’s no flag day — 1.0 tilesets keep working indefinitely.

Authoring tools have been slower to adopt 1.1:

• Cesium ion — emits 1.1 tilesets with implicit tiling for new uploads as of 2023
• py3dtiles — added implicit tiling support in 7.0 (2023)
• Pix4D / Metashape / RealityCapture — emit 1.0-style tilesets as of the time of writing; check version notes for updates
• PDAL — emits 1.0-style .pnts tilesets via the writers.tiler pipeline

If your tooling emits 1.0, your tilesets still work and still render in every modern viewer. Upgrading to 1.1-aware tooling buys you smaller tileset.json files, faster initial loads, and the metadata system. It’s not a forced migration.

What surveyors should care about

Practical impact, ranked by how much it’ll affect day-to-day work:

The metadata system is the biggest practical win. Being able to expose LiDAR classification, intensity, and capture metadata directly in a browser viewer — without separate attribute tables — closes the gap between “client looks at the survey” and “client interrogates the survey.” That’s the difference between a pretty deliverable and a useful one.

Where the standard is going

3D Tiles Next was the working name for the body of work that became 1.1. Future directions being explored in the OGC and Cesium community:

• Deeper glTF integration — 1.1 already made glTF the primary tile content format. Future versions likely fold more of the spec into glTF extensions, blurring the line between “a glTF model” and “a 3D Tiles dataset.”
• Improved point cloud handling — point cloud rendering in 3D Tiles still lags Potree on raw point fidelity. Active work in this area.
• Time-dynamic 3D Tiles — capture history visualisation (a quarry over six months, an infrastructure asset over years). Currently handled application-side; future spec versions may formalise it.
• Better authoring tools — the biggest gap right now is not the spec, it’s the tooling ecosystem. Expect more authoring software to catch up to 1.1 over the next year or two.

The headline: 3D Tiles is now a mature, OGC-ratified, vendor-neutral standard with broad implementation. The format isn’t going anywhere — if anything, 1.1 cements it as the default streaming format for large-scale spatial data.

If you’re delivering 3D Tiles to clients today, Swyvl reads both 1.0 and 1.1 tilesets and exposes metadata in the share link viewer when present. You don’t have to know which spec version your authoring tool emitted to get a working share link.