Terrain lighting bug in scene with volumetric clouds after upgrading to UE5


After upgrading a Cesium project with volumetric clouds from Unreal Engine 4.27 to 5.1,
we noticed an issue where the terrain lights up brightly when the solar time is at dusk or dawn.

Below are two screenshots of a minimalistic project (Cesium Quick Start with volumetric clouds and “Use Per Sample Atmospheric Light Transmittance” enabled on the cloud component) in UE4.27 and UE5.1:

I’ve tried toggling all the possibly relevant options on the following components:

  • Volumetric Clouds:
    • unchecking “Use Per Sample Atmospheric Light Transmittance” fixes the lighting on the terrain, but the lighting on the clouds still looks wrong
  • Cesium Georeference: clicking “Place Georeference Origin Here” seems to solve the issue, but this wasn’t necessary in UE4.
  • Cesium SunSky (Directional Light, Sky Light, Sky Atmosphere): no effect
  • Changing exposure and auto-exposure settings: no effect

Any help would be appreciated.


Hi @sam_lapere,

I wonder if this is related to this issue: SkyAtmosphere sometimes hides earth's surface · Issue #527 · CesiumGS/cesium-unreal · GitHub. It seems to be the opposite problem – instead of it being too dark, it gets too bright – but the fact that it’s solved by repositioning the georeference origin makes me think it’s related.

We haven’t been able to investigate the issue closely, so I don’t have a clear solution. For now, changing the georeference origin as you move across the Earth is probably the best workaround.

Thanks for looking into this. That issue (#527) does look similar in the way it depends on rebasing the origin, but in our case the presence of volumetric clouds in the scene seems to be breaking the lighting of the terrain when the sun is at grazing angles (when per sample atmospheric light transmittance is enabled). When I disable the volumetric cloud actor or make it invisible, the terrain is lit correctly, without having to rebase the origin.

Hope that bit of info helps.


In case it might help someone else, we fixed the issue by explicitly rebasing each frame, setting the world origin equal to the camera location.