In Far Cry 6, players are introduced to Yara, a fictional Caribbean Island. In order to incorporate a tropical island experience to the open world, we needed something that would be new to Far Cry – a complete and dynamic weather system.
Inspiration The landscape and weather of Yara was inspired by Cuba and other tropical locations. After early research was conducted, it became apparent that Far Cry 6 would need to showcase sunny weather, fog, storms, and everything in between. During storms, players should feel fully immersed in the fantasy as they experience the wetness and booming thunder around them.
The goals for our system were to have dynamically changing weather states, natural transitions that emulate reality, and solutions that fit within our budgets. The open-world aspect of Far Cry 6 heavily influenced the decisions that were made due to the need to support all times of day and all locations.
Core Controls The weather manager is the core code for our weather system. It contains information used to define and control weather, some of which is exposed as settings in our weather database.
The first step was to create weather building blocks, otherwise known as presets. These are weather types such as “Broken Clouds” and “Thunderstorm”, all of which are defined in the weather database. Next, a weather forecast was required. We used a text file where every hour was assigned a weather preset. This method allowed us to fully art-direct the weather with up to 5 full day cycles per region. The next step in the system involved regions. Yara itself is split into three regions, each with a distinct visual identity. Smaller sub-regions could also be defined by artists, such as for caves and interiors.
For every region, our weather manager exposed min and max curves in the database for a few of the weather parameters, allowing the weather to be dynamically modified as the player moved around. At this point, our weather manager allowed for overrides, such as for gameplay missions and pre-rendered cutscenes. Weather also needed to be specially replicated for players in multi-player co-op.
Material Wetness Wetness is an essential component of weather, as the world should visually change when it rains. As such, every asset needs a wet state, which could lead to a couple risks, such as increased production time and lack of cohesion.
Ultimately, the chosen solution was to work in parallel with asset creation and have wetness be tech-art driven. Wetness should work ‘out of the box’ and support wetness by default. The final implementation was split according to two wetness types: Static and Dynamic.
Static wetness applies to our Object Bank assets which includes props and structures. Their wetness level was affected by a wetness shadow map, which masked out wetness when objects were occluded, such as by a balcony or when indoors. This allowed level artists to freely reuse assets in the world.
Dynamic wetness is reserved primarily for weapons, vehicles, and characters. Their wetness level is calculated by ray casts to detect rain exposure and includes local wetness which handles submersion in water. For dynamic wetness, wetness is applied in each shader, allowing for full customization. We used dynamic wetness for things like vegetation and terrain.
Terrain wetness is not complete however without the addition of puddles. A puddle itself was a terrain decal, which contained an alpha gradient and wrote to terrain porosity. The gradient served as a pseudo signed distance field, allowing puddles to build from the center. These decals were scattered by our terrain and road recipe systems. In addition to these puddles were puddle effects in the form of procedural simulations for rain and wind ripples on the surface of the puddles.
With the art pipeline for wetness, the thing that really drove our success was limiting complexity, studying references, reducing production dependencies wherever possible, and identifying the biggest wins so that we could focus on what ‘sells’ the weather the most.
Rendering Features There were several rendering features needed to complete the depiction of our weather states such as atmospheric scattering, volumetric clouds, volumetric fog, GPU particles, ocean rendering and tree bending. The complexity of delivering dynamic weather was not just developing the features themselves, but the many interlocking parts which needed to be polished both separately and together.
We used physically based formulas and aim to be energy conserving as a goal. We have a global illumination system employing probes. These probes contain data for different time of day increments, but that data doesn’t include any weather. To counter this, we fade out indirect lighting when cloud coverage is high. We also created look up tables for humidity and turbidity ranges which we interpolate between to simulate our atmospheric scattering with the Bruneton sky model and Preetham sun model.
We created volumetric clouds so that our clouds would look better in motion and smoothly blend between different weather states. These clouds then need to be incorporated into our cubemap relighting system which aims to reflect time of day changes, weather, and clouds in the reflections on surfaces that are either shiny or wet.
We encountered many problems attributed the interaction of separate systems that needed creative solutions. One common problem was overcast lighting and weather where the image wasn’t dark enough and could appear flat. This could happen because of fog washing out the image which we fixed by fading the fog based on cloud coverage. This could also happen if clouds were of uniform thickness, which is why we limit coverage even during a storm. And lastly, this could happen if authored skies for atmospheric scattering were too turbid and grey. If you want blue skies breaking through your clouds, it comes from the atmospheric scattering.