A Balrog in the Browser

October 10, 2005
by Andrew M. Phelps and Christopher Egert

Abstract

This article outlines the process of creating a fire simulation with semi-realistic properties for use in a typical game engine or other real-time 3D environment. Fire simulation is broken down into three major areas: point-sprite generation, image animation, and additional effects (smoke, sparks, and glow). Also discussed are additional solutions for multi-texturing and manipulation of the textures needed to produce the simulation, as well as discussion of directions this work could be extended.

An example of the simulation is provided using a Shockwave3D implementation. NOTE: for reasons relating to the glow effect, only the OpenGL render mode is currently supported. This file is written in the Lingo language for backwards compatibility only: it is wholly capable of being ported to the JavaScript-like syntax in DMX 2004. A screenshot of the running simulation is provided in Figure 1:

Figure 1: Fire simulation with projective texturing, refraction, reflection, and secondary texture blending - #OpenGL renderer.

1 POINT SPRITE GENERATION

1.1 TILE GEOMETRY

The fire in this demo is rendered to "point sprites" which are essentially just small, 2-triangle, planar bits of geometry, as shown in the figure below. There is essentially no reason to use anything more complex, as the actually edges of the sprite are ignored due to the alpha of the fire textures.

-- 1 ----------- 2
-- |\            |
-- |  \          |
-- |    \        |
-- |      \      |
-- |        \    |
-- |          \  |
-- |            \|
-- 4-------------3
-- Integers represent positions in the
-- vertex, normal, color, and texCoord
-- List which should all have a length
-- of 4.

Figure 2: Point sprite tile geometry layout. See the "3D_TOOLS" script in the demo for further details.

1.2 CAMERA ORIENTATION

The only real "trick" in using these geometry tiles as point sprites is to apply proper motion to them, and to ensure they are oriented towards the camera. Each type of sprite in the simulation (fire, smoke, glow, spark) implements a set interface, along with any additional functions it may contain. That interface is described below:

mActivate - loads the sprite from the pool of pre-existing geometry (see below) and positions it randomly near the emitter.

mUpdate - is called per-frame, and updates the sprites position, animation, etc.

mMove - moves the sprite in 3D-space, usually called from mUpdate.

mDie - kills this sprite object and places the geometry back on the unused heap.

mSetScale - sets the scale of the sprite.

mSetShader - sets the shader of the sprite.

mSetShaderTrans - sets the transparency of the sprite's shader.

mAnimate - sets the current texture of the sprite's shader to the next one in a pre-created array of textures.

In order to ensure camera orientation, the mUpdate method of every sprite type uses the pre-built Director function pointAt to orient the sprite directly towards the viewing camera.

1.3 MANAGING A SPRITE COLLECTION

Finally, the sprites are managed as a collection through their respective managers. Each of the manager classes (fire, smoke, glow, spark) create a sample mesh tile, and then instance several models from it. These models are stored in a list internal to the manager, and the manager in turn supplies an interface that can hand off a reference to a single tile in the list. The managers then mark this tile as active, and reshuffle the list such that at any time, when the demo requests a tile from the manager, it will receive an unused tile. As sprites call their mDie routine, the sprite is marked inactive in the list and can be handed out again by the manager for re-use.

This is done because of the noticeable overhead in creating models on the fly in Shockwave 3D. While it is more memory intensive to hold all the models in advance, S3D seems to perform better when there is less memory "shuffle" - the exact amount of memory taken up is less of a factor on modern systems.

2 IMAGE ANIMATION

2.1 CAPTURE FROM VIDEO / LIVE CAPTURE

The basis of the fire effect is in fact real fire. This is in contrast to many CG techniques: most particle simulations of fire effects attempt to model the fire from discrete particles or color ramps. The inspiration for the use of real fire imagery comes from the Lord of the Rings fire effect on the Balrog in The Fellowship of the Ring that was done by Weta [1]. In an interview with Weta staff for 3D World Magazine, they stated:

"CG flame effects are notoriously artificial looking, so the use of completely rendered fire was dismissed fairly early on during the production schedule.

"CG fire usually has a soft look to it that you can spot straightaway. We wouldn't have been very happy with that, so it was either a matter of actually setting fire to something and compositing that onto our model or coming up with a better way. We actually did shoot tests using gas jets, sort of doing shadow puppets with real flame, but it never looked close to being convincing. You just never got the right sense of scale."

Instead, the artists made use of Maya's particle system, but rather than rendering the fire as a pure particle effect, individual shots of real fire were added as sprites to each of the 50,000 particle elements. "It means each sprite is animated and then so is the particle itself. The results look pretty incredible." [2]

