Implementing Globe-Circumnavigation Flight for Multiplayer in Unreal Engine

Cesium for Unreal
1

@Kevin_Ring

We’re working on a multiplayer game feature where a Pawn can fly around a globe, returning to its starting position after flying in a straight line. We’ve encountered several challenges and are seeking advice:

  1. Distance from Origin:
  • The Pawn flies very far from the origin, causing issues with Niagara and SkeletalMesh.
  1. Gravity and Alignment:
  • Unreal Engine only has Z-axis gravity, which doesn’t work for a spherical world.
  • We need a way to keep the Pawn and ground aligned, ensuring the ground is always below the Pawn’s Z-axis while allowing movement around the globe.
  • This alignment is crucial for maintaining the illusion of flight for multiple players.

We’ve experimented with the following approaches:

A. CesiumOriginShiftComponent:

  • Set Mode = ChangeCesiumGeoreference and Distance = 0
  • Result: The Earth sphere rotates while the Pawn stays in place. This works visually for a single player but isn’t suitable for multiplayer.

B. Disabled CesiumOriginShiftComponent:

  • The Pawn moves around the world and aligns with the sphere.
  • Issue: The Pawn moves far from the origin, distorting meshes and Niagara effects.

C. Custom WorldOriginShift:

  • We created our own system to shift the world origin to the Pawn’s position after a certain distance.
  • This approach breaks the alignment code somehow.

Questions:

  1. Where is the alignment code for actors with the Earth sphere when using CesiumOriginShiftComponent? It’s not inside the component itself, as disabling the Tick doesn’t affect alignment.
  2. How can we combine approaches B and C to maintain Pawn-sphere alignment while shifting the world origin locally for each player?
  3. When combining B and C, objects spawned in front of the camera appear lopsided. How can we fix this? Should we add alignment code to all actors or make them relative to the Pawn?
  4. What might be causing issues when we implement WorldOriginShift ourselves?

Any insights or suggestions would be greatly appreciated!

2

The Pawn flies very far from the origin, causing issues with Niagara and SkeletalMesh.

I suggest you report this to Epic. I don’t know if they’ll do much about it in the short-term, but it’s good to let them know it’s affecting people. Given Unreal’s use of double-precision these days, there’s no inherent reason this should be a problem.

Unreal Engine only has Z-axis gravity, which doesn’t work for a spherical world.

Same here. In previous conversations I’ve had with folks at Epic, they’ve suggested disabling gravity and using a custom force instead, though they recognize this isn’t a perfect solution. I haven’t tried it myself.

We need a way to keep the Pawn and ground aligned, ensuring the ground is always below the Pawn’s Z-axis while allowing movement around the globe.

This is definitely the problem that CesiumOriginShift is meant to solve.

The Earth sphere rotates while the Pawn stays in place. This works visually for a single player but isn’t suitable for multiplayer.

I’ve done very little multiplayer work in Unreal, so I can’t help much here, but I can appreciate the challenges. Ideally, each player would have their own origin, and coordinates communicated between clients would be expressed in something like ECEF instead of Unreal’s coordinate system. I have no idea how realistic this is within Unreal’s multiplayer system, though.

  1. Where is the alignment code for actors with the Earth sphere when using CesiumOriginShiftComponent? It’s not inside the component itself, as disabling the Tick doesn’t affect alignment.

It’s in CesiumGlobeAnchor.

CesiumOriginShift changes the georeference origin based on the current location of some Actor. CesiumGlobeAnchor keeps any object (including but not limited to the one that triggered the origin shift) at the same location and orientation relative to the globe, even when the georeference origin changes.

Questions 2-4 I don’t know that I really can answer, as I don’t know how you’ve implemented your custom world origin shift.

3

Thanks for the previous answers. We’ve resolved most of our rendering issues with Cesium, but we’re now facing challenges with movement replication:

  1. Our goal is to address the origin problem and enable users to fly around the world.
  2. We’ve partially solved this using CesiumOriginShift and CesiumGlobalAnchor components on the Pawn. This keeps the Pawn at (0,0,0) while the Earth rotates beneath it.
  3. However, this approach complicates movement replication in a multiplayer environment. Although players move on their respective clients, their positions don’t change relative to the origin. As a result, all players appear next to each other.
  4. We attempted to replicate latitude and longitude for each player instead of Unreal coordinates, but this lacks the necessary precision for accurate positioning.

Questions:

  • Is there a way to achieve the flying effect using CesiumOriginShiftComponent and CesiumGlobalAnchorComponent while allowing the Actor to move in the world?
  • Can we shift the origin of the entire world while keeping the Actor aligned with Earth?
  • How can we maintain precise positioning in a multiplayer setup with Cesium integration?

Any insights or suggestions would be greatly appreciated. Thanks in advance for your help!

4

We attempted to replicate latitude and longitude for each player instead of Unreal coordinates, but this lacks the necessary precision for accurate positioning.

I wouldn’t expect this to be an issue as long as you’re using double-precision coordinates for the longitude/latitude. Single precision definitely won’t cut it.

Is there a way to achieve the flying effect using CesiumOriginShiftComponent and CesiumGlobalAnchorComponent while allowing the Actor to move in the world?

Sorry, I don’t know what you mean by “flying effect”?

Can we shift the origin of the entire world while keeping the Actor aligned with Earth?

I don’t understand your question here, either. CesiumOriginShift shifts the world. CesiumGlobeAnchor keeps the Actor aligned with the globe. I guess you’re saying something is missing in that, but I don’t know what.

How can we maintain precise positioning in a multiplayer setup with Cesium integration?

I think I answered this previously: the only way I know is to communicate player coordinates in a common coordinate system like ECEF, rather than Unreal coordinates (because Unreal coordinates are different on different clients). Unless Unreal’s multiplayer system has a strange limitation where it can only transfer single-precision coordinates, there shouldn’t be any precision issue in this. A double-precision number has at least 14 digits of precision. The Earth (WGS84 ellipsoid) has a radius of 6378137 meters at the equator, which means we have 7 digits of precision available after the decimal point. That’s sufficient for sub-micrometer positions.

5

@carlrealvr can you elaborate on the problems you saw with SkeletalMesh when far from the origin? I mentioned your difficulties with large coordinates to some folks at Epic today. The gravity direction and Niagara problems were unsurprising to them, but they were surprised to hear there are problems with SkeletalMesh.