Implicit tileset glitch

3D Tiles
1

I am working with the Delaware example data from cesium_3dtiles_samples/samples/1.1/delaware at master · bertt/cesium_3dtiles_samples · GitHub to test our X3D integration of 3D tiles (some examples at Inline tiles test ).

Here is a sandcastle with the tileset which has the view set at a distance which produces a gap in tile selection:

This occurs only over a fairly small interval in range but probably should not.

The tileset structure looks relatively simple but there could potentially still be something unusual in the description.

A Cesium glitch ?

3

I have not yet looked at the details here. Just to quickly confirm, I assume that you’re talking about the disappearing tiles here:

Cesium Implicit Tiles Disappearing

This is with the bounding volume visualization enabled, and it might already be a hint at what the reason is: Maybe these tiles simply don’t have content?

The data set was recently updated. Maybe @bertt can confirm whether it is supposed to have content at this level of detail?

4

Yes, I believe you captured what I see. Sorry, I did not realize that the initial view in the Sandcastle is not deterministic as it depends not just on the camera position but also on window size and aspect ratio. Here is the gap:

image
image943×710 62.6 KB

If the tiles do not have content, should they be selected for rendering in the first place ? Is that defined in the subtree ?

Related github issue:

5

I think that there is no special treatment of empty tiles in terms of whether they are selected or not.

(If there was, one could easily come up with ~“configurations of empty and non-empty tiles” that would raise some questions that are hard to answer. An obvious one would be that a parent tile has 4 children, and one of them is empty. When exactly should the remaining 3 ones be rendered?..)

The linked issue contains some details about the tiling process that is used for generating this tileset. I’d have to check the exact approaches there, i.e. what exactly by_feature and by_area are doing, beyond a rough, intuitive idea of what they likely mean.

But I think that the bottom line of your last comment captures the main point here:

the tile in question also should be populated by a subset of the features, perhaps randomly selected.

A bit more generally: There should be something in these tiles. And there are different options for what ‘something’ could be:

  • A random subset of the buildings/features. That could look odd (e.g. when it randomly selects a bike shed instead of the football stadium…)
  • The ‘largest’ buildings (that could be the ‘by_area’ approach)
  • Something that depends on the number of vertices of the feature (i.e. prefer simple rectangles instead of complex shapes)
  • An approximation (i.e. simplified version) of the content of the children

The last one would best capture the idea of “refining” and “LOD”, but of course, does raise the question about how that simplification is computed. For complex-shaped buildings, one could approximate them with the convex hull or a bounding box. But when the content of the children consists of 8x8 rectangle-shaped buildings (maybe with some of the ‘cells’ being empty), it’s not necessarily clear what the ‘simplified’ visual representation of that should be…

6

Thanks for engaging. As you noticed from my github comment, it was my impression as well that there should not be empty tiles for a given level, at least for a REPLACE refinement strategy.