Approximating the Fire Flicker Effect Using Local DynamicRadiance Maps

Jonathan Brian MetzgarUniversity of Colorado at

Colorado Springsjonathan@metzgar-

research.com

Sudhanshu Kumar SemwalUniversity of Colorado at

Colorado Springsssemwal@uccs.edu

ABSTRACTRealistic fire and the flicker effect is a complicated process to simulate in realtime and little work has been doneto simulate this complicated illumination effect in realtime. Fire is not a directionally uniform source of light butvaries in intensity not only with time but also with direction. Most realtime applications use a standard point lightsource model for local illumination effects and may use a model to change the light source intensity with time but notdirection. The problem is that point light sources are isotropic, but many sources of light have anisotropic qualitiesas well. Radiance maps and Precomputed Radiance Transfer (PRT) have been used to increase realism at realtimeinteractive frame rates. These models approximate global illumination by applying an environment map (typicallyapproximated with spherical harmonics) to get their soft lighting effect. In this paper we present Local DynamicRadiance Maps (LDRM) which uses radiance maps in a local illumination model to add anisotropic behavior tolight sources. We implemented a realtime rendering engine that supports shadow mapping and the physically basedCook-Torrance model to approximate global illumination. In particular, we generate dynamic radiance maps usingPerlin noise to simulate the nonlinear radiance of fire and we also implement a rudimentary Lattice-Boltzmannflame rendering effect. Finally, we show how LDRM can be applied not just to approximating the fire flicker effect,but as a general framework for simulating the illumination properties of other nonlinear light sources.

Keywords: radiosity, global illumination, fire, Lattice-Boltzmann, radiance maps, shadow-mapping.

1 INTRODUCTIONAdvances in graphics processing units (GPU) have re-sulted in not only improved speed and quality of com-puter generated images, but now feature massively par-allel processors capable of running several general pur-pose programs. This parallelism allows for the imple-mentation of global illumination algorithms. Physicalsimulations of natural phenomena like fire and water aretaking advantages of the hardware acceleration.Rendering fire is a big challenge for computer graph-ics because it touches so many areas of image genera-tion. It is even harder to do it well in realtime. Onewould want to eventually render fire based on a full 3Dsimulation using Navier-Stokes equations and render ascene in realtime using the illumination effects mod-eled by a radiosity algorithm. Since this is not practical,fire imagery is often created through precomputed ren-derings, video, or particle effects and the illumination

Permission to make digital or hard copies of all or part of thiswork for personal or classroom use is granted without fee pro-vided that copies are not made or distributed for profit or com-mercial advantage and that copies bear this notice and the fullcitation on the first page. To copy otherwise, or republish, topost on servers or to redistribute to lists, requires prior specificpermission and/or a fee.

comes from a point light source with a dynamic inten-sity. But, simply modulating the intensity and locationof a point light source does not adequately model theway that fire radiates in a nonlinear way. It is this non-linear radiance that causes the flicker effect to occur.

For the last decade, radiance maps and precomputed ra-diance transfer have become essential for creating highquality realtime visualizations. Essentially by utiliz-ing approximations like spherical harmonics, they canquickly apply the illumination model to objects in ascene and get radiosity like shading effects. This modelworks with an outward-in approach where the incominglight is mapped to a sphere which is mapped to the pre-computed radiance map. We propose a variation of thismethod that 1) dynamically computes the radiance and2) is a local source of radiance which can move aroundinside an environment. We call these local dynamic ra-diance maps or LDRM. The main goal of the LDRMmodel is to make lights appear and act like they belongin the scene by modeling their anisotropic behavior as afunction of time.

In this paper, we present a new way to approximate theflicker effect by procedurally generating a LDRM intoa cube map. This LDRM is projected outwards fromthe position of the fire source through the cube textureand onto the surrounding scene’s geometry simulating

the first bounce of radiosity. To achieve our results, wehave chosen bump mapping, physically based lighting,and soft shadow mapping algorithms to calculate directand indirect illumination of the fire source. Finally, weimplement a procedurally simulated fire effect based ona Lattice-Boltzmann model which can be simulated onthe GPU or CPU to approximate the flames emitted froma torch. This is rendered in our scene at the location ofour fire source.

