1) Background

2) Prior works

- Reeves (1 and 2)

- Fireworks paper

- Hydrocode simulations

3) Discuss research to date

- experiences with books on fluid dynamics

- change of approach to finding hydrocode simulation

- discarding of this approach

- decision to model spherical shock wave

4) Project status

5) Bibliography

There are two general approaches taken in the simulation of

explosions; particle systems and hydrocode simulations. Particle systems

make use of a large number of individual particles to model the appearance

of an explosion, and to date have been mainly used in motion pictures.

(In particular, Reeves' simulation of a ring of explosions expanding

over a planet surface in "Star Trek II: The Wrath of Khan" bears mention.)

Hydrocode simulations make use of fluid dynamics equations to model

the behavior of explosions more realistically, and have to date been

mainly used by engineers for visualization. The purpose of this paper

is to discuss my research into these techniques, and to discuss the

methods I am using in my project to simulate explosions.

In this section, I will give a brief overview of some prior work

that has been done in this area. I will discuss mainly particle systems,

though I will briefly address hydrocode simulations as well.

Reeves (1 and 2)

The idea of using particle systems for modeling objects was

first brought to prominence by William T. Reeves (then of Lucasfilm, Ltd.) in a

paper called "Particle Systems" -- A Technique for Modeling a Class

of Fuzzy Objects" [REEV83]. In this paper, he describes how particle systems

differ from other methods of modeling, describes the basic model of

a particle system, and describes some potential applications of particle

systems.

A quote from the paper would be best to sum up how particle

systems differ from other methods. "The representation of particle systems

differs in three basic ways from representations normally used in image

synthesis. First, an object is represented not by a set of primitive

surface elements, such as polygons or patches, that define its boundary,

but as clouds of primitive particles that define its volume. Second, a

particle system is not a static entity. Its particles change form and move

with the passage of time. New particles are "born," and old particles "die."

Third, an object represented by a particle system is not deterministic, since

its shape and form are not completely specified. Instead, stochastic

processes are used to create and change an object's shape and appearance."

[REEV83, pp. 359-360]

Reeves discusses several advantages of particle systems over

other methods:

1) Particles are simple, the simplest drawing primitive possible. Because

of this, it is possible to render many more primitives for the same computational

cost, resulting in the ability to render more complex images.

2) The model definition is procedural and parameterized. A highly detailed

model can be rendered without requiring large amounts of human intervention

to lay it out.

3) Particle systems are dynamic by their very nature. This means that they

are naturally suited to animation.

Reeves then describes the basic conceptual model of a particle

system.

"1) New particles are generated into the system.

2) Each new particle is assigned its individual attributes.

3) Any particles that have remained within the system past their

lifetime are extinguished.

4) The remaining particles are moved and transformed according to

their dynamic attributes.

5) An image of the living particles is rendered in the buffer. " [REEV83, p361]

Under "particle generation," Reeves gives several methods

for determining the number of new particles to be generated; this can

be done either by choosing a predetermined mean number of new particles

to generate (plus or minus some random factor), or by making the

number of particles to generate a function of screen size.

Under "particle attributes," Reeves lists several attributes

that must be determined:

1) initial position.

2) initial velocity (speed and direction).

3) initial size.

4) initial color.

5) initial transparency.

6) shape.

7) lifetime.

Under "particle extinction," Reeves suggests that the particle

be assigned a lifetime of a predetermined number of frames, and that

this value be decremented for each frame rendered. When the lifetime

value reaches zero, the particle is extinguished.

Under "particle dynamics," Reeves discusses how to modify the

particle's position as a result of its velocity, and as a result of

other accelerations on the particle (i.e. the force of gravity). Also

discussed is how to manipulate the color of the particle over time.

Under "particle rendering," Reeves discusses two simplifications

to the rendering process that are possible in particle systems. First, he

assumes that the particle system need not interact with other surface-based

scene elements; this means that the rendering algorithm need only

handle particles. Second, he assumes that each particle is a point light source;

thus, you need not worry about calculating the shadows of particles.

Reeves then goes on to describe some of the methods used in

generating the wall of explosions that appeared in "Star Trek II; The

Wrath of Khan," to suggest some other potential applications for

particle systems (simulated fireworks, rendering of particle systems

on line-drawing display hardware, and modeling of organic objects

such as grass), and to discuss ongoing research into the modeling of clouds

and other topics.

Finally, Reeves offers several conclusions. He concludes that

particle systems have proved efficient to render, and that they allow

highly-detailed modeling of dynamic events that would not otherwise be

possible.

