Cesium Origin Shift

Cesium for Unreal
1

Hi,

I’m using Cesium for Unreal to create a global flight simulator - I’m doing this by loading a tileset from disk. I have been attempting to use the orign shift component on the aircraft due to the issue described here which appears Epic are still yet to fix.

The origin shift component removes the jitter from the aircraft as intended but it also seems to cause my terrain to slightly jump around each time the orign shift is performed. This is not a big issue when flying at altitude, but when flying low to the ground (coming in for landing, for example) it is extremely distracting and borderline unusable as a simulator.

A temporary fix I came up with was a blueprint that would move the georeference to the centre of a runway when X meters away from that point - something similar may have been able to have been achieved with sub levels. However, this still doesn’t solve the issue when low-level flying e.g. flying the machloop in Wales.

I’m unsure what else to try at this point and whether this may be an issue with my terrain, I’ve seen others on this forum describe creating projects similar to mine but they don’t appear to have run into this issue - see Lildreas in the forum post describing floating point jitter. I also don’t really want to start modifying the engine as suggested in some of the links within that post.

Many thanks!

2

Hi @SimonLation! Sorry to hear about the issue you’re experiencing. Can you tell us what version of Unreal and Cesium for Unreal are you using, to help us track down the bug?

On the point of your temporary fix, you should be able to achieve something similar using the Distance property on the CesiumOriginShiftComponent. But, of course, it would be better to solve the underlying issue here.

3

Hi @azrogers, I’m using UE 5.3 with Cesium 2.4.0.

I tried using the distance mode of the origin shift component, however, I found that doing so would sometimes mean that an origin shift still takes place when close (or on) the runway. Using the solution I came up with meant that an origin shift never takes place when close to the runway.

Thanks :slight_smile:

4

I have a peculiar interaction happening while using CesiumOriginShift on a Pawn that uses JSBSimMovementComponent (which uses the Unreal GeoReferencingSystem component set with the same geo co-ordinates as the CesiumGeoreference component). When the origin shift occurs, the terrain goes flying away.

Does anyone have any advice on what might be going on and how to setup these components so I only need one georeference object?

5

Hi @Richard_Hawley, welcome to the community!

Personally I’ve never used the JSBSimMovementComponent, but in general, Cesium doesn’t automatically sync with the Unreal georeferencing plugin. Still, you can write a Blueprint that manually syncs the Cesium georeference with the Unreal one every frame. There are methods on CesiumGeoreference that can help with this purpose, notably Get Origin Longitude Latitude Height and Set Origin Longitude Latitude Height.

image

Let us know if that solution works for you!

1 Like
6

Any suggestions or confirmation you can replicate on your side @janine @azrogers?

7

Hi @SimonLation, I’m so sorry we missed your original response.

It’s true that CesiumOriginShift will continually shift the georeference, and therefore move everything geolocated in the scene. But since everything is shifted, those movements should effectively cancel out and still result in a seamless experience. So the fact that you’re seeing those jitters is strange indeed.

Can you share the following information so we can try to understand what’s going on?

  • What data are you using – Cesium World Terrain, or your own data?
  • Does setting the Mobility flag on your terrain to Moveable make a difference?
  • What does the CesiumGlobeAnchor on your aircraft look like? Is the Teleport when Updating Transform setting enabled?

We’ll try to troubleshoot from there. If none of those settings make a difference, I’m not sure how much we can advise other than by looking at the contents of your scene. We may have to ask for a minimal sample project, or at least the aircraft Blueprint, for testing purposes. (You can send it via private message if you’d like).

Thank you again for your patience :pray:

8

Hi @janine, no problem.

  • I’m using my own data
  • The terrain is set to moveable
  • The globe anchor has the that setting enabled.

I’ve done some further testing. I’m using the DynamicPawn so movement is controlled manually rather than by the data that was being fed in, but the terrain still has the jitter.

I’m unsure if jitter is the correct way to describe it, the terrain just visibly moves ever so slightly when the shift happens - sometimes it is more noticeable for no apparent reason. Are you able to replicate this on your side by flying the dynamic pawn close to the terrain?