2 PREVIOUS WORKSimulating fire is a fluid simulation problem that has avariety of solutions ranging from artist derived flameprofiles, procedural generation of flames, and fluidsimulation of flames. [Ngu01a] and [Ngu02a] presenta solution for Navier-Stokes equations to simulate theflames but is time consuming. [Hon07a] combineboth a Navier-Stokes simulation with detonation shockdynamics to get wrinkled flames and cellular patternsbut also takes a long time to render. A near realtime firesimulation and control system that uses artist derivedflame profiles is described by Lamorlette and Fosterin [Lam02a]. The Perlin noise function and an artistspecified flame profile is used to generate proceduralfire by [Ful07a].The groundbreaking 1970’s work by [Har73a] and[Har76a] first introduce the Lattice-Boltzmann Model(LBM) methods which have become the basis of manynon Navier-Stokes fluid simulations. [Wei02a] useoverlapping textures with turbulence details employingLBM for motion of the flames. [Zha03a] also employLBM to simulate fire fronts around solid objects.Some models, such as [Lam02a], discuss in much de-tail how to compute the lighting effects. For example[Lam02a] uses an emitting sphere at each flame seg-ment to generate lighting. It is assumed that the light-ing details are automatically handled at the rendererlevel which combine several global illumination algo-rithms like radiosity, ray tracing, and/or photon map-ping. Importance sampling using volumetric illumina-tion has been used by [Zha11a]. GPU simulation withvolumetric data creates a variety of realistic and detailedfire simulation such as moving fire [Hor09a],Radiance maps are images that store the intensities oflight passing through each pixel. The direction of thelight is determined by the projection used to create theimage. They are used in high dynamic range imagery(HDRI) as described by [Deb97a]. Methods such asprecomputed radiance transfer (PRT) first introducedby [Slo02a] use a spherical harmonics representationfor low-frequency radiance computation. These spher-ical harmonics representations approximate a high res-olution HDRI radiance map and are very effective forrelighting objects in an environment. Primarily theyhave been used for static scenes but the technique is

expanding for dynamic scenes as well. For example,[Kri05a] relight architectural models in real-time withmoving lights by combining precomputed point lightsource clouds.

3 THE POINT LIGHT MODELThe predominantly implemented illumination model forfire in realtime applications is the point light sourcemodel. It is used widely because there is hardware sup-port for the algorithm and also because it is easy to com-pute the shading value since the light position is sub-tracted from the vertex or fragment position to get the�Lvector that is used by a Lambertian illumination model.In some implementations, the intensity is constant witha distance based falloff function. It can become more so-phisticated by varying the intensity of the light or addinga random perturbation to the coordinates of the lightsource. The intensity and position are often varied us-ing a smooth noise or interpolation scheme. The easiestway to think of this is a person holding a simple lightbulb with a rapidly sliding dimmer switch and a jitteryhand. In Figure 1, you can see the smooth uniform in-tensity that the point light model has. The problem isthat point light sources are isotropic, but many sourcesof light are anisotropic. We will now present the LDRMmodel which attempts to model the anisotropic featuresthat fire and other natural phenomena possess.

4 THE LDRM MODEL

Figure 1: The LDRM method is compared to the pointlight source method. In the LDRM image, the intensityand frequency is turned up very high to clearly showthe difference of the LDRM method and the point lightsource method. Realistic settings would be tuned to bemore subtle.

Our Local Dynamic Radiance Map (LDRM) modelstores a dynamically computed radiance map at co-ordinates P. The light emitted from P is cast in alldirections simulating the first bounce of radiosity. Theradiance may either be precomputed as an animation

or procedurally generated in realtime. A cube map orother similar abstraction is an ideal way of storing theseradiance values.We reproduce Kajiya’s rendering equation [Kaj86a] be-low so we can illustrate how the LDRM fits into thisstandard model:

I(x,x�) = g(x,x�)[ε(x,x�)+�

ρ(x,x�,x��)I(x�,x��)dx��]. (1)

