Overview
Midway in my schedule, a little WIP is in order. This blog contains the pre-product
As a reminder, my part in this project consists of implementing a dynamic, portable, adaptable, optimized and coherent Daytime and Weather cycle in any given environment. In this case, my colleagues (3xLA, 1xLD, 1xChar, 1xAnim) chose to work on a Rural autumnal Northern Hardwood / Boreal Forest Post-Apocalypse / Fantastic AAA next-gen environment... Quite a challenge!
Other notable big features and technical challenges are:
- New engine (UE4)
- Speed Tree for large plants and trees
- Pivot painter vertex deformation for smaller plants
- Use of DX11 light propagation volumes (LPV)
- Use of DX11 distance field ambient occlusion (DFAO) (unstable...)
ion documentation and methodologies , the elements completed so far, the encountered problems / solutions, what is left To Do, and References. I'm probably going into too much details for some people's taste but I figured it would be a starting point for someone wishing to do a similar system and help him figure out if it would take too much time. Consider this Blog as an Article/Tutorial instead.As a reminder, my part in this project consists of implementing a dynamic, portable, adaptable, optimized and coherent Daytime and Weather cycle in any given environment. In this case, my colleagues (3xLA, 1xLD, 1xChar, 1xAnim) chose to work on a Rural autumnal Northern Hardwood / Boreal Forest Post-Apocalypse / Fantastic AAA next-gen environment... Quite a challenge!
Other notable big features and technical challenges are:
- New engine (UE4)
- Speed Tree for large plants and trees
- Pivot painter vertex deformation for smaller plants
- Use of DX11 light propagation volumes (LPV)
- Use of DX11 distance field ambient occlusion (DFAO) (unstable...)
Methodology & scoping
Doing a Daytime cycle is in itself a big enough challenge already. In order to know if adding a WeatherCycle on top of that would be shooting myself in the foot given the 4 months of school production time available, doing a lot of preemptive research and digging was imperative.
The first place I went to took for was Sebastien Lagarde's website input on his complete water observations applied to video games. I quickly realized the complexity of reproducing rainny nature and started dressing a long list (not shown) of all the elements, options, criteria, implications I could think of related to rain/wetness of a rural forest environment. I then did the same for day/time cycles watching some dynamic environment's time lapses real / in-game. This helped me establish 6 main features to help categorize tasks together:
The first place I went to took for was Sebastien Lagarde's website input on his complete water observations applied to video games. I quickly realized the complexity of reproducing rainny nature and started dressing a long list (not shown) of all the elements, options, criteria, implications I could think of related to rain/wetness of a rural forest environment. I then did the same for day/time cycles watching some dynamic environment's time lapses real / in-game. This helped me establish 6 main features to help categorize tasks together:
- Rain FX
- Daytime
- Enviro
- Shading
- Code
- Audio
Completed elements
If you don't want to read:
- Master shaders (Main,Color,Detail,Fuzzy,SpeedTree,Vertex,Wet ctrls, Landscape, Particles, Skydome)
- Rain (Slash, drops, haze)
- Wetness (Objs/Terrain)
- Clouds (procedural)
- Day/Night Cycle (lighting/colors transit)
- Post/Process WIP (Basic PP volume, LUT color correct, Skylight shader)
- Wind (Clouds dir, LightFn Dir*, WPO dir, Rain/Haze Dir)
- Fog (Height Fog, Atm Fog)
- Audio (Ambience / Thunder system basics)
- Master shaders (Main,Color,Detail,Fuzzy,SpeedTree,Vertex,Wet ctrls, Landscape, Particles, Skydome)
- Rain (Slash, drops, haze)
- Wetness (Objs/Terrain)
- Clouds (procedural)
- Day/Night Cycle (lighting/colors transit)
- Post/Process WIP (Basic PP volume, LUT color correct, Skylight shader)
- Wind (Clouds dir, LightFn Dir*, WPO dir, Rain/Haze Dir)
- Fog (Height Fog, Atm Fog)
- Audio (Ambience / Thunder system basics)
-DayNight Cycle- (0..1)
I was totally amazed when I started observing how other games do it:
GTAV - VIDEO
When the sun sets past the horizon, the sun light shuts down, instantly teleports 180' to the moon location, and is turned back On, revealing a (HDR eye adjusted or boosted) skylight trying to light the whole environment during the short surgery.
Far Cry 3 - VIDEO
Does the same thing as GTAV but actually only for the sun/moon disk and flare. The actual light orientation never reaches a completely flat angle relative to the horizon. I presume this helps avoid washing the whole scene in shadow during sun/moon set/rises and thus keeps a rather nice light composition and retains object volumes throughout the 24h cycle.
Assassins Creed 4: BlackFlag - VIDEO
Does not even teleport the sun to the moon... the moon IS the sun (or is it backwards?). Anyways, the sun light basically makes a 360' turn around the map and only approaches the horizon for 1/4 of the 24h cycle to swap back and forth to night time. Its light does not even shut down, does not produce flat washed out shadows (same sun disk/light orientation disparity technique as Far Cry 3) and suggests a completely unrealistic planetary sky travel that's not even cosmologicaly possible. But no one cares because no one noticed, so win-win right?
I opted for the GTAV method. Wanted to avoid separating the sun representation from the actual light at the cost of washing out shadows at sun set/rise. This adds more realism & some excitement upon teleporting a star around our planet :)
To start off, I did not use the SkySphere blueprint (BP) that Epic offers because it is incomplete for night time, is not ready for a weather system and I would like to learn how to do such a system under only a single actor blueprint. So one blueprint to rule them all... (is that a bad movie quote joke?) To keep it simple, 0 = sun rise, 0.5 = sun set so 0..0.5 = daytime and rest is night time. 0..1 values are easy to manage so I used that advantage in the shading of the skySphere and math gradients in blueprints used as masks for the color / intensities transitions.
I was totally amazed when I started observing how other games do it:
- Some clouds move, are particles, are static textures, are procedural, react to sun light orientation or some don't.
- Shadows turn off or not (in reality its the light), cloud shadows appear, they flatten at sun set or don't.
- Colors of fogs, atmosphere, SunLight, light-shafts, post-process, skydome, skylight, water, particles, cube-maps change depending on daytime or weather conditions.
- Day to/from night transitions seemed to be a nice problematic to avoid having more than 1 directional light casting whole scene dynamic shadows and transferring all related properties connections (especially to atmospheric fog which can only take 1 light at instancing).
GTAV - VIDEO
When the sun sets past the horizon, the sun light shuts down, instantly teleports 180' to the moon location, and is turned back On, revealing a (HDR eye adjusted or boosted) skylight trying to light the whole environment during the short surgery.
Far Cry 3 - VIDEO
Does the same thing as GTAV but actually only for the sun/moon disk and flare. The actual light orientation never reaches a completely flat angle relative to the horizon. I presume this helps avoid washing the whole scene in shadow during sun/moon set/rises and thus keeps a rather nice light composition and retains object volumes throughout the 24h cycle.
Assassins Creed 4: BlackFlag - VIDEO
Does not even teleport the sun to the moon... the moon IS the sun (or is it backwards?). Anyways, the sun light basically makes a 360' turn around the map and only approaches the horizon for 1/4 of the 24h cycle to swap back and forth to night time. Its light does not even shut down, does not produce flat washed out shadows (same sun disk/light orientation disparity technique as Far Cry 3) and suggests a completely unrealistic planetary sky travel that's not even cosmologicaly possible. But no one cares because no one noticed, so win-win right?
I opted for the GTAV method. Wanted to avoid separating the sun representation from the actual light at the cost of washing out shadows at sun set/rise. This adds more realism & some excitement upon teleporting a star around our planet :)
To start off, I did not use the SkySphere blueprint (BP) that Epic offers because it is incomplete for night time, is not ready for a weather system and I would like to learn how to do such a system under only a single actor blueprint. So one blueprint to rule them all... (is that a bad movie quote joke?) To keep it simple, 0 = sun rise, 0.5 = sun set so 0..0.5 = daytime and rest is night time. 0..1 values are easy to manage so I used that advantage in the shading of the skySphere and math gradients in blueprints used as masks for the color / intensities transitions.
In most dynamic day time games out there, when a mission starts, the time and weather always adjust to a new setting. This allows a proper level art composition and lighting along the player's mission path. Just like rigging for animation, such a system thus requires both automated and manual control. Whether it be for missions, level design requiring triggerable daytime/weather events or manual command. You don't want to show off your level art at a night time to you artistic or creative director when its supposed to be at noon because you don't have control! Coupled with a time rate control letting the player continue moving while the sun/weather adjusts to a new position adds a lot of challenges. The main one being the consistency of time rate behavior across a very large range (0.001x to 100x). Those systems are now implemented.
For the lighting, I'm using a combination a movable directional light (injected in a light propagation volume providing dynamic global illumination), a movable skylight (signed distance field ambient occlusion sadly is too unstable with moving trees), and an ambient cube map that will be ported to a post-process material later on.
Bellow are some screenshots showing daytime progress. The transition is rather smooth, colors blend well and night time uses the same light as in day time. Works in-game and in editor. Trickery achieved!
For the lighting, I'm using a combination a movable directional light (injected in a light propagation volume providing dynamic global illumination), a movable skylight (signed distance field ambient occlusion sadly is too unstable with moving trees), and an ambient cube map that will be ported to a post-process material later on.
Bellow are some screenshots showing daytime progress. The transition is rather smooth, colors blend well and night time uses the same light as in day time. Works in-game and in editor. Trickery achieved!
-Weather Control- (0..2)
The approach I ultimately used to reduce the amount of public parameter controls for the weather was to include both the rain and cloud cover under one parameter. 0..1 controls cloud cover and 1..2 controls the rain amount. Under the hood, cloud cover stays and 1..0 and rain amout at 0..1 also. There is also a wind strength 0..1 param. So we presuppose that it will never rain under partial cloud cover unless clouds pile in slower than rain amount increases and that they recess faster than rain amount decreases. This interpolation dependence between values has to be carefully monitored to account for that kind of exception.
The controls are a target for the real values to interpolate to over time (in-game) while still allowing direct preview (in editor). So if I hit a trigger in-game asking 2.0 of weather amount, it will interpolate the real weather amount from 0..2 in a couple of seconds. When real weather changes rain amount, the real rain amount lags behind and in turn sets the target of the accumulation rate of the wet amount for wet-able shaders.
That kind of dependency creates a lot of potential bugs that have to be fixed... and fast! So, I had to design twice all sub systems in parallel in order to have a real time in-game version and a static manually tweakable in-editor version to debug and iterate faster. This would also allow the artists to place their assets in the time and weather that they want for their environment in 1 or 2 clicks.
For the clouds, I tackled the procedural approach first because I knew it would be the one causing the most problems. Using a spherical / planar hybrid skySphere geometry, I was able to easily overcome the cloud panning,direction, masking, instruction count and fog problems . The rest is a bunch of noise function magic in the shader. It still needs to have an orange tint during sun set/rise and only when cloud cover is not 100%. The static cloud textures will be generated in Vue from the LA team.
For thunder, it only happens under 100% cloud cover and over 75% rain amount. Since you are implicitly guaranteed to have the sun turned off at this point, why not use it to cast the light/shadows produced by the thunder flash? So when a flash occurs, override the sunLight orientation so that it always points from the flash to the player (making sure the daytime doesn't affect its colors and atmospheric fog, etc). Plug in the sounds with a random delay, make it work in-game / editor and done!
For the rain, GPU emitters are used for the rain drops, CPU for splashes and haze. I chose to pre-place the emitters in the level (no following the player) and turn them on from blueprint (FX LODs are not supported on GPU). I knew overdraw would be a problem to simulate rain haze during heavy rain. So, since many GPU particles are visible, I used a panning volumetric noise mask on the rain drop opacity to simulate macro variations in rain density. Since rain drops are so small, very small amount of overdraw occurs and thus more pixel instructions would not hurt too much. Coupled with a resulting smaller need of CPU rain haze particles (HUGE overdraw) to achieve the same sensation, I think its the best of both worlds.
To sum up what's implemented :
Cloud Cover - changes light function shadows, skyLight / sunLight from 0.75..1, post reflections, procedual clouds contrast
Rain Amount - affects wet amount accumulation / dry off, fog density, FXs, sounds, skyLight, post reflections
Wet Amount - affects shading on all materials, affects fog density until under 0.5 (air moisture)
Wind Amount - affects SpeedTree(currently a bug) & grass, rain angle, rain haze speed, sound
Wind Direction - omitted for simplicity's sake for now
The approach I ultimately used to reduce the amount of public parameter controls for the weather was to include both the rain and cloud cover under one parameter. 0..1 controls cloud cover and 1..2 controls the rain amount. Under the hood, cloud cover stays and 1..0 and rain amout at 0..1 also. There is also a wind strength 0..1 param. So we presuppose that it will never rain under partial cloud cover unless clouds pile in slower than rain amount increases and that they recess faster than rain amount decreases. This interpolation dependence between values has to be carefully monitored to account for that kind of exception.
The controls are a target for the real values to interpolate to over time (in-game) while still allowing direct preview (in editor). So if I hit a trigger in-game asking 2.0 of weather amount, it will interpolate the real weather amount from 0..2 in a couple of seconds. When real weather changes rain amount, the real rain amount lags behind and in turn sets the target of the accumulation rate of the wet amount for wet-able shaders.
That kind of dependency creates a lot of potential bugs that have to be fixed... and fast! So, I had to design twice all sub systems in parallel in order to have a real time in-game version and a static manually tweakable in-editor version to debug and iterate faster. This would also allow the artists to place their assets in the time and weather that they want for their environment in 1 or 2 clicks.
For the clouds, I tackled the procedural approach first because I knew it would be the one causing the most problems. Using a spherical / planar hybrid skySphere geometry, I was able to easily overcome the cloud panning,direction, masking, instruction count and fog problems . The rest is a bunch of noise function magic in the shader. It still needs to have an orange tint during sun set/rise and only when cloud cover is not 100%. The static cloud textures will be generated in Vue from the LA team.
For thunder, it only happens under 100% cloud cover and over 75% rain amount. Since you are implicitly guaranteed to have the sun turned off at this point, why not use it to cast the light/shadows produced by the thunder flash? So when a flash occurs, override the sunLight orientation so that it always points from the flash to the player (making sure the daytime doesn't affect its colors and atmospheric fog, etc). Plug in the sounds with a random delay, make it work in-game / editor and done!
For the rain, GPU emitters are used for the rain drops, CPU for splashes and haze. I chose to pre-place the emitters in the level (no following the player) and turn them on from blueprint (FX LODs are not supported on GPU). I knew overdraw would be a problem to simulate rain haze during heavy rain. So, since many GPU particles are visible, I used a panning volumetric noise mask on the rain drop opacity to simulate macro variations in rain density. Since rain drops are so small, very small amount of overdraw occurs and thus more pixel instructions would not hurt too much. Coupled with a resulting smaller need of CPU rain haze particles (HUGE overdraw) to achieve the same sensation, I think its the best of both worlds.
To sum up what's implemented :
Cloud Cover - changes light function shadows, skyLight / sunLight from 0.75..1, post reflections, procedual clouds contrast
Rain Amount - affects wet amount accumulation / dry off, fog density, FXs, sounds, skyLight, post reflections
Wet Amount - affects shading on all materials, affects fog density until under 0.5 (air moisture)
Wind Amount - affects SpeedTree(currently a bug) & grass, rain angle, rain haze speed, sound
Wind Direction - omitted for simplicity's sake for now
-Wetness Control-
The wetness control works well for both (and ALL) opaque/masked assets, speedTree assets and landscape, but only for non puddle-able & non water glide-able surfaces. Base roughness and metallic have a negligible effects for now but this will have to be worked on further. Especially far distanced objects and landscape seem very shiny when it should not be that apparent. Far away wet surfaces are only apparent for flat surfaces (micro = flat at a distance), otherwise, there is too much macro (macro = micro at a distance) variations in the surface to allow any kind of obvious reflections.
There is 3 levels of wet amount:
- Wet = darken albedo (only for non-metallic), lower roughness
- Damp = smoother normal, much lower roughness
- Soaked = flat normal if puddle, water glide if banked non-rough surface.
Puddle rain drops and ripples will be a nice challenge but Sebastien Lagarde's magic texture will probably give you an idea of how this will be tackled. Water gliding function is 90% done but a normal map vector calculation is doing something wrong. Projecting in world space a procedurally animated normal map on any object in any scale / rotation requires some forethought!
The wetness control works well for both (and ALL) opaque/masked assets, speedTree assets and landscape, but only for non puddle-able & non water glide-able surfaces. Base roughness and metallic have a negligible effects for now but this will have to be worked on further. Especially far distanced objects and landscape seem very shiny when it should not be that apparent. Far away wet surfaces are only apparent for flat surfaces (micro = flat at a distance), otherwise, there is too much macro (macro = micro at a distance) variations in the surface to allow any kind of obvious reflections.
There is 3 levels of wet amount:
- Wet = darken albedo (only for non-metallic), lower roughness
- Damp = smoother normal, much lower roughness
- Soaked = flat normal if puddle, water glide if banked non-rough surface.
Puddle rain drops and ripples will be a nice challenge but Sebastien Lagarde's magic texture will probably give you an idea of how this will be tackled. Water gliding function is 90% done but a normal map vector calculation is doing something wrong. Projecting in world space a procedurally animated normal map on any object in any scale / rotation requires some forethought!
-MasterShaders-
This was actually the first thing I did at the beginning of the production to get the artists to immediately plug the master shader on their blocked assets. All the functions were plugged and only needed to be filled later without touching the master. This would allow me to visualize shader progress globally on the wet system, grass and tree wind and other visual features later down the road and find out problems earlier. Using a bunch of work textures gathered over past projects, custom functions and high level abstraction of the master shader, I was able to have a modular design approach. This would hide unnecessary complexity, promote re-usability, allow smoother debugging and optimize operation count later down the road. Unreal Engine has a nice switch feature that allows you to disable unnecessary parts of the shader at the only cost of longer offline compile times.
[1] The object Master Shader (opaque & masked) has the following passes:
UVs - Texture/Color parameters - Material Vtx - Fuzzy - Wet Vtx - Reflection - Ambient Occlusion Vtx - Wind Vtx - Alpha
[2] The Sky Dome shader - generates the sun disk, texture/color blend, procedural clouds
[3] The Particles shader - allows 4 channels per texture, speed dependent opacity, depth bias or camera fade, UV atlas
[4] The Post-Process shader - only has a semi-functional replication of a dynamic post-process vol ambient CubeMap. As stated earlier in the DayTime cycle section, will be used to completely replace the skylight and ambient cube map.
[5] Eventually, a Character Skin shader will be created when I get them based on the master shader.
This was actually the first thing I did at the beginning of the production to get the artists to immediately plug the master shader on their blocked assets. All the functions were plugged and only needed to be filled later without touching the master. This would allow me to visualize shader progress globally on the wet system, grass and tree wind and other visual features later down the road and find out problems earlier. Using a bunch of work textures gathered over past projects, custom functions and high level abstraction of the master shader, I was able to have a modular design approach. This would hide unnecessary complexity, promote re-usability, allow smoother debugging and optimize operation count later down the road. Unreal Engine has a nice switch feature that allows you to disable unnecessary parts of the shader at the only cost of longer offline compile times.
[1] The object Master Shader (opaque & masked) has the following passes:
UVs - Texture/Color parameters - Material Vtx - Fuzzy - Wet Vtx - Reflection - Ambient Occlusion Vtx - Wind Vtx - Alpha
[2] The Sky Dome shader - generates the sun disk, texture/color blend, procedural clouds
[3] The Particles shader - allows 4 channels per texture, speed dependent opacity, depth bias or camera fade, UV atlas
[4] The Post-Process shader - only has a semi-functional replication of a dynamic post-process vol ambient CubeMap. As stated earlier in the DayTime cycle section, will be used to completely replace the skylight and ambient cube map.
[5] Eventually, a Character Skin shader will be created when I get them based on the master shader.
-Audio-
So far, the blending between ambient and rain works and thunder sounds burst at random intervals after a flash. The sound classes, mixes and blueprint setup are done. The reeverb volumes are yet to be placed in the level. This section is a low priority until the whole project is relatively completed. I don't want to count on the sounds to make this system look better than it is and become biased.
So far, the blending between ambient and rain works and thunder sounds burst at random intervals after a flash. The sound classes, mixes and blueprint setup are done. The reeverb volumes are yet to be placed in the level. This section is a low priority until the whole project is relatively completed. I don't want to count on the sounds to make this system look better than it is and become biased.
Problems encountered
SpeedTree
- Wind actor does not update from blueprint - Bug reported to Epic staff
- Replacing auto-generated instances with the new master shader with 3-4 LODs and different leaf types is tedious for LAs
- LODs are not easily controllable when used with foliage painting, will have to be very aggressive on them.
- Generates an incredible amount of overdraw!
Performances
- Foliage overdraw is a major problem. Not to forget that forward rendering is used on transparent objects, not deferred!
- Blueprint ops are very heavy. Need to update time dependent ops at each loop ending and not each frame ticks.
- Skylight updates stutter on each captures, requires transfer to custom post material and blend multiple offline cube maps.
Post-process in BP
- Epic will eventually solve this... patience!
Mysterious crash
- When playing in editor, at random, the Display Card on the computer would freeze and require a full reboot. Migrating the whole project to a new one solved the issue but the source was never narrowed down after 12 hours of troubleshooting.
Code Architecture
- The sheer complexity of mother nature and its replication in concept VS in practice proved (again) way more challenging than anticipated in order to keep a solid and optimized blueprint code structure. Since i'm going in head first in such a project, I'm accepting the fact that it's not going to be a perfect system and sometimes, a bit too sketchy. But if I had to do it again, the architecture and its pitfalls would be addressed way more in advance and seriously. In the meantime, I'm doing my best to stay disciplined in commenting and abstracting every sub-systems as much as possible and even maybe, overhaul the whole system later on. I though the code part would be 50% of the work but it ended up being more 80%.
Water Glide
- As stated earlier in the Wetness Control section, 3-4 days were spent on a feature that's more troublesome than its visual impact. I will give one more try / cheat on this feature when I get a chance to make it worthwhile.
Thunder
- Was relatively easy to do but it was very daring and long to reuse the sun light on this. Around 10 major parameters needed override to make this work. The sound system was a hassle as well. The only stop was if the detail was becoming too subtle to notice in order to move on.
GPU particles
- No LOD support, you have to do them by hand via blueprint
- Vector fields are nice but you can't animate them via Parameters... so forget wind dependent movement noise in rain.
- Wind actor does not update from blueprint - Bug reported to Epic staff
- Replacing auto-generated instances with the new master shader with 3-4 LODs and different leaf types is tedious for LAs
- LODs are not easily controllable when used with foliage painting, will have to be very aggressive on them.
- Generates an incredible amount of overdraw!
Performances
- Foliage overdraw is a major problem. Not to forget that forward rendering is used on transparent objects, not deferred!
- Blueprint ops are very heavy. Need to update time dependent ops at each loop ending and not each frame ticks.
- Skylight updates stutter on each captures, requires transfer to custom post material and blend multiple offline cube maps.
Post-process in BP
- Epic will eventually solve this... patience!
Mysterious crash
- When playing in editor, at random, the Display Card on the computer would freeze and require a full reboot. Migrating the whole project to a new one solved the issue but the source was never narrowed down after 12 hours of troubleshooting.
Code Architecture
- The sheer complexity of mother nature and its replication in concept VS in practice proved (again) way more challenging than anticipated in order to keep a solid and optimized blueprint code structure. Since i'm going in head first in such a project, I'm accepting the fact that it's not going to be a perfect system and sometimes, a bit too sketchy. But if I had to do it again, the architecture and its pitfalls would be addressed way more in advance and seriously. In the meantime, I'm doing my best to stay disciplined in commenting and abstracting every sub-systems as much as possible and even maybe, overhaul the whole system later on. I though the code part would be 50% of the work but it ended up being more 80%.
Water Glide
- As stated earlier in the Wetness Control section, 3-4 days were spent on a feature that's more troublesome than its visual impact. I will give one more try / cheat on this feature when I get a chance to make it worthwhile.
Thunder
- Was relatively easy to do but it was very daring and long to reuse the sun light on this. Around 10 major parameters needed override to make this work. The sound system was a hassle as well. The only stop was if the detail was becoming too subtle to notice in order to move on.
GPU particles
- No LOD support, you have to do them by hand via blueprint
- Vector fields are nice but you can't animate them via Parameters... so forget wind dependent movement noise in rain.
To do
- Water glide debug
- Camera Lens droplet
- Foot Splashes from character
- Static clouds plug (using Vue's renders from our Level Artists)
- General polish/improvement (colors, sounds, transit, cube blend, wetness,etc)
- Character skin shader
- Additional sounds
- Pivot painter shader implementation for small plants (grass)
- Performances!!!!!! (Will go through most of this VIDEO)
- [P4] Water streams / ponds, water falls (I don't have enough information if this will be needed for now)
- Camera Lens droplet
- Foot Splashes from character
- Static clouds plug (using Vue's renders from our Level Artists)
- General polish/improvement (colors, sounds, transit, cube blend, wetness,etc)
- Character skin shader
- Additional sounds
- Pivot painter shader implementation for small plants (grass)
- Performances!!!!!! (Will go through most of this VIDEO)
- [P4] Water streams / ponds, water falls (I don't have enough information if this will be needed for now)