3D Tiles - Load tiles without extensions

[lilleyse]

The loader no longer cares about the tile extensions but instead looks at the magic of the content buffer. If the magic is not a valid type, it tries to parse it as JSON. So a tile content url of tileset/1/0 can refer to a b3dm, i3dm, pnts, or external tileset.

This requires a few structural changes:

• Cesium3DTileContent related files:
  • Removed request and initialize function. Requests are generic now and handled in Cesium3DTile. The constructor takes an array buffer and byte offset. Resources like model, modelInstanceCollection etc are created immediately (but not ready initially).
  • No longer stores state. This is now stored in Cesium3DTile. However they still have a readyPromise. contentReadyToProcessPromise is removed here, but added to Cesium3DTile.
• Cesium3DTile:
  • Added contentReadyToProcessPromise, contentReadyPromise, and contentState.
    • The promises are undefined until the request happens, so they are always undefined for empty tiles. This will be helpful for the tile expiration approach I was going with.
  • content is undefined until the tile is loaded.
  • New content tags:
    • hasRenderableContent - previously hasContent
    • hasTilesetContent
    • hasEmptyContent - newly added
    • All three are mutually exclusive
    • Since a tile's content is not known until it is loaded, hasRenderableContent and hasTilesetContent are false until the content is loaded.
• Cesium3DTileset
  • loadTileset no longer makes the request and then parses the JSON, just parses the JSON. Otherwise it is mostly unchanged, just indented differently.

To-do:

• Tests and fix broken tests.
• Optimizations if the url extensions do exist:
  • [EDIT : Not applicable, the browser doesn't do this, we stringify and parse json in loadWithXHR] Tileset3DTileContent takes an array buffer and converts to JSON. This could be inefficient if we already know the url ends with .json and let the browser do the work instead.
  • [EDIT: doesn't provide any optimization, so will skip just so behavior is consistent] hasRenderableContent and hasTilesetContent can be set right away if the extension exists.

[lilleyse]

Updated with tests.

@austinEng can you double-check the traversal changes?

[austinEng]

@lilleyse Traversal looks good to me

[pjcozzi]

@pmconne this may be of interest for your dynamic tileset generation.

[pjcozzi]

hasRenderableContent - previously hasContent
hasTilesetContent
hasEmptyContent - newly added

Should this be something like a contentState enum since they are mutually exclusive?

[pjcozzi]

Are there any optimizations or functionality that we are foregoing by not knowing the tile type until the buffer is downloaded? I do not think so and we could always add a type property to the JSON in a later version, but we could roadmap this now if something worthwhile would be possible.

[pjcozzi]

Are these really needed?

[pjcozzi]

In the case when the tileset is JSON, do you know if the overhead here is high? Perhaps not since new Uint8Array should be basically free? It's important that we do not create high overhead for tilesets of tilesets since I expect many users will use this feature for large tilesets.

[lilleyse]

The main overhead is trying to get the magic first, which should be pretty small. The alternative is to try to parse as content as JSON first, which would have worse overhead for the b3dm, etc tiles.

[pjcozzi]

Just those comments. Did you test this with some of the large tilesets in addition to the Sandcastle examples?

[lilleyse]

Are there any optimizations or functionality that we are foregoing by not knowing the tile type until the buffer is downloaded? I do not think so and we could always add a type property to the JSON in a later version, but we could roadmap this now if something worthwhile would be possible.

Right now there's little impact. The only area that has changed is the selection heuristic will return for renderable/tileset content, while before it was only for renderable content.

[lilleyse]

Should this be something like a contentState enum since they are mutually exclusive?

If they were enums I would probably still make getters for better readability, would that be too much?

[lilleyse]

Just those comments. Did you test this with some of the large tilesets in addition to the Sandcastle examples?

I tested on a few large tilesets, I'll test on more tomorrow.

[pjcozzi]

If they were enums I would probably still make getters for better readability, would that be too much?

Whatever you think.

Let me know when this is ready.

[lilleyse]

Another thing I remembered is that hasTilesetContent and hasRenderableContent are false until the content is downloaded. If going with enums it would have to be [tileset, renderable, empty, indeterminate]. What's here is simpler for now.

Tested on more tilesets, no issues.

[pjcozzi]

Can you also please update the spec to say that the extension is not required? Runtimes should look at the magic.

[lilleyse]

CesiumGS/3d-tiles#213

[pjcozzi]

Looks good!

[pjcozzi]

@lilleyse I can't delete the no-tile-extension branch? Do you have another PR targeting it? Can you please retarget to 3d-tiles and delete the no-tile-extension branch.