The radiance of the LDRM is represented by ε(x,x�)while being directly affected by the visibility of the pointx at point x� by the function g(x,x�). More specifically,the function ε(x,x�) is the radiance coming from direc-tion�L where�L is the vector from the position of the lightsource to the point x, and is the direction of the sample.This value can be obtained by looking into the radiancemap using the direction provided. For example, mostgraphics hardware have the ability to easily look up thisvalue from a cube map using a vector as an input.

Figure 2: Two LDRMs generated using different fre-quencies of noise and their corresponding effect on theenvironment.From Kajiya’s rendering equation, we then map this to asimplified model where we can incorporate our render-ing algorithms. Since we are not simulating the integralin his equation, we decided to make that a constant valueand focus on just ε and g which is just the radiance of thelight source and the visibility of the light source with thesurface being illuminated. Essentially, the LDRM actslike a Gaussian surface in the sense, that instead of try-ing to compute the interactions with the actual flames orother phenomena and the surrounding environment, weperform an intermediate step of mapping it to a surfacewe can easily use in a rendering situation. This is clearlyseen in Figure 3.The incoming radiance which we will now call R, is thendivided into the specular and diffuse reflection colorskspecularR and kdi f f useR, respectively where kspecular +kdi f f use = 1. Depending on the reflectance model used,kspecular and kdi f f use may be computed differently. Wedecided to implement the Cook-Torrance model and wewill discuss later in section 4.1 how to compute thesevalues.The dynamic radiance of a torch fire is approximatedby using Ken Perlin’s noise function. The radiance ofeach direction of the torch fire is computed and storedinside the radiance map. The unit vector l is used asinput to the Perlin noise function and the resulting valueis used to look up the color associated with the radiance.

Figure 3: The LDRM method (right) differs from thepoint light source method (left) by modeling the light’soutgoing radiance as a function of time, intensity, anddirection.

A blackbody radiation color map is used to give color tothe torch fire. An example color map is shown in Figure7.The LDRM is flexible. If a variety of natural phenom-ena used the same kind of simulation algorithm but dif-fered only in color, a different color map will easily al-low for adjusting that. For example, fire could probablyuse the same simulation code, but the specific chemicalcombustion properties would be approximated by map-ping the resulting intensity values with the appropriatecolor map.In our implementation, we have chosen Perlin noise be-cause it generates smooth noise that can be animatedand provides enough variety for our ideas to be imple-mented. Generation of a LDRM function that simulatesthe unique properties of fire (or other phenomena) ismost definitely a topic for future study but is outside thescope of our research. Later we will discuss this pos-sibility, but our experiments with Perlin noise showedsignificant enough improvement in scene realism ver-sus the traditional point light source method that we dis-cussed in the last section.

Figure 4: The LDRM projects radially from the centerof the light position. Areas in blue get ambient lightingwhile others get direct illumination.

Figure 4 shows a diagram of how the LDRM methodworks. The box located around the position of the lightrepresents the cube map. The arrows emitted from thecenter of the light through the box will look up the ap-propriate radiance and project it on the environment. Ifthe area is in shadow (represented by shaded blue areas)then an ambient algorithm can determine the final illu-mination of those fragments. The containing rectangle

and the red and green rectangles represent the environ-ment and objects visible to the light source. Figure 2shows two example LDRMs generated using two differ-ent frequencies of noise. It can be easily seen how theLDRM works in a practical sense by observing that vari-ation in intensity in the environment corresponds to thefrequency of noise.

5 IMPLEMENTATION

Figure 5: A rendering of the fire flicker effect program.

Our fire flicker effect simulation presented in this paperis designed to employ the LDRM model. A variety ofrendering algorithms is used to simulate global illumi-nation and a screenshot is shown in Figure 5. The globalillumination algorithm implements the Cook-Torrancemodel, Blinn bump mapping, and cube map shadowmapping. It uses a simple ambient function that approx-imates indirect illumination by scaling the direct illu-mination by the amount of shadow present at that pixellocation. The Cook-Torrance model allows for physi-cally based illumination while the bump mapping algo-rithm allows for increased higher-frequency pseudo de-tails. Finally instead of rendering the LDRM cube mapin the scene, flames are dynamically computed and ren-dered into 2D textures and drawn onto rectangles in afan like structure to give the torch a 3D look. In effect,the torch fire is used as an aesthetic place mat to showwhere the LDRM is located in the scene.

