OGC seeks public comment on Community Standard Work Item for 3D Tiles 2.0

[ogcscotts]

The Open Geospatial Consortium (OGC) is seeking public comment on the proposed 3D Tiles 2.0 Community Standard Work Item, a revision to the 3D Tiles Community Standard designed to support the efficient streaming of high-resolution, semantically rich 3D geospatial data.

Overview
The proposed revision continues the evolution of the standard by further aligning it with the glTF ecosystem through glTF 2.1 and its external asset referencing capabilities for spatial subdivision. It also removes several legacy 3D Tiles 1.0 features and file formats to simplify implementation and improve interoperability.

3D Tiles 1.0 is an OGC Community Standard for sharing, visualizing, fusing, and interacting with massive heterogeneous 3D geospatial content across desktop, web, and mobile applications.

Version 1.1 enhanced the Standard by improving semantic metadata support, enabling implicit tiling, and introducing direct references to glTF files, allowing for better integration with the glTF ecosystem.

The proposed scope for OGC 3D Tiles 2.0 includes:

• Primary Scope

• Baselining on glTF 2.1

• Secondary Scope

• Architectural, Engineering, and Construction (AEC) rendering extensions
• Time-dynamic 3D Tiles
• Voxel support
• Vector Tiles
• 3D Gaussian Splatting

Backward Compatibility
A tileset conforming to 3D Tiles 1.1 will also conform to 3D Tiles 2.0, with the exception of the asset.version field.

Implementations of 3D Tiles 2.0 will accept tilesets declaring an asset.version of either 1.1 or 2.0.

While 3D Tiles 2.0 tilesets should declare a glTF 2.1 document as the entry document, they may also use a tileset JSON document as the entry point, provided it excludes features removed in version 2.0.

[nsnarayanam]

Comment on the proposed 3D Tiles 2.0 Community Standard Work Item (OGC 26-034)

Submitted on behalf of Aganitha Space Technologies, an active participant in OGC
Standards Working Groups.

We support the direction of this work item. Consolidating on glTF 2.1 and retiring
the legacy binary tile formats (b3dm, i3dm, pnts, cmpt) removes a long-standing
source of implementation divergence and lowers the barrier for new producers and
renderers. The points below are offered to strengthen interoperability between
3D Tiles content and the discrete global grid systems now widely used as the
analytical fabric for Earth observation and digital-twin workloads.

1. Spatial subdivision and alignment with DGGS.
3D Tiles implicit tiling subdivides space with quadtrees and octrees over region or
box bounding volumes, and the glTF 2.1 external-asset referencing cited for spatial
subdivision extends that model. Neither has a defined relationship to a discrete
global grid. We ask that 2.0 either specify a non-lossy referencing path between a
subdivision node and DGGS zone identifiers, per the OGC DGGS Abstract Specification
(Topic 21) and OGC API - DGGS, or state explicitly that such alignment is out of
scope and record the rationale. Without one of these, 3D Tiles content and
DGGS-indexed analytics stay siloed at the tiling layer even when they describe the
same volume of space.

2. Voxel support and 3D grid cells.
Voxel support sits in the secondary scope. We recommend the voxel data model be
designed so a voxel tileset can carry or resolve to DGGS zone identifiers, including
3D and extruded cell systems, rather than introducing a voxel indexing scheme that
cannot round-trip to an established grid hierarchy. This matters for volumetric
atmospheric and subsurface fields, where the same voxels are queried analytically
outside the renderer.

3. Time-dynamic tiles: temporal validity, not only animation.
Time-dynamic 3D Tiles should specify temporal validity at the tile and content
level, distinguishing observation time from valid time, and should provide a way to
express absence and uncertainty. A tile covering an interval with no observation is
not the same as a tile asserting observed emptiness, and consumers need to tell them
apart. We suggest binding this to EXT_structural_metadata so temporal uncertainty
travels as semantics rather than convention. This connects directly to work underway
in IEEE P4011 on temporal uncertainty and missed-observation risk, which we would be
glad to bridge into the SWG.

4. Referencing external semantic records.
As semantic richness increases, a normative pattern for referencing external
authoritative records by URI from structural metadata (for example to OGC API -
Features or Records resources, or to knowledge-graph entities) would let 3D Tiles
content link out to source observations rather than embedding all semantics inline.
This keeps large tilesets lean and their meaning traceable.

We would welcome the chance to contribute to the SWG on the DGGS-alignment and
temporal-validity items in particular, and can supply reference cases from
operational DGGS-native Earth-intelligence pipelines if useful.