In 1985, Reeves, together with Ricki Blau, presented another

paper on the topic of particle systems, "Approximate and Probabilistic

Algorithms for Shading and Rendering Structured Particle Systems." [REEV85]

This paper builds on the work in [REEV83], and is mainly devoted to

discussion of using particle systems to render objects such as plants,

trees, and grass (in contrast to the previous paper, which was mainly

concerned with modeling amorphous phenomena such as explosions). Because

of this, this paper is of limited utility in furthering the work I

am doing.

In the paper "Rendering Fireworks Displays," [LOKE92] the authors

describe the creation of a program that can be used to render simulated

fireworks displays using a particle system. The program they created

is made up of several components. First, there are two sets of particles,

live particles and dead ones. The dead particles are preserved and reused

in the interest of efficiency; it is computationally cheaper to preserve

the particles and reuse them than it is to deallocate and reallocate

memory for particles as they are born and die. Another component of their

system is the particle system rendering engine (PSRE), which is responsible

for handling all modifications to velocity, color, and other particle

attributes. The list of active particles is fed into the PSRE, which

draws the particles to the display buffer. After the particles have been

drawn, they are run through a standard series of viewing transformations

and rendered to the video display buffer.

Loke, et. al, handle color by using the alpha value of the particles

(as in OpenGL, the alpha value represents transparency, and can be varied

from completely opaque to completely transparent) to gradually fade out

each particle. When the particle becomes completely black, it is removed

from the pool of active particles and assigned to the dead particle pool,

for eventual reuse. In order to enhance the visual effects possible,

each particle is assigned a value called "delta-RGBA", which is then added

to the alpha. This allows the particle to be brightened or darkened

simply by changing the sign of the delta-RGBA value; this effect is useful

in simulating fireworks particles that alternately darken and brighten

again. The system also allows the RGB components of the system to be

modified, so that the particles can change colors, say from red to green

to blue.

The system described in [LOKE92] is also able to simulate

the effects of differently-shaped shells. In "real life", aerial fireworks

come in two shapes; cylindrical and spherical. Each of these shapes

has different properties. The system is capable of modeling these, and

of modeling other shapes as well. This is done by changing the distribution

of particles when they are initialized. For a spherical effect, the particles

are distributed roughly on the surface of a sphere around an imaginary

center. Cylindrical shells are modeled by distributing the points in

the shape of a cylinder. (This system is interesting because the user

is able to program in unusual shell shapes that have never been used

in real-world fireworks displays; the authors experimented with such

unusual shapes as conical or cubic).

By manipulating the direction and velocity of the particles, they

were able to get such effects as "spinner" particles that spin around

in corkscrew fashion as they move. When combined with the "trail" effect

built into the system, this is quite impressive-looking (judging from

the still photographs included in the article -- I haven't seen the

system in action).

Hydrocodes

In the early portion of my research, I spent a lot of time looking

for hydrocode simulations. Hydrocode simulations are fluid dynamics programs

used widely in the defense industry for visualization of the processes

that occur in explosions. The use of hydrocode simulations is discussed

in both [TAKA92] and [MEYE94]. However, the discussion is centered on

the use of hydrocode programs in experimental simulations of the

effects of explosions on material; the hydrocode software itself is

not discussed in detail. I was unable to find any documents that described

the design of such software in searches through George Mason's XLIBRIS

system, or in searches through the various search engines available

on the World-Wide Web (Yahoo, Lycos, Excite, AltaVista, etc.). Similarly,

I was unable to find any publicly-available source code for hydrocode

simulations. Several weeks ago, despairing of ever finding anything

on hydrocodes that I could work with, I decided to stop pursuing

further information on hydrocode simulations. Aside from the lack of

success in locating examples, perusal of the available literature

on hydrocodes suggested that they are very computationally-expensive

programs that are used mainly for scientific visualization rather than

for interactive programs. However, I am confident that there are

areas of hydrocode simulation that can be optimized to allow for their

use in real-time simulations; for more thoughts on this, see my section

below on "future work."

In this section, I will discuss the properties of "real-world" explosions.

I enumerate some of the characteristic properties of explosions, and

describe each of these properties.

In the introductory section to its chapter on detonation, [Mey94] has

this to say about explosions:

[Mey94, p. 244]

This admirably sums up the essential properties of explosions;

that they are very rapid processes, and that they produce large volumes of highly

compressed gases.

[Mey94] goes on to state: "Fast chemical reactions involving the production

- Detonation" [Mey94, p. 244]

Generally, explosions which deflagrate are known as "low-order explosives."