5.1 Illumination and Shadow ModelThe Cook-Torrance model was chosen because it is aphysically based model. Other models can easily be in-tegrated as desired. The LDRM was used to supply thespecular color kspecularR for the Cook-Torrance model.This color is mixed in with the surface color of the frag-ment being rendered and scaled by the dot product ofthe surface normal and incoming light vector�L.Since a torch is an omni-directional light source, cubemapped shadow mapping was selected to render theshadows. It is a fairly straightforward algorithm to im-plement, but it does take some tweaking to get the high-est image quality. We chose to write a scalable multi-sampled shadow algorithm that we could adjust to mea-sure performance of our technique. The number of sam-ples can go from one sample to N = 257 samples. Here

N can be varied based on the hardware capabilities ofthe system. The penumbra width is adjustable as a con-stant parameter in the shader program. Figure 6 showstwo screenshots of the program using 1 sample shadowsand 257 sample, wide penumbra shadows.

Figure 6: These two images shows a basic one sampleshadow and a wide penumbra, 257 sample shadow.

5.2 Radiance Cube Map GenerationPerlin noise is a simple solution to generating non-linearradiance that is repeatable, smooth, and fluid. Depend-ing on application performance, the noise can either begenerated on the GPU or CPU. The fire program im-plemented in this paper used the GPU and a render-to-texture set up to render the six sides of a cube map. TheGPU code for generating Perlin noise was implementedby [Gus06a] which we slightly modified to adjust fornoise scaling and animation parameters used in the fireprogram.The six textures are used as a cube map in the final ren-dering pass by the global illumination shader. The grayscale output of the radiance is then converted from heatvalues to RGB values by looking up the data in a colorlook up table. The texture is updated once per frameor as needed to maintain a target frame-rate. The colorlook up table is shown in Figure 7 and one side of aLDRM is shown in figure 8.

Figure 7: The color look up table mapping heat to theircorresponding RGB values.

Figure 8: One face of a cube map generated by theLDRM method.Special care needs to be taken to balance the noise sothat it adds a subtle lighting effect to the scene. If thefrequency of the noise is too high then the effect maylook overdone where it can quickly be distracting. Onthe other hand, using hardly any noise or under using theeffect will look as if the effect is not being used, so care-ful balancing needs to done to find a good range wherethe effect will be effective. Figure 2 shows this effect in

practice. Note how the high frequency map may makethe environment look splotchy which is not realistic.The LDRM may be used to create good lighting effects,but it is not complete without some motion of the shad-ows in the environment. Perlin noise is used once againto compute a time-varying offset which we add to theoriginal position of the light. This new position is usedto render the shadow maps and lighting. The final prod-uct then has dancing shadows which enhance realism.

5.3 Global Illumination in the SimulationThe equation

Cout =max(Rambient ,Rshadow) ·�kdi f f use +Rspecular · kspecular

�.

(2)is the basis for the global illumination algorithm for thefire program. The Rambient term specifies the ambientintensity of the pixel, the Rshadow represents the contri-bution of any direct lighting occuring at the pixel, thekdi f f use term is the color of the surface at that pixel, thekspecular term is the color of the specular reflection of thepixel, and the Rspecular term is the amount of reflectedlight at the pixel.The terms are all computed from four different algo-rithms. The first algorithm is bump mapping which cal-culates the normal of the pixel. The second algorithmis the Cook-Torrance model which calculates the specu-lar reflectance values Rspecular and kspecular of the pixel.The third algorithm is the Cube Map Shadow algorithmwhich allows for omni-directional point light sources.Finally, the fourth algorithm is an intensity falloff modelfor the Rambient term to model indirect light. These havebeen covered in detail in previous works, but integrat-ing them together will be briefly explained in light ofthe equation to compute Cout .

