FEEDBACK REQUESTED: Documentation for Cesium Native / Cesium for Unreal

janine · November 4, 2024, 4:27pm

Hi all,

The Native Runtimes team is planning to develop + update our documentation so that developers can more easily contribute to Cesium for Unreal + Cesium Native. In particular, we’re looking at tasks like:

Publishing documentation for Cesium Native in an accessible place
Creating contributor’s resources for Unreal / Native, similar to CesiumJS
Creating guides for API design + best practices
Developing high level explainers for various parts of the code, e.g.,
- Explanation of the multi-threaded async system in Cesium Native
- Explanation of the tile selection algorithm in Cesium Native
- Architectural diagrams showing how Cesium for Unreal interfaces with Cesium Native

We would love to get input from our community on what YOU would like to see regarding documentation and contributor resources! Please be open and honest about any documentation areas that we can improve, or any guides we could create that would better help you understand
the workings of Cesium Native / Cesium for Unreal.

Thank you in advance for your input!

yunusyurtturk · November 5, 2024, 9:45pm

Hi,

I have experience working with cesium-for-unreall and osgEarth, both of which use cesium-native. While exploring the codebases for these implementations, I spent some time identifying the entry/common point(s) where cesium-native integrates with Unreal and osgEarth. The method I was looking for was updateView(). Once I understood how updateView() is called, understanding the responsibilities of cesium-native became clearer.

It may be helpful to provide some explanation of updateView() as part of:

Developing high-level overviews for different parts of the code

and

Creating architectural diagrams to show how Cesium for Unreal interfaces with Cesium Native.

janine · November 5, 2024, 10:45pm

Hi @yunusyurtturk,

Thank you for your input, and for being the first to chime in on this thread!

That’s a good point – the updateView method is a key integration point with cesium-native, and we want users to more easily understand it. I’ve noted this internally so that we can improve our documentation for this function. If you think of anything else, don’t hesitate to let us know!

Kyn21kx · November 7, 2024, 1:38am

Hi there, as the current developer of the Cesium For Godot extension I think it would have been amazing for me to have a couple of things.

More explicit and publicly available architecture design of the intended 3D tile loading system, i.e going from tileset to asset accessor and how individual tiles will be streamed, as this can vastly accelerate the learning curve of any future integration / implementation.
Explicit mention of the importance of the Cesium3DTilesContent::registerAllTileContentTypes(); method, as it was a source of minor frustration when we had all the setup done for receiving tiles, and they were not loaded in the tilesToRenderThisFrame collection.
More Geospatial learning resources, I feel like we all could benefit a lot from including more sources and recommended readings for the developers in Geospatial topics, this is not so much a topic that relates directly to documentation, but I believe many devs will be interested in learning more about the foundational principles of the technology they’re implementing and its use cases when these resources are available within the documentation.
That’s all I have for now, all and all, you guys make a great product and I’ve been enjoying the integration!

janine · November 7, 2024, 4:03pm

Hi @Kyn21kx, welcome to the community!

Thank you for the detailed writeup – this is super helpful. Your first point sounds like an extension of the updateView point made by @yunusyurtturk, and I think it’s good to see this common thread. Our team should definitely focus on making the 3D Tile loading pipeline more accessible to the public. I also agree that geospatial concepts are another hurdle that we could lower with some dedicated materials.

I’m continuing to note all of these points down. Thanks again for your input, and as always let us know if anything else comes up – we’re here to help!

Trent_Brown · November 26, 2024, 4:20pm

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.

github.com/CesiumGS/cesium-unreal

Multiplayer Origin Rebasing Support Notes

opened 09:59PM - 04 Jun 21 UTC

closed 12:35PM - 03 May 22 UTC

xuelongmu

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. ![image](https://user-images.githubusercontent.com/10490807/120864779-c4896800-c55a-11eb-93c9-767b7458a42f.png) _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). ![image](https://user-images.githubusercontent.com/10490807/120861749-cc92d900-c555-11eb-8772-db88b4f1a076.png) _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.

github.com/CesiumGS/cesium-unreal

Pawn falls through cesium tileset

opened 05:19PM - 25 Nov 24 UTC

TrueNorthTrent

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
Net Mode Server | ie, Does cesium load a component for each multiplayer actor? How do mobs not fall through the ground?

Is it possible to set client to be authoritative over it’s own collision/physics?

janine · November 27, 2024, 3:34pm

Hi @Trent_Brown,

Thanks for your input. I created this Github issue for us to investigate multiplayer behavior in Cesium for Unreal when we get the chance.

This post is asking for feedback about how we can help developers navigate the Cesium for Unreal / Cesium Native codebases. So definitely let us know if you have feedback there – otherwise, I suggest opening new threads about documentation that is more user-facing. Thank you!

Topic		Replies	Views
What Cesium for Unreal tutorials do you want to see? Cesium for Unreal announcement	34	5529	April 16, 2024
Open UI for Cesium for Unreal Engine Cesium for Unreal	3	189	October 23, 2023
3D Tiles 1.1 support? Cesium for Unreal	9	1023	July 20, 2022
CZML in Cesium... CesiumJS	6	170	June 29, 2012
Cesium Release Roundup General announcement	40	4041	December 2, 2024

FEEDBACK REQUESTED: Documentation for Cesium Native / Cesium for Unreal

Related topics