The two most well-known members of this class are black powder and

modern smokeless powder; both of these are used in firearms as propellant

charges. Explosions which detonate, on the other hand, are known as "high-order

explosives." This group contains such well-known explosives as TNT,

dynamite, and C-4. [Mey94] distinguishes between deflagration and detonation

by the fact that a detonation produces a shock wave, whereas a deflagration

doesn't. [Dav43] distinguishes between high and low explosives by the

method used to initiate the reaction; whereas low-order explosives are

set off by an ignition spark or flame, high-order explosives will detonate

only if exposed to shock. Sensitivity to shock varies; most high explosives

used for military or commercial purposes are so insensitive to shock that

they will not detonate without help from a small charge of "primary

explosive."

Here is a table of common explosives and their detonation velocities (from [USA62]).

While the previous section focused on the properties of the explosives themselves,

this section focuses on the effects of explosions on their surroundings.

The study of the properties of shock waves is a field in itself. ([TAKA91] is

a two-volume set of proceedings from a single conference on shock waves). I will

not attempt to exhaustively discuss shock waves in this paper, but I will briefly

discuss them here, because they are an interesting and important part of the phenomenology of an explosion.

[Mey94] uses the example of a piston to describe a shock wave. Assume that

you have a cylinder filled with compressible fluid and a piston at one end. If the piston

is rapidly forced into the cylinder, the fluid compresses, but it doesn’t compress evenly.

Between the head of the piston and the as-yet-unaffected body of liquid is a layer of

super-compressed liquid that is being squeezed between the piston face on one side and

the inertia of the surrounding liquid on the other side. This layer of super-compressed

liquid is essentially a shock wave. In an explosion, the piston is replaced with a rapidly-expanding ball of gas, but the idea is essentially the same.

"Charles Edward Munroe, while working at the Naval Torpedo

Station in Newport, discovered in 1888 that if a block of guncotton

with letters countersunk into its surface is detonated with its lettered

surface against a steel plate, the letters are indented into the surface of the

steel. Similarly, if the letters are raised above the surface of the guncotton,

by the detonation they are reproduced in relief on the steel plate, embossed

and raised above the neighboring surface. In short, the greatest effects are

produced on the steel plate at the points where the explosive material stands

away from it, at the points precisely where explosive waves from different

directions meet and reinforce each other. Munroe found that by increasing the

depth of the concavity in the explosive he was able to produce greater and

greater effects on the plate, until finally, with a charge that was pierced

completely through, he was able to puncture a hole in it." [Dav43]

A shaped charge is one which is built with a concavity in it. This

concavity results in the Munroe Effect discussed above. In shaped charges

designed for the penetration of armor, the concavity is typically lined

with metal, which results in the formation of an extremely fast-moving

jet of superheated metal, capable of burning a hole through many inches of

steel.

When an explosive shell detonates, it throws fragments of the

shell for quite long distances. [Mey94] gives a set of equations called

the Gurney equations [Mey94, p. 234] that are used to predict the velocities

of these fragments.

For cylindrical objects, the Gurney equation is:

V0 = sqrt (2E) (M/C + ½) ** (-1/2)

V = V0 (r/a)

where V0 = the initial velocity of the fragments

E = a value for the chemical energy of an explosive

M= the mass of the cylinder

C= the mass of the explosive

r= the outside radius of the cylinder

a= the inside radius of the cylinder

sqrt = the square root function

**= the exponentiation operation

For spherical objects, the Gurney equation is:

V0 = sqrt (2E) (M/C + 3/5) **(-1/2)

V = V0 (r/a)

At first glance, these equations seem somewhat arbitrary. But [MEYE94] states:

and arrived at expressions relating the velocity of fragments to the ratio C/M." [MEYE94, 234] So, though the equations are quite simple, they are also quite accurate.

My initial intent for this project was to find a set of equations

that described the behavior of an explosion, transform them into a program,

and use them to drive an explosion simulation. This approach was frustrated

by the lack of literature on the behavior of explosions. There is a

reasonably large body of work available on the effects of explosive stresses

on engineering materials ([MEYE94] in particular does a thorough job of

discussing this area), but nothing I have found to date has discussed

the behavior of the explosion itself. Books that I examined on the topic of fluid dynamics and fluid mechanics dealt mainly with more typical engineering fluid problems (flow through pipes, velocity of flow out of a nozzle, etc.). I was unsuccessful in my search for a set of equations that described the behavior of an explosion. I assume that it is possible to derive such a set of equations from first principles, but my skills in

