Someone actually tried packaging on this branch and is running into an issue, see #1749

A new issue to add to the list: when a Dynamic Pawn gets added to the level, the lighting on the splat goes haywire:
image

@david-lively reports this issue:

[UE] [2025年10月15日-16.55.01:627][ 59]LogCesium: Setting bounds: IsValid=true, Min=(X=357940124.922 Y=-120781445.651 Z=-123751071.001), Max=(X=357954552.308 Y=-120777170.055 Z=-123756954.477)
[UE] [2025年10月15日-16.55.01:627][ 59]LogCesium: Setting bounds: IsValid=true, Min=(X=357940124.922 Y=-120781445.651 Z=-123751071.001), Max=(X=357954552.308 Y=-120777170.055 Z=-123756954.477)
[UE] [2025年10月15日-16.55.01:627][ 59]LogCesium: Setting bounds: IsValid=true, Min=(X=357940124.922 Y=-120781445.651 Z=-123751071.001), Max=(X=357954552.308 Y=-120777170.055 Z=-123756954.477)
[UE] [2025年10月15日-16.55.01:627][ 59]LogCesium: Transform visible: false
validateComputeFunctionArguments:1175: failed assertion `Compute Function(Main_00005947_8a69e872): The pixel format (MTLPixelFormatR32Uint) of the texture (name:<null>) bound at index 5 is incompatible with the data type (MTLDataTypeInt) of the texture parameter (User_SplatInterface_SplatIndices [[texture(0)]]). MTLPixelFormatR32Uint is compatible with the data type(s) (
 uint
).'
validateComputeFunctionArguments:1175: failed assertion `Compute Function(Main_00005947_8a69e872): The pixel format (MTLPixelFormatR32Uint) of the texture (name:<null>) bound at index 5 is incompatible with the data type (MTLDataTypeInt) of the texture parameter (User_SplatInterface_SplatIndices [[texture(0)]]). MTLPixelFormatR32Uint is compatible with the data type(s) (
 uint
).'

Likely something to do with it running on the Apple GPU.

Gaussian Splats as depicted in the style of Tom Snyder:

Perhaps it goes without saying that there's some precision issues at play here. To some degree this problem is intractable with the requirements that a) everything happens on the GPU and b) everything must be sorted together. But there's definitely some things we can do to improve this I think. Probably if we rebased the Gaussian Splat Niagara system to be at the center of all currently loaded splats, it would help reduce precision issues instead of having it remain at (0, 0, 0) always.

@azrogers I've fixed the Android builds, though I'm not very satisfied with my understanding of what was going wrong. The fix was to remove the explicit reference to zlib::zlib in CesiumGltfReader's target_link_libraries. That was (apparently!) causing -isystem c:/android-ndk-r25b/toolchains/llvm/prebuilt/windows-x86_64/sysroot/usr/include to be added to the clang command-line in CesiumGltfReader, which was (apparently!) causing the wrong cmath or math.h or something to be included. Like I said, not an entirely satisfying explanation.

Particularly, the Hines Rowing Center tileset from the Sandcastle hovers over the terrain.

@azrogers, the Hines Rowing Center is using a WGS84 ellipsoid rather than Cesium World Terrain. Given this, it is known that it hovers over Cesium World Terrain. Here's a screenshot of it hovering in CesiumJS after the CWT terrain is selected.

Re: precision issues. Wow, yeah that's bad...

Probably if we rebased the Gaussian Splat Niagara system to be at the center of all currently loaded splats, it would help reduce precision issues instead of having it remain at (0, 0, 0) always.

This seems like the most reasonable solution given the situation.

EDIT: Although, this may be another instance where separate Niagara systems are warranted. That creates its own issues with sorting two splats on top of one another, but it might be an acceptable solution if precision continues to be an issue.

EDIT: Although, this may be another instance where separate Niagara systems are warranted. That creates its own issues with sorting two splats on top of one another, but it might be an acceptable solution if precision continues to be an issue.

We've been discussing this on the team. Splitting it up into multiple systems would cause some very obvious artifacts with two tilesets close by to each other, but should be fairly negligible with tilesets that are far away from each other - which is the most likely circumstance where the precision issues would manifest. The other circumstance would be if there are lots of tilesets, or a few very large tilesets, spanning a large distance - but you'd probably run into VRAM issues there before precision issues anyways.

We've been discussing this on the team. Splitting it up into multiple systems would cause some very obvious artifacts with two tilesets close by to each other, but should be fairly negligible with tilesets that are far away from each other - which is the most likely circumstance where the precision issues would manifest. The other circumstance would be if there are lots of tilesets, or a few very large tilesets, spanning a large distance - but you'd probably run into VRAM issues there before precision issues anyways.

There are potentially changes that could be made on the tiler side to help with very large tilesets, allowing for the potential of better culling. It won't fix the precision issues, but it could help with any potential VRAM issues.

Let me know if you want to come to one of your stand ups and I'm willing to do so. Just need to know what day and the time.