5.4 Ambient and Shadow TermThe ambient term is a simple approximation based ona inverse falloff law from the distance to the fire. Theambient term Ra is computed by the formula

Rambient =1

4|L| . (3)

This equation is a variation based on the inverse powerlaw I = P

4πr2 which gives us a brighter overall light in-tensity which is normally lost unless you do a full onradiosity simulation to get the intensity back through in-direct reflections. This gives us some of that light whichis normally “lost” in a local illumination model.The shadow term Rshadow is computed with the follow-ing formula:

Rshadow = min��Nvertex ·�L,�Nbump ·�L

�∗ 1

n

n

∑j=0

s j (4)

where �Nvertex is the interpolated vertex normal, �Nbumpis the per pixel normal derived from the normal map,�L is the incoming direction of the light source, n is thenumber of samples being used for the shadows, and s j isthe boolean result of comparing the jth pixel depth valueto the light depth buffer which is either 1 or 0. Taking theminimum of the dot products eliminates bump mappingon polygons not facing the light.Together the ambient and shadow terms are used to de-termine the minimum illumination level of the fragmentto be rendered. A simple maximum function is used tochoose the ambient term or shadow term. If a fragmentis completely shadowed, then the ambient term is used,otherwise the fragment is in penumbra and has some il-lumination.

5.5 Diffuse and Specular TermThe diffuse term kdi f f use is generated from the surfacecolor or texture of the object. The specular termsRspecular and kspecular are the coefficient of the reflectedlight and its color, respectively. This is where we canincorporate the LDRM model. The kspecular value isobtained by using the �L vector as the lookup in theLDRM cube map. The Rspecular term is based off theCook-Torrance model equation [Coo81a]

Rspecular =Fπ

DG(N ·L)(N ·V )

. (5)

F is the Fresnel term, D is the micro-facet distributionfactor, G is the geometric attenuation factor, V is theview vector, and L is the vector from the light to the frag-ment. Additional details about using the Cook-Torrancemay be found by referring to the original paper. It is im-portant to note that the LDRM model is not just limitedto Cook-Torrance, but may be incorporated with any il-lumination model.

5.6 CPU and GPU 2D Flame SimulationOur flame rendering system is based off a simple cellularautomata model to generate fire. This cellular automatais a simplified model of Lattice Boltzmann Methods(LBM) which originated with the work of [Har73a].[Che98a]’s work summarize the developments of themodel into its more current form. The method worksby using a lattice structure representing the fluid to besimulated. A convection operator and collision oper-ator transform the lattice over time and cause the fluidprocess to occur. The nineties demo scene fire effectused a simple averaging function to cause convectionand simulate collisions. Figure 9 shows a screenshotthat simulates this full screen fire effect.This fire effect can be modified to generate small flamesor torch sources. Further improvements can be made toincrease precision as well. Typically this effect uses 8-bit integer mathematics to store the heat values. While

Figure 9: This image shows a fire simulation where theentire bottom row is used as the heat source and thatuse of integer math causes noisy artifcats near these ran-domized heat sources.

this is accurate enough for most of the effect, it resultsin artifacts near the source of the fire as shown in Figure9. Changing the representation from integers to floatingpoint math eliminates these artifacts and increases dy-namic range. This can be coupled with established HDRtechniques and physically based color computations fordifferent chemical reactions.The flame is generated by adding or seeding heat topoints on the lattice. The flame will flow during theconvection operator step. During the collision opera-tor step, the flame mixes together. The three steps willcause the flame to take shape as this process repeats.A simple circular falloff model is used for seeding theheat to the fire. Notice in Figure 11 two different kindsof falloff patterns: the simple radial falloff used in thefire program and a noisy radial falloff used for the firesin Figure 10. By quickly changing the location of thefalloff pattern, turbulence is created. The fire effect andvarying levels of turbulence are shown in Figure 10.

Figure 10: The radius of the circle in which the centerof the flame source is moved causes a more turbulentflame. On the far right, improperly handled edges cause“heat sink” artifacts.