mathematics and physics are simply not up to such a task.

As I experienced no success in finding a set of equations with

which to model the behavior of an explosion, I next determined to find

a hydrocode simulation that had already been built and modify it to

suit my needs (in large part, this optimization would have consisted

of stripping out much of the detailed behavior that makes hydrocode simulations

useful to engineers (as well as too computationally expensive for use

in real-time graphics simulations). Again, however, I experienced little

success in finding sources. The few elements of literature that mentioned

hydrocode simulations were generally engineering papers in which hydrocode

simulations were used to analyze the behavior of materials. I found no

papers that discussed the hydrocode simulations themselves, or how

to build them. Searches for source code proved equally fruitless. I

was able to locate several sites on the World-Wide Web that discussed

hydrocodes; however, the codes that I found were either very expensive

commercial packages or were packages available only under license from

the U.S. government. Also, discussions with engineers on the USENET

newsgroup sci.engineering.mech (a newsgroup devoted to mechanical

engineering, and one of the very few places where I found references

to hydrocodes on USENET) convinced me that hydrocodes are simply too

computation-intensive for use in real-time simulation.

At this point, I regretfully decided to abandon the idea of doing

an explosion simulation based on fluid dynamics. I did this regretfully,

but I felt that I had no choice, as I had exhausted all sources of

information that I had found so far, and didn't feel that any new

sources were likely to turn up in a timely fashion. Additionally, the

information that I had located about hydrocodes indicated that they

were much too computation-intensive in their present form to be useful

without extensive modification. Were I able to get access to the source

code for a hydrocode simulation, it would undoubtedly be huge, poorly-

commented, and difficult to follow. Based on past experience with trying to

maintain and modify such unwieldy systems in a commercial environment,

I felt that it would take more time to understand and optimize such code than

it would to build my own simulator.

At this point I was left wondering what to do. I decided to see

if there were other ways to model an explosion besides the fluid dynamics

method that would also yield the environmental interactions that the

fluid dynamics method would, but in a more computationally efficient

fashion. In looking into shock waves, it became apparent that the

shock wave can be modeled as essentially a thin shell of intense

pressure. That is, the pressure before the shock wave arrives is normal,

the pressure within the shock wave is very high, but the shock wave

is quite thin, and after it has passed through an object, the pressure

drops off quite rapidly. Essentially, the shock wave of an explosion in

air can be modeled roughly as an expanding sphere.

- decision to model spherical shock wave

Finally, here was something approachable. The explosion's

interaction with its environment could be modeled as an expanding sphere.

Deformation of the sphere as a result of contact with the ground is

a difficulty, but for a first trial, the explosion could be modeled in

midair, so that this difficulty is avoided.

Here is an ultra-simple object diagram to illustrate the objects that make up the final program.

There are basically five classes of object in the system: the

Point object (a particle, an element of the particle system), the Explosion

object (a group of particles with a shock wave sphere), the SceneObject

object (an object in the scene that is affected by the explosion), and the

Scene object (this is the parent object that holds all the scene objects

within it. Initially, the user plots the positions of the various

SceneObjects, and also plots the origin points of the various Explosion

objects. At each iteration, a set of Points are allocated and stored in the List

object. As these Points fade out, they are removed from the "live" list and

stored in the "dead" list for later recycling. The points are generated in a

sphere around the center of the Explosion. As each point is allocated, it is

also initialized with an initial velocity and an alpha value of 1 (for complete opacity).

SceneObject objects are initialized with a velocity of zero.

After the initialization, the program enters a rendering loop. In

each loop step, the position of the particles is recalculated, the

alpha value is diminished by a given amount, and the scene is rendered.

Each scene object will contain the appropriate OpenGL code needed

to render itself. The scene will be rendered by the Scene object

iterating through its internal arrays of SceneObject and Explosion

objects, calling the draw() method of each one.

After rendering the scene, the top-level program calls a method

of the Scene object called recalculateScene(), which in turn calls

the recalculate() method of each object in the scene to calculate its

new position. The program continues to loop through the drawScene()

and recalculateScene() methods until all particles in the scene

have died out. The current design does not allow for generation of new

particles; initially, a dense cloud of particles is generated surrounding

the center of the explosion, and those particles remain alive until

they fade to complete transparency, at which point they are considered

"dead," and are no longer rendered. As the system is not yet operational,

it remains to be seen whether this is sufficient to provide a decent

simulation. If it is not, I will add generation of new particles into

the system.

The shock wave sphere exists within the cloud of particles, and

expands as the particle system expands at the same average velocity

of the particles. When the sphere encounters a SceneObject (that is, when

the distance from the center of the explosion to the nearest point

of the object is less than or equal to the radius of the sphere), the

SceneObject's velocity is modified to some fraction of the velocity of

the sphere (it will take some experimentation to find the appropriate

value for this; I feel that it is probably better to simply find

a reasonable multiplier than to go through the calculations necessary

to find the pressure applied by the shock wave to the surface of the

object and calculate the velocity of the object as a function of this).

The direction for the motion of the object is determined by calculating

the direction vector from the center of the explosion to the nearest

point on the object.

For simplicity's sake, I am currently keeping the shock wave model to

a simple non-deformable sphere, ignoring the interaction of the

shock wave with other shock waves, and ignoring the presence of the

ground. A simple expedient method for accounting for the ground would

be to assume the ground is at height 0, and to not calculate motion

for anything at or below the ground. Particles reaching height 0 could

be reflected elastically.

I am intentionally keeping the user interface quite simple at this point.

I envision that the user interface will be a simple series of standard-input prompts for

the number of explosions, center of an explosion, number of particles

to be plotted in an explosion, number of scene elements, location of each

scene element, and so forth. For ease of testing, I may provide a file interface, so

that the program can read its initialization values in from a file. If time permits, this

code could easily be attached to a GUI-type user interface for ease of operation, but, as I’m currently dividing my programming time among Unix workstations, a Windows 95 machine, and a Windows 3.1 machine, I’d like to keep the code as free of system dependencies as possible for as long as possible.

I used a type called SceneObject in order to allow for extensibility; in the initial implementation, I intend to use only very simple objects. Most likely, these objects will be cubes of a single color.

After deciding to do a particle simulation rather than a pure

hydrocode simulation, my first objective was to get something up and

running as soon as possible. However, I did not want to simply cobble

together a solution to a specific problem that would not work well

when I attempted to generalize it later on. With this in mind, I set

out to make sure that the design for the project would be flexible

enough to accommodate future modification. I chose to implement the

project in C++ rather than in straight C because I felt that the

best way to attack the problem was by doing an object-oriented analysis

of the elements of the problem; C++ would allow me to keep the object-

orientedness of the design throughout the development cycle. Further,

I felt that the project had the potential to grow to be quite large

as it developed. When this occurs, it becomes difficult to keep track

of the entire project; in this situation, it is useful to break the project up

into encapsulated objects, so that you can work with the details of

implementation of one object without fear of inadvertently modifying

a value depended upon by an obscure piece of code in another module.

For the design step, I decided to encapsulate the entire functionality

for rendering a scene inside a "Scene" object. This allows the main routine

to be kept very simple; aside from basic setup (setting OpenGL options,

creating a window, installing a display loop callback function, etc.),

the core functionality of the main function is contained in a few

lines of code in the display callback function, which makes repeated

calls to the move() and draw() methods of the Scene object.

The Scene object is responsible for everything needed to draw

the scene. It contains two main types of data; a set of Explosion objects

and a set of SceneObject objects (these objects will be described below).

As currently implemented, the Scene object can contain up to 10 Explosions

and 10 SceneObjects; as an enhancement, I plan to replace the fixed-dimension

arrays currently used with linked lists, so that the scene can contain

any number of Explosions and SceneObjects.

The Scene object has two main public methods that are called by

the program in which it is used; a move() method and a draw() method. The

move() method simply traverses through the set of Explosions and the

set of SceneObjects, calling the move() method of each. This is where

the positions of particles, particle alpha values, object positions, and

so forth, are modified. Similarly, in the draw() method, the draw()

methods of all of the constituent Explosion and SceneObject objects

are called. These methods are responsible for drawing the object in its

current state to the currently-open OpenGL window.

The Explosion object is the meat of this project, and where most

of the source code and complexity is found. The Explosion object has

the same two main public methods as the Scene object; a draw() and a

move() method. The move() method is responsible for all necessary

modifications to the position of the Points in the Explosion; including

the generation of new Points into the system and the removal of

"dead" Points from it. The draw() method simply traverses the list

of live particles, drawing each one in according to the values for red,

green, blue, and alpha stored within each point.

The Explosion object contains quite a few variables that are

used to maintain the state of the explosion. These variables include:

- the number of points to be generated at each time step

- the x, y, and z coordinates of the center of the explosion

- two linked lists of Points, one for live particles and one for dead ones

Because a particle system requires that new points be generated

into the system at each time step, my initial scheme of using

a single generation of a large number of points needed to

be replaced with multiple generations of points. The livelist

is a way to contain these points in a convenient way. The

deadlist is included for efficiency. As particles fade and die,

they are removed from the live list, their variables are

zeroed out, and they are placed into the dead list. This

allows the particles to be reused, rather than forcing me to

free and then recreate them. This works well because a single

generation of particles will tend to die out in the same time step;

This means that, after the particles begin to die out, they are

added to the dead list, but are immediately reused by the

process that generates new particles into the system. Thus

memory allocation and usage approach a steady state as soon

as particles begin to die out. This is important, because

large numbers of particles are required to make a realistic-looking

explosion.

- the initial radius of the explosion

- the initial red, green, blue, and alpha values for the particles

- the initial velocity of each particle

- the amount to decrement alpha at each time step

- the number of time steps in which to generate new points

Though I found that the generation of all particles in a single

time step was unsatisfactory (because it led to an "expanding

shell" effect rather than a good "fuzzy" explosion), I found

that the continuous generation of points for an indefinite

period was equally unsatisfactory; rather than looking like

an explosion, the result looked rather like a frothing cloud.

As a compromise, I inserted an integer value that indicates

the number of frames in which new particles will be generated.

I am still experimenting with this behavior, but it appears

to give best results when new points are generated for only

a small number of frames (30 or less).

The Explosion object has one other particularly interesting method;

this method is called generate_points_on_sphere(). I found a description

of the algorithm used to do this in the description of a Fortran function

called VRAN3S contained in the CERNLIB (the URL describing this routine is

"http://wwwcmd2.inp.nsk.su/cernlib/shortwrups/node155.html"). The basic

idea behind the algorithm is to generate random x, y, and z coordinates

in the range from -1 to 1 (i.e. within a cube about the origin). As each

point is generated, the distance formula is applied to see whether the

point falls within the unit sphere from the origin. If it is not within

the sphere, it is discarded; otherwise, the point is projected onto

the surface of the unit sphere. This process continues until the requisite

number of points have been projected onto the sphere.

- The Point object

The Point object is used to keep track of the color, position, and

velocity of each particle in the system. It has no public member

functions, and its data elements consist of:

1) its x, y, z, position

2) values for each component of its RGBA color

3) its directional velocity (dx, dy, dz)

