View Categories

Weather System

7 min read

Weather System #

Weather System Overview #

The core systems needed for the weather system is a time manager and a day night cycle system. We have made extensive documentation for those. This doc is about the weather system itself.

The weather system provides the user with the ability to create interactive environments and enhance immersion within the environments. It simulates diverse weather conditions that respond both to time and spatial changes, including player interactions. This document details the design, implementation, and functionality of the weather system, providing developers with the knowledge to customize, control, and extend weather effects as needed.

Core System #

Actors #

    • BP_SectionBiome
    • BP_GlobalBiome
    • BP_ControlArea

Components #

    • AC_Biome_WeatherManager_Advanced
    • AC_PlayerController_WeatherManager

Interfaces #

    • BPI_Biome
    • BPI_ControlArea_NotifyPlayer
    • BPI_Weather_NotifyPlayer

Material Parameter Collections #

    • MPC_Player_WeatherAttributes
    • MPC_WeatherEffects
    • MPC_WeatherLensEffects

System Setup #

To setup the weather system Drag out BP_BiomeGlobal and BP_SectionBiome into your level.

Once that is done go into your character controller and add AC_PlayerController_WeatherManager component.

Adding this component is crucial because without it the biomes wont register the character as a listener for its events and functionality.

Once Everything is added in we will turn our attention to the section biome first. In both the global biome and the section biome you will see a system category, this is where the customization for the biome behaviors happen.

A section biome has a transition width and a priority at the top, the transition width ensures the weather effects fade in according to distance through the transition area, while the priority sorts out which biome we should be in based on importance if many are overlapping. Each Biome(Section and Global) has a transition structure. This transition structure is a Markov chain of user created probabilities. This allows us to determine probabilities for conditions occurring over others. Another option is the data table option. if you do not want to create Markov chains over and over, you can import a data table with the correct format, and generate the Markov transitions from the data table. Use DataTable Transitions must be checked. Then hit refresh data.

The Weather system also allows the user to control certain weather lens effects and sounds within a speficied area. Setup is very simple. Drag out the BP_ControlArea Actor into your level. The control area is just a simple Box Overlap wrapper.

The application time is when the player enters and leaves the control area, how long do we want to apply the effect, the controls control the lens effects for the duration of overlapping the control area.

Modifying or Adding Weather Conditions #

To modify the existing weather conditions navigate to the DataAttributes folder.

Inside a weather condition you have a condition enum, which helps the system find the specific type of condition. How long to apply the condition for and how long to keep the condition active for, the lighting intensities change the sun light intensity and color. The material modifiers change the snow accumulation, dust accumulation. The Rain intensity changes how intense the rain is. The Temperature is the biome temperature which in return will effect the frost lens effect on the player, you have different types of coverages.

To Add a weather condition is simple. Navigate and open the Enum_WeatherStates and add in the desired condition. Next Create the asset inheriting from the DA_GeneralWeatherAttributes. Once created open it up. Select the condition name and find your newly created condition which is important. Next

Go into the AC_Biome_WeatherManager_Advanced and add the condition to the array

Open up the AC_PlayerController_WeatherManager component. There are two functions that need to be updated. These are called Apply Weather Attributes and Apply Weather Attributes Continually.

High Level System Overview #

Actors #

BP_SectionBiome and BP_GlobalBiome inherit under BP_Biome. Sectional biomes are biomes with a fixed area.

BP_GlobalBiome is a biome with an infinite extent. If a player if not in a sectional biome it would be expected that a player is in a global biome.

BP_ControlArea is an actor with a determined area whose main goal is to control the specific biome properties. An example would be if the player walks into a house in the middle of a blizzard control the players temperature.

Components #

AC_Biome_WeatherManager_Advanced is to be attached to any actor intended to be a biome. AC_Biome_WeatherManager_Advanced handles all of the server side logic, including a biome timer and calling event dispatchers.

AC_PlayerController_WeatherManager is to be attached to a player controller if you want to interact with the biome. AC_PlayerController_WeatherManager binds event dispatchers from AC_Biome_WeatherManager_Advanced and handles all of the owning client logic.

Interfaces #

BPI_Biome interface is a simple interface to get the owning biome that the AC_Biome_WeatherManager_Advanced is attached to. Since the BP_SectionBiome and the BP_GlobalBiome are similar in their functionality we still need to differentiate between them for the functionality that they are different in.

BPI_ControlArea_NotifyPlayer is an interface that sends out two events “OnPlayerEnteredControlArea” and “OnPlayerExitedControlArea” to the AC_PlayerController_WeatherManager component. With the intention of notifying the component to perform certain logic.

BPI_Weather_NotifyPlayer sends out two events “OnPlayerEnteredBiome” and “OnPlayerExitedBiome” to the AC_PlayerController_WeatherManager component With the intention of notifying the component to perform certain biome specific logic.

Material Parameter Collections #

MPC_Player_WeatherAttributes consists of parameters with the intention of being associated to the player. These parameters should change functionality related to the player.

