Weather, sky and Ultra Dynamic Sky

Every weather profile NameFrame ships, what each one actually does to the sun, fog and clouds, and the full compatibility surface for Ultra Dynamic Sky and Ultra Dynamic Weather. All the numbers on this page are read out of the shipping code.

Two drivers, pick one#

environment:
  weather_driver: builtin
  weather: rain

environment:
  weather_driver: ultra_dynamic
  ultra_dynamic_weather:
    Weather: [clear_skies, rain_light]

The nine built-in profiles#

Each profile drives the sun, the fog and, where it matters, the cloud layer. Every value below is a range sampled per frame, so two rain frames are not the same frame.

Random weather#

Set weather: random and NameFrame samples a profile per frame. Without explicit weights it uses this distribution:

Overriding a profile#

A profile sets a starting point. Any of these keys, set alongside it, replaces that part of it and leaves the rest alone:

environment:
  weather: overcast
  sun_elevation_deg: [40, 55]     # narrower than the profile's 18 to 48
  fog_density: [0.02, 0.03]
  cloud_layer_bottom_km: [1.2, 1.8]
  cloud_layer_height_km: [8, 11]
  cloud_tracing_max_distance_km: [90, 160]
  cloud_view_sample_count_scale: [1.4, 1.9]
  suppress_precipitation: false
  suppress_clouds: false
  weather_settle_seconds: 1.0

Touching any cloud key turns the cloud layer on for that profile, unless you explicitly say suppress_clouds: true. That is deliberate: asking for a cloud base and getting no clouds would be surprising.

Mixing several profiles in one run

environment:
  weather_profiles:
    - {name: clear_sun, weight: 40}
    - {name: overcast,  weight: 25, fog_density: [0.02, 0.04]}
    - {name: rain,      weight: 20}
    - {name: fog,       weight: 15}

Each entry can carry its own overrides, so "rain, but never darker than this" is one line rather than a separate run. Entries with a weight of zero or less get dropped.

Ultra Dynamic Sky and Ultra Dynamic Weather#

NameFrame drives UDS/UDW as an ordinary Blueprint actor, so it works with the assets you already own and does not need a patched copy.

How the actors get found

By default NameFrame looks for an actor whose class name contains Ultra_Dynamic_Sky for the sky role, and Ultra_Dynamic_Weather for the weather role. If your project renamed them, say so:

environment:
  weather_driver: ultra_dynamic
  ultra_dynamic_sky:
    actor: BP_MySky_C            # exact actor name
    class_contains: MySkyClass   # or match on class
    params:
      Time of Day: [900, 1700]

Parameters can go under params: (or parameters:), or directly on the section as shown elsewhere on this page. Both compile to the same thing.

When both roles are present, NameFrame also links them: the weather actor's UltraDynamicSky reference gets pointed at the sky actor, so a UDW preset change drives the sky as well.

Values a property accepts

From Studio's text fields the same thing is written inline, because a text box cannot hold YAML:

Time of Day=900,1700;Cloud Coverage=0,10
Weather=clear_skies|rain_light|snow

Weather presets NameFrame knows about#

10 stock Ultra Dynamic Weather presets, reachable under 19 names. Write the short name in your recipe and NameFrame resolves the asset path. A full asset path also works, which is how you use a preset of your own.

Defaults NameFrame applies#

Turn the dynamic driver on without listing parameters and these are the values it drives. Anything you set explicitly replaces the matching entry.

Ultra Dynamic Sky

Ultra Dynamic Weather

Particle placement support#

These get filled in automatically whenever you drive Ultra Dynamic Weather, even if you only asked for a preset. They are what makes rain and snow land in front of the capture camera instead of around the player pawn.

Named times of day#

Instead of a number, Time of Day takes these names, which expand to a range sampled per frame.

Manual overrides and why they are handled separately#

UDW exposes two ways to control weather: pick a preset, or set the individual manual-override values for rain, snow, fog, cloud, thunder and lightning. They fight each other, because applying a preset resets the manual values.

NameFrame treats any property whose name contains manual override, rain, snow, fog, cloud, thunder, lightning and similar as a manual override, and applies it after the preset has settled. The particle-placement properties and Weather itself are explicitly excluded from that rule, since they are how the preset gets applied in the first place.

Practically: you can ask for rain_light and then push the rain intensity higher, and the second instruction will not get wiped by the first.

Three things that catch people out#

Precipitation is invisible in captures

UDS/UDW rain and snow are GPU Niagara systems, and Unreal does not render those inside editor scene captures. The frame comes out with wet-looking ground and no rain in the air.

NameFrame composites the precipitation onto the report and dataset images instead. It is on by default. In Studio it is Composite rain and snow particles into generated output, and on the CLI it is --precipitation, with --precipitation-strength to scale the density. It works with both weather drivers.

Blueprint defaults come back after settling

Some UDS/UDW Blueprints reassert their own values during the transition. NameFrame reapplies the requested values after the settle period for exactly that reason. If you see a property snapping back, that reapply step is what stops it, and it is on by default.

Exposure across many times of day

A fixed negative exposure bias, inherited from a sunny-only render profile, turns valid daytime UDS frames nearly black. If you have not set render.fixed_exposure explicitly, the compiler switches to adaptive exposure for the dynamic driver. Set it yourself only when you know the range of times you are capturing.

Settle time#

weather_settle_seconds is the pause between applying weather and capturing. Default is 0.75, and the shipped dynamic-weather profile uses 1.5. It exists because sky, fog and lighting transitions are not instantaneous. Set it to zero and you capture frames mid-transition, which looks like weather that does not match the recorded environment values.

For long runs, Frames per weather batch lets several frames share one weather state, so you pay the settle cost once per batch rather than once per frame.

See also#