- The List object

This is a doubly-linked list structure that I have recycled from an

earlier course at GMU. Were I developing this project under a single compiler,

I probably would have used a vendor-specific List class, or one

of the Standard Template Library (STL) collection classes. However,

I am using several platforms to develop this project, and I wanted

to protect myself against potential library incompatibility problems

by maintaining control of the source code myself.

- The SceneObject object

I've learned how to use OpenGL.

I've learned how to implement a particle system to graphically

represent a dynamic object or process.

I've learned that there are no sources available to me

that describe the behavior of explosives in terms that would

be useful as the foundation for a simulation.

I've learned that there are no freely-available hydrocode simulations

of explosions

Some conclusions that I have come to about hydrocode simulations are:

1. Hydrocode simulations to date have been mainly concerned with visualization for engineers, and have not been intended to provide real-time, realistic-looking depiction of explosions.

2. Hydrocode simulations, when used to calculate an entire volume, are too slow to be used for real-time graphics at this time. This is addressed in [KASS90]: "The problem is that truly a accurate simulation of fluid mechanics usually requires computing a motion throughout a volume. This means that the amount of computation per iteration grows at least as the cube of the resolution. If there are linear systems to be solved at every iteration, the computational cost can grow even faster. In addition, the number of iterations required may grow as the resolution is increased. As a consequence, accurate simulations of fluid mechanics is typically reserved for vectorized supercomputers or very highly parallel machines." [KASS90, pp.49-50]. (This paper presents a method for fast fluid dynamic simulation of waves in shallow water by calculating only the motion of the surface, and ignoring calculations within the volume. This is one of the approaches that I wished to try if I had been able to find a hydrocode simulation.)

