I would love to see more documentation on the current status of multiplayer server integration works.
I’ve found lots of posts over time with various problems – but all of these seem minor now, in comparison to the current state which is that you just fall through maps if the netmode is set to client in a project.
opened 09:59PM - 04 Jun 21 UTC
closed 12:35PM - 03 May 22 UTC
research
## Overview
I did some investigation into multiplayer support with Cesium for U… nreal - specifically, whether multiplayer would be compatible with World Origin Rebasing.
As mentioned in the [reference frames documentation](https://github.com/CesiumGS/cesium-unreal/blob/54c0e4f0afb37a6e1c2866f36939e28a4a747667/Documentation/reference-frames.md), Unreal Engine uses both an FIntVector (int32) to represent the position of a "floating" world origin relative to the absolute world origin (0,0,0), and an FVector (float) to represent the location of actors relative to that floating origin.
World Origin Rebasing is the process of moving the floating origin closer to the player character's location in order to avoid floating precision errors, which can be noticeable after traveling a few kilometers away from the floating origin. Cesium for Unreal will call Unreal Engine's world origin rebasing function once the world origin is a user-specified distance away from the player camera, if the `Keep World Origin Near Camera` feature is enabled in the `CesiumGeoreference`.
The normal World Origin Rebasing functionality is not compatible with multiplayer, as it cannot handle a client + server having different world origins. But a few engine versions ago, a [multiplayer version was added](https://github.com/EpicGames/UnrealEngine/pull/2359) and can be enabled via the Project Settings -> `Enable Multiplayer World Origin Rebasing`.
## How it works
The way the multiplayer origin rebasing resolves the "multiple world origin" issue is by interpreting location vectors in the absolute world frame. That is, when a server sends (replicates) an updated movement location to a client, that location vector is rebased to the absolute origin frame before being sent, and when the client receives it, they rebase it to their own floating origin before applying the location update.
This all happens under the hood when the `Enable Multiplayer World Origin Rebasing` feature is enabled. But you will also need to account for this when writing gameplay code, so here's a blueprint example, which demonstrates a teleportation mechanic that can be called from a client. My goal is to teleport the player pawn to the location of `BP Teleport Actor`. On the client side, I rebase that vector to the absolute origin before sending it to `S_Teleport` (server-side function), which rebases it back onto its own floating origin before actually teleporting the actor. The consequence of the server-side teleport is then propagated back to the client.
Cesium for Unreal's world origin rebasing logic is compatible out of the box with multiplayer origin rebasing.
_Blueprint example showing a custom teleportation mechanic, accounting for the multiplayer origin rebasing changes._
## Caveats
The glaring compromise to this approach, however, is that there is still a maximum distance we can reasonably play in before the floating point accuracy breaks down (approx 20x20 km play area). The philosophy behind doing this at all is that the jitter from client-side systems (in animation, client-side physics, particles) is noticeable sooner than in server-side systems like movement correction, which are more macroscopic. So, we can freely rebase client-side systems to benefit from smooth animations, until we reach the server-side accuracy limit.
In order to have multiplayer gameplay on a truly global scale, Unreal Engine will most likely need double floating precision support.
There was also a Cesium for Unreal specific issue I encountered as well, which is that when Frustum Culling is turned on, the ground that the client is standing on can be unloaded at any time in the server's game instance. Because physics is mostly handled server-side, and the server is the authority on what's actually happening in-game, the client is now falling into oblivion. Meanwhile, the client does not immediately notice - after all, in their game instance, they're standing on solid ground - until the discrepancy manifests itself via some catastrophic glitch.
Disabling Frustum Culling resolved the issue, but also creates a ton of overhead, as all loaded tiles must be held in memory. A possible solution is for the server to avoid unloading tiles in the vicinity of clients. What would be even better is to only load the collision geometry rather than the entire gltf mesh + texture. This would also be a helpful step towards supporting dedicated servers, which do not actually render anything, and only handle gameplay logic, physics simulation, and network replication. As Cesium for Unreal currently decides which tiles should be rendered via calculating a view frustum, it probably wouldn't work at all in a dedicated server in its current state.
## Links
Link to a sample project with gameplay examples at this [Unreal Engine forum thread](https://forums.unrealengine.com/t/pull-request-world-origin-shifting-in-mp/62649/77) and a [direct Google Drive link](https://drive.google.com/file/u/1/d/1yv1LZljx5JeyQLhkzVMr1BbNsRVFXecp/view?usp=drive_open).
_Screenshot of a server + client with different floating world origins, as indicated by the location of the red spheres._
Note: When enabling the multiplayer world origin rebasing in your own project, I found that a restart was necessary, even though it wouldn't prompt you to restart. Otherwise the behavior is very buggy.
Hi. I’m working on UE 5.3.2 binary version with the latest version of Cesium from the Marketplace. Whenever I create a new map with a Cesium terrain in multiplayer, I get this strange behavior. When the default Third Person Character walks on the Cesium 3D ,the character’s position in the client does not match the position in the server. Here is a quick test I did where I draw a debug sphere to show where the server thinks the client is positioned:
[Cesium-Terrain-Position-Bug]
This causes str…
I’m not sure, as I’ve done little multiplayer and have never used PlayFab at all. Does the problem seem to be that the terrain doesn’t get load in time (i.e., the player falls through before it gets a chance to load)? Or is it not getting loaded at all? Or is it there, and yet the player goes through?
This section of the Placing Objects on the Globe tutorial may be relevant:
opened 05:19PM - 25 Nov 24 UTC
Hi team,
I've been having trouble getting collision working for players in Un… real Engine when using Cesium tilesets. I initially thought upgrading to UE 5.5 might fix the issue due to the Chaos Engine changes, but unfortunately, the problem persists. My characters consistently fall through the tileset floor, and it seems like the collision isn't recognized.
Here's what I've observed so far:
Behavior:
When the game is running in standalone mode, or as a client in multiplayer mode, the pawn falls through the Cesium tileset floor.
In Listen Server mode, the collision works as expected, and the character doesn't fall through the tileset.
Debugging Steps:
I've tried increasing the character capsule's collision size to ensure it interacts with the tileset properly.
Verified that the Cesium tileset is loaded in the world when the issue occurs.
Enabled collision settings on both the Cesium3DTileset and the CesiumGltfPrimitiveComponent with no success.
Observed no noticeable collision response even though the tiles are visible and rendered correctly.
Environment:
Unreal Engine versions 5.3, 5.4, and 5.5 all exhibit this behavior.
Issue primarily occurs in rural tilesets (possibly related to tile streaming or dynamic loading).
Would love to see examples of how Cesium could be used in various multiplayer setup modes.
Net Mode Client | ie, how does collision data get shared between client/server
Is it possible to set client to be authoritative over it’s own collision/physics?