An Overview of How to Accurately Model Procedurally Spreading Fire

The Smoke demo, which highlights the scalability of a multi-threaded game engine architecture, includes a novel approach for creating procedural fire. As part of a farmhouse scene, complete with AI-controlled chickens, horses, swallows, structures, and farm equipment, trees are set ablaze by a meteor storm. The fire spreads throughout the trees' canopies, harnessing the power of the latest Intel® multi-core processors with a highly parallel architecture. The player of the Smoke demo must work quickly to extinguish the fire as it realistically spreads from branch to branch and tree to tree. These types of special effects are the essence of procedural fire. In this article-the prelude to a comprehensive white paper about procedural trees and fire-we describe the mechanism used to create realistic fire and the corresponding internals, as well as the natural addition of the water effect.

The source code to the Smoke demo project is available at /en-us/articles/smoke-game-technology-demo-download.

Simulating Fire


Computer graphics researchers have long placed a significant emphasis on rendering aesthetically pleasing fire in 3D. Until now, efforts have failed to realistically capture the physical characteristics of fire. The natural randomness and turbulence of fire typically leads to a rendering solution based on well-understood calculations, such as Perlin noise and Gaussian distribution-based particle systems. These visual effects all point to a common model of fire but do not demonstrate the physical properties of fire beyond a single flame source.

Intel's Smoke demo combines a traditional particle system that captures the visual effects of fire with a secondary system that treats fire as a heat source. This heat emitter dictates how a fire spreads by following a fuel source, how intense the fire is at any particular position, and the proximity of the heat source to another fuel source.


Implementation


Objects in Smoke
The Smoke demo architecture1 uses individual components defined as systems that house typical game engine features, such as physics, graphics, audio, and AI. A typical game entity in Smoke is an abstract object linked to several systems. For example, a horse in Smoke's farm scene has the following systems:

  • Graphics for the model and skeletal animation
  • Geometry to control position and orientation
  • Physics for collision detection
  • Audio for sound effects

The structural logic is the same for every object in the scene, such as the meteors that rain down from the sky, which include the graphics, physics, and audio systems as well as the fire system. The fire system is responsible for the demo's physical and visual properties of fire.


Fire System


Smart Particles

The procedural fire system consists of two discrete parts: a particle emitter based on a particle system inspired by Luna2 that includes billboard flame textures (fire particles) and a heat emitter system that models the heat property of fire (heat particles). These graphics are show in later figures to differentiate the two particle systems.



A fuel source, such as a tree in the Smoke demo, consists of multiple branches and canopies (for each leaf cluster). However, any geometry, including meteor objects, can be a potential fuel source. Each branch and canopy of a tree can serve as a host to the fire's smart particle system. The system can use the host object's axis-aligned bounding box (AABB) to not only determine where the visual flame particles should be positioned but also to conduct collision checks in the heat emitter. Just as in a real fire, heat tends to spread upward and away from a heat source, moving up a tree from branch to branch, finally reaching the canopy. At the same time, fire can occasionally spread downward, following the path of a canopy to a branch as indicated in Figure 1.


Figure 1. The smart particle system—fuel source detection as a heat particle intersects a bounding box.

Smart Particles


Meteor objects are the only objects in the scene that are initially burning. They also serve as hosts for the fire system, and as they fall through the scene some may pass near an element, such as a tree, that is also associated with the fire system. Trees in the demo consist of branches and canopies, each of which is an individual geometric object. If that object is not already burning, the fire system's collision-detection algorithm will set it on fire, further propagating fire throughout the tree and potentially to other trees in the scene.

The heat emitter's collision check is a time-intensive computation well-suited to run within Smoke's highly parallel, task-oriented architecture. Each burning object consists of several individual fires that represent a visual particle system and a physical fire particle from the heat emitter. In terms of the collision check, the fire particle is treated like a ray and is tested against an intersection of an adjacent fuel source's AABB. The magnitude of this ray approximates the physical nature of a fire's heat to set that object on fire. Objects that are outside the range of this ray are not affected.



Figure 2. The smart particle system-collision detection between a heat emitter and a branch.

Each fire object is iterated against all branches that are on fire and checked against each heat emitter to detect if there is a collision with an adjacent fuel source. The algorithm for this check consists of the following pseudo code:

For each Fire Object (each tree)

For each Fire in all Fire Objects (each branch)

For each Heat Emitter in each fire

Check for collision against the list of fuel sources

If collision, mark object as burning



The deepest piece of this code performs the actual intersection test between the heat emitter's heat rays in Tree A and a branch in Tree B as shown in Figure 3. Because the heat particle belongs to a heat emitter in a different object, that fire's heat particle must be translated into the local space of the other geometric object (see Figure 3).