Gravity sources: The current model does not contain gravity sources. It would be possible to account for gravity as a simple acceleration in the z direction. However, I would like to do a more general solution. Instead of a single planar source of gravity, I would build a set of GravitySource objects that would be managed by the Scene object. A GravitySource could be either a point source or a planar source. This would make it possible to model both explosions occurring on a planet surface (in which case the planar model would hold; gravity would be modeled as an attractive force applied in a direction normal to the plane defined as the gravity source), or in free space (in which case the GravitySource(s) would be modeled as points that exert an attractive force in all directions from their centers). The point-source model is attractive because it would allow the SceneObjects to be assigned GravitySources, which would cause them to exert a gravitational force upon one another.

Exploding particles: Explosions could include sub-explosions, which would be attached to the Point objects. This would yield a "cluster-bomb" effect, in which a single originating explosion throws out a group of sub-explosions, which explode after a time interval has passed.

Exploding objects: In a similar fashion, an Explosion object could be associated with a SceneObject object. When the blast wave from an Explosion encounters a SceneObject, the SceneObject could detonate.

Frame-based rendering: In order for these effects to be filmed, it is necessary for a camera to take a picture of the screen at each iteration. Rather than entering an animation loop, the simulator could be made to render on a frame-by-frame basis, so that this filming process could be done more easily. This would be as simple as replacing the current display loop with a simple while() loop.

