This section describes the development of SWIFT, briefly explaining how each aspect of the platform was determined and created using UE features. Following this, a detailed explanation of how data are generated through the use of predetermined movie renders and graphical shaders. Finally, the proposed DL methods are presented.
3.1. SWIFT Development
To develop SWIFT, various IDEs (integrated development environments) were considered. Among these, Unity and Nvidia Omniverse are the best-known development tools. Unity is in a very similar state to UE, containing very well-written documentation and countless guides made by the community, but it lacks graphical technologies that are ready to use in UE and are critical for the development of SWIFT, such as Nanite and Lumen. On the other hand, Nvidia Omniverse lacks easy-to-use documentation and guides made by the community that are expected from other IDEs like UE and Unity, therefore requiring more time spent on learning the software. Nvidia Omniverse’s software is even more complicated; it requires an RTX graphics card and expensive proprietary hardware that many developers may not have for their projects, meaning that developing SWIFT in this restrictive IDE could well limit future development opportunities. Accordingly, UE was chosen to create, develop, and generate SWIFT. Developed by Epic Games, it was originally designed as a gaming engine and has quickly gained the support of scientific developers. UE has impressive graphical capabilities and technologies, facilitating easier and quicker development for SWIFT. This allows for a greater focus on developing the simulation while UE handles the graphical aspects of the dataset. UE is constantly being updated and upgraded with the industry’s best graphical simulation and gaming technologies, keeping it ahead of other IDEs in graphical performance. Therefore, it has a broad lifetime for the future, with plentiful support and maintenance from Epic Games.
SWIFT underwent development during versions 5.2 and 5.3 of UE. These versions are pivotal since PCG was introduced in version 5.2 and Nanite received significant updates in version 5.3, which now includes landscape support.
Nanite and Lumen, technologies crafted by Epic Games for UE, stand as important advancements in graphical processing. Nanite reduces process time for rendering geometries by virtualizing geometries; with this, it can dynamically change the resolution of triangles to better accommodate screen space. Lumen, on the other hand, acts as a light system; with a hybrid ray-tracing technology, it achieves indirect lighting and dynamic illumination with significant speed and light-processing demand. Temporal Super Resolution (TSR) is another graphical technology developed for UE version 5, enabling the use of heavy technologies such as Lumen. TSR is an antialiasing technology, which improves image resolution through the use of algorithms by rendering parts of the screen in extreme definition and then meshing them together to form a single image. By rendering small parts per frame, TSR significantly reduces the computational load of each frame, allowing the use of heavy features like Lumen with a reduced performance.
Inspired by Makowski et al.’s work on biomes [
33], three biomes that could be formed in ecological ecosystems found in Canada were developed, as shown in
Figure 1: temperate and boreal forests, with their respective dense vegetation, and bare tundra for regions that suffer from extreme cold conditions. These biomes were generated using UE 5.2’s new tool, PCG. A modular forest model was quickly developed for each type, with different densities, heights, and steepness tolerances as well as flora. PCG was employed to allow the project to adapt to any landscape with its forest types. This feature allowed the project to be completely automated regarding its scenarios, from landscape to forests.
Nowadays, the digital elevation model that represents the elevation of terrain and objects is an extensively developed technology, with satellite images already supporting the extraction of the mentioned maps. UE allows the importing of these maps for the generation of landscapes; therefore, any terrain from any place in the world can be imported into the project. Since PCG is used to generate vegetation, these realistic terrains are automatically covered by millions of trees and plants and can quickly be used to simulate our wildfire.
3.2. Data Simulation
The full simulation of a phenomenon such as a wildfire is still an open issue. Wildland fires at a landscape scale are so massively complex and their processing is so heavy that no proper understanding has been developed yet. In addition, with many factors affecting a wildfire, such as weather conditions, flora properties, physics simulations, and heat transfer, modeling wildfires is a challenging task [
50].
SWIFT simulates weather conditions with a few parameters, i.e., wind speed, wind direction, humidity, and temperature, which dictate the simulation conditions and directly affect wildland fire behavior. Rain and snow are also simulated; when humidity is above 85%, rain starts falling, and when the temperature drops below degrees, snow completely overtakes rain and then paints everything white.
Plants are simulated individually. They contain their values and parameters that determine the fire behavior when burning and heating. Thus, they contain their own fuel, heat transfer, plant humidity, plant temperature, flash point, and a flag indicating whether they are already burning or not.
Initially, SWIFT’s fire model was greatly inspired by the work of Pirk et al. [
34] on burning trees, incorporating functionalities such as heat being consumed to evaporate the liquid content of plants instead of building up inside the plant, the pyrolysis of material, and the decrease in fuel efficiency. However, when testing the simulation of thousands of individual fires, the performance of the simulation decreased significantly. Consequently, some features were simplified, with the understanding that the focus of SWIFT is on the visual fidelity of fires rather than the accurate simulation of this phenomenon.
The simulation performance requires more improvements to be interactive for large-scale fires, but it is better than the first prototype and is enough to be rendered with no performance loss. Fire in SWIFT is simulated by separating the visual and mechanical aspects. The visual fire is built with a combination of UE Niagara particles, a system that allows complex simulations by unifying features such as indirect light, heat distortion, or mirage, and different types of particles for fire, embers, and smoke.
Fire contact is determined by two geometries, a sphere around the center of the fire and a fan-shaped polygon. These geometries are determined by the fire size, the strength of the wind, and its direction. Any flora inside or in contact with these two objects is considered within the fire’s reach and will be directly affected by it. When affected by the fire, a plant’s temperature increases with each frame following Equation (
1).
where
is the current simulation speed,
is the plant’s heat absorption,
is the plant’s total fuel,
is the plant’s humidity, and
is the fire’s heat. Many aspects of this mathematical statement are transformed into multiplications from fractions to reduce process costs. Firstly, the humidity value is calculated, generating a range between 0.5 and 1. This value affects the rate of heat accumulation, meaning that a plant with higher humidity will heat more slowly. The humidity absorption is then multiplied by the heat absorption of the plant and the heat of the fire. This calculation gives the value of the heat absorbed by the plant, which is then divided by one-third of its total mass, represented by the remaining fuel. This means that a larger flame will be required to heat a bulkier plant. This process is then multiplied by the simulation speed, which simplifies the calculation for multiple iterations without needing to recalculate the value each time. This simplification implies minimal errors, which are not significant in large-scale simulations. When the plant’s temperature rises sufficiently to reach its flash point, i.e., the point at which the material evaporates into flammable gas and ignites, the simulation marks the plant as burned and creates a new fire to consume it.
Fire cannot burn on a large scale if the flora it burns is small or has little available fuel, which means that the heat of the fire is limited by the biomass of the flora. However, when the fire adequately consumes its fuel source, the increase in heat follows Equation (
2).
where
is the simulation speed,
is the plant’s humidity, and
is the global humidity. Similar to Equation (
1) of flora temperature increase, the fire can only burn the biomaterials available to it. This is simulated by reducing material consumption according to humidity; all functions share this same decrease of up to 50% due to flora humidity. Then, this value is multiplied by 0.45, an arbitrary value that determines how fast the heat of a fire will increase. Ideally, this value should be related to fuel type and energy release, but for simplification purposes, an arbitrary number was chosen. In addition, there is a second part to this function in the form of a heat reduction according to the global humidity to emulate saturated surroundings that are extremely humid, such as those found in snow or rain. This means that our simulated fire will be progressively dampened and eventually put out by wet weather conditions.
This fire has a visual effect that increases as the fire heats up. This increase in size is also influenced by the amount of fuel remaining, which indicates that a single example of flora that is very close to dying or is initially small will not produce a large flame in the same way as a tree. When the example of flora achieves a temperature above 60 degrees, its water content begins to evaporate, slowly decreasing over time, as shown in Equation (
3).
where
is the simulation speed and
is the plant’s current temperature. This equation normalizes a value to a range between the minimum of 60 degrees and the maximum of 300 degrees and then multiplies the result by 0.1%. Therefore, when the temperature reaches 300 degrees, the plant will lose 0.1% of its humidity each time the function runs. Since the plant temperature is affected by its mass, the plant’s mass will also affect this calculation.
3.3. SWIFT Data
To generate the SWIFT dataset, a UE feature, namely, Sequencer, was widely used to produce movie renders and mass images. A complete forest environment was developed, as shown in
Figure 2. It was directly generated using heightmaps extracted from satellite images of a region in Moncton, New Brunswick, Canada. PCG was then applied to this generated landscape, producing three distinct biomes over the expanse of the Moncton region.
This environment simulates approximately 4.7 million plants, encompassing various types from trees to grass chunks. These plants lack code functionality, which greatly improves performance for such a large environment but also makes it difficult to simulate the actual spread of a fire.
All simulations and data were processed on a machine with an NVIDIA GeForce RTX 3090, an AMD Ryzen 9 5900X 12-Core Processor 3.70 GHz, and 32 GB of RAM (NVIDIA, Santa Clara, CA, USA).
Four wildfire scenarios were developed in the vast Moncton landscape, each with different angles and viewpoints. They include ground and aerial views, providing a comprehensive visual exploration of each scenario as well as a rich and diverse dataset for training DL models. The videos were also recorded in a daytime simulated environment without weather change (a clear sky, a temperature of 21 Celsius, and at 1 p.m.).
With the simulation ready, four render sequences were developed to showcase multiple wildfire scenarios. Each sequence ranged from 1 to 2 min and produced both images and videos for SWIFT. These sequences were also designed to provide a wide variety of data by changing the angle and position of the camera. Quick movements simulated fast-flying drones resulting in blurry images, while slower movements captured clearer images. Aerial views provided an overview of the fire, and the final sequence included both distant and close-up fire shots.
These render sequences were then processed; the time to process each frame was approximately 0.127 s, with an average of 5000 images per render sequence before filtering out bad frames. It took roughly 11 min to render an entire scenario of 2 min and 47 frames per second. These were then converted into an MP4 (MPEG-4) video file using the FFmpeg conversion algorithm.
Both normal images and their corresponding ground truths (masks) were generated. They required different passes to be generated. For each class sequence and its ground truth, the processing time was effectively doubled. The switch between images was performed internally via UE by changing material properties and rendering configurations. When generating a ground-truth mask, all lighting features were turned off, turning the world completely black. However, the fire or smoke material was set to be emissive, allowing it to be visible even without external lighting. This technique ensured that the fire or smoke was the only visible element in the scene.
RGB images and their corresponding ground-truth images were generated separately using the Niagara feature. The latter enables consistent simulations that remain unchanged even after being regenerated numerous times. Adding to that, this feature allowed us to develop a single scenario and record it from multiple angles and image types without any differences from the actual fire simulation.
Ground-truth images are the basis for DL training. They are a copy of a normal image but in binary or grayscale format. The learning method can recognize the fire in the normal image by matching it with the corresponding ground truth. For fire images, we generated grayscale images as the corresponding ground-truth images, as shown in
Figure 3. When these images include more than one class, such as fire and smoke in the same image, the ground truth is set to adjust dynamically, displaying multicolored pixels whenever the two masks overlap, as depicted in
Figure 4.
Smoke ground-truth images were generated using two methods, as depicted in
Figure 5. One is a normal grayscale image, which can be used to acquire specific information such as the strength of the effect, i.e., when a flame has moved far from its source and is quickly dying or when smoke particles are less dense and therefore less visible. The second method is the use of a graphical binary filter. This code analyzes the pixels in the frame and paints them either completely white for pixels that have values above 0.015 for their respective colors or completely dark in the case of failure to achieve this threshold.
The SWIFT dataset comprises around 70,000 images of 1920 × 1080 pixels, as illustrated in
Table 3. These images were filtered to improve quality, notably by removing overly blurred images. Three background videos were generated, containing around 18,000 images. They contain no fire or smoke and therefore required no ground-truth variants.
For actual wildfire data, four scenarios were developed, each of which was used to generate ground-truth data. These scenarios were then processed in different configurations: only fire effects, only smoke effects, and visible fire and smoke effects. This distinction was useful for generating a broad database for different types of DL methods.
Besides the fire data, five simulation videos were produced. These videos showcase the simulation in effect, its behaviors, and its functionalities, allowing for a demonstration of the actual developed simulation. These simulation videos contain their simulation parameters, such as weather conditions, wind, simulation speed, temperature, and time of day, as shown in
Table 4.
In summary, the SWIFT dataset was generated using UE. It comprises 69,206 synthetic images and 15 videos of wildland fires with a high resolution of 1920 × 1980 pixels, depicting aerial, terrestrial, and forest interior views. This dataset is annotated and divided into four categories: fire (16,404 images and 4 videos), smoke (17,638 images and 4 videos), both fire and smoke (17,116 images and 4 videos), and no-fire/no-smoke (18,048 images and 3 videos). Each folder also includes the corresponding ground-truth images and videos. Additionally, the SWIFT dataset contains five simulation videos with their simulation parameters, including weather conditions, wind speed, humidity, wind direction, temperature, and time of day.