Hello,
We’re developing an internal tool for Sintetic Dataset generation for the aeronautical industry and during our testing we identified a few technical issues with the Cesium renderer in Unreal. We’re using the Photorealistic Map Tiles and we’re having the following issues:
1- Tiles are rendered with low resolution even in close proximity
2- Tiles aren’t being loaded even though the forbid holes flag is on
3- Using the event OnTileSet Loaded to pause the simulation while waiting for the loading doesn’t avoid this issue
4- After about 3 hours of simulation, the tiles stop rendering completely
Any idea what the issues are? How can we further diagnose the issues here?
Thank you
This may only fix issue 1, but select your tileset asset in the outliner, under Level of Detail, lower the Maximum Screen Space Error value, by default its set to 16, I usually use around 8 or 4, the lower the higher resolution it will be, Adjusting the tile loading settings may help resolve issues 2-4 but I’m not sure
Hey @jdteixeira, welcome to the forum.
Thanks for the detailed report. This looks like a few separate behaviors:
-
Low resolution tiles near camera:
@RS1RS92 is correct on this, lowering Maximum Screen Space Error is the right direction. For synthetic data generation, values like 4 or 2 can help, with the tradeoff of more tile requests and higher memory/network load.
-
Missing tiles and Forbid Holes:
Forbid Holes only affects rendering behavior. It does not force additional tiles to load if there aren’t any there, not saying that that is necessarily the case.
-
Waiting for full readiness:
OnTilesetLoaded means the root is loaded, not that all visible LOD tiles are finished. For capture pipelines, I think check whether IsLoading returns false before frame capture, and monitor stats while running to confirm the request queue is actually draining.
-
Stops rendering after long runs:
The 3-hour failure pattern sounds like a resource-pressure issue (memory, queue saturation, or long-running request churn), not just a one-off tile miss.
If you can share these details, we may be able to help futher:
- Unreal version
- Cesium for Unreal version
- Camera movement pattern (speed, jumps, scripted path shape)
- Whether tiles eventually fill if camera pauses
- If you can also provide a minimal reproducible project or short scripted repro path, that would help a lot. Preferably using the Cesium for Unreal Samples repo as a base. I understand it may not be feasible to share your data here though, you can always share by DM if you like.
Cheers!
Hi. Thank you for the help. Unfortunately I can’t really share stuff here, but we’ve made some progress. The tile loading issues were mostly solved by combining the ontileset loaded with a loadprogress =100 branch to validate tiles loaded. The long term usage bottleneck is still an issue that we don’t know if it’s system realted or just throttling from the API, as tiles don’t load on the editor either until a system restart. So I don’t know if it’s a memory issue or a token limit issue. Is there a way I can log stuff to diagnose this?
Hey @jdteixeira,
Glad the OnTilesetLoaded + load progress check helped!
For the long-running stop, you can check out your Cesium ion dashboard, it will show usage metrics, and you can filter by token as well. If you’re hitting rate limits, this could be reflected here. You can also DM me your accounts email and I will check if there’s anything we can see regarding rate limits.
For logging in Unreal, filter the Output Log by LogCesium. Potentially failed tile requests will show up there and tell you whether it’s an auth issue or something else.
If the Output Log shows no errors and tiles just stop loading, it’s more likely resource pressure (memory or GPU). Checking system memory and GPU memory usage around the time of the failure would help narrow it down.
What does the Output Log show around the time tiles stop loading?
Ok, so for debugging, I left an overnight session running generating a dataset of 5000 images. Starting at 20:00, it ran fine until 00:03, and that was when tiles stopped being loaded. On Ion, my token usage was at 2 sessions for that day. The Unreal Log shows the following:
[2026.06.12-00.04.29:379][612]LogCesium: Error: [2026-06-12 01:04:29.380] [error] [TilesetJsonLoader.cpp:1076] Received status code 400 for tile content https://tile.googleapis.com/v1/3dtiles/datasets/CgIYAQ/files/AJVsH2ygiNkSA-4rm8r74ACjZ_ciNhjH0cl1Py4wQMJF_3SpW5WkvacqKzqDJa5ptOYzK6_7l10bIoOFvYshgYBhjWGMF5LmaT1jDqQk1B_yWztc2ONp5qoQpfQeTWSGcBJXZb1jvObGAr6BFMqY9qXeLX5FVxhbMXyZS4tVaUr_ErGi5FbhqvyLRMpQ.glb?
This then repeats to other tiles. I’ve also left HWInfo logging resource usage on the machine and this is the overall result for that period.
Around 00:00–00:06:
| Metric |
Observation |
| Network download |
Only +1 MB total; one tick appears at 00:03:02.706 |
| RAM load |
47.5–48.1% |
| RAM available |
Minimum 16,956 MB |
| Pagefile |
2.5% |
| GPU memory usage |
62.8–65.5% |
| GPU memory available |
Minimum 4,241 MB |
| GPU memory allocated |
Max 8,047 MB |
| CPU usage |
11.6–19.5% |
| GPU core load |
41–54% |
| Disk activity |
Max 1.9% |
| Thermal/power limit flags |
No GPU thermal/power limit, no CPU throttling |
From what I gathered from other reported issues, the google API sssion token expired?
Thanks for your patience on this one, my understanding is that we just proxy them from google, so potentially a timeout on googles side or we mismanage the proxy. If you could check for me if it’s just the google tileset that fails after 3 hours or if other ion assets that you’ve uploaded have the same issue?
Cheers
Hi, so I ran a test with Cesium World terrain + Sentinel - 2 for 3 and a half hours and it ran correctly.
Thanks for testing that. This confirms the issue is specific to Google Photorealistic 3D Tiles and not a general resource or memory problem on your end.
The errors after running for hours, combined with Cesium World Terrain running fine for the same duration, points to an authentication or credential expiration issue on the Google 3D Tiles path specifically. Some form of access credential used to fetch tiles from Google’s endpoint appears to expire without being refreshed during long-running sessions.
I’m going to flag this internally with our engineering team since this is really useful diagnostic data. Thank you for being so thorough with the logging and the comparison test.
As a potential workaround while we investigate: would it be feasible for your pipeline to periodically destroy and recreate the tileset actor (every 2-3 hours, for example) to force fresh credentials? I can’t guarantee it will resolve the issue, but it’s worth trying while we look into the root cause.
I’ll follow up here once I have more information from the team.
We’re looking into that solution already, by using the refresh tileset event. Is that event enough for that or do we need to actually destroy the actor and spawn a new one?
I would probably say try both to be safe
So, destroying the actor isn’t really an option although I did implement a loopable event in a BP present in the level to just refresh the tileset. I ran a 4 hour run and after the 2 hours (7200 seconds) it did the refresh, didn’t break the loadprogress count and actually refreshed the map. The rest of the time the sim ran correctly. I’m leaving the BP’s structure here in case someone else stumbles across this issue. This is merely a patch and is in no way a solution as I didn’t test it too indepth so please keep digging into the problem on your side with google please.
That’s great to hear, glad the periodic RefreshTileset approach is working for your pipeline. Thanks for sharing the BP setup too, that will definitely help others who run into the same issue with long sessions.
I wrote a small test to check this in Cesium Native (what Cesium for Unreal is built on) and was able to reproduce this outside of Unreal, looking at a solution internally and will update here when I have more info.
For anyone using Cesium Native, destroying and recreating the tileset should work as well.