More complex scene objects: Scene objects are currently rendered by using the simple object rendering from the Glaux library. It would not be too difficult to inherit objects from a base SceneObject object, and override their draw() methods, in order to render more complex objects.

Shattering of objects: [Eng95] describes some quite interesting work that has been done with the shattering of arbitrary computer graphics models. It would be interesting to add shattering objects to my explosion simulator. Each SceneObject could have a shattering threshold, which could probably be implemented as simply the minimum velocity a blast wave must have in order to shatter the object. If the blast wave does not have sufficient velocity, the object will simply be displaced, as it is now. However, if the velocity of the blast wave is larger than the shattering threshold, the object will shatter. [Eng95] implemented shattering by simply breaking up complex tessellated objects into their constituent polygons and applying velocity and rotation to those polygons. I have seen this effect in several television advertisements, including the ad for the movie, "Mission Impossible," in which the Mission Impossible logo is exploded into fragments. In this particular instance, it looks as if the exploding object was combined with a "real-life" explosion for greater realism.

Camera fly-through: It should be possible, without too much difficulty, to add a moving camera to the simulation. That is, the camera is initialized with a velocity and given a series of points that make up the track that it is to follow, and it moves from point to point at the given velocity. This would make it possible for the camera to "fly through" an explosion or series of explosions, which could be an interesting visual effect.

In the course of implementing this project, an idea occurred to me for a potentially interesting special effect using particle simulation and a generic image; the effect would be to dissolve the image into a particle cloud. The idea is as follows:

1) An image is read in by the program.

I am not sure what the ideal format for this image would be, but I would assume that one of the standard image file formats currently in use (JPEG, GIF, BMP, TIFF, etc.) would be adequate. For maximum utility, the program should be able to read in at least one standard image format; this means that the programmer will not have to implement a program-specific file format and/or file conversion utility. As long as the program is able to read in a single standard image format, the user will be able to use one of the many shareware image conversion utilities available to convert their images to the desired format. Thus, by being able to handle a single standard image format, the user will be able to process nearly any image they desire.

2) Each pixel of the image is assigned to a particle.

The program will convert the color scheme stored in the particle to an RGBA value, and will assign initial x and y coordinates to the particle based on its position in the bitmap. The initial onscreen image should be an exact duplicate of the appearance of the bitmap. Because the initial image is 2-dimensional, I assume at this point that I will deal only with x and y coordinates and do the effect as a 2-dimensional effect.

3) The initial image is displayed.

4) Each particle is assigned a random velocity (i.e. random values in some negative-to-positive range are chosen for delta-x and delta-y).

5) In each of the following frames, the particles are moved by adding delta-x to x and delta-y to y, and re-plotted.

The alpha value of the particles could also be decremented at each step, so that the image not only dissolves but also fades.

The end result of this should be the ability to gradually dissolve an arbitrary image into a random cloud of particles. Additionally, if the process is filmed and then reversed, the image will appear to coalesce out of a cloud of random points. Potentially, this effect could be used in films to materialize or dematerialize arbitrary objects in motion pictures. (The dissolve effect could be done against a "blue-screen" background and then integrated with the main film later; this is a standard method of introducing special effects into films).

I remain convinced, if only at an intuitive level, that the

problem of doing a fluid-mechanics-based 3d real-time simulation of an

explosion is not inherently intractable. I believe that the technique

described in [Kas90] (performing the fluid mechanics calculations only

on the surface instead of throughout an entire volume) holds promise.

Even if it is not possible to calculate a purely 2-dimensional surface,

the calculations could be performed for only a thin shell near the

surface of the explosive phenomenon.

Further, it would make eminent good sense to use a particle

system to model this. Really, there is no other alternative, unless the

surface of the explosion is modeled using large numbers of very small

polygons.

Finally, though I believe that this work is possible, I think