Figure 3. A translation and collision test to translate heat particles from Tree A to Tree B.


Fire System Parameters


The fire system includes a set of input values for the visual and heat-emitter particle systems that control individual particles:

  • Type (spherical fire for meteors, line for branches, patch for canopies)
  • Fire density (how many heat emitter or visual particles exist for a single burning element)
  • Size (the rendered billboard's size)
  • Impulse (impulse velocity vector applied to guide fire in a default direction)
  • Shift (upward position adjustments to guide fire direction)
  • Lifetime (how long do the heat emitter and or visual particles live)

The following images depict the initial spherical fire from the meteor catching a tree on fire (Figure 4), then spreading throughout that tree (Figure 5), and ending with the fire spreading to another tree (Figure 6).



Figure 4. A meteor spreading fire to a standing tree.


Rendering Fire, Smoke, and Embers


The visual particle system used to render the flame billboards uses a sequence of textures alternating over the lifetime of the particle. This creates the transition of a growing flame expiring into smoke and embers that rise above the tree in a towering plume implemented in Ogre* 3D3 shader code.



Figure 5. The fire system spreads upwards, following the fuel sources.



Figure 6. Once the initial tree is fully ablaze, the fire spreads to the next tree.



Figure 7. Fire, smoke, and embers over burning trees; a smoke plume generated in Ogre* 3D.


Water


The Smoke demo includes a water hose (Figure 8) that allows users to move around the scene and extinguish the fire caused by the falling meteors.

As already noted, each fire object-in this case an entity bound to the geometric tree object-is iterated over every branch that is on fire. The fire object is checked against each heat emitter contained in the fire for a collision with an adjacent non-burning branch. Water is a natural extension of the fire system, and additional checks are used to extinguish a burning element in the collisionchecking code and to prevent the water from spreading, as the fire does, to another object.



Figure 8. The fire system-water introduced as a cold emitter.

Much like the geometric meteors use an attached fire system that is parameterized to start fires as a heat emitter, the invisible geometric cold object has a fire system instance set as a cold emitter, enabling it to participate in collision detection and to interact with other fire system objects. The Smoke demo uses the Particle FX plug-in provided in the Ogre 3D package for its script-based particle system. Collision detection occurs through the fire system that is bound to an invisible geometric object fired from the camera's position like a rapid-fire projectile. As the water object passes by or collides with a burning object, the attached fire system determines if any of the cold emitter's rays intersect with a burning object, thereby extinguishing the fire.

An added bonus to this effect is that the invisible water object is also bound to Smoke's multi-core-compatible Havok4 physics system, allowing the water object to act as a projectile and to interact with destructible elements in the scene, such as the farmhouse.


Conclusion


The Smoke demo incorporates a unique approach to modeling spreading fire, including separate approaches for visual and physical particle systems that can interact with the scene. This method lends itself well to arbitrary objects in the Smoke architecture, as well as to a parallel approach that divides the work of collision detection from the graphics-rendering piece over available hardware threads in a multi-core CPU.


Future Work


The current fire system does not include several effects that could be implemented in the future, including:

  • Destruction of burning pieces over time
  • Reigniting previously extinguished objects
  • Adding decals or changing textures for burning or burned objects


About the Authors


Hugh Smith, a senior software engineer in the Intel Software and Services Group, works with independent software vendors in the game industry. Hugh is guiding the performance optimizations for Intel® Graphics and multi-core products for leading PC game titles. He can be reached at hugh.a.smith@intel.com.

Jeff Freeman is a software engineer in the Intel Software and Services Group, where he supports Intel graphics solutions in the Visual Computing Software Division. He holds a B.S. in Computer Science from Rensselaer Polytechnic Institute. He can be reached at jeffrey.m.freeman@intel.com.

1 As described in Ryan Shrout's white paper: A Smoke Screen from Intel: Implementing Multi-threaded Gaming, Intel, 2008.
2 Luna, Frank D. Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. Plano, TX: Wordware Publishing, 2006.
3 Ogre* 3D Open Source Object-Oriented Graphics Rendering Engine. http://ogre3D.org.
4 Havok* Physics, http://Havok.com.


[ISN EDITOR'S NOTE: This article was independently acquired and published by Gamasutra for inclusion on its platform-agnostic Intel Visual Computing microsite. It is republished here with permission from both Gamasutra’s editors and the article’s author.]

Capture the buzz. Subscribe to Intel® Software Dispatch for Visual Adrenaline. (Did we mention it's fun, informative, visually stimulating, free, and you can unsubscribe at any time?)

For more complete information about compiler optimizations, see our Optimization Notice.