Narasimha Sharma Narayanam
Founder, Chairman & CEO, Aganitha Space Technologies
nsnarayanam@aganithaspace.com

[cnreediii]

Well written justification document! A few questions:

1. Not clear whether 2.0 is backwards compatible with 1.1 or not. In OGCland, a major version number indicates that the revision is not backwards compatible. However, the text states that 1.1 implementations (other than assert-version and the removal of some deprecated elements) are compatible. Just seeking clarity.
2. The base lining on glTF. Does this then preclude the use of other 3D "asset" formats? Just wondering.
3. The use of BENTLEY_materials_line_style and BENTLEY_materials_point_style glTF extensions. Does this preclude the use of other materials styling technologies?
4. Vector tiles. A terminology issue. There is no such thing as a vector tile. A tile in graphics/GIS land is a mathematical construct. The vector data content is tiled. So to be semantically correct, we are speaking of tiled vector data. Mapbox really messed the tiling terminology up :-) I "fight" this terminology battle in the OGC also. Maybe because I helped developed geospatial tiling technologies back in the late 1970s! Used the same timing scheme regardless of data type.

Regards - Carl

[bjornblissing]

Comments on the proposed 3D Tiles 2.0 Community Standard Work Item 26-034

Submitted on behalf of: Vantor

Review date: This review reflects the material available on 2026-07-15. Changes made after this date are not included.

Summary and Position

Vantor supports initiating the 3D Tiles 2.0 Community Standard Work Item. The comments below are intended to inform the scope and priorities of the work, not to object to it proceeding.

The proposal sets a promising direction. The current technical material is best read as an overview of work in progress rather than an implementation-ready 3D Tiles 2.0 candidate specification. The public proposal is primarily an index into draft extensions and open pull requests. Several foundational areas still need stable normative definitions before independent implementations can be expected to behave consistently, including the glTF 2.1 data model, scalable hierarchy, coordinate systems, traversal, and compatibility with 3D Tiles 1.1.

The comments below focus on the current 2.0 material and on existing 1.1 behavior whose disposition in 2.0 is not yet stated consistently or normatively. Established 3D Tiles 1.1 behavior is taken as the baseline and is discussed only where its treatment in 2.0 would benefit from clarification.

Comments

1. The normative scope is not yet collected into a versioned specification. The justification is suitable as a proposal to begin standards work, but it is not normative specification text. The public material still consists largely of mutable drafts and pull requests. There is not yet a pinned set of dependencies, a complete aggregate schema, defined conformance classes, or a validator target for a reproducible 2.0 release.

2. The proposed glTF 2.1 foundation is not yet stable. The tileset design depends on glTF 2.1 external assets, shapes, and bounding volumes, but the linked glTF specification and schemas do not yet define those concepts. This makes it difficult to stabilize or validate the 3D Tiles core while its foundation is still evolving.

3. The compatibility policy needs a clearer migration story. The justification states that 1.1 tilesets remain compatible, yet the proposal also removes formats and properties allowed by 1.1. The relationship between the legacy JSON path and the new glTF path, including mixed-version references and conversion expectations, needs to be stated consistently.

4. The scalable hierarchy is not yet fully defined. Implicit tiling, subtrees, and external tilesets are central to streaming large datasets, but their availability, subdivision, loading, boundary, and failure behavior remains incompletely defined. These pieces should be stable before the core representation is finalized.

5. Core runtime behavior and the tile content model need further definition. The draft does not yet provide a complete traversal and refinement contract, particularly across external assets and loading failures. It also replaces the established multiple-content model with a single externalAsset without explaining how independently selectable or available content layers map to the new representation.

6. Coordinate systems and bounding volumes need one coherent contract. CRS declarations can change the interpretation of every coordinate, yet they are described as optional. The relationship among CRS units and axes, glTF coordinates, node transforms, and the new geospatial bounding shapes is not yet clear enough to guarantee consistent interpretation.

7. The new content capabilities are ahead of their normative definitions. Vector styling, temporal selection, sparse voxels, AEC rendering, and Gaussian splatting all have useful demonstrations and implementation interest. Their minimum semantics, dependencies, and interoperability requirements are not yet consistently defined.

8. A core extension set for 3D Tiles 2.0 should be distinguished from optional extensions. Unlike 3D Tiles 1.1, 3D Tiles 2.0 is not a self-contained format; it is built on glTF 2.1 and a set of extensions. The specification should clearly identify the extensions required for an asset to qualify as a core 3D Tiles 2.0 tileset. It should also define a realistic baseline of extensions that implementations will be expected to support, rather than require support for every extension developed under this Work Item. Most proposed vector, temporal, voxel, AEC, Gaussian-splat, and other specialized extensions should remain outside this core set unless they are necessary for basic interoperability.