MPC_WeatherEffects consists of parameters with the intention of changing functionality affected by the biome properties(clouds, snow, biome temperature etc).

MPC_WeatherLensEffects consists of parameters with the intention of changing post process functionality for the player( frost on the lens or rain on the lens or etc).

Temperature management #

Temperature management is super important for a system like this. We have extremely advanced control over it.

To make sure to handle each use case, this is our thinking process arround temperature managent:

Where is the temperature managed? #

Temperature is defined on multiple spots:

  • Time manager
    • For all biomes the same
    • Is a: Get base temperature function
  • Biome (due to local weather conditions)
    • For all actors in that biome the same (is basically the weather)
  • Local perspective e.g. player (near fire, inside, in water, etc)
    • Local perspective in UI for player
      • AC_LocalTemperature
        • Gets the biome and time

How we determine outside temperature #

Outside Temperature:

  • time manager (Get Gloal Temperature)
  • Season temperature is leading for a base temperature
    • Winter
      • -15 / 7
    • Spring
      • 10 /20
    • Summer
      • 20/45
    • Fall
      • 2-17
  • Time of day temperature is an offset on the base
    • Morning
      • -7 / -3
    • Afternoon
      • -2 / 2
    • Evening
      • -6 / -2
    • Night
      • -12 / -6
  • Weather Type Temperature is an extra offset on the base
    • DA_Blizzard
    • DA_Cloudy
    • DA_Foggy
    • DA_HailStorm
    • DA_LightRain
    • DA_Overcast
    • DA_PartlyCloudy
    • DA_Rainy
    • DA_SandStorm
    • DA_Snowy
    • DA_Clear
    • DA_Thunderstorm
    • DA_ThunderstormWithRain
    • DA_Windy

Temperature update logic #

Logic:

We want to update a function always when this happens:

  • On Time of day changed
  • On Weather type changed
  • On Season changed

The function:

Calclute local Temperature (on player controller)

  • Initially we cache the season, time of day and weather temp.
    • All of these are cached seperately
  • When we call this function, we need to provide: What is changed? (enum)
    • E.g. Season, time of day, or weather chancged.
    • Based on this, we only calculate a new value for only that specific type, the other base values remain the same. And we assume it is only called once at the time.
  • Get Season
    • Get Season Temperature (random value in range)
  • Get Time of Day
    • Temperature (random value in range)
  • Get Weather
    • Temperature (random value in range)
  • Combine them and return value and set it and call event dispatcher On temp changed

Make a temperature component which gets time manager, and potentially a biome to calculate final temperature. This one should also check for control areas (inside) and near fire.

For Biomes:

  • Biome Weather Transitions
    • Make the probability a MAP to season so we can define it per season. If none selected, just a default value

Temperature screen effects #

Screen effects

  • Event dispatcher listening in attribute manager and swithc state effects (wet, hot etc)
    • All logic in attribute manager
  • Bind on in control area
    • Check if state effect should be removed or not

Temperature use cases we considered: #

  • Is in control area, how to handle temp? Should control area hold temp data? Yes
  • Near fire etc? How to handle?
  • Control area and near fires etc are an override.
    • Possible lerp to final amount
  • How to hanlde building structure?

Ideas we considered and implemented:

  • Line trace upwards to see if we see a roof (whatever roof is), e.g. under a rock? Sure!
  • We need a combi of a line trace and a cxontrol area overlap
    • Line trace:
      • Always, but check if we find buildable (for custom structures)
    • In control area overlap
      • We assume that all predefined buildings, we can manually place a control area box. So there, we do not need a line trace but we still do it tough
    • Oth cases:
      • On true? In control area or buildable above you
        • Get info from control area
          • Predefined control area > read out component or info from data asset
          • Builldable? > Read out a default value for a data asset
        • But what is we have a fire inside?
          • Stack? Override?
    • Fire outside?
      • Fire outside should have a control area component assigned
  • DataAsset of control area
      • Min and max temp in this control area regardless of the offset
      • Base temperature
        • (this is the temperature that we see as where a temp settles in general. E.g. 20 degress.
      • Offset value
        • How much does it basically offset based on outside. Negative or positive value.
          • E.g. It is -50 outside
            • Min value is 5 and max is 35
            • Base is 20
            • Offset is 10
            • This means that we do -50 plus 10 = -40 =< 5- > thefore 5
            • Since the value didn’t go from one side of the base value to the other, we don’t account for it
          • it is 35 degrees outside
            • Min value is 5 and max is 35
            • Offset is 10 (offset is negative when it is above 20 degrees, and positive if it is lower than 20.
            • 35
          • It is 25 degrees outside
            • Min value is 5 and max is 35
            • Base value is 20
            • Offset is 10
            • If we use the offset:
              • 25-10=15 degrees
              • Here we went over the base value, and since we don’t want that we want to make it go to 20
              • The calculation for that is:
                • Actual offset = max(abs(current temp-base temp), offset) * current temp > base : -1 ? 1
What are your Feelings