Potential scope for the next version of 3D Tiles

[lilleyse]

The 3D Tiles community has been extremely active since 3D Tiles 1.1 was published in January 2023 and we feel like it's time to start scoping out the next version - whether that's 3D Tiles 1.2 or 3D Tiles 2.0.

Below are some of the in-progress features and potential breaking changes to consider for the next version.

Feel free to add your ideas to this issue!

Time-dynamic 3D Tiles

• Time-dynamic 3D Tiles #102 - 3DTILES_time_dynamic

Gaussian splats

• KHR_gaussian_splatting and KHR_gaussian_splatting_compression_spz_2

Voxels

• EXT_primitive_voxels and 3DTILES_content_voxels
• Support for non-uniform subdivision
• Support for generic accessor quantization in glTF

Vector data

• Vector Tile Roadmap #25
• Vector data... in glTF? #825

AEC rendering

• Reconcile iMdl tile format with 3D Tiles spec iTwin/itwinjs-core#7311
  • EXT_mesh_primitive_edge_visibility to replace CESIUM_primitive_outline
  • EXT_mesh_primitive_restart
• Implicit surfaces

Package format

• Package tileset in a single file #89
• Archive format that supports fast streaming #399
• Need for a new 3dtiles archive format #422
• A proposal for a 3D Tiles packaging format specification #727
• Entry compression in 3D Tiles packages #806
• Packages as external tilesets #804

Metadata

• Clearer relationship between tileset and glTF metadata #828
• Add support for multiple semantic vocabularies on a single dataset #811
• Add support for metadata semantic on classes #812
• Remove alphanumeric restriction on property IDs, support unicode #797
• No Data values for Enums #785
• 3DTILES_metadata: Statistics on mixed-length array properties #529
• Figure out scope of summary statistics #573
• What is the process for defining new metadata semantics? #574
• Ideas for structuring Metadata Semantics #643
• Consider allowing a "parent" class for metadata classes #786
• Thoughts about support for 'units' in metadata #800
• Binary representation for explicit tiles #635

Implicit tiling

• 3DTILES_implicit_tiling_custom_template_variables
• 3DTILES_implicit_tiling_multiple_contents

glTF 2.1

• Spatial subdivision within a glTF model #553
• glTF 2.1 and complex scenes KhronosGroup/glTF#2532

Geolocation

• 3DTILES_ellipsoid
• Clarify the concept of being 'geolocated' in 3D Tiles #803

Other

• Asset Schema: Add support for "generator" field #821
• MIME type 3D tiles #341

Spec clarifications

• Add external tileset clarification to overview #406
• Clarify bitwise operators for implicit tiling #507
• Section in the 3D Tiles spec about recommended glTF extensions #602
• Semantic clarification with Bounding Volumes and ImplicitTiling #777
• How to support placeholder tiles - empty tiles used for culling but not refinement #609
• Interpreting "should" around extensions definition in spec #814
• no visible tiles for certain zoom levels NASA-AMMOS/3DTilesRendererJS#1304

Potential breaking changes

Note: would mandate a major version bump to 3D Tiles 2.0

• Remove legacy tile formats b3dm, i3dm, pnts, cmpt
• Remove legacy tileset.properties
• Remove multiple contents
• Remove content metadata groups
• Consider removing schema.id #831
• Potential breaking changes to EXT_mesh_features and EXT_structrural_metadatal
  • Potential breaking changes to EXT_mesh_features
  • Potential breaking changes to EXT_structural_metadata
  • Rework EXT_mesh_features and EXT_structural_metadata #829
• Semantics vs. extensions #782 (comment)
• Store longitude and latitude in degrees instead of radians #387
• How should tiles point to external tilesets? #584
• Question: Should tile geometricError be scaled by transform scale before SSE calculation? #813
• Whether tile transforms should apply to region

[lilleyse]

Another spec clarification to add: external tileset refinement behavior NASA-AMMOS/3DTilesRendererJS#1304

[runaas]

#558 ?

[lilleyse]

@runaas possibly! We're still trying to decide on the direction of 3D Tiles metadata and how it might interact with BIS / iModel and other systems in the future. I'm curious to hear about your use case for hierarchical metadata.

[runaas]

We are generating 3DTiles from 3DCityDb (CityGML) databases, using data from IFC models and models generated from 2.5D map data by our own programs. Here we have a very heterogeneous collection of properties, currently made possible by using json data in batch tables hierarchies.

We need something hierarchical because a window is also part of a wall that is a part of a building storey that is a part of a building that is a part of a building site that is a part of a project.... and in addition the window may be part of a "layer" (totally orthogonal to the other hierarchy), and there may be windows that are directly part of the building without being part of a wall or storey. Duplicating the higher level attributes into all of the geometry objects will expand the tile data volume immensely!

The system in 1.1 where an object can have several feature_ids and refer to several property tables could be nice if only data from more than one feature_id / property table could be used for styling and picking of property data, but as only one can be selected through FeatureIdLabel it is not so useful for us (should we style only by house properties or only window properties? Is the user interested in the window, wall, building or layer properties when picking?).

In addition the object properties can be quite various and unpredictable, and not well suited for the rigid class structure of 3DTiles 1.1. We are currently using json in b3dm for a more free attribute structure, and would find a json (and/or bson, jsonb or another equivalent binary format if that gives better performance) datatype very useful. As modern databases also support json columns I would believe we are not alone in wanting this.

So, for us the 3DTiles 1.1 metadata structure as of today is mainly a step rearwards from b3dm, and even if we are exploring 1.1 for use in platforms that don't support 3DTiles 1.0 (unity etc...), we'll have to use 1.0 and b3dm, i3dm, cmpt for a long time if this is not improved.