9. The packaging and streaming model needs to be demonstrated. Moving the hierarchy into glTF does not by itself define efficient hierarchy access, request granularity, caching, or failure handling. These operational characteristics are part of the core value of 3D Tiles and should be validated alongside the data model.

Recommendation

Vantor recommends that the Work Item proceed, and that the resulting candidate Community Standard address the points above before submission for standardization. Vantor is willing to participate in the review of the resulting drafts.

[jeremiefarret]

Comment on the proposed 3D Tiles 2.0 Community Standard Work Item (OGC 26-034)

Submitted on behalf of SGDL Innovation SA, a Swiss deeptech company working on spatial encoding, multidimensional object indexing, and physical AI architectures, and an active participant in MPEG 3D Graphics & Haptics activities.

We support this work item. Consolidating on glTF 2.1 and retiring the legacy binary tile formats is the right move, and it opens a natural point of contact with spatial-indexing methods that currently sit outside the 3D Tiles ecosystem. Our comments focus on the subdivision model and the voxel scope.

1. Space-filling curve alternatives to quadtree/octree subdivision.
   Implicit tiling in 3D Tiles subdivides space with quadtrees and octrees. This is a reasonable default, but it isn’t the only, or always the most efficient, way to linearize multidimensional spatial data. Space-filling curve-based indexing (Hilbert, Morton, and generalized variants) preserves spatial locality more tightly under certain access patterns and scales more naturally to higher-dimensional or non-uniform data. We’d ask that the implicit tiling model either accommodate a pluggable subdivision/indexing scheme, or that the SWG document explicitly why quadtree/octree was chosen as the sole mechanism, so alternatives aren’t foreclosed by omission.

2. Voxel support should anticipate learned/tokenized representations, not just raw grids.
   The secondary-scope voxel data model should be designed with an eye toward voxel tokenization for machine consumption (e.g. transformer- or state-space-based encoders operating on voxel volumes), not only human/renderer-facing dense grids. If the voxel model is defined purely as a rendering primitive now, retrofitting it for AI-native indexing later will be costly. We’d welcome the chance to share early results from our own voxel tokenizer work if that’s useful input to the SWG.

3. Multidimensional object indexing beyond 3D.
   Several downstream use cases (trajectory data, time as a fourth dimension, genomic/sequence data mapped into spatial structures) benefit from indexing schemes that generalize past three spatial dimensions.

We’d support language in the work item that keeps the door open to N-dimensional extensions of the tiling/voxel model, even if full support isn’t in initial scope.

We’d welcome participation in the SWG on the subdivision-scheme and voxel-indexing points, and can bring reference material from operational spatial-indexing and voxel-tokenization work if helpful.

Jérémie Farret CTO, SGDL Innovation SA

[akmorgan99]

Responses to OGC public comments

Aganitha Space Technologies

DGGS is out of scope for 3D Tiles 2.0, but we are open to future extensions that add support for all relevant DGGS features including the discrete global grid and zone identifiers. While we aren't pursuing this at the moment, we welcome any SWG or community extension proposals aimed at bringing better support for DGGS into 3D Tiles. This is a huge benefit of moving to glTF 2.1 because adding a support extension is much easier than doing a major release update.

EXT_structural_metadata remains a major concept within 3D Tiles 2.0 and we continue to rely heavily on it. This extension remains the primary method to add uncertainty and other semantic meaning to your data within 3D Tiles and should have no issues storing data regarding temporal validity for your use case. There is no plan to support "sidecar" metadata files or other authoritative records, but you can store IDs for tiles and other elements using EXT_structural_metadata that can tie back to a value within an application database. This method is used today with 3D Tiles 1.1 extensively within the AEC space, and will remain a fully supported workflow in 3D Tiles 2.0

Carl Reed

3D Tiles 2.0 isn't backwards compatible with 3D Tiles 1.1, but we don't have plans to replace or deprecate 3D Tiles 1.1 at the moment. New features and extensions will target 3D Tiles 2.0, but just as with the release of 3D Tiles 1.1, we expect wide-spread adoption to take time. On full release, we expect to have tooling to convert tilesets using 1.1 to 2.0, just as we did to bring 1.0 tilesets up to 1.1. For the Cesium runtimes we will continue to support 3D Tiles 1.1 for the foreseeable future. This all may change later, but not until we're confident that 3D Tiles 2.0 has enough critical mass within the community to do so.

