Sublevels in UE5 broken

Cesium for Unreal
1

I’ve noticed quite a lot of very strange behaviours trying to use sublevels in an UE5 Cesium project. How to reproduce:

  1. Create new UE5 project, enable World Composition as first thing, disabling Enable World Bounds Check.
  2. Add Cesium World Terrain, CesiumSunSky and DynamicPawn

Until now everything works as expected, all good.

  1. Create new Layer “CesiumLayer” in World Composition, with Streaming Distance disabled.
  2. Create new Sub-Level “Project_1”, assign it to the new generated “CesiumLayer” and save it to the disk.

Already now we have the first very strange thing happening.
In the tutorial it is mentioned that you should see a blue mesh, showing the loading distance. This is not happening.
During investigating why this is not shown, I noticed that the Lat/Long position in the Sub-Level is inverted in the CesiumGeoreference object:

image
image425×523 37.7 KB

This seems to be a serious bug. Shall I open an issue for this on Git?

  1. So I go and swap these miss aligned coords back to how they should be.
    Immediately I see the blue loading distance mesh, looks good.

But this is not the only strange thing.

  1. I double click on the Sub-Level “Project_1” in the Levels window to make it the current level, it’s shown ad bold blue now in the Levels window list of levels.
  2. I add a cube into “Project_1”, it is shown correctly in the viewport, and it states “Selected Acator(s) in Project_1, Level Project_1”. All seems to be good.

image
image1122×839 187 KB

  1. I double click the Persistent Level in the Levels window to make it the current level, and I move a bit away in the viewport. I select the CesiumGeoreference and I see the following:

image
image1420×1047 125 KB

If I understand everything correct, I should now be able to set the Gelocation Origin to the new position, without the “Project_1” level being moved, right?

  1. I press “Place Georeference Origin Here”, and it seems to not have moved the “Project_1” Level.

I see the blue loading mesh distance still where it should be. But the Cube from “Project_1” Level have moved in relation to the new Georeference Origin.

image
image1396×1046 116 KB

As I understand this is clearly a bug.
I know there is a way to circumvent this by adding “Cesium Globe Anchor” to the Cube (and this works correct). But using different sub-level would make our life much easier to not being forced to put this anchor on every object.

I also checked out the Cesium Sample project, there is a example of using sub-levels. It also behaves very strange and is clearly broken.

UE 5.0.3, Cesium Unreal Plugin Version 1.19.0

Any feedback would be greatly appreciated.

Greeting

Claude

2

Hi @CStoner,

Some strange stuff you’re seeing here - especially the flipped longitude / latitude - so we will need to investigate. Can you tell us more about what looks wrong in the Samples, though? I was under the impression that was working reasonably well in UE5.

Just as a bit of context, World Composition is deprecated in UE5, so we need to replace the sublevel system with something different. In the meantime, it’s admittedly kind of been on life support, because it doesn’t make sense to invest in something built on a deprecated feature. In the recently-released Cesium for Unity, we implemented a much simpler system for managing scenes at multiple locations on the globe that doesn’t rely on any engine level streaming system. So the still-evolving plan is to bring something like that over to Unreal as well.

Kevin

3

Thank you Kevin for your response,

about the Cesium Sample project, if you have only the Persistent Level loaded, everything seems to be good, I can relocate the Georeference Origin and it’s not affecting the not loaded sublevels…

But as I understand, if a sublevel is loaded in the editor, but not set as current level (so for example the Persistent Level is the current level), I should be able to relocate the Georeference Origin to some other place, and it should not affect the objects inside the sublevel:

image
image1544×1043 194 KB

But by doing so, the objects of the sublevel get relocated too:

image
image1566×1074 214 KB

Maybe I’m getting this point wrong, and all the sublevels need to be unloaded first before you can do such a relocation… Please correct me, but then the tutorial should be updated with that fact, as I’ve got the impression that this is not intended.

About your statement of fixing a deprecated system (World Composition), I fully understand your point. But as the new World Partitioning is not yet supported by Cesium Unreal, we are kind of short of any Level Load Management now in UE5… Any hint from your side how and when this will be addressed?

I’m not a big fan of Unity, but what you described for it with “we implemented a much simpler system for managing scenes at multiple locations on the globe that doesn’t rely on any engine level streaming system”, such an approach would be highly appreciated to be used also for UE.

For now, I’m helping myself out by using different Landscapes (all anchored with the Globe Anchor), positioned at different locations. All Objects on that landscapes need to be children of the landscape, and then don’t need to have the anchor themselves. This is just a workaround, because all the landscapes keep being loaded at runtime, what is far from optimal.

Best regards,
Claude

4

Ok, I see what you mean about setting the PersistentLevel as current. When you set any sub-level to be current, all other sub-levels are deactivated. But setting the PersistentLevel as current does not deactivate whichever sub-level is currently active. And because that sub-level isn’t deactivated, any non-anchored objects from the sub-level (just like non-anchored objects from anywhere else) will remain fixed in the Unreal coordinate system rather than moving with the globe when the georeference is changed.

The good news is that changing the georeference while the persistent level is current doesn’t change the georeference parameters of the sub-level, nor does it move non-globe-anchored objects in the Unreal world. So when you realize this isn’t behaving as expected, it’s easy to get back to a good state. Either hit the eye icon next to the sub-level that is incorrectly still showing to hide it, and carry on changing the georeference in the persistent level. Or you can double-click the sub-level to reset the georeference to the right place for that sub-level.

So hopefully this is an annoyance, not a total workflow-killer. Does that seem right, or is there a more serious repercussion that I haven’t realized?

I’m going to investigate your original post now, where you described problems with a newly-created project, and will let you know what I find in a separate post.

5

yeah that’s a cool feedback. Indeed the sublevel objects don’t get “permanently” moved. So I guess simplest thing would be then to ignore that, and simply unload or at least hide the sublevels if you work with the persistent level.

I’m wondering what comes out of your other investigation.

6

Ok I looked into the issues in your original post.

First, you are right that there’s a bug where the longitude/latitude get flipped on a newly-created sub-level. We introduced this bug quite awhile ago now when we changed the display order of the latitude and longitude parameters in the UI (putting latitude first). In UE, the only way to change the display order is by changing the physical order of the properties in the class. And when we changed the physical order, we didn’t notice that this change affected the order of the parameters in the member initializer list where the FCesiumSubLevel instances are first created.

So I’ll open a PR to fix that, thanks for reporting it!

I think this hasn’t been as catastrophic as it sounds because the usual workflow with sub-levels is to create a new sub-level, then fly to the place it should be located, and then click “Place Georeference Origin Here”. And when you do that, the longitude/latitude are applied correctly (not flipped). So the bug only manifests when you create a new sub-level while the georeference is already at the correct location, and then click the Enable checkbox without realizing that the location is actually incorrect (flipped).

The rest in your original post, steps 6-9, is I think the same issue that you saw in the Samples project, and that I’ve hopefully addressed above. Double-clicking the PersistentLevel does not hide the previously selected sub-level, which is surprising but easily solved just by hiding it manually.

Kevin

1 Like
7

Here’s the PR with the fix:

1 Like
8

Cool, thank you for the fast fix!