Hi there,
We’ve been having an issue recently where if the user pans over many sublevels in Cesium too quickly it can cause some levels to stay loaded whilst outside of the load area. I believe this can be due to a race condition when the levels are loading whilst we exit the load area.
To combat this, I notice that when we start the application all of the sublevels are loaded and then unloaded causing a large frame time spike at the start of the application; dependent on the size of the SubLevels.
I was curious to explore using Unreal’s Level streaming rather than level actors in Unreal for Cesium’s sub levels so that levels are only loaded when visited. I was curious to know if this approach had been explored before? What was the reason to use level actors for Cesium sublevels over other approaches?
Many thanks for your responses,
Kieran
I will leave the GitHub issues I have raised also:
opened 04:53PM - 24 Feb 26 UTC
enhancement
needs triage
### Feature
Currently we use Level Instance Actors with a `CesiumSubLevelCompon… ent` to handle loading sublevels at specific geographic locations. This has posed a couple issues in our project:
- Every level instance actor is loaded at the start of the game and quickly hidden causing a huge spike at the start of the game depending on the amount of level instances.
- Occasionally level instances do not get correctly hidden until the player goes to the location and triggers a load/unload. This is fine if the level instance actors use the globe anchor or the world is fixed in location (Not using the Cesium Origin Shift component)
To resolve this, we should consider using Level Streaming. This would work by creating a cesium level streaming actor that behaves exactly the same as the `CesiumSubLevelComponent` inside the persistent level. Once the player is within the bounds, we load the level via level streaming. This will
- Ensure that levels are streamed in only when they are needed and not all levels are loaded at the start
- Levels will be correctly loaded and unloaded when the player is at the correct geographic location
Some questions that I would have about implementation and how it would work and it would be great to get some ideas on this:
- How would the globe anchor work in streamed in levels? Not an issue for our use case but maybe for others.
- How would using the editor to edit these levels work?
_I figure that we can update the georeference as we do currently to be the streaming actor's geolocation. All streamed levels must be built off the unreal engine origin (0.0,0). This might mean that the Cesium Origin Shift is required?_
_Why don't we use globe anchor on our actors within level instances?_
Since we use the Cesium Origin Shift component so that Unreal's gravity works correctly and to prevent floating point errors, it would mean having to translate all of our actors, this would also trigger lighting recalculations as our actors are real-life venues with many lights which can be very expensive.
opened 10:57AM - 25 Feb 26 UTC
bug
needs triage
### What happened?
When having a project with many sublevels across the globe, … all level instance actors are loaded (and sometimes visible) when not at the relevant locations. The level instance actors should only be loaded and visible when the player is at the correct location of the sublevel.
This has become more apparent when waiting for PSOs to be precompiles via a loading screen and then loading into the level.
### Environment
Cesium for Unreal version: 2.21.1
Unreal Engine Version: 5.7.1
Operating System: Windows
### Reproduction steps
1. Have a persistent level with a georeference, 3dtiles, sunsky
2. Create many 3d sublevels with models with collisions (make them big to be obvious)
3. Create a loading screen that will check for all PSOs to be precompiled before loading into the main level (using [`FShaderPipelineCache::NumPrecompilesRemaining()`](https://dev.epicgames.com/documentation/en-us/unreal-engine/pso-precaching-for-unreal-engine#loading-screen))
4. Run the game, wait for loading screen to finish, load into the main level. Observe all sublevels flash as they are initially loaded. One (incorrect) sublevel is always consistently shown after all have been loaded.
5. Consecutive loads (with PSOs cached) seems to load collisions of incorrect sublevels despite not being visible
### Supporting evidence
_No response_