Tileset of tilesets: selection/loading waiting for all children to be loaded?

[e-andersson]

With a scenario like described in below diagram, it seems that no b3dm root will be loaded for all tiles.json one level above have been loaded. So if one subtileset represents San Francisco and the other Rio de Janeiro, none will be loaded before both have been in view in the Cesium viewer.

@lilleyse, what do you think about this scenario? Might recent changes to selectTiles in Cesium3DTile or something with the new request scheduler have some effect? I don't see this happening without using the last few weeks of changes from the 3d-tiles branch.

[lilleyse]

I may have to think through this more carefully, but should it be fine if the root uses additive refinement?

[e-andersson]

Forgot to say this is for replacement refinement.
On 14 Jan 2016 5:13 p.m., "Sean Lilley" notifications@github.com wrote:

I may have to think through this more carefully, but should it be fine if
the root uses additive refinement?

—
Reply to this email directly or view it on GitHub
#3424 (comment)
.

[lilleyse]

The situation you described is expected for replacement refinement, since the tile is not allowed to refine to its children until they are loaded. I think it makes more sense for the root to use additive refinement.

[lilleyse]

The recent changes in selectTiles definitely affect this situation. Before we let a tile refine as long as its immediate children are loaded (in the the case of empty tiles, this would happen immediately). But now we only refine if there is content to fill the gaps, which requires traversing down the tree and loading the b3dm roots.

[pjcozzi]

I think this is related (from the roadmap, #3241):

Optimize replacement refinement - instead of requesting all children when a tile needs to refine, request only the visible ones, and then allow refining a tile if all the required visible tiles are loaded (instead of all - including invisible - tiles). When the camera moves, and children that are not yet loaded are needed, either render the parent or render the available children and the parent with clipping.

This is a good path forward (and I think fixes the above problem, right?), but a combination of additive and replacement refinement might also get the job done, but add complexity to the generation tool.

@e-andersson if you think this approach meets your needs, it would be an awesome contribution!

[e-andersson]

@lilleyse you're right, it makes more sense to use additive refinement for the root, and it does work that way. There are similar structures (but somewhat more tree-like, without extra empty tiles) further down the tree though, and it would require a bit of work to check this carefully. Further down it looks like this:

      B
   T     T
   B     B

where B = b3dm tile and T = tiles.json tile. In this case, I think additive refinement for the root B would not work, since the B's further down are intended to replace it rather than add to it.

It sounds like the suggestion from the roadmap would solve the problem. @pjcozzi I'll look into if it's something I can add.

[pjcozzi]

That would rock, thanks @e-andersson!

[e-andersson]

I've been trying a fairly naive approach to changing the replacement refinement today. I loop (won't want that later) through a tile's children to see if it has visible children that are not loaded yet and determine whether the tile is refinable based on that, and if not, render the parent like before.

When tilting the camera towards the horizon this looks pretty bad, since previously sharp tiles get blurry when a parent that covers more space is selected while waiting for newly visible tiles to load. This sounds like it should have been expected behavior up until now too, but somehow it hasn't. This should be expected, right? On second thought, this could simply be the effect of not first loading all children of a tile, so when previously invisible children come into view, the parent is selected until they are loaded.

I think we'd need to use available children and clip the parent (as suggested) to make this look good, if the above behavior is as expected.

It seems there are also cases where there is no loaded parent either, and empty space is displayed. Will look further into this.

[pjcozzi]

When tilting the camera towards the horizon this looks pretty bad, since previously sharp tiles get blurry when a parent that covers more space is selected while waiting for newly visible tiles to load. ...This should be expected, right?

Yes, this is expected. @kring and I have discussed before. We just weren't sure how bad it would look.

I think we'd need to use available children and clip the parent (as suggested) to make this look good, if the above behavior is as expected.

Yes, I think this has potential. The Cesium implementation will need some events so a tile can update itself with some approach to avoid cracking (e.g., drop new skirts) when a sibling/cousin changes. I would do this after getting the basic approach to work.

The other option is to prefetch children outside of the view frustum (this could be an option), so we refine as soon as all the visible children are ready, but we request all the children (visible ones first) to proactively minimize the jarring LOD switch when the camera moves.

It seems there are also cases where there is no loaded parent either, and empty space is displayed. Will look further into this.

Perhaps just a code bug...or something subtle in the approach that we didn't think of yet.

[e-andersson]

Back at work today after having been sick for a few days.

I'm still working on this, will try to get the basic approach (loading only visible children rather than all children) to work.

[e-andersson]

Prefetching children outside of the view frustum might make a small difference, but if we do request all children, I think when zooming in quickly LODs would get much slower to refine.

[pjcozzi]

@lilleyse @e-andersson are there any updates here? Is this something we need to consider for the 3D Tiles Draft 1.0 implementation?

[e-andersson]

I think the loading issues have been addressed, except for #3517. @pjcozzi did you notice that "blank-space-when-loading-tileset" issue with the Vricon sample data set?

[pjcozzi]

@e-andersson I do notice a slight difference in loading between the one tileset.json and the tileset of tilesets. The later appear to have a quick flash when zooming in. The best way to reproduce this is to use a tiny cache size (like 1 tile) so every time you zoom back in the tile is reloaded. Cache replacement doesn't appear to affect this.

I will work with @lilleyse to reproduce this.

With that said, I'll close this issue and we'll finish the fix in #3517.