Implicit tiling

[loshjawrence]

DRAFT @pjcozzi

[pjcozzi]

Can we retarget this pull request to a new staging branch something like 3d-tiles-new-extensions? We can queue up the upcoming extensions there then merge in master when everything is in good shape.

[pjcozzi]

I think the structure of this extension/schema is in good shape. The spec and schema require some attention to get them to production.

I don't have bandwidth to provide feedback on each iteration so I would suggestion the following:

• @loshjawrence review my comments and batch up any questions for me
• @loshjawrence make any changes along with feedback from @shehzan10
• @lilleyse reviews
• Bump to me for a final review.

In general, the big areas to improve include:

• Context - help the reader know why this extension should exist at all and why its major components exist. Define use cases. Compare to the core spec that uses explicit tiling.
• Concepts - introduce a new Concepts section that defines key concepts for this spec; most key concepts are currently hiding in individual properties descriptions.
• Spec language - throughout use concise and precise spec language by look at the rest of the 3D Tiles spec and the glTF spec for examples.
• Property naming - revisit the JSON property names and strive for concise, precise, and consistent naming.
• Figures and examples - Throughout provide more examples and figures to illustrate them where I flagged. Figures can still be hand drawn for now.
• JSON to uri - The key concept of generating a uri from the JSON/availability and knowing when the uri/tile will be present should be more carefully presented and built ground up with a series of simple examples.
• Property reference - Each property should be fully defined, including its datatype, bounds, and relationship/dependency on other properties. The glTF property reference can serve as a good example.

[pjcozzi]

The intro needs more context - probably 2-3 paragraphs total. In this order, concisely explain:

• Why
• What
• How

I have written down basically all of this elsewhere in public GitHub issues and internal notes. Please let me know if you need help finding it.

Also, include a representative image here.

[pjcozzi]

The spec should also have a list of common use cases somewhere that we have gathered in the other GitHub issues and internal notes, e.g.,

• Global quadtree like WMTS
• Global double-headed quadtree for terrain like quantized-mesh
• Local octree for point clouds
• Etc

Include an example for each and the motivation for using implicit tiling compared to 3D Tiles' default explicit tiling whether it be any combination of random access for analytics and visualization, reduced IO, interoperability with other standards, etc.

[pjcozzi]

The spec should also include an example - maybe an appendix that should a simple quadtree or whatever in the explicit 3D Tiles JSON - and then with the implicit extension.

[loshjawrence]

@shehzan10 Please review when you get a chance. I did not cover all of Patrick's comments. This is taking long than I expected and need to switch to implementation since I'm getting behind on that.

[pjcozzi]

@loshjawrence one more question: we discussed that availability should be more general purpose than just boolean for its presence, bounding volume, number of triangles, etc. However, we don't want the overhead of a JSON object per tile for this metadata so we discussed the ability to define a general schema and then each tile to store a small binary blob in that schema. Is this something covered by this extension? Or is that separate?

[loshjawrence]

@pjcozzi Separate, it lives here atm #383

[loshjawrence]

@shehzan10 @lilleyse Can you guys add what ever comments you may have when you get a chance?

[pjcozzi]

@shehzan10 @lilleyse Can you guys add what ever comments you may have when you get a chance?

Bump @shehzan10 @lilleyse

[pjcozzi]

@loshjawrence one more question - ContextCapture can export tiled OBJs - how does that tiling map to 3D Tiles implicit tiling? And can you please include an example in the spec?

[loshjawrence]

It sounds like we currently take the tiled obj leaves and tile those through the beast. When I talked to Gary last about getting the beast to output implicit tilesets he it would be matter of swapping out a function. @likangning93 feel free to correct me if I'm misquoting here.

[lilleyse]

It should be more clearly stated that subtrees are aligned to completeSubtreeLevels. If completeSubtreeLevels is 9 firstSubtreesWithContent must start at either level 0, 8, 16, etc. Also provide some context for this choice - that it makes it easier to fuse tilesets or do partial updates.

[lilleyse]

Can we encode more metadata in the subtree and go beyond just availability?

A generic / extensible JSON object in header would open up more possibilities for storing metadata. E.g. tighter bounding volume, subtree stats (number of tiles available), subtree depth if it's less than completeSubtreeLevels.Even availability could be a JSON property with a byte offset / byte length into some binary section, modeled after the glTF / batch table/ feature paradigm.

This idea will help make the subtree/availability concept more extensible and future-proof.

[lilleyse]

If implicit tiling is going to be used for vector and raster data we may need to think more about Web Mercator. It would be nice if a tileset.json with the implicit tiling extension could be compatible with existing imagery tilesets without the need to unproject to WGS84. At the very least the tileset.json would need to constrain its region to -180.0 -85.06 180.0 85.06 and state the projection somewhere.

@tfili put this list together of various imagery tiling schemes in another issue:

TMS - WGS84 1x2 or Mercator 1x1 depending on xml file. Will default to mercator.
WMS - Defaults to WGS84 1x2 if not specified on provider creation.
WMTS - Defaults to Mercator 1x1 if not specified on provider creation.
Bing - Mercator 2x2
Google Earth - WGS84 2x2

[lilleyse]

Related but not necessarily part of this extension - tiles should have a metadata store too, somewhere to put their bounding volume, content bounding volume, children bounding volumes (potentially) for optimal culling at runtime. Quantized-mesh stores does this too.

We first started thinking about this for tile expiration (#217) where new tiles might have different bounding volumes or expiration than what was in tileset.json.

[loshjawrence]

For region tilesets, this needs to add something like:

globalContext: {
    boundingVolume: {
        region:[...]
    }
}

Local tileset should use this too, i.e. some subset is checkouted updates are added and needs to be integrated back to the source with correct alignment, keys, subtrees.

[sanjeetsuhag]

Some notes from offline discussion with @lilleyse

• How do we want to handle the file path with external tilesets? Using an approach similar to symlinks could work.
• How do we want to store the feature table data at the subtree level? Storing the name property of EXT_3dtiles_feature_metadata could work.
• How do we handle the inaccuracy that S2 regions (using spherical geodesics) introduces?
• How do we keep the availability object size minimal? We want to keep availability as small as possible, to store information vital for rendering and traversal, but metadata should be kept separate. Need to investigate if this breaks random access when looking up metadata.
• Will different subtrees store different metadata within a tileset?
• Will different tiles within a subtree store different metadata?

[lilleyse]

A second draft of this extension is here: #414