ka_sc
July 20, 2021, 12:06am
1
I am trying to make feature picking in large batched 3d gltf tiles work.glTF/extensions/2.0/Vendor at master · KhronosGroup/glTF · GitHub ? Is it the way to do it or has it changed?
Looks like EXT_3dtiles_feature_metadata is gone as well?
CesiumGS:3d-tiles ← CesiumGS:batch-table
opened 08:07PM - 26 Feb 20 UTC
**See https://github.com/CesiumGS/glTF/pull/3 for the more up-to-date schema**
…
For https://github.com/CesiumGS/3d-tiles/issues/269
For https://github.com/CesiumGS/3d-tiles/issues/385
Direct Link|Version|Changes
--|--|--
[`EXT_3dtiles_feature_metadata`](https://github.com/CesiumGS/glTF/blob/b18bec3a3b9b54ac2abfe899f70d21b5df070858/extensions/2.0/Vendor/EXT_3dtiles_feature_metadata) | 0.0.0 | Initial draft
[`EXT_feature_metadata`](https://github.com/CesiumGS/glTF/blob/feature-metadata/extensions/2.0/Vendor/EXT_feature_metadata) | 0.0.0 | Second draft with numerous revisions and a new name. Currently just in schema form.
b3dm, pnts, i3dm, and cmpt are moving to glTF! This gives us the opportunity to rethink how feature metadata works and lean on glTF wherever possible.
Here's the gist of it:
* The "Feature Table" concept in 3D Tiles 1.0 is being removed. The feature table stored position and appearance properties for point clouds and instanced models; instead we can use glTF attributes like POSITION, COLOR, and NORMAL. More on that in the [3DTILES_content_gltf](https://github.com/CesiumGS/3d-tiles/pull/427) extension.
* The "Batch Table" concept in 3D Tiles 1.0 is staying, but it's being split into "Feature Types" and "Feature Collections". The concept of "batching" models still applies but it should be treated as a verb only in specific cases.
* There's now support for multiple feature collections. You can define per-point properties (like intensity) and per-group properties (like architectural component) in the same tile.
* CesiumJS implementation for the original [`EXT_3dtiles_feature_metadata`](https://github.com/CesiumGS/glTF/blob/b18bec3a3b9b54ac2abfe899f70d21b5df070858/extensions/2.0/Vendor/EXT_3dtiles_feature_metadata/README.md): [`feature-metadata` branch](https://github.com/CesiumGS/cesium/tree/feature-metadata)
To do:
* [ ] How can this extension be written so that someone can import the model into a modelling program, export it, and not lose important information like the feature id attributes? Feature types and feature collections can now be stored separately (inspired by [gmdf](https://github.com/AnalyticalGraphicsInc/gmdf))
* [ ] Provide complete examples
* [ ] How can we improve styling capabilities?
* [x] Property min/max for color ramp. Require this in the accessor? Add min/max property for JSON arrays when type is `number`?
* [ ] Enum values and labels, e.g. for LAS classification, and a per-enum count.
* [x] The property type (string, number, boolean, etc)
* [ ] Do all vertices in a triangle need to have the same feature id? Otherwise, how is the feature id attribute interpolated? Barycentric or provoking vertex?
* [ ] Per-triangle feature IDs?
* [ ] Feature id ranges? https://github.com/CesiumGS/3d-tiles/issues/366
* [ ] Polyline counts to dynamically generate indices on the client and reduce payload size
* [ ] Add back the texture metadata image
* [ ] How can you group multiple instances to represent the same feature? E.g. a group of trees in a city? In general - should the `EXT_mesh_gpu_instancing` and `EXT_feature_metadata` interop be simplified?
* [ ] Should this extension be split into multiple extensions? See conversation starting at https://github.com/CesiumGS/glTF/pull/1#issuecomment-613159556.
* [ ] Add back batching explanation
* [ ] Add table of contents
* [ ] Multiple material ids per texel
* [ ] Built-in longitude, latitude, and height semantics.
* [ ] Per-feature bounding volume semantics: https://github.com/CesiumGS/3d-tiles/issues/127
* [ ] Allow for styling language to style based on semantics
* [ ] Linkages between different feature tables (e.g. a property in one table is an index to a feature in another table)
* [x] Need a Draco point cloud extension like [3DTILES_draco_point_compression](https://github.com/CesiumGS/3d-tiles/tree/master/extensions/3DTILES_draco_point_compression) - https://github.com/KhronosGroup/glTF/issues/1809 **(OBE with Meshopt)**
* [x] No clear alternative yet for `RGB565` compressed colors. Draco and Meshopt offer better solutions so we should consider scrapping `RGB565`.
* [x] No clear alternative yet for oct-encoded point cloud normals. Draco or Meshopt offer better solutions.
* [x] The old point cloud feature table defines some custom attribute compression schemes like quantized positions but there's already a lot of overlap with [KHR_mesh_quantiziation](https://github.com/KhronosGroup/glTF/tree/master/extensions/2.0/Khronos/KHR_mesh_quantization).
* [x] Feature table binary properties are now stored in glTF accessors. 3D Tiles supports double precision properties but glTF does not. glTF doesn't have a double `componentType` and padding for glTF chunks is 4 bytes which makes it more difficult to align double properties to 8-byte boundaries for usage with JavaScript's `Float64Array`. If this would be a breaking change to the glTF spec what can we do to get around it? Enforce that double properties are aligned to an 8-byte boundary relative to the start of the glb / glTF buffer? **(OBE: now using Apache Arrow)**
* [x] Feature table properties do not have as strict alignment requirements as glTF accessors. glTF requires that accessors are aligned to 4-byte boundaries even if the component type is less than 4 bytes (common for feature ids to be uint8 or uint6). See https://github.com/KhronosGroup/glTF/tree/master/specification/2.0#data-alignment. **(OBE: now using Apache Arrow)**
* [x] Still need to finalize the schema for external feature tables. See https://github.com/CesiumGS/glTF/pull/1#issuecomment-627348459 for the latest.
* [x] Write schema
* [x] Well known semantics for feature table properties? E.g. the property object contains a `semantic` field like "NAME" or "ID", and the client knows that it can get the name from that property.
* [x] How are per-vertex properties (not IDs) interpolated across a triangle? **(OBE: all per-vertex properties are stored in feature collections via implicit feature IDs)**
* [x] How should per-texel feature properties be sampled? `NEAREST` sampling makes sense most of the time but maybe it's best left up to the discretion of the tileset author to chose their own samplers.
* [x] Is it possible to incorporate global feature ids? https://github.com/CesiumGS/3d-tiles/issues/265. Does this affect the feature hierarchy extension? Is this what the "ID" semantic is?
* [x] What are valid property names? All utf-8 strings? See https://github.com/CesiumGS/3d-tiles/pull/412
* [x] Make sure `normalized` is applicable to signed and unsigned types
* [x] Is `EXT_3dtiles_feature_metadata` the right name? Should the `3dtiles` part be dropped?https://github.com/CesiumGS/glTF/pull/1#discussion_r414540907
* [x] Point size attribute? Line width? **(Out of scope for this extension)**
* [x] Remove feature metadata dependency on accessor and buffer view so it can be used by non-gltf payloads (vector tilers TBD) and 3D Tiles metadata
* [x] Do metadata textures belong in primitive or material?
* [x] Metadata at the node/mesh level. Can node metadata be stored in a feature table?
* [x] No clear alternative yet for `CONSTANT_RGBA`. **(Topic moved to [3DTILES_content_gltf](https://github.com/CesiumGS/3d-tiles/pull/427))**
link to sample code
@ka_sc
The feature metadata extension that you referenced in your post is an old version of our feature metadata extension.
Here is our documentation for 3D Tiles next. This documentation includes the most recent information related to 3D Tiles next, which should be released later this year.
# 3D Tiles Next
**3D Tiles Next** is a set of capabilities for the future of 3D Tiles. Currently, they take the form of extensions to the [3D Tiles 1.0](https://github.com/CesiumGS/3d-tiles/tree/main/specification) specification. In the future, these extensions may be incorporated into 3D Tiles 2.0.
The 3D Tiles Next extensions add capabilities to 3D Tiles on a number of fronts:
3D Tiles Next **enables new methods for storing metadata.** Metadata can now be stored at different levels of granularity: tileset, tile, group, feature, and texture. Texture metadata allows for fine-grained storage of metadata down to individual texels. Feature metadata is similar to the existing Batch Table format, but allows for additional types such as enumerated types (enums). Tileset, tile and group metadata provide standardized methods to store coarse-grained metadata about a tileset.
<img src="figures/3d-tiles-next/metadata-granularity.png" alt="Metadata Granularity" width="600">
**Implicit Tiling** is an alternate method for describing a tileset that **enables new algorithms and optimizations**. This compact tree representation allows for new tree traversal algorithms, raycasting, and faster spatial queries. It also **provides interoperability** with several geospatial formats such as CDB, TMS, WMTS, and S2.
<img src="figures/3d-tiles-next/implicit-tiling.jpg" width="600px" alt="Implicit Tiling">
**S2 Bounding Volumes** provide a tiling scheme that is **suited for global scale tilesets**. Cells at the same level of detail have approximately equal area. Furthermore, the [S2 tiling scheme](http://s2geometry.io/) is designed to **minimize distortion near the poles**.
<img src="figures/3d-tiles-next/s2.png" width="600px" alt="S2 Tiling Scheme">
**glTF is the future of 3D Tiles**. 3D Tiles Next provides an extension to support glTF models directly in a tileset. In the future, even 3D Tiles 1.0 formats (such as B3DM) will be rephrased as glTF models.
show original
Could you please provide some more information about your data? What is your datasource? Are you working with an older version of the Vricon base globe?
-Sam
2 Likes
ka_sc
July 22, 2021, 8:30am
3
Thanks so much, i take a look
@ka_sc
No problem! Please keep me in the loop.
-Sam