We are encountering an issue with tile loading in Cesium for Unreal Engine. When moving the camera, not all tiles load correctly. In the attached image, the blue tiles represent those that failed to update. Initially, all tiles appear blue at a certain LOD level, but as we move closer to the ground, only a few tiles are updated while others remain unchanged.
The behavior isn’t clearly distance-based. We initially assumed that tiles update according to SSE (i.e., if a tile does not meet SSE(), it will be refined). However, we noticed that tiles behind others are updating before tiles in between. This raises the question of whether tile refinement is distance-dependent.
Here are the main observations:
The SSE isn't being updated consistently during camera movement.
When the SSE is updated, the tile isn't always refined, which seems unusual.
No custom code is interfering with the tile loading process.
What other factors could be controlling whether a tile is refined or not? And how can we further debug this issue?
Any insights or suggestions would be appreciated @Kevin_Ring
Tiles are refined based on SSE, which is in turn computed from the tile’s geometric error and distance. Specifically, it is the distance to the closest point on the tile’s bounding volume. So if you’re seeing tiles “farther away” unexpectedly refine earlier, that would most likely indicate that those distance tiles either have a larger geometric error, or their bounding volumes are incorrect (i.e., too big).
Thanks for taking a look at this @Kevin_Ring If this issue is indeed related to bounding volume inaccuracies or geometric error discrepancies, is there anything we can proactively do to correct or mitigate this behavior? Any recommendations or thoughts you have would be greatly appreciated, and we are ready to implement your suggestions for further debugging.
Additionally, we’ve observed another notable behavior: occasionally, tiles remain stuck at a lower level of detail (LOD), failing to refine correctly upon initial loading. However, if the tile is culled by moving the camera left and right (thus removing it from the camera frustum temporarily), it loads correctly with the proper LOD upon re-entering the view. This suggests that the initial refinement process fails, yet the subsequent creation of the tile from scratch works correctly.
Could this indicate a potential issue with the refinement logic when the tile is already within the camera’s frustum versus when it is entirely recreated after culling? If you have insights into why this might happen or factors that could influence this specific refinement behavior, it would be very helpful.
If this issue is indeed related to bounding volume inaccuracies or geometric error discrepancies, is there anything we can proactively do to correct or mitigate this behavior?
Well, if either of these are the problem, it would indicate a problem with the tileset you’re loading. Which tileset is it? If it’s not one of the Cesium ion ones, then how was it created?
Additionally, we’ve observed another notable behavior: occasionally, tiles remain stuck at a lower level of detail (LOD), failing to refine correctly upon initial loading.
That certainly sounds like a bug, but not one that I’ve seen myself. I know I sound repetitive here, but since I believe you’ve made customizations to the tile selection algorithm, I have to guess that those customizations are the cause of this behavior. If you can tell me how to reproduce this in a stock version of Cesium for Unreal, I’ll definitely take a look.
The only thing I can think of that would cause that in the stock plugin is if the server is intermittently failing. If a tile fails to load, Cesium for Unreal generally won’t retry, so that tile will be missing or low detail until that tile is unloaded and reloaded.
@Kevin_Ring
A few follow-up points and a question:
We’re using the Google Earth tileset, and I’ve confirmed that the issue occurs even without our custom modifications.
One factor that might contribute: we’re flying at extremely high speeds. The camera goes far out into space (where we see the Earth in very low detail), and then flies rapidly down toward the surface while looking in the direction of flight. When stopping mid-flight, we can clearly observe LOD mismatches—some tiles load at a different detail level than their neighbors, often with visible seams between them.
To debug this, I applied a custom shader that visualizes tiles by height level, and it became obvious that tiles in the same area don’t share a consistent LOD. You could probably reproduce this using an SSE-based approach as well.
My theory is that this might be caused by the “kicking” mechanism—possibly the parent tile remains visible because its child tiles weren’t ready in time.
Alternatively, as you mentioned, it might be due to intermittent HTTP request failures. In either case, it seems like we need some kind of retry mechanism to reload or refresh the affected tiles.
Any thoughts on how we might enable or implement that retry logic, or otherwise ensure more consistent tile refinement under these conditions?
Thanks again.
Update - @Kevin_Ring did you get a chance?
When stopping mid-flight, we can clearly observe LOD mismatches—some tiles load at a different detail level than their neighbors, often with visible seams between them.
This isn’t unexpected for a period of time after you stop rapid motion. The loading process needs time to catch up.
However, if this doesn’t resolve itself after letting tiles load for a moment, that’s unexpected. If a network failure is the cause, there should be a message in the Output Log. Do you see anything?
