no visible tiles for certain zoom levels

[dbuck]

Description

Seeing a visual blackout when transitioning to a "content": { "uri": "4_0_1.json" } child tile.

from: https://raw.githubusercontent.com/matterport/3DTilesSampleData/refs/heads/main/uskTEa4gEb5/mesh_tiles/4.json

to: https://raw.githubusercontent.com/matterport/3DTilesSampleData/refs/heads/main/uskTEa4gEb5/mesh_tiles/4_0_1.json

Reproduction steps

1. https://nasa-ammos.github.io/3DTilesRendererJS/example/bundle/index.html?unlit=1#https://raw.githubusercontent.com/matterport/3DTilesSampleData/refs/heads/main/uskTEa4gEb5/mesh_tiles/4.json
2. zoom in on the scan
3. Note at the point where it's transitions from the lowest to next lod level, there is a certain zoom level where it's blank? continue zooming in and it'll load the child tiles.

video:

skipping-tiles-with-child-content.mp4

Code

// code goes here

Live example

Live example on the current master/bundle builds:

https://nasa-ammos.github.io/3DTilesRendererJS/example/bundle/index.html?unlit=1#https://raw.githubusercontent.com/matterport/3DTilesSampleData/refs/heads/main/uskTEa4gEb5/mesh_tiles/4.json

Screenshots & Tile Set

No response

Library Version

v0.4.15

Three.js Version

r176

[dbuck]

fwiw the canTraverse is negative on that empty parent tile. A helpful breakpoint that gets triggered right as the parent tile is dropped. That's definitely not the right spot to 'fix' though because the child tiles haven't been processed/loaded by the time it's being stopped.

[gkjohnson]

Thanks for the report - it looks like Cesium doesn't have this issue (see the cesium-comparison example) but it's not really clear what the "correct" behavior should be. Here's what's happening currently:

• The TilesRenderer "errorTarget" is set to 16 which means that any node that has a higher screen space error value should be "refined" and traverse the children.
• The external tileset json, "root" of the external tileset, and immediate children in that root all share the same "geometricError" value of 0.9.
• At the point where everything seems to disappear the calculated screenspace error is ~10 for both the "external node" and the immediate root of the external tileset file, which is under the error target threshold needed in order to "refine" the tile and traverse / render children.

So from my reading of the specification the traversal should stop at these nodes since they don't meet the error threshold (though it's clearly not what Cesium has chosen to do):

In a client implementation, geometric error is used with other screen space metrics—​e.g., distance from the tile to the camera, screen size, and resolution-- to calculate the SSE introduced if this tile is rendered and its children are not. If the introduced SSE exceeds the maximum allowed, then the tile is refined and its children are considered for rendering.

Notably the traversal implementation is currently designed to not stop at "external" nodes that reference a tileset json file and instead immediately refine so the external child node is always traversed - this is a behavior that was recommended per the Cesium Unreal implementation - but it's unclear to me if this logic is also supposed to apply to the external root node. And if so under what conditions? Always? Only if it has no content? Only when REPLACE refinement? etc.

cc @lilleyse @kring Do you have any thoughts on how this should behave in this case? Here's the rough state of the hierarchy when tiles seem to be disappearing assuming an "error target" of 16 and "REPLACE" refinement:

1. root (geometry, SSE: ~17)
└ 2. external tileset.json (external json, SSE: ~9)
  └ 3. external root (empty, SSE: ~9)
    └ 16x children with geometry

From the referenced portion of the spec above it seems like traversal should stop at node 2 or 3 here until the camera zooms to a point where the screen space error value gets above 16, at which point the 16x children can be loaded. But that's not what seems to be happening in Cesium.

[dbuck]

Thanks for the info, that's helpful context! fwiw, we have about 7 million 9 million of these tilesets in-the-wild now, but we're still using a pretty old package version 0.3.9 in prod.

[gkjohnson]

fwiw, we have about 7 million 9 million of these tilesets in-the-wild now

Yeah to be clear I think we can fix this but I would jut prefer not to guess at what the behavior should be now. It used to be the case that the traversal in this project never stopped at empty tiles. Then we added support. And now it seems to be the case that traversal should only stop at empty tiles sometimes. It's been discussed elsewhere but there's a lot of ambiguity in the specification around how tiles should be displayed and where possible I'm trying to harmonize on some of the liberties that Cesium has taken so there's some kind of reliability and sense of "correctness" between viewers.

we're still using a pretty old package version 0.3.9 in prod.

To be clear - are you "stuck" on 0.3.9 due to this issue?

[lilleyse]

Notably the traversal implementation is currently designed to not stop at "external" nodes that reference a tileset json file and instead immediately refine so the external child node is always traversed - this is a behavior that was recommended per the Cesium Unreal implementation - but it's unclear to me if this logic is also supposed to apply to the external root node.

The correct behavior would be to stop at node 3 and not refine to the 16x children. CesiumJS seems to be incorrect. I haven't tried Cesium for Unreal but I think it would be correct.

Also, the spec should explicitly state that external tilesets are unconditionally refinable, e.g. should stop at node 3 instead of node 2.

[dbuck]

in case it makes a difference in this case the 16x children have the same SSE as the empty root tile with no contents?

[dbuck]

we're still using a pretty old package version 0.3.9 in prod.

To be clear - are you "stuck" on 0.3.9 due to this issue?

Updating just hadn't come up for a couple years. Most of the churn / difference is that some of our app-specific behaviors we had done by monkeypatching and adjusting the tile.__error calcs can now be done with plugins. As far as I can tell, the two blockers left to work through are this issue + the memory tracking in LRUCache doesn't play nicely with our external texture references shared across multiple tiles at the lowest lod.

[lilleyse]

in case it makes a difference in this case the 16x children have the same SSE as the empty root tile with no contents?

In this case it doesn't make a difference. The empty root tile is only supposed to refine when its SSE is greater than 16.

[gkjohnson]

Thanks Sean - is there any plan to make these changes to Cesium? I recall we also discussed some possible changes here, as well. It would be nice to start to converge on some common behavior where possible.

But overall it sounds like the current behavior is correct. So regarding this point:

fwiw, we have about 7 million 9 million of these tilesets in-the-wild now

I suppose these are technically malformed data sets, then, assuming you don't want the missing tiles gap. When you say "in the wild" do you mean people are viewing the data through a dedicated Matterport viewer? Or are users downloading the 3d tiles data sets and running them in their own custom viewers?

If it's the former then you should be able to "fix up" the external json files on load by setting the external root node geometricError to Infinity which will force it to always refine. Notionally something like so:

tiles.addEventListener( 'load-tile-set', ( { tileSet } ) => {

  tileSet.root.geometricError = Infinity;

} );

This could be done with something like a MatterPortFixUpPlugin, as well, that's distributed to users if they're writing their own viewers.

---

@lilleyse it would be nice to get CesiumGS/3d-tiles#821 merged and in officially so tile generation tools can start being encouraged to include their generator and version number in the assets. This is another case where if we knew the data source we might be able to warn users of some incompatibility.