Gaussian splats not rendering in Standalone/packaged builds — Cesium for Unreal 2.24.1

Cesium for Unreal
1

Environment

  • Cesium for Unreal 2.24.1
  • Unreal Engine 5.7
  • Windows 11
  • Splat asset hosted on Cesium ion, referenced by asset ID

Setup

We’re building a collaborative viewer where users pick assets from a custom UI and the app spawns tilesets at runtime. Tilesets are created with SpawnActorFromClass on a Blueprint subclass of ACesium3DTileset, and IonAssetID / IonAccessToken are set on the returned actor after the spawn completes.

Problem

The Gaussian splat asset does not render in a packaged Shipping build. The same failure reproduces in a Standalone Game session launched from the editor, which has made iteration much faster.

What works

  • Regular 3D Tiles (Cesium World Terrain, imagery, other 3D Tiles assets) load and render correctly through the exact same spawn code
  • The splat asset renders correctly in the Cesium ion web preview, so the asset itself is good
  • No errors or warnings appear in the log relating to the splat

What we’ve ruled out

  • Not replication — the spawn function has no net flags, it’s a plain local call
  • Not cooking or asset stripping — reproduces in Standalone, which runs off editor assets
  • Not the ion token or networking — other tilesets stream fine in the same session
  • Not asset validity — confirmed in ion preview

What we found in the changelog

v2.28.0 lists “Fixed Gaussian splats not rendering in Standalone Game sessions launched from the editor,” which matches our symptom closely. We’re currently unable to upgrade from 2.24.1.

Questions

  1. Is the v2.28.0 fix likely to cover packaged Shipping builds as well, or was it specific to Standalone sessions launched from the editor?
  2. Is there a known workaround on 2.24.1 — a setting, or a way to force the splat subsystem to initialise correctly in a non-PIE world?
  3. Does spawning a splat tileset at runtime and setting IonAssetID after BeginPlay cause problems specific to splats? Since setting that property triggers a tileset reload, and splats render from a separate actor managed by UCesiumGaussianSplatSubsystem, we’re wondering whether the splat actor survives that reload. Would deferred spawn (setting the asset ID before FinishSpawningActor) be the recommended approach?
  4. For a splat asset that isn’t geolocated in ion, does the georeference need to be set to True Origin, or is there a recommended way to handle a non-geolocated splat alongside geolocated terrain in the same scene?
3

Hey @Prab_Aujla, welcome to the forum! Great write-up, the systematic elimination of variables really helps.

You’ve found the right changelog entry. PR #1849 fixed two underlying issues that prevented Gaussian splats from rendering in any non-PIE game session:

  1. The subsystem’s world lookup (GetPrimaryWorld()) only checked GEditor, which is null in Standalone and packaged builds, so it never found the right world context to initialize the splat rendering.
  2. The splat actor was spawned with bTemporaryEditorActor = true, which suppressed BeginPlay in game worlds. That meant the Niagara system backing the splat never initialized.

1. Does the v2.28.0 fix cover packaged Shipping builds?
Yes. Both root causes affect all non-PIE game sessions equally (Standalone and packaged). The fix resolves both.

2. Workaround on 2.24.1?
There isn’t a straightforward workaround since the fix touches internal subsystem and actor initialization code. If upgrading directly to v2.28.0 isn’t feasible, you could potentially cherry-pick the changes from PR #1849 (it touches two files with relatively contained changes), but that requires building the plugin from source.

3. Runtime spawn + setting IonAssetID after BeginPlay?
The rendering failure you’re seeing is caused by the subsystem bug above, not by the spawn timing. Once the subsystem fix is in place, setting IonAssetID after spawn (which triggers a tileset reload) should work the same as it does for regular 3D Tiles, I believe. That said, I don’t have specific confirmation that deferred spawn vs. post-spawn property setting makes a difference for splats specifically, so if you do upgrade and still see issues with the spawn pattern, let us know.

4. Non-geolocated splat alongside geolocated terrain?
This is independent of the rendering bug. For a non-geolocated splat, the georeference origin determines where in the world it appears. You don’t need to switch to True Origin for the whole scene. I believe you can set the CesiumGeoreference origin to your desired location and your geolocated terrain will still work correctly alongside it. If you need more control over placement, you can attach a CesiumGlobeAnchorComponent to position the splat at specific coordinates.

I’d recommend upgrading to v2.28.0 when you can since it resolves the core issue. There’s also a separate known crash in the Gaussian Splat Subsystem when changing maps on v2.27.0, which has a fix in progress.

Let me know how it goes!

4

Just wanted to close the loop on this , upgraded to v2.28.0 and I can confirm the fix works. Gaussian splats now render correctly in Standalone, and I also tested a packaged Development and Shipping build, both rendering as expected.

A few follow-up notes for anyone who lands on this thread later:

  1. Runtime spawn + setting IonAssetID after BeginPlay — this works fine on 2.28.0. I tested both deferred spawn and post-spawn property assignment, and the tileset reloads and renders the splat in both cases, same behavior as regular 3D Tiles.
  2. Non-geolocated splat alongside geolocated terrain — setting the CesiumGeoreference origin as suggested worked, and attaching a CesiumGlobeAnchorComponent gave me the fine-grained placement control I needed. Terrain was unaffected.

Thanks for the detailed breakdown of the root causes.

Marking this as solved. Thanks again!