Similar accounts have of this effect have been echo by others involved with Weta and The Fellowship of the Rings [3].

It did, in fact, look incredible. It spawned several other CG artists to create their own flame effect demos, including two that heavily inspired our work here, the nVidia Corporation "Vulcan Demo" [4], and a popular TrueSpace particle demo [5]. The nVidia demo is particularly advanced in its implementation of real-time flame, including several techniques that map the Weta-style implementation to real-time programmable hardware through shading languages at the vertex and pixel level. Thus, this demo contains additional effects that are not attempted here: heat shimmer, texture warping, and surface instancing are chief among our omissions. Nonetheless, our technique relies on the basis of the WETA technique, and can be described thus:

Figure 3: Process diagram for playing back flame video on camera oriented point sprites.

One minor issue that we had in incorporating this technique was obtaining an original video suitable for dissection into individual images. Unlike the movie industry, RIT, as a general practice, tends to frown upon setting portions of the campus on fire, and as such we resorted to using commercially available alternatives. The best well-known of these is the Combustion video set, which features numerous videos of raging infernos and individual flames from a variety of flammable media, and in a variety of colors and styles. A complete view of our resulting fire imagery is shown in Appendix 1.

2.2 PLAYBACK ON SCALED SPRITE

Once we dissected the video into component images, the images were cropped to maximize the use of texture space. A normal video is generally of such a resolution that individual flame jets do not largely fill the area: flame tends to be higher than it is wide, and common video resolutions are the reverse.

Figure 4: Process diagram for conserving texture space for textures created from video footage of real-world flame.

As such, we cropped the flame sprites to a resolution of 74x144, and then scaled the geometry of the point sprite to a similar aspect ratio in-scene. NOTE: for support of older cards, or just to be more effective in the use of VRAM, the texture sizes in any real use of this technique should be powers of two. Thus, our resolution of 74x144 would map most closely to 64x128 or so. We did not bother with this conversion for the purposes of a tech demo, but any production use of this technique would benefit greatly from a more appropriate texture size algorithm.

2.3 SMOKE

In addition to the basic fire sprites, the second effect needed to pull off the demo is smoke. Smoke operates in exactly the same way as fire sprites with regard to managers and camera orientation. The difference is that they are effected by a wind vector as a part of their movement routine, and they animate though a series of images that appear as an alpha-blended smoke-puff. These images were created in 3D-Studio-MAX using the Combustion(tm) plug-in set [8], and are in fact the second half of the image set used for the authors explosion demo [9]. Samples of the smoke sprites are shown below.

Figure 5: Smoke images created in 3dsMAX that fade in and out on alpha scale. Previously used for explosion demo.

2.4 GLOW

The second effect used to enhance the basic fire sprites is the additive blending glow that serves as a backdrop to the video texture. This glow effect can be greatly enhanced by "brightening" the images in the GLOW_IMAGES cast.

The actual technique used to create the "glow" effect is the same additive-blending technique that has been circulating the dirGames-L and dirGames-3D lists for some time. This technique has been well documented by Duffin [6], and by Noisecrime [7]. The technique basically involves creating a number of 'invisible' texture layers behind the desired map, enough to force the hardware into a second draw pass thereby enabling a true 'additive' color modulation. Unfortunately, since its release in 2003, better hardware has become available that under the DirectX7 driver cannot be "tricked" into a second pass. For this reason, and for a more believable sprite-lighting scenario, we recommend using the OpenGL render mode for this effect if at all possible. If DirectX7 is required, then the glow feature will need to be disabled.

2.5 SPARKS

The sparks thrown up by the fire in this demo are simply glow-sprites with a much brighter additive texture, scaled down appropriately relative to the other sprites in the scene. They are given their own manager and sprite class such that their movement method can be differentiated, but beyond that there is no discernable difference between the sparks and any of the other sprite types, with the following exception:

The number of sparks in the scene is controlled in a completely different manner than the other types of sprites. Every other sprite category in the scene uses n number of new sprites per frame, meaning that every frame, n- new sprites of that type are born. Thus, for fire, 1 new fire sprite is added to the simulation per frame (which eventually dies off as its animation is played out). For smoke sprites, 2 new instances are created per frame, and 1 new glow sprite is also added. Sparks operate differently, on a "chance per frame" basis. At startup, a constant limiter is set from 0-100 that represents the possibility that a spark is born. Every frame, a random value is selected in the same range, and compared to the pre-determined value. If the random value is within the range set by the limiting factor, then a spark is created.

