Overlapping GeoReference Datasets

We are creating a project with many locations that we have modelled throughout Australia into a unified UE4 project. Each project is contained within their own sublevels in the World Composition structure. We have created it pretty straight forward using the Cesium Georeference and using the Georeference object to control the sublevel streaming.

However, we have hit a pretty big snag:

We have two sites that by themselves don’t pose an issue as we can set their georeferenced location and jump to that location with the FlyToLocation function with the Cesium Pawn.

The issues arise when moving around in world. These two scenes are very close to each other, so the level streaming bounds within the GeoReference object overlap. If we are at Location A, the world is rebased to this location, this is now our origin and the World terrain is correctly transformed. If we move around this location, we begin to overlap the streaming bounds of Location B. When this happens, the world is rebased to Location B including the sublevels of Location A. So now both Location A and Location B are positioned at the new world origin at Location B, but we are also still within the bounds of Location A so the world then will rebase if you move again between the two locations.

This is causing neither location to remain correctly located in the world location and the World Terrain and sublevels sort of ping pongs between the two locations. Because both of these Locations are quite long (45km and 14km) if we set their georeferenced location to be the same it is causing content streaming problems due to out of bounds world position.

In the Cesium examples, all the example datasets are very far apart so the rebasing issue does not happen or there is a dataset within another data set but they are georeferenced at the same coordinates. Is this a known limitation for level streaming using the Cesium Georeference? Should we approach the streaming differently perhaps?

Hi @V2i, thanks for reaching out.

We’re looking in to this issue. In the meantime, it seems like using one sublevel for both locations may be the best way to move forward. In your World Settings, is Enable World Bounds Checks set to true? If so, try setting it to false.

In the long term, it may be a good idea to approach level streaming differently, like you suggested. You could try using Level Streaming Volumes to more specifically encapsulate each area: Stream Sublevels with Level Streaming Volumes | Unreal Engine Documentation

You could also try to set up a tile-based level streaming solution as outlined in this overview - World Composition User Guide | Unreal Engine Documentation

We will experiment on our end, but would love your feedback if you’re able to find a solution that works for you. This information will definitely be good to incorporate in the plugin documentation.


Also, I made an issue for this problem here - Georeferenced sublevels not behaving when two sublevels are close together · Issue #611 · CesiumGS/cesium-unreal · GitHub. We’ll track the status of this there. If you have any further information to add, please feel free to add to the Github issue or comment here.
I did have one question to help us test - Approximately how far apart (in km or Unreal units) are the origins for each sublevel?


Hi Alex,

In kilometres the origins of each sublevel are about 30 km apart.

We also had disabled World Bounds Checks before we had posted the question.

Just to avoid some confusion, when I referred to the streaming bounds earlier I meant the Cesium Georeference Load Radius parameter for each sublevel.

I think some of this issue might be because we are an edge case of sorts. The data we are loading for each site are fully detailed road networks contained across multiple sublevels i.e the 45km road with twists and bends are segmented into 5 sublevels. These five sublevels for all purposes can be considered one as they are geolocated at the same location in the Cesium Georeference.

Hello @V2i,

We are currently working on fixing this issue. Our current idea in the case of overlapping sublevels, is to just choose the nearest sublevel to the camera and only load that one. This would also require unloading the other sublevels even though the camera may be within their radii. Will that solution work for your case?

Nithin Pranesh

Hi @Nithin_Pranesh ,

I think that this solution should work for us persisting the nearest sublevel is probably the cleanest solution.


Hi @V2i,

Nithin’s changes were just merged in, so you can download a version of the plugin with this fix from the github repository.

Click on the green checkmark near the top, and you can select the correct version for your operating system here.

The next time we update the plugin on the marketplace, the change will be included there too.

Let us know if this fixes your issue!