The glTF 2.1 specification leaves open the possibility of supporting other file types as asset formats, but limits it to the glTF MIME types in specification. Extensions targeting glTF 2.1 will be able to override this requirement. This design is intentional; we want to rely on the extension mechanism to indicate if a different asset type is supported, so renderers parsing the glTF asset know what to expect and can fail fast if the application (or asset) requires it.

With the shift to building 3D Tiles 2.0 atop of glTF 2.1, there's no change regarding support for glTF material extensions of any kind. You can continue to use any glTF material extensions as long as the renderer you're using supports them. Regarding extensions, there are other benefits to bringing 3D Tiles and glTF closer together:

1. Extension designers for glTF extensions can better plan for parameters that may cross or interact beyond child asset (i.e. tile) boundaries.
2. When designing 3D Tiles extensions, we can more reliably build atop existing glTF extensions. (e.g. 3DTILES_conditional_content for 1.1 relied on it's own method, but we are exploring using KHR_node_visibility for the 2.0 version. This reduces repetition and vastly simplifies implementations.)
3. The lift to bring several classes of extensions into the 3D Tiles world is more predictable.
4. New extensions to 3D Tiles that prove useful to both the 3D Tiles and glTF communities will be eligible for ratification by Khronos with the IP guarantees that provides.

Duly noted regarding the "Vector Tiles" terminology. I uniquely relate to this, because I'm seeing the same thing happen in the Radiance Fields world with everything "splatting" related being called Gaussian splatting. That said, we chose this terminology to align with the industry and community such as Esri, Mapbox Vector Tiles and others.

Vantor

We provided the normative specification for 3D Tiles 2.0 with the justification document. The draft is being kept up to date on the 3D Tiles GitHub repository. We also have a GitHub milestone for 3D Tiles 2.0. Unfortunately, this milestone isn't really representative of how far along we are in the development of 3D Tiles 2.0 and only provides insight into a slice of what is going on in the background, but maybe it will be useful.

As of 31 Jul 26, the External Assets, Unified File References, Shapes and BVH changes to the glTF Specification are now published as PRs on the glTF repository. We may expect very minor changes to these but they're stable and the Nvidia team working on Vulkan glTF Renderer has already added support in an experimental release. Internally, we also have implementations that will be available soon.

We acknowledge the confusion regarding migration. 3D Tiles 1.1 will remain supported within Cesium but won't be getting new features, and there will be a migration tool from 3D Tiles 1.1 to 3D Tiles 2.0. Our recommendation is that viewers continue to support both 3D Tiles 1.1 and 3D Tiles 2.0, but that creators move to 3D Tiles 2.0 when they can. Please see my response to Carl for more details.

Since 3D Tiles 2.0 is built atop glTF 2.1, we are using glTF extensions to normatively define the core runtime behaviours, coordinate systems, content capabilities, and others. The 3DTILES_tileset extension contains the core definitions and acts as the entry point for everything else. Other 3D Tiles related glTF extensions may or may not have other dependencies based on their needs. One recognized area for improvement is the 3D Tiles 2.0 specification needs to cleanly define what features are required for an implementation to be considered compliant.

On a technical level, there is little difference between what 3D Tiles 1.1 does today and what glTF 2.1 and 3D Tiles 2.0 will do tomorrow for streaming. Validation will continue to be performed but no issues are expected. glTF 2.1 will provide a more robust ability for packaging large assets. This includes support for 64-bit binary formatting and mechanisms to support packaging external assets in a single file.

SGDL Innovation SA

We have a 3DTILES_shape_S2 extension for 3D Tiles 2.0 that adds support for using S2 cells as bounding volumes. This supports the modified Hilbert curve provided by the S2 library. We welcome any additional extensions or community requests to add additional support for other space-filling curves to 3D Tiles 2.0.

Voxel support in 3D Tiles 2.0 is aimed at rendering but we are interested in exploring future extensibility for future use cases. We will continue to support deep semantic metadata for latent spaces, indexing, and other applications through the EXT_structural_metadata extension. There's room to grow here and we are looking at ways to grow this in the future.

While we refer to them as "time-dynamic 3D Tiles," the 3DTILES_conditional_content extension actually allows you freedom to define any fourth-dimension that you require. We've had discussions regarding everything from flip-book style animations to arbitrarily tagged data, and expect with the flexibility we're providing the community will be able to surprise us with the additional use-cases they find for conditional content support.