Figure 11: Two falloff patterns for seeding fires. Thesecond pattern adds some turbulence to the resultingflames.This fire effect can be computed using a GPU anda graphics based shader language (i.e. GLSL) wasadequate for our simulation. The algorithm is shownin Listing 1 and is fairly straightforward. It determineswhether the fragment is in the simulation area or not(which if not handled correctly creates “heat sinks"shown on the far right in Figure 10). Simulatingdiffusion and cooling is obtained by averaging severalneighbor samples at each fragment and multiplying

by a factor li f e, respectively. Heat is added to all thefragments located inside a circle (a “heat sink") whichis randomly jittered according to the desired turbulenceof the flame.

@VERTEXSHADERuniform mat4 ProjectionMatrix;varying vec2 uv;

void main() {\\uv = gl_MultiTexCoord0.st;

gl_Position = ftransform();}

@FRAGMENTSHADER#version 140uniform sampler2DRect FireLattice;uniform sampler1D radianceCLUT;uniform float a, b, radius;uniform float width, height;uniform float heat, life;uniform float turbulence;in vec2 uv;out vec4 gl_FragColor;float rand(vec2 co) {return fract(sin(dot(co.xy ,vec2(12.9898,78.233))) * 43758.5453);

}void main() {float x = uv.s, y = uv.t;float data = 0;float r2 = radius * radius;

if (x >= 1 && x < width-2 &&y >= 3 && y < height-1) {

if (x >= a-radius && x < a+radius &&y >= b-radius && y < b+radius) {

float f = (x-a)*(x-a) + (y-b)*(y-b);if (f < r2) {data = texture(FireLattice,

vec2(x, y)).a;data += heat * (1 - f/r2);

}}data+=texture(FireLattice,

vec2(x, y+1)).a;data+=texture(FireLattice,

vec2(x-1, y-1)).a;data+=texture(FireLattice,

vec2(x+1, y-1)).a;data+=texture(FireLattice,

vec2(x, y-2)).a;data = clamp(data * life / 4.0,

0.0, 1.0);} else {data = 0;

}vec3 color2 = texture(radianceCLUT,

data).rgb;gl_FragColor = vec4(color2,data);

}

Listing 1: A GLSL Shader that computes the flame sim-ulation.

6 RESULTSThe LDRM model takes up relatively little extra loadin conjunction with normal rendering depending on thenumber of lights being used. The majority of perfor-mance loss comes from shadow mapping when largenumbers of samples are being used. Rendering high res-olution LDRM cube maps may also reduce performancebut this can be mitigated by using low resolution mapswhen large numbers of lights are being used.The benchmarks were conducted using a Windows 7OS, Intel i7 930 2.80GHz processor with 6GB of RAM,and a NVIDIA GeForce GTX 480 graphics card with1.5 GB of GDDR5 memory. Each benchmark was mea-sured by recording the number of frames per second(FPS) once per second over a period of 25 seconds. Themean frame rate was then computed to filter noise inthe readings, though the noise present was so low thatit had an insignificant effect on the final numbers. Fi-nally, we kept the frame rate as high as possible so wecould ensure that our simulation would run on less ca-pable graphics cards.

Figure 12: A comparison of radiance cube map size ver-sus performance.

We tested the performance of our method using differ-ent resolution LDRM cube maps and by not renderingthem at all. Figure 12 shows the results when 1, 2, 4, or8 lights are being used. When using a 256x256 LDRMcube map, performance drops by 41%, 68%, and 83%for 2, 4, or 8 lights, respectively. When using 512x512cube maps, performance drops by 39%, 66%, and 82%for 2, 4, or 8 lights, respectively. For 1024x1024 cubemaps, performance drops by 33%, 60%, and 77% for2, 4, or 8 lights, respectively. Compared to not us-ing LDRMs at all, performance drops by 4% to 17%for 256x256 cube maps, 6% to 25% for 512x512 cubemaps, and 11% to 42% for 1024x1024 cube maps.Next, we tested the performance of our flame renderingsystem on the CPU and the GPU. Overall, the GPU hada clear lead in performance especially as resolution isincreased. However, until much higher resolutions offlame simulations are used, the number of flames ren-dered per second on the CPU was in the hundreds whichis sufficient. It is also clearly shown that using the GPUin conjunction with the CPU yielded little decrease inoverall performance. We are unable to easily compare

Figure 13: On the left, we see that application perfor-mance is not affected until high resolution lattice sizesare used. On the right, the GPU far surpasses the CPUin raw fire rendering performance.

our flame rendering algorithm with others because oursis not volumetric and has very strong boundary condi-tions which make it incapable of handling interactions ina 3D environment which a volumetric simulation could.When integrated with the global illumination simula-tion, the GPU advantage becomes more obvious. CPUperformance drops off fast when using high resolutionlattice simulations, though it is almost unnoticeablewhen using reasonably sized maps. In contrast, theGPU simulations have a very small performancepenalty when using large lattices. It should be notedthat multithreading was not used in the CPU simulation,but the GPU still has enough compute power for thelarge lattice sizes that even an 8 core CPU could notoutperform it. Figure 13 shows the performance graphsfor running the global illumination simulation andrendering the flames with either the CPU, GPU, orboth. It also shows the baseline performance of the GIsimulation without rendering the flames. Effectively,you get the flame rendering for free for small resolutionflame images.

Figure 14: On the left, antialiasing halves overall per-formance. On the right, reasonable numbers of shadowsamples still allow interactive frame rates.

Finally, we examine the performance of the global illu-mination algorithm. Figure 14 shows the performanceof the global illumination algorithm both when usingmulti-sampled shadows and different resolution shadowmaps, respectively. When using a reasonable number oflights, it is very easy to obtain very interactive rates. Per-formance drops quite a bit when using anti-aliasing, butthe image quality is greatly improved and small pixel ar-tifacts that show up when not using anti-aliasing almostentirely disappear.Shadow quality is very good at 33 samples per pixel andthe frame-rate is quite interactive. Wide penumbras areallowed which increases the realism of far off shadowswhere the area lighting effect of the flames would not

create sharp edges. The shadow map size affects per-formance but not as dramatic as varying the numberof samples. Memory usage does increases quickly sotweaking is necessary to determine the lowest accept-able shadow map resolution.Adding motion to the shadows does a good job of dis-tracting the observer from noticing some minor prob-lems with shadow mapping. Some of these problemsinclude light leakage or surface acne. Ultimately, themoving shadows create the realistic appearance that thefire has on the scene while the LDRM model adds a sub-tle ambience to the scene, that when switched off, makesthe simple intensity modulation based fire flicker effectseem somewhat lifeless.

7 CONCLUSION AND FUTURE WORKThe LDRM model presented in this paper helps add re-alism to scenes where torch fires are being used. Theambiance created by using shifting anisotropic illumi-nation patterns add subtle depth and realism to scenescompared to the simple point light source model. Theperformance penalty is small and the algorithm is trivialto implement for any realtime graphics engine.Future study of LDRMs to enhance direct illuminationis promising and is an excellent extension to normal pre-computed radiance transfer. In the future we are lookinginto simulating a volumetric fire and comparing the ac-tual radiance with our approximation. We believe thatcreating LDRM models of other nonlinear light sourceswould be highly beneficial towards accurately simulat-ing other phenomena in a realtime application. Finally,we are looking into using spherical harmonics as a sub-stitute for cube maps which may allow LDRMs to beused in resource limited environments.

8 REFERENCES[Che98a] Chen, S., and Doolen, G.D., Lattice boltzmann

method for fluid flows. Annual Review Fluid Mechanics,1998, pp.329-364.

[Coo81a] Cook, R. L., and Torrance, K. E., A reflectancemodel for computer graphics. Proceedings of the 8th an-nual conference on Computer graphics and interactivetechniques, ACM, New York, NY, USA, SIGGRAPH’81, 1981, pp. 307–316.

[Deb97a] Debevec, P. E., and Malik, J., Recovering high dy-namic range radiance maps from photographs. Proceed-ings of the 24th annual conference on Computer graphicsand interactive techniques, ACM, New York, NY, USA,SIGGRAPH ’97, 1997, pp. 369–378.

[Ful07a] Fuller, A. R., Krishnan, H., Mahrous, K., Hamann,B., and Joy, K. I., Real-time procedural volumetric fire.In Proceedings of the 2007 symposium on Interactive 3Dgraphics and games, ACM, New York, NY, USA, I3D’07, 2007, pp. 175–180.

[Gus06a] Gustafson, S., Dsonoises, a set of useful functionsfor sl., 2007. url:http://staffwww.itn.liu.se/~stegu/aqsis/DSOs/DSOnoises.html

[Har73a] Hardy, J., Pomeau, Y., and de Pazzis, O., Time evo-lution of a two-dimensional classical lattice system. Phys.Rev. Lett. 31, 5, 1973, pp. 276–279.

[Har76a] Hardy, J., de Pazzis, O., and Pomeau, Y., Moleculardynamics of a classical lattice gas: transport propertiesand time correlation functions. Phys. Rev. A 13, 5 (May),1976, pp.1949-1961.

[Hon07a] Hong, J.-M., Shinar, T., and Fedkiw, R., Wrinkledflames and cellular patterns. In ACM SIGGRAPH 2007papers, 2007, ACM, New York, NY, USA, SIGGRAPH’07.

[Hor09a] Horvath C and Geiger W., Directable high Resolu-tion simulation of fire on the gpu. In ACM SIGGRAPH2009 papers, 2009, ACM, New York, NY, USA, SIG-GRAPH ’09, 28(3).

[Kaj86a] Kajiya, J. T., The rendering equation. In ACM SIG-GRAPH 1986 papers, ACM, New York, NY, USA, SIG-GRAPH ’86, 1986, pp. 143-150.

[Kri05a] A. W., Akenine-Möller, T., and Jensen, H. W., Pre-computed local radiance transfer for real-time lightingdesign. ACM Trans. Graph. 24, July 2005, pp. 1208-1215.

[Lam02a] Lamorlette, A., and Foster, N. Structural model-ing of flames for a production environment. Proceedingsof the 29th annual conference on Computer graphics andinteractive techniques, ACM, New York, NY, USA, SIG-GRAPH ’02, 2002, pp. 729-735.

[Ngu01a] Nguyen, D. Q., Fedkiw, R. P., and Kang, M. Aboundary condition capturing method for incompressibleflame discontinuities. Journal of Computational Physics172, September, 2001, pp. 71–98.

[Ngu02a] Nguyen, D. Q., Fedkiw, R., and Jensen, H. W.Physically based modeling and animation of fire. Pro-ceedings of the 29th annual conference on Computergraphics and interactive techniques, ACM, New York,NY, USA, SIGGRAPH ’02, 2002, pp. 721–728.

[Slo02a] Sloan, P.-P., Kautz, J., and Snyder, J. Precomputedradiance transfer for real-time rendering in dynamic, low-frequency lighting environments. Proceedings of the 29thannual conference on Computer graphics and interactivetechniques, ACM, New York, NY, USA, SIGGRAPH ’02,2002, pp. 527–536.

[Wei02a] Wei, X., Li, W., Mueller, K., and Kaufman, A.Simulating fire with texture splats. Proceedings of theconference on Visualization ’02, IEEE Computer Soci-ety, Washington, DC, USA, VIS ’02, 2002, pp. 227–235.

[Zha03a] Zhao, Y., Wei, X., Fan, Z., Kaufman, A., and Qin,H. Voxels on fire. Proceedings of the 14th IEEE Visual-ization 2003 (VIS’03), IEEE Computer Society, Wash-ington, DC, USA, VIS ’03, 2003, pp. 36.

[Zha11a] Zhang, Y., Zhu, D., Qiu, X., Wang, Z. ImportantSampling for volumetric illumination of flames. VisualComputing in Biology and Medicine, VR in Brazil, Com-puter & Graphics, 35(2), 2011, pp. 312-319.