An Overview of Procedural Fire [PDF | 1MB]
The “Smoke” demo, created to highlight the scalability of a multi-threaded game engine architecture, includes a novel approach to procedural fire generation. As part of a farmhouse scene complete with AI controlled chickens, horses, swallows, barn, and farm equipment, trees are set ablaze by a meteor storm. The fire spreads throughout the canopies of the trees, harnessing the power of the latest Intel® multi-core processors with a highly parallel architecture. The user must work quickly to extinguish the fire as it realistically spreads from branch to branch and tree to tree in the scene. This is procedural fire.
First, as a prelude to a comprehensive Procedural Trees and Fire white paper available soon, we describe the mechanism used to create realistic fire and corresponding internals and lastly, the natural addition of the water effect. Instructions on obtaining the source code to the Smoke demo project are noted at the end of the Conclusion chapter.
Computer graphics researchers have placed a significant focus on rendering aesthetically pleasing fire in 3D that often fails to capture the physical characteristics of fire. The natural randomness and turbulence of fire often yields a rendering solution based on calculations such as Perlin noise and Gaussian distribution based particle systems that are well understood. 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.
The 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 that particular position, and the proximity of that heat source to another fuel source.
Objects in Smoke
The Smoke demo architecture  uses individual components defined as systems that house typical game engine features just such physics, graphics, audio, AI, etc. A typical game entity in Smoke is an abstract object that is linked to several systems. For example, a horse in Smoke’s farm scene has the following systems:
The procedural fire system consists of two discrete parts, a particle emitter based on a particle system inspired by  that includes billboard flame textures (Fire particles) and a heat emitter system that models the heat property of fire (Heat particles). These graphics will be referenced in later figures to differentiate these two particle systems.
|Fire Particles||Heat Particles|
A fuel source, such as a tree, consists of multiple branches and multiple canopies (for each leaf cluster) in the Smoke demo although any geometry could potentially be a fuel source, including meteor objects. 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 conduct collision checks in the heat emitter. Just as in real fire, heat tends to spread upwards and away from a heat source, moving up a tree from branch to branch, finally reaching the canopy and occasionally downwards following the path of a canopy to a branch as indicated in Figure 1.
Figure 1 Smart Particle System – Fuel Source Detection
Meteor objects are the only objects in the scene that are initially burning, falling from the sky, and passing through or near the trees. Trees in the demo consist of branches and canopies, each of which is an individual geometric object. Meteor objects also serve as hosts for the fire system and as they fall through the scene some may pass near an element that is also associated with the fire system such as the trees. 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 running designed for multi-core CPU’s. Each burning object consists of several individual fires that represent a visual particle system and 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 will not be affected.
Figure 2 demonstrates how a collision between a heat emitter and a branch will mark it as burning. This activates that object’s visual particles and heat emitter, allowing the fire to spread. This process repeats over time until all fuel sources within range are on fire.
Each fire object is iterated over 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 innermost 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. Since 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 as shown in Figure 3.
Fire System Parameters
The fire system includes a set of input values for the visual and heat emitter particle systems that control individual particles.
Rendering Fire, Smoke, and Embers
The visual particle system used to render the flame billboards utilizes a sequence of textures alternating over the lifetime of the particle, creating a transition of a growing flame expiring into smoke as well as embers that rise above the tree in a towering plume implemented in Ogre3D  shader code.
The Smoke demo includes a water hose as shown in Figure 5 that allows users to move around the scene and extinguish the fire caused by falling meteors.
As noted in the previous section, each fire object, in this case an entity bound to the geometric tree object, is iterated over all branches that are on fire and checked against each heat emitter contained in that fire for a collision with an adjacent non-burning branch. Water is a natural extension of the fire system, utilizing additional checks to extinguish a burning element in the collision checking code and to prevent the water from spreading like fire to another object.
Figure 5 Fire System – Water
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 interact with other fire system objects. The Smoke demo uses the ParticleFX plug-in provided in the Ogre3D  package for its script-based particle system. Collision detection is facilitated 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 a burning object extinguishing the fire.
An added bonus to this effect is that the invisible water object is also bound to Smoke’s Havok  physics system, allowing the water object to act as a projectile and interact with destructible elements in the scene such as the farmhouse.
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 approach lends itself well to arbitrary objects in the Smoke architecture as well as a parallel approach that divides the work of collision detection from the graphics-rendering piece over available hardware threads in a multi-core CPU.
Send email requests to email@example.com for source availability.
The current fire system does not include several more realistic effects of fire that could be implemented in the future, including:
 [Luna06] Frank Luna. Introduction to 3D Game Programming with DirectX 9.0c: A Shader Approach. Wordware Publishing Inc.
 [Smoke08] Ryan Shrout. “A Smoke Screen from Intel: Implementing multi-threaded gaming”. Intel 2008.
 [Ogre3D08] Ogre3D Open Source Object-Oriented Graphics Rendering Engine http://www.ogre3d.org.
 [Havok08] Havok Physics http://www.havok.com.
Hugh Smith is a Senior Software Engineer in the Software Services Group working with independent software vendors in the game industry guiding performance optimizations for Intel graphics and multi-core products to leading PC game titles. He can be reached at firstname.lastname@example.org.
Jeff Freeman is a Software Engineer in the Software Solutions 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 email@example.com.
List of Figures
Figure 1 Smart Particle System – Fuel Source Detection
Figure 2 Smart Particle System – Collision Detection
Figure 3 Translation and Collision Test
Figure 4 Fire, Smoke, and Embers Over Burning Trees
Figure 5 Fire System – Water
The same structural logic is true for all objects in the scene such as the meteors that rain down from the sky that include the graphics, physics, and audio systems as well as the fire system. This fire system is responsible for the physical and visual properties of fire in the demo.
Intel's compilers may or may not optimize to the same degree for non-Intel microprocessors for optimizations that are not unique to Intel microprocessors. These optimizations include SSE2, SSE3, and SSSE3 instruction sets and other optimizations. Intel does not guarantee the availability, functionality, or effectiveness of any optimization on microprocessors not manufactured by Intel. Microprocessor-dependent optimizations in this product are intended for use with Intel microprocessors. Certain optimizations not specific to Intel microarchitecture are reserved for Intel microprocessors. Please refer to the applicable product User and Reference Guides for more information regarding the specific instruction sets covered by this notice.
Notice revision #20110804