3D Capture missing tiles

Cesium ion
1

Hi,

I’m experiencing issues with tiling of 3D Capture data via Cesium Ion. It appears that some tiles are not listed in the .subtree file; as a result, when zooming in, parts of the model (quads) are missing.

image
image1128×978 399 KB

Example tilesets:

  • 4537111 (missing tile 2/1/1/0 and its derivatives)
  • 4562928 (missing tile 3/3/2/0 and its derivatives)

Additional observations:

  • The issue is reproducible — uploading the same model multiple times results in the same behavior.
  • The missing tiles are actually created (they are accessible via HTTP requests), but they are not listed in the .subtree file.
  • This issue does not occur when processing the same model using the 3D Model tiler
2

At whoever has access to the data and investigates it: It could be worthwhile to run this through the 3D Tiles Validator. But note that the validator will only detect invalid data. It will not detect all forms of “wrong” data. When there is an entry missing in the subtree files, then the validator will say: “Sure, there’s no tile” (and it cannot know that there should be a tile). But it might be able to detect certain form of inconsistencies (like the content being present and the tile missing or so).

3

@Marco13 Thanks for the hint!

I tried to run the validator on the tileset. It produced 2 errors, but I’m not sure if they’re related to the issue.

{
  "date": "2026-03-25T06:37:19.033Z",
  "numErrors": 2,
  "numWarnings": 0,
  "numInfos": 0,
  "issues": [
    {
      "type": "STRING_PATTERN_MISMATCH",
      "path": "/schema/id",
      "message": "Property 'id' must match the pattern '/^[a-zA-Z_][a-zA-Z0-9_]*$/', but has the value 'cesium-tiling-pipeline'",
      "severity": "ERROR"
    },
    {
      "type": "TILE_IMPLICIT_ROOT_INVALID",
      "path": "/root",
      "message": "The tile defines 'implicitTiling' and may therefore not define 'metadata'",
      "severity": "ERROR"
    }
  ]
}
4

These errors are almost certainly unrelated.

But… it might be that there are other errors beyond that. The validator is trying to validate the implicit tile hierarchy. It notices that the root tile is invalid. So it has to stop the validation there. Any error in the root could make the whole hierarchy invalid, and cause “unrelated”/“follow-up”-error messages that distract from the (literally:) root cause. I took a note about that at Try to continue structural validation in case of non-critical errors · Issue #360 · CesiumGS/3d-tiles-validator · GitHub (even though this may be a bit open-ended and low priority).

In this particular case, someone who has access to the data set should investigate it more closely. It sounds like there could indeed be an issue in the tiler that generated this data. But maybe one specific question: You said

It appears that some tiles are not listed in the .subtree file

Did you verify that in any form? I’m currently wondering whether the missing tiles are really caused by a missing bit in the binary .subtree file, or whether they might not be rendered because of some rendering glitch in CesiumJS.

(If the data sets are not too large and can be shared (in doubt priviately, via PN), you can attach them as a ZIP file here - maybe I can have a closer look, just to try and narrow down the reason for the error…)

5

Did you verify that in any form?

A kind of - I used LLM-generated parser to list all the tiles from .subtree file and tiles that are missing visually were not in the list.

or whether they might not be rendered because of some rendering glitch in CesiumJS.

Missing nodes not appear in the network requests, that lead me to the assumption that it just doesn’t know that they exist.

(If the data sets are not too large and can be shared (in doubt priviately, via PN), you can attach them as a ZIP file here - maybe I can have a closer look, just to try and narrow down the reason for the error…)

Thank you. I can’t publicly share it here, but I sent you the ZIP with the tileset in PM.

6

There are some functionalities in the 3d-tiles-tools that could be helpful here. Specifically, there is an open issue at Extend `analyze` command to handle `subtree` files · Issue #131 · CesiumGS/3d-tiles-tools · GitHub to extend the existing analyze command to print some information about the subtree structure. (This issue has been open for quite a while now. Unfortunately, stuff like this is considered to be “low priority” compared to other things. But it should not be sooo much effort - maybe I can allocate some time for tackling this…)

In any case, I’ll (first) try to allocate some time to have a closer look at the data set. From what you described so far, it sounds like the subtree files indeed do not match the actual structure, but I’ll try to confirm this as far as possible.

1 Like
7

I had a closer look at the data that you provided via PM. And it indeed looks like the subtree file is plainly inconsistent with the actual data.

As mentioned above: The validator does not detect this. It can only detect structural inconsistencies (e.g. when a child tile is ‘available’, but not its parent tile). In this case, the subtree just says: “There is no tile”. The fact that the actual file exists (and should be marked as ‘available’) is something that is not validated. One could do that, in theory. There could be a check for the actual files, and this could be reported as
“There is a tile at (x,y,z), but this is not marked as ‘available’”
But nothing prevents the user from storing arbitrary files there, so I’d hesitate to add this, because it could cause “wrong warnings”…

However, I quickly hacked together a test, based on some small demo in the 3D Tiles Tools. This just checks the availability information, and compares it with the presence of the files. And this indeed generates this output:

Tile availability from coordinates:
  (level 0, (0,0,0)) index 0, available: true, exists true
  (level 1, (0,0,0)) index 1, available: true, exists true
  (level 1, (1,0,0)) index 2, available: true, exists true
  (level 1, (0,1,0)) index 3, available: true, exists true
  (level 1, (1,1,0)) index 4, available: true, exists true
  (level 1, (0,0,1)) index 5, available: false, exists false
  (level 1, (1,0,1)) index 6, available: false, exists false
  (level 1, (0,1,1)) index 7, available: false, exists false
  (level 1, (1,1,1)) index 8, available: false, exists false
  (level 2, (0,0,0)) index 9, available: true, exists true
  (level 2, (1,0,0)) index 10, available: true, exists true
  (level 2, (0,1,0)) index 11, available: true, exists true
  (level 2, (1,1,0)) index 12, available: false, exists true INCONSISTENT!
  (level 2, (0,0,1)) index 13, available: false, exists false
  (level 2, (1,0,1)) index 14, available: false, exists false
  (level 2, (0,1,1)) index 15, available: false, exists false
  (level 2, (1,1,1)) index 16, available: false, exists false
  (level 2, (2,0,0)) index 17, available: true, exists true
  (level 2, (3,0,0)) index 18, available: true, exists true
...

As you suspected: The tile is there, but it is not marked as ‘available’. (And the fact that it should be available is clear when loading the data in CesiumJS…)

Unfortunately, there is no easy way to handle this on the client side.

If this is “urgent”, I could probably quickly create a fixed .subtree file for this specific data set (just drop me a note).

But this apparently is a bug in the tiler. I’ll open an issue internally, with additional information and a link to this forum thread, so that information about the progress or possible fixes can be posted here.

1 Like
8

If this is “urgent”, I could probably quickly create a fixed .subtree file for this specific data set (just drop me a note).

No need, thanks. I’ll have dozens of such models, so I need find workaround on my side. Following the approach you tested (compare actual data vs subtree) I might be able to fill the missing parts.

But this apparently is a bug in the tiler. I’ll open an issue internally, with additional information and a link to this forum thread, so that information about the progress or possible fixes can be posted here.

Thanks a lot for your help! Could you please leave a comment here when/if the tiler internal issue will be resolved?

9

It is an internal issue, and was just opened, so I don’t know when exactly it will be resolved. I added the link to this forum thread in the issue, and usually, the intended workflow for that is that when someone closes the issue, there will be a notification in the forum thread as well. In doubt, I should receive a GitHub notification when it is closed, and when I see that, will post a short comment here. (Short form: I’ll try :slight_smile: )

1 Like