You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The JSON tree structure for explicit tiling can get quite bulky, especially as new metadata properties are added. It would be more concise to encode tiles in binary.
The general idea is to model this after subtrees where each tile conforms to a class and tile metadata is stored in a property table.
There would be a tile class that defines the structure of each tile. It would make heavy use of semantics. This would include semantics that define the bounding volumes (TILE_BOUNDING_SPHERE, TILE_BOUNDING_REGION, TILE_BOUNDING_BOX), a semantic for referring to tile content (TILE_CONTENT_IDS), and a semantic for referring to child tiles (TILE_CHILDREN_IDS). There would also be semantics for geometric error, transform, and other built-in tile properties. The class could also have user defined properties (aka metadata).
There would also be a class for tile content. This would have bounding volume semantics and a CONTENT_URI semantic, as well as user defined properties.
So far this is no different than how metadata works today. Tiles could be encoded in a binary property table, same with tile contents.
TILE_CHILDREN_IDS is what determines the tree structure. This semantic would be a variable-length array of indices into the tile table. Cyclic chains would need to be forbidden. TILE_CONTENT_IDS would link tiles with their content. It would be a variable-length array of indices into the content table.
tileset.json would need to have buffers and bufferViews to store the data.
Mockup of what this might look like:
schema.json: country and triangleCount are custom properties
The JSON tree structure for explicit tiling can get quite bulky, especially as new metadata properties are added. It would be more concise to encode tiles in binary.
The general idea is to model this after subtrees where each tile conforms to a class and tile metadata is stored in a property table.
There would be a tile class that defines the structure of each tile. It would make heavy use of semantics. This would include semantics that define the bounding volumes (
TILE_BOUNDING_SPHERE
,TILE_BOUNDING_REGION
,TILE_BOUNDING_BOX
), a semantic for referring to tile content (TILE_CONTENT_IDS
), and a semantic for referring to child tiles (TILE_CHILDREN_IDS
). There would also be semantics for geometric error, transform, and other built-in tile properties. The class could also have user defined properties (aka metadata).There would also be a class for tile content. This would have bounding volume semantics and a
CONTENT_URI
semantic, as well as user defined properties.So far this is no different than how metadata works today. Tiles could be encoded in a binary property table, same with tile contents.
TILE_CHILDREN_IDS
is what determines the tree structure. This semantic would be a variable-length array of indices into the tile table. Cyclic chains would need to be forbidden.TILE_CONTENT_IDS
would link tiles with their content. It would be a variable-length array of indices into the content table.tileset.json would need to have
buffers
andbufferViews
to store the data.Mockup of what this might look like:
The text was updated successfully, but these errors were encountered: