While developing my volumetric cloud shader I came across the need for various noise patterns of specific types and qualities. There are a few good ones inside of the Volumetrics official plugin for unreal, but instead of using these I thought it could be fun to create my own.

Before this, I was generating cloud textures from shader parameters at runtime, but this was expensive and made it hard to see what was going on within the texture itself. It resulted in a lot of trial and error, changing the noise generation parameters to get a good final look. It’s definitely more effective to just sample texture assets.

I set out to create a tool for unreal engine that would allow the user to create various noise textures, both as 2d and 3d texture assets. This would allow me to experiment with different noise parameters, resolutions and types to refine the look of my volumetric clouds. Because I was working with clouds, I initially wanted three noise types, Perlin, Worley and a combination of the two Perlin-Worley noise. I created a blueprint library in C++ that contained functions for generating tileable perlin and worley noise, then played around with different methods of combining these noise patterns to try and get results that mirrored the noise used in Horizon: Zero Dawn’s cloud rendering noise, based on a GDC cloud rendering talk I had seen. In the end I found good results from multiplying an inverted perlin noise over a worley noise pattern, and playing around with a clamp on the values of the perlin noise. This created a texture that resembled the head of a cauliflower which is ideal for use on those puffy Cumulonimbus clouds.

I added the ability for the user to get each channel of a texture to a different noise pattern. This meant that I could use one 3d texture for all of the cloud generation setup. Following the Horizon: Zero Dawn method, I set up the texture’s red, green and blue channels to have perlin-worley noise of increasing frequency. This would be layered like a FDM texture in the cloud shader. In the textures alpha channel I have a perlin noise, which can be used for general cloud placement. Next I made a 2d RGB texture of low resolution perlin-worley noise of increasing frequency to use for cloud edge erosion.

To make the tool more user friendly, I created an editor widget that houses all the settings for the texture. The user can set how many channels are active, and the specific noise pattern for each channel. Maybe in the future I’ll include a preview, but for now I just have a button that runs the generation and saves it to a texture asset within the project, at a location the user can set. I also included a warning to tell the user when their resolution or frequency settings would result in a texture that wouldn’t correctly tile.

A small but useful tool that saves me having to open Houdini by being able to generate the noise in the engine.

The final output of the generator

This is the big one, this project is my first attempt at creating custom low level shaders in Unreal Engine. After tinkering with volumetric rendering within Unreal for quite awhile, I could never get it to do what I wanted it to do. It was built to create clouds that can look good at a distance, and to be versatile. I wanted clouds that exist in the world in 3d space and can be flown through without a significant drop in quality for a flight simulator. Ultimately I wanted more control over how clouds and weather were created and rendered.

Initially I toyed around with the different built in volumetric tools. I created a concept where each cloud would be a Niagara system displaying a volumetric material as well as a volumetric mesh setup. While these could have worked I quickly realised that they would be impractical for scaling to a large 1000km2 world which I wanted. The solution was to create my own system and code a HLSL shader.

The goal for the projects was to create a plugin that allowed for the creation and rendering of clouds across massive worlds. Firstly I set some outlining goals: The clouds would be rendered using common cloud raymarching techniques. I had a good understanding of these methods already from my previous work in the default shader and there are many great papers and talks from AAA developers about this topic. The renderer should have a smart system of knowing where clouds are not to speed up rendering. In the default shader, every pixel of the screen that intersects the minimum distance above the level runs the raymarching shader. There is a conservative density pass that you can first run your cheap calculations through. But ultimately I was limited by the material editor on how cheap you could get this pass. Working from the ground up would enable cheaper early exits for the shader. The system would need to work on large worlds, with potentially thousands of clouds. The old system I built created a weather map in a render target that decided where clouds were. The resolution of this render target limited the detail of the clouds and how big of an area the weather map could cover before repeating. Plus the weather map material created its own GPU costs. This was not necessarily scalable to large worlds. Next the system would work with multiplayer and can be replicated. Because by default the clouds are entirely material based the server would have no idea where clouds were. Lastly the CPU would have data on cloud position, density, etc for use with AI and replication verification.

Basic Rendering Setup

These are a set of tough goals so I started with the basics, just getting a handle on creating a custom HLSL shader and creating a custom render pass.

After spending far too long reading the source code of the built in cloud shader I decided on a rendering architecture. Without modifying the engine code you are limited with where you can place a custom render pass. The options are basically before the main pass, after the main pass, at the start of the postprocessing, or after postprocessing. You may also place passes at specific points within the postprocessing pass. I broke the cloud shader up into two parts. One would conduct the ray marching and output that to a render target. This would then be held until a point in the post processing pass where it would be composited into the scene colour, depth, or wherever else it was required. I ran into a couple problems with the composite pass occurring after the screen had been scaled when screen percentage scaling was enabled. Most of the time in game the screen percentage is 100% so no scaling is required but often in the editor, the viewport is rendered at a smaller resolution then during or after post processing it is scaled to the final resolution. To support this feature I needed to be careful to work in buffer space, not viewport space, as viewport space is the final upscaled resolution, not the size of the rendertarget. Also the composite pass would need to happen before any upscaling in the postprocess step.

This method also allowed me to easily render the raymarch pass at a lower resolution to save on performance, then scale it to full resolution in the composite pass. Currently I’m rendering the cloud image at half the resolution of the buffer, meaning it runs roughly 4x as fast, at the cost of some quality.

I created a ViewExtention and other support classes, and set up the two pixel shaders as well as a fullscreen triangle vertex shader to apply the pixel shaders to. There is a built-in fullscreen triangle shader, but I implemented my own for maxim control.

For initial testing I just wanted the shader to conduct a trace from each pixel in the correct direction. To display this I have the shader return the colour red, if the trace intersects a sphere at absolute world position 0,0,0. One major change from previous versions of unreal is the use of the LWC (Large World Coordinates) system within rendering. This uses double floats for extra precision to handle large worlds. Also the idea of Absolute world space vs translated world space. To prevent floating point error, world positions would be dealt with in Translated world space, that is world space relative to the camera. This was written to two render targets, one for colour and one for depth. These were then passed to the composite shader.

The composite shader does a depth aware bilinear upscale to match the cloud render target resolution with the overall buffer resolution, then adds the cloud colour to the scene at the beginning of postprocessing.

Overall the rendering architecture is as follows: UAdvancedCloudRenderingSubsystem adds and manages the FCloudRenderingSceneExtention. The scene extension handles gathering data from the CPU and passing it to the GPU shaders. After the main pass the cloud pass is run to fill out the cloud render targets. Then at the beginning of postprocessing the clouds are composited into the scene.

Red ball composited into the scene by the cloud shader

Cloud and Weather system

The next step in the process is to set up a system that feeds cloud data into the shader. It will need to tell the shader in which areas to run a raymarch to create clouds. The built in cloud shader uses a planet sized sphere intersection to tell the shader where to run. I wanted to create a different system that instead only ran the shader in areas of the sky where clouds actually were. In addition to this, the system should allow for the creation of clouds to be done on and managed by the CPU. This way would simplify the creation and replication of weather as well as allowing AI to utilize cloud data.

My first attempt was to create a cloud manager actor, ACloudManager. This would store an array of FCloudInstance, a struct which contained all the data about a specific cloud such as position, size, cloud type, etc. This array would then be converted into a GPU Buffer and uploaded to the GPU for use in the shader. I created a child of this class that managed streaming of clouds close to the player camera, uploading only nearby clouds to the buffer.

This system worked well, but presented a few issues that would impact performance. Firstly each ray in the shader needed to check for intersections with every cloud instance in the buffer. The performance impact of this would be huge when the system was scaled to thousands of clouds. I’m sure there is a mathematical way of optimizing such a loop but I already had a better idea for FCloudInstance storage.

intital cloud tests using actor volumes

The Cloud Grid system

Instead of storing the cloud instances with an actor, I wanted to store them within a WorldSubsystem. This subsystem would divide the world space into chunks, then those chunks into cells. Each cell would store a reference to the index of what cloud instance bounds intersect that cell. A chunk would only have cells that contained at least one cloud.

Chunks could easily be streamed and their positions rebased based on player view, allowing for easy compatibility with extremely large worlds. And ray interaction over each cell can be optimized with a Digital Differential Analyzer Algorithm (DDA). This would skip empty space and allow for 1000s of cloud instances. Further the chunks could be used for wind simulation or other effects later on.

A downside of this would be that the subsystem itself shouldn’t replicate. Instead a deterministic procedural weather system should feed into the grid system, with this weather system handling replication. Another downside is an increased use of GPU memory, but an extra mb or two is trivial compared to the 3d noise textures used to render the clouds, so I wasn’t too worried.

When updating the grid GPU buffers I was careful to batch updates and perform them incrementally to prevent hitches, this would allow for FCloudInstances to move in the wind or change shape over time. A future feature would be that cloud movement is computed each frame without change to the buffer by using a wind vector and elapsed time. The buffer would be periodically updated and the cloud position would be checked against this and resynced if necessary. For now if clouds move, there is a semi-noticeable jump as the buffer updates are not performed each frame.

This grid system ended up being way bigger than I thought it would be, but nothing overly complex had to be done to have it work. The system, while hard to visualize in the editor because of its scale, is simple to understand. Alongside implementing the grid system I added custom logging categories, a cheat manager for console commands and a cloud actor that creates a cloud instance for easy debugging.

Cloud grid debug visuals

Next Steps

Next I’ll work on integrating the grid system into the shader and actually rendering some clouds! This will include working with the built in lighting and atmosphere systems to light and create shadows for the clouds.

In this project, I expanded upon Unreal Engine’s default volumetric cloud system to create a custom volumetric cloud material and a dynamic weather system driven by data assets.

Dissatisfied with the limitations of the default cloud settings, I designed a new material to intergate into the unreal volumetric cloud system from scratch, gaining some experience in volumetric rendering, ray casting, and ray marching, as well as optimizing performance for real-time applications.

Key features and innovations of the project include:

Custom Cloud Material: Developed using Unreal’s Material Graph, incorporating 3D textures for volumetric noise and using graph assets to control cloud shapes. This allows artists to modify cloud appearance easily without directly adjusting low-level material parameters.

Dynamic Weather System: Driven by data assets that define cloud coverage, type, rain level, and other weather parameters. The system smoothly blends between weather states during runtime using render targets to generate masks that control transitions across the game world.

Realistic Visuals: Experimented with cloud shapes, density, and lighting effects, drawing inspiration from real-world how other games achieve realistic skies.

I designed the system to be efficient and scalable, with minimal performance impact on gameplay. The cost of the dynamic weather system depends on how much of the screen contains clouds:

Dynamic weather system: ~0.5 ms mostly because of the large render targets.

Volumetric clouds: ~4 ms on average, settings tweaks can lower this at the cost of looks.

While there is still room for optimization, it’s always a balance between beauty and speed and for this project I wanted beauty.

Through this project, I developed a good understanding of volumetric shaders, GPU-efficient rendering techniques, and complex material workflows within Unreal Engine. Additionally, I gained practical experience in creating artist-friendly, scaleable systems for procedural and data-driven environments. Next project is to write a volumetric shader in UE5 from scratch.

For this project, I developed a day-night cycle subsystem in Unreal Engine that accurately simulates the positions of the sun and moon based on real-world data. Written in C++, the system allows users to set a local time as well as latitude and longitude, and the subsystem calculates and displays the correct positions and paths of the sun and moon across the sky throughout the day. I implemented my system from scratch not realising that there is already a plugin that contains many of the calculation functions.

This project required a decent understanding of Unreal Engine’s dynamic lighting system, atmosphere setup, and interaction with material systems. I also created a complex sky sphere material, extending the one included in the Sun position calculator plugin. The material includes:

Correct mapping of the lunar surface from a flat texture, I set it up to allow for rotation of the moon but our moon is tidally locked.

Moon terminator effect for realistic daytime shading on the moon.

Accurate moon phases that dynamically change the intensity and distribution of moonlight.

The system integrates with Unreal’s lighting pipeline to ensure that both directional light (sun and moon) and atmospheric effects blend and respond correctly to changes in time and location. This project taught me a lot about dynamic lighting, atmosphere rendering, and material-driven environmental effects in Unreal, as well as how to combine mathematical astronomical calculations with game engine visual systems.

For this project, I developed a comprehensive career generator for IL-2 Sturmovik: Battle of Stalingrad, called Crosswind. The program would run separately to the flight simulator but would have access to the game files. It would allow players to create a pilot in a specific squadron and experience the campaigns featured in the game, aligned with historical developments, frontline movements, and key battles.

The program simulates multiple squadrons operating in a theater, tracking each pilot’s progress and automatically generating missions as the player advances through the campaign day by day. When a player is assigned a mission, the program creates a corresponding mission file that can be played directly in IL-2. After completing the mission, the program parses the game logs to determine the outcome, updating the player’s statistics and the performance of all AI pilots involved. AI pilots would be assigned to squadrons and their experience would be translated into their in game skill. Pilots would increase in skill after successful missions. Aircraft damage, pilot injury and loss were all tracked.

To enhance the user experience, the program uses Vulkan to render images of aircraft, squadrons, and frontlines. This provides a fast, hardware-accelerated visual representation of the simulated world, allowing players to quickly understand squadron positions, mission targets, and campaign progress at a glance. The Vulkan integration required careful management of GPU resources and real-time rendering pipelines while keeping the UI responsive and clean.

This was my first attempt at developing a large-scale Windows application. I placed strong emphasis on designing a clean and intuitive user interface, making it easy for users to interact with complex systems. The program is written in C++ and leverages XML files for all data storage, ensuring that new squadrons, missions, and pilots can be easily added or modified. The project did become cumbersome and somewhat hard to manage. I also found that programming standards mistakes that I had made earlier in the project eventually came around to bite me.

Through this project, I gained significant experience in planning and structuring a large software project, emphasizing maintainable code, modular architecture, and data-driven design. It was a valuable exercise in balancing simulation complexity with usability and in understanding the workflow of integrating an external game with a custom management tool.

The program did end up making me realise just how old and limited IL-2 is, it’s hard to have complex and intresting missions. Maybe I’ll have to make my own flight simulator at some point.