This seems to break with every other iteration of Cesium. If you move Cesium actors between levels, or put it on any level other than your persistent, it crashes the engine with an “ERROR: ACCESS VIOLATION.”
I understand that moving them can break references to each other, but that’s fine, it shouldn’t crash the engine.
Currently using the V2 Beta.
Please describe what you’re seeing in more detail so that we can investigate.
Add Cesium to your persistent level.
Add a new empty level in your levels tab.
Move your cesium actors to the empty level.
Acknowledge broken references if prompted.
Crash.
I’ve posted about this previously here, so this was fixed and broken again.
The v2.0 preview has gone through a lot of changes to the sub-level system (a completely rewrite, really), and perhaps some of those changes are interfering with level streaming more generally. This is one reason we’ve released a preview! But I’ll investigate this and let you know what I find. Thanks for reporting it.
Thank you
I just tried playing around with this a bit.
First, the issue you previously reported seems to still be fixed. Creating Cesium objects inside a sub-level appears to work fine. In v2.0, the Cesium UI creates the CesiumCameraManager, CesiumCreditSystemBP, and CesiumGeoreference in the persistent level, even when a sub-level is active. Other objects, like Cesium3DTileset actors and CesiumSunSky, are created in the active sub-level. I believe this is all working as expected. It is pretty much never useful to create these manager objects in a sub-level, but previous versions of Cesium for Unreal made it too easy to do this accidentally. If all your Cesium content is in a single sub-level, and nowhere else, then it might be ok. But as soon as you have multiple sub-levels with Cesium content, having redundant copies of these objects in each will cause problems (such as incorrect georeferencing and missing credits).
Now, moving objects into a sub-level after they’re created does seem to be a problem. Unreal appears to delete and recreate the objects that are moved. Doing that while other objects reference those objects is always going to be fraught, as it invalidates the pointers. That’s why the Editor warns about it when you start the operation. But I agree it shouldn’t crash, so I’ll see what we can do to avoid it.