Unreal 5.2 – Sky and Weather System


Architecting a runtime weather system in Unreal Engine 5.2: dynamic sky, volumetric clouds, Niagara particle effects, and tri-planar landscape texturing.


This project is an environment and weather system demo built entirely in Blueprints with Unreal Engine 5.2, developed following this Udemy course. It implements three weather states — sunny, rainy, and snowy — switchable at runtime, each driving a coordinated set of visual systems: sky atmosphere, volumetric clouds, dynamic lighting, Niagara particle effects, and landscape surface response. The project is less about gameplay and more about understanding how to architect a system that keeps multiple rendering subsystems synchronized around a single source of truth.

You can watch the demo in action here: YouTube


Weather as a State Machine

The most important architectural decision in a weather system is how weather state is represented and how changes propagate to all the systems that depend on it. The naive approach handles each visual element independently — a Blueprint for rain particles, another for cloud density, another for light color — with no central coordination. This produces a system that’s hard to keep in sync: changing the weather requires remembering to update every element manually, and transitions between states are difficult to make feel cohesive.

The cleaner approach treats weather as a single state that all subsystems observe. One actor (a Weather Manager) holds the current weather state as an enum — Sunny, Rainy, Snowy — and exposes a single function to transition between states. When that function is called, it drives every downstream system from one place: sky parameters, cloud opacity, light color and intensity, particle system activation, and landscape material parameters. Adding a new weather state or a new visual element means extending one system, not hunting for every place that needs to change.


Dynamic Sky: SkyAtmosphere and Volumetric Clouds

Unreal’s sky is built from three layered components that work together:

The SkyAtmosphere component simulates physically based atmospheric scattering — the reason the sky is blue, sunsets are orange, and the horizon is lighter than the zenith. It’s driven by the DirectionalLight (the sun) rotation, so rotating the sun through the day cycle automatically updates the sky color and scattering without manual parameter changes. The atmosphere responds to the sun angle continuously, producing the correct sky color at every time of day.

The SkyLight captures the sky’s current color and uses it as ambient light for the scene — objects in shadow are lit by the sky color rather than flat ambient. In a day/night cycle, the SkyLight needs to be recaptured periodically (or set to real-time capture mode) so that indoor shadows and shaded areas reflect the current sky state. Real-time capture is expensive; for most games, recapturing at key transitions (sunrise, sunset, weather change) is the right balance.

Volumetric Clouds add a geometry layer to the sky — actual 3D cloud shapes that cast shadows, receive light from below, and evolve over time. Cloud density, coverage, and albedo are parameterized per weather state: sparse, high-altitude clouds for sunny; dense, low-lying overcast for rainy and snowy. The transition between states lerps these parameters over time, producing a gradual cloud transition rather than an instant snap.


Day/Night Cycle

The day/night cycle is implemented by rotating the DirectionalLight actor on its pitch axis over time. One full rotation corresponds to one full day — the rate of rotation determines day length. At noon (sun directly overhead) the lighting is harshest; at sunrise and sunset (sun near the horizon) the atmospheric scattering produces warm orange tones; at night (sun below the horizon) the DirectionalLight contribution drops to zero and the SkyLight captures the dark sky.

Stars are added as a separate dome mesh with an emissive material that becomes visible only when the sky is dark — controlled by the sun angle. A simple alpha blend driven by the sun’s elevation angle fades stars in as the sun sets and out as it rises.

The challenge of day/night cycles is performance: real-time dynamic shadows from a rotating directional light are expensive, and fully dynamic global illumination (Lumen) must update continuously as lighting changes. For open-world projects, shadow distance and Lumen update rate are the main performance levers.


Niagara Systems: Weather Particle Effects

Niagara handles all the particle-based weather effects, and the variety here demonstrates the breadth of what Niagara can express:

Rain is a high-count particle system with fast-falling, streak-shaped sprites. Rain particles use velocity inheritance from the wind direction, which makes the rain angle change when wind shifts. Rain is not a screen-space effect — it’s a world-space emitter that moves with the player, always centered around the camera to cover the visible area without simulating rain across the entire level.

Rain splashes and puddles are triggered when rain particles collide with surfaces. Niagara’s collision module detects the impact point and spawns a secondary splash emitter at that location — a radial ring of small droplets. Puddles are decals spawned at the same location and accumulated over time, giving the ground a progressively wetter appearance the longer it rains.

Snow uses slower, drifting particles with random lateral velocity to produce the characteristic unpredictable movement of snowflakes. Snow particles are larger, lower-count, and more transparent than rain — the visual language of snow is softness and accumulation rather than force.

Snow footprints are a surface deformation effect: as the player walks, their foot position is used to paint into a render target that drives a displacement in the landscape material, leaving visible indentations in the snow. This connects the particle system to the landscape material in a way that makes the snow feel physically present rather than purely decorative.

Lightning bolts and flashes are triggered probabilistically during the rainy state. The bolt is a Niagara ribbon renderer — a series of connected points with randomized lateral offsets that produce the jagged shape of a lightning strike. The flash is a brief, high-intensity SkyLight intensity spike synchronized with the bolt spawn time, washing the scene in white light for a single frame.


Landscape: Tri-Planar Texturing

The landscape uses tri-planar projection combined with texture bombing for its surface materials.

Standard UV mapping on a landscape produces visible tiling at scale — the same texture pattern repeats regularly across large terrain areas. Texture bombing breaks this repetition by sampling the texture at multiple slightly offset UV positions and blending between them, randomizing the pattern distribution. The result reads as a continuous, non-repeating surface even at a distance.

Tri-planar projection addresses the stretching artifact that appears on steep terrain slopes when using standard UV projection. Standard UV maps texture coordinates along the XY plane — on vertical cliff faces, this stretches the texture vertically, producing the characteristic smeared look of badly textured terrain. Tri-planar projection samples the texture from all three world-space axes (XY, XZ, YZ) and blends between them based on the surface normal. Vertical surfaces use the XZ or YZ sample; horizontal surfaces use the XY sample. The blend is smooth, eliminating stretching entirely regardless of slope angle.

Both techniques are implemented in the landscape material, which means they apply automatically to any terrain geometry without per-polygon UV authoring.


Runtime Weather Transition

Switching weather states at runtime requires more than just enabling or disabling particle systems. A credible transition involves:

  • Cloud density and coverage lerping over several seconds
  • Light color and intensity interpolating toward the new state’s target values
  • Particle systems for the previous weather fading out as new ones fade in
  • Landscape material parameters (wetness, snow coverage) blending toward the new state

All of these transitions are driven by the Weather Manager with a shared alpha value that advances over the transition duration. Every subsystem reads the same alpha and applies it to its own blend, keeping everything synchronized without each system needing to know about the others.


Reflection

The sky and weather system is unusual among the Blueprint projects in this series because its value is almost entirely visual — there’s no gameplay, no AI, no interaction system. What it demonstrates is how to orchestrate multiple rendering subsystems (atmosphere, clouds, lighting, particles, materials) as a coherent whole, driven by a clean central state machine.

From a production standpoint, weather systems of this kind appear in virtually every open-world game, and the architectural patterns here — centralized state, parameterized transitions, Niagara for particle effects, material parameter collection for landscape response — are the same ones used in production implementations, just at a smaller scale. The Niagara work in particular has direct relevance to any project that needs particle-based environment effects, since the techniques (collision-triggered secondary emitters, ribbon renderers, world-space emitters that follow the camera) are general-purpose and reusable.

Leave a comment

Create a website or blog at WordPress.com

Up ↑