3 FUTURE WORK

3.1 SURFACE INSTANCING

The current emitter positions sprites by randomly distributing them in the X/Z plane within a certain boundary value. While this is adequate for a perfectly flat burning surface, the effect would be decidedly unconvincing for any complex surface, or worse yet character mesh. It should be possible to either use several small emitters bound to a given surface or, perhaps better yet, to instance the point sprites across the surface of a mesh. There has already been work in the area of normal-aligned instancing that looks ripe for incorporation into this technique [10].

3.2 REAL VIDEO SPRITES

Finally it should be noted that much of the complexity of this demo is derived from the process of splitting the video source imagery into component textures and playing them back. It may be advantageous to directly slam the video into the texture rather than to chunk it into individual flames - but doing so is not directly supported in Shockwave 3D. Nonetheless, it is entirely possible to build an Xtra to do such work if it is needed, this functionality is already included (for an entirely different purpose) in the Designer's Augmented Reality Toolkit (DART) Xtra that is available from the Georgia Institute of Technology GVU Center [11]. It is unclear if the benefits of video compression and control would outweigh the ability to sample the video at discrete time intervals when creating the texture array, but this should be fully explored for any production use of these techniques.

4 CONCLUSION

This demo explores the combination of several current techniques to construct a simulation of semi-realistic fire. While the fire produced here is visually acceptable, it would be greatly enhanced (and operate significantly faster) through a shading language, similar to the nVidia Vulcan demo. However, since many environments still do not support such a language, this implementation may provide a decent alternative until that technology is more widely adopted. This fire simulation should provide some insight into how to establish real-time flame for other games and virtual worlds that require such a visual effect.

REFERENCES

[1] Weta Digital, Ltd. and Weta Workshop, Ltd. Online: http://www.wetadigital.com/

[2] 3D World Magazine. Weta Interview. Vol. 1, Issue 22. http://www.computerarts.co.uk/3dworld.

[3] Feeny, Catherine. "Making Middle-Earth: 'The Lord of the Rings'". Available online: http://www.theonering.net/perl/newsview/8/1009002788.

[4] Nguyen, Hubert. "Fire in the 'Vulcan' Demo", in GPU Gems: Programming Techniques, Tips, and Tricks for Real-Time Graphics. Fernando, Randima, Ed., pp. 87-105, 2004, Boston, MA. Cited October 4, 2005.

[5] Moleman, Christian. "Realistic Fire, Weta Style." TrueSpace4 Demo Article.

[6] Duffin, Malachy. "Additive Blending Effects in Shockwave 3D." Director Online User Group (DOUG). Available online: http://director-online.com/ buildArticle.php?id=1110. Cited Oct 1, 2005.

[7] Noisecrime. "Additive Blending Tutorial" Noisecrime Productions. Available online: http://director-online.com/buildArticle.php?id=1110. Cited October 1, 2005.

[8] Autodesk, Inc. Autodesk Combustion. Available Online: http://usa.autodesk.com/. Cited October 1, 2005.

[9] Phelps, A. and A. Cloutier. "Simulation Arcade-Style Explosions in Game Environments. Director Online User Group (DOUG). Available Online: http://director-online.com/buildArticle.php?id=1129. Cited October 1, 2005.

[10] Higgins, Tom. "Tree Scattering Across a 3D Terrain" Macromedia. Available Online: http://poppy.macromedia.com/~thiggins/articles/scattering/. Cited October 1, 2005.

[11] MacIntyre, Blair, et. al. "The Designer's Augmented Reality Toolkit" Georgia Institute of Technology, GVU Center. Available Online: http://www.cc.gatech.edu/projects/ael/projects/dart.html. Cited October 1, 2005.

APPENDIX 1: COMPLETE FIRE SPRITE IMAGERY

APPENDIX 2: FIRE AT VARIOUS CONFIGURATIONS AND SETTINGS

Fire demo with extra glow, extra smoke, and extra sparks, respectively.

Shockwave Demo: FINAL_FIRE_DEMO.dcr

Source File: FINAL_FIRE_DEMO.zip

Andrew (Andy!) is a professor at the Rochester Institute of Technology (RIT) serving in the Dept. of Information Technology, specializing in Multimedia and Web Programming. He is developing a game programming curriculum, with an emphasis on Lingo based solutions as well as more traditional approaches. Visit his home at andysgi.rit.edu. Christopher A Egert is an assistant professor in the Interactive Media Group of the Information Technology Deptartment at the Rochester Institute of Technology. http://www.it.rit.edu/~cae/.