Avoid holes when frustum culling is disabled, even with unconditionally-refined tiles #597
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Way back in #488, we added some logic to detect empty tiles with a geometric error greater than their parent's geometric error, and treat these specially.
If such a tile's parent's geometric error is too high, then, by definition, this tile's geometric error will be too (since it's greater), and therefore we should immediately refine past that tile.
Except! the tile's children may not be loaded yet. Prior to #488, we would make the mistake of rendering the placeholder while waiting for the children to load. This created totally unnecessary holes in the tileset, even with
forbidHoles
enabled. So the special logic added in #488 detected this case and marked the tile "unconditionally refined." And special logic in the traversal guaranteed we wouldn't select such a tile for rendering.But during the tile content loader refactoring - I think! - this system gained a subtle bug where we accidentally treated these unconditionally-refined tiles as renderable. It didn't cause any problems in the
forbidHoles
mode, but when disabling frustum culling we would sometimes get these temporary holes in the tileset.So this PR fixes that bug, making it so any unconditionally-refined tile - not just an external tileset - is considered unrenderable. But then this caused a problem in
forbidHoles
mode because the checkif (!child.isRenderable() && !child.isExternalContent())
went from false to true for these unconditionally-refined tiles, skipping some necessary logic. So this PR fixes that as well.This is fairly difficult to test well, but I did add some basic tests to confirm it is working correctly both with and without
forbidHoles
.