that it will require a thorough understanding of fluid dynamics on the

part whoever attempts to implement it. In fact, I would predict that

a physicist or engineer with a moderate background in computer graphics

would have a better chance for success than a computer graphics expert

with a smattering of physics and engineering. Failing that, I believe

that a collaboration between a skilled physicist or engineer and a skilled

computer graphics programmer would also bear fruit; The physicist/engineer

would be responsible for providing equations that describe the behavior

of an explosion, and the graphics programmer with transforming those

equations into a program.

[Smi84] Smith, Alvy Ray -- "Plants, fractals, and formal languages"

Computer Graphics, vol. 18, number 3, July 1984, pp. 1-7

[Por84] Porter, Thomas and Duff, Tom -- "Compositioning digital images"

Computer Graphics, vol. 18, number 3, July 1984, pp. 253-259

[Sim90] Sims, Karl -- "Particle animation and rendering using data parallel computation"

Computer Graphics, vol. 24, number 4, August 1990, pp. 405-413

[REEV85] Reeves, William T., Blau, Ricki "Approximate and Probabilistic Algorithms

for Shading and Rendering Structured Particle Systems"

Computer Graphics (Proc. Siggraph) Vol. 19, No. 3, July 1985, pp. 313-322

[REEV83] Reeves, William T. "Particle Systems -- A Technique for Modeling

a Class of Fuzzy Objects"

Computer Graphics (Proc. Siggraph) Vol. 17, No. 3, July 1983, pp. 359-376

[LOKE92] Loke, Teng-See, Tan, Daniel, Seah, Hock-Soon, and Er, Meng-Hwa "Rendering

Fireworks Displays"

IEEE Computer Graphics and Applications, May, 1992, pp. 33-43

[KASS90] Kass, Michael, and Miller, Gavin "Rapid, Stable Fluid Dynamics for Computer Graphics"

Computer Graphics (Proc. Siggraph) Vol. 24, No. 4, August 1990, pp. 49-55

[Wol93] Wolff, Robert and Yaeger, Larry "Visualization of Natural Phenomena"

1993, by Springer-Verlag Publishers

[Ros72] Rosko, Joseph -- "Digital simulation of physical systems"

1972, by Addison-Wesley Publishing Co., Inc.

[Hog92] Hogger, S.G. -- "Mathematics for Computer Graphics"

1992, by Cambridge University Press

[Bec89] Becker, K. and Doffler, M. -- "Dynamic Systems and Fractals"

1989, by Cambridge University Press

[Cou67] Courant, R and Friedrichs, K.O. -- "Supersonic flow and shock waves"

1967, by Interscience Publishers, Inc.

[Str96] Street, R.L., Watters, G.Z., and Vennard, J.K. -- "Elementary fluid mechanics"

1996, by John Wiley and Sons

[Gou88] Gould, Harvey and Tobochnik, Jan -- "An introduction to Computer

Simulation Methods; Applications to Physical Systems" volumes 1 and 2

1988, by Addison-Wesley

[Rip87] Ripley, Brian -- "Stochastic Simulation"

1987, by John Wiley and Sons

[Fle88] Fletcher, C.A.J. -- "Computational Techniques for Fluid Dynamics"

volumes 1 and 2

1988 by Springer-Verlag

[Hee90] Heermann, D.W. -- "Computer Simulation Methods in Theoretical Physics"

1990 by Springer-Verlag

[Hoc88] Hockney, R.W., and Eastwood, J.W. -- "Computer Simulation Using Particles"

1988 by IOP Publishing, Ltd.

[USA62] Department of the Army -- "FM 5-34; Engineer Field Data"

1962 by Department of the Army

[USA64] Department of the Army -- "FM 5-13; The Engineer Soldier's Handbook"

1964 by Department of the Army

[Pur87] Purcel, Edwin J., and Varberg, Dale -- "Calculus with Analytic Geometry"

1987 by Prentice-Hall, Inc.

[Dav43] Davis, Tenney L. -- "The Chemistry of Powder and Explosives"

1943 by Angriff Press

[MEYE94] Meyers, Marc A. "Dynamic Behavior of Materials"

Copyright 1994 by John Wiley & Sons, Inc.

[TAKA91] Takayama, Kazuyashi "Shock waves : proceedings of the 18th

International Symposium on Shock Waves"

Copyright 1992 by Springer-Verlag

[Eng95] Engle, Rob and Rosso, Andrea "Explosions and Shattering"

http://graphics.stanford.edu/courses/cs348c-95-fall/projects/engle_rosso/cs348c.html