Add 3DTILES_content_conditional

[javagl]

(This was originally called 3DTILES_dynamic, but for alignment with the <PREFIX>_<scope>_<feature> pattern, it is now called 3DTILES_content_conditional)

This extension is supposed to be a generalization of what was originally referred to as "time-dynamic" tiles.

Context

The idea of "Time-dynamic 3D Tiles" was originally brought up in #102, about 10 years ago. The issue was largely dormant since then. Recently, it has gained some traction. The goal would be to define the scope, use-cases, and possible implementations for (time-) dynamic 3D tiles more clearly (and eventually consider to make this a core feature of 3D Tiles 2.0).

Despite the topic only recently receiving more attention, there are some discussions that are a bit scattered at different places. I'll try to summarize a few links here:

The initial proposal for (time) dynamic 3D Tiles was made in this comment. It consisted of the following pull requests:

• Add 3DTILES_time_dynamic extension #817 : This defines metadata with 'semantics' for the content. This metadata was supposed to be assigned to contents in the tile.contents array. The metadata defines a time-range, given as ISO8601 strings, indicating that the respective content should be associated with (or 'exist in') this time range.
• Add 3DTILES_implicit_tiling_multiple_contents extension #816 : This defines a generalization of the concept of "multiple contents" for implicit tiling, with the goal of having a more compact representation of content metadata in implicit tiling, for the case that the number of contents should vary between the implicit tiles
• Add 3DTILES_implicit_tiling_custom_template_variables extension #815 : This defines a generalization of the 'template URI' concept of implicit tiling, with the goal of being able to access contents not only based on the implicit tile coordinates, but also based on 'time stamps' (or other properties)

I wrote a longer comment with a first feedback pass on that. The summary of that is

• Representing "(time) dynamic contents" as "multiple contents" (i.e. the tile.contents array) raises a few questions. Multiple contents are not so widely supported. It is not clear how to combine the metadata that determines the "time-dynamicness", and other metadata that is supposed to be stored for the content. There is no established infrastructure for maintaining "metadata semantics". Fixing the "dynamicness" to time, and to ISO8601 strings in particular, may be too restrictive.
• The generalization of "multiple contents for implicit tilings" was just a workaround for some of these limitations
• The generalization of the "template URI" is something that should be considered, but is not specific for "(time)-dynamic content"

I therefore proposed to generalize some of that to dynamic content (not restricted to time). The initial drafts/suggestions have been added in that comment and the subsequent comments in that issue. Further discussion has happened there and at other places. The draft pull request for the implementation in CesiumJS, at CesiumGS/cesium#12977 , contains additional considerations. Some of them are focussed on the actual implementation, but obviously connected to the underlying data model (and what the implementation actually needs from that data model).

Current State

The README.md of this pull request reflects the current state of the discussion. This is still a draft.

I'll try to summarize some of the open questions here. Given that these questions have mainly been brought up during the development of the implementation for CesiumJS, it might be better to discuss this in the implementation PR in CesiumJS:

• Type information or schema definition: Right now, the top-level extension object defines the "dimensions" that serve as the basis for the selection of the active content. The types of these properties are currently limited to string. One could make a strong case to allow additional types here, and maybe include additional information about valid value ranges. At some point, this would resemble a "metadata schema". Actually using a "3D Tiles Metadata Schema" was considered in a comment about using metadata in the implementation pull request, but did imply too many possible inconsistencies and undesired side-effects. But still, there are several levels for the types that could be allowed for these dimensions. Some of the options are summarized in another comment about type information in the implementation pull request.

• Selection/activation criteria: Until recently, the implementation made the assumption that two content items could not be 'active' at the same time when one of their 'keys' properties had different values. This allowed building an efficient "lookup" in the implementation, but it did limit the flexibility of what could (easily) be modeled. As part of a recent generalization, that assumption has been lifted. The new approach allows defining arbitrary conditions for a content item to be 'active'. This may have performance implications and may warrant further investigations. Some details are in a comment about activation criteria in the implementation pull request.