9

@janine Using Unreal 5.4 has fixed the mesh jitter issue I was experiencing. I’m still having the same issue with origin shift causing the terrain to move around when rebasing though. This is not a big of a deal breaker as it previously was since I can increase the distance at which a rebase will take place. I would still like to get to the bottom of this though.

10

Tried using CesiumWorldTerrain which doesn’t seem to have the same terrain issue as when I use my own local tileset - could this be an issue with the tileset?

11

Hi @SimonLation, thank you for sharing more detail with me. I’m glad to hear that Unreal 5.4 fixed your mesh jittering!

Hm, I wonder if there are some differences between Cesium World Terrain and your dataset that are particularly important. It might help to share more information, but I also want to respect the privacy of your data. If this gives you any ideas: Cesium World Terrain is streamed in quantized-mesh format, and we position everything in Cesium based on the WGS84 ellipsoid. Perhaps this is different from what your data expects?

12

I believe my terrain is in 3D Tiles format, not quantized mesh. Positioning is done using the same cooridnate system (ESPG:4797 I believe). Do you happen to have a known “good” 3DTiles tileset and/or a quantized-mesh version?

13

@janine Thanks to @ILoveFlan’s post I have found that setting the georeference mode to “True Origin” removes the jumpiness of the terrain. The tooltip for this mode notes that it is not recommended but not why, I assume this would not be recommended due to accuracy?

14

Hi @SimonLation,

I believe my terrain is in 3D Tiles format, not quantized mesh. Positioning is done using the same cooridnate system (ESPG:4797 I believe). Do you happen to have a known “good” 3DTiles tileset and/or a quantized-mesh version?

Thanks for sharing. Cesium World Terrain is in quantized-mesh, which I believe is projected with
EPSG:4326. For another point of comparison, Google Photorealistic 3D Tiles is streamed as purely 3D Tiles (even the terrain). I hope those two datasets can offer points of comparison.

Thanks to @ILoveFlan’s post I have found that setting the georeference mode to “True Origin” removes the jumpiness of the terrain. The tooltip for this mode notes that it is not recommended but not why, I assume this would not be recommended due to accuracy?

That’s a really interesting find. Let me take a step back…

The purpose of CesiumGeoreference is to georeference the Unreal level, i.e. to assign the Unreal origin (0, 0, 0) to some specified point on the globe. Combined with CesiumOriginShift, you can move around the world, and the origin will consistently rebase to your position, so you have seamless roaming without worrying about stuff like the changing up-direction across the globe.

In “True Origin” mode, you are instead positioning the Unreal origin (0, 0, 0), at whatever the tileset’s origin is. It is usually not recommended because for many tilesets, e.g., global terrain tilesets, the tileset’s origin is the center of the Earth. So you’re essentially georeferencing the level to the center of the Earth, instead of a point on the Earth’s surface. CesiumOriginShift isn’t relevant here.

I’m not sure why “True Origin” would work better for your case, especially if your objects are globe-anchored underneath that same georeference. I guess that would be one thing to check, if everything in your world is geolocated by the same georeference actor.

But based on your feedback, it sounds like there’s some disagreement with the data and the plugin. I couldn’t tell you what without looking more closely, but I hope this explanation helps.

15

Hi @janine,

In “True Origin” mode, you are instead positioning the Unreal origin (0, 0, 0), at whatever the tileset’s origin is. It is usually not recommended because for many tilesets, e.g., global terrain tilesets, the tileset’s origin is the center of the Earth. So you’re essentially georeferencing the level to the center of the Earth, instead of a point on the Earth’s surface. CesiumOriginShift isn’t relevant here.

What is the behavior if we use “True Origin” and Origin Shift Component set to “Change Cesium Georeference”? Would we not be updating to the correct z up? When testing it does seem like I am remaining on the globe’s surface as expected, however, I have not tested working with collisions and physics to verify this.

16

Hi @janine, thank you for the extended explanation - the Google tiles also do not have this problem so I agree with you that it’s most likely a disagreement between my data and the plugin.

I can send you a sample of the terrain I am using but would rather do this over PM if possible.