Fire Simulation For Games

Transcription

1 Fire Simulation For Games Dennis Foley Abstract Simulating fire and smoke as well as other fluid like structures have been done in many different ways. Some implementations use very accurate physics some don't. Also different implementations differ greatly in speed. However these faster versions of fluid simulations may have less accurate physics. A wide use of fire simulations is in games, the simulations used in games are usually the quicker less accurate type. This paper describes my plan and result for a fire simulation for use in games. 1 Introduction/Background For my final project for Advanced Computer Graphics and Animation CMPS 162, I created a fire simulation. I have seen computer generated fire used in games and movies and wanted to create my own version of the simulation. I am a CS Game Design major so naturally I wanted to use my version in games. My goal was not to just have the visual aspect of fire but also the burning effect and be able to use this feature dynamically in a game. I have seen similar projects like this such as Peter Blaskovic's fire fluid simulation 3 ( This example uses more accurate physics such as Navier-Stokes equations [1]. I had thought about using these fluid equations but they were to difficult to understand and there was a lack or clear resources. I found another project by Jos Stam, from the University of Toronto, that created fluid realistically

2 specifically for games ( [2]. However this implementation of fire was difficult for me to understand and also made use of CUDA, which seemed to be too overwhelming for me to learn in my time constraints. 2 Method/Results I decided to use a simple implementation of textured particles that I have come to understand with my previous experience with particle systems. The idea is that instead of simple dot or square as a particle in your system you have a quad with a blurry fire texture mapped to it. In my simulation I used textures with a Gaussian blur applied. This combined with an alpha channel and blending creates a somewhat realistic looking fire effect whether or not the physics are accurate. The physics of my implementation are also simple they just use a sin wave which causes each particle to oscillate back and forth as they travel upwards. Real fire also has changes in color so I needed to include this in my simulation. In textures in opengl you can multiply a texture color by a r, g, b value altering the final color. I first tried to use a white texture with r, g, b values of 1, 1, 1 and multiply these by specific r, g, b values that I wanted such as.8,.8, 0 which would result in a orange color. However as I changed the r, g, b values by small amount each time I would get weird colors that I did not want. I decided in the end that all I really wanted was three colors yellow, orange and red. So I simply created three different textures with these colors and and different intervals of a particles lifespan I would bind different textures to their surface. This gave me more control, as I can just change the texture to change the color, and the results were my desired effect. All of these ideas resulted in what you will see when you run my project and push 'SPACE'.

3 Illustration 1: A picture of my results for the fire effect. The second phase of my project was the burning effect, this was interesting to me because I wanted to make fire that could be used dynamically in a game. For instance if an archer shot a flaming arrow and hit a character that character would light on fire. I started off thinking I could just reuse my particle effect that I built in the first phase of my project. However that particle effect only seemed to look good when there were about two hundred particles blended together which resulted in multiple different colors and motion effects. When I began to implement my burning simulation my plan was to

4 have a new particle system for every polygon of a mesh that was on fire. For a model such as the woman model which has about three thousand polygons in its mesh, I couldn't possibly have a particle system of two hundred particles being updated for that many polygons. So I lowered the count of my system to ten this sped things up a bit however it didn't maintain the color effects because there were much fewer particles most would be one color. So I simplified my system to use one texture with a blend of yellow, orange and red colors. The movement of this system was also limited but because each system was on a mesh surrounded by other fires they all blended together. This ended up looking good, but it still has speed problems. To solve major speed problems in my initial implementation I limited the amount of fires that could be burning at simultaneously to twenty fires, this is easily changeable if wanting to test the maximum fires possible by changing the variable firelimit. Another idea I had for optimization would be instead of creating new systems of particles I could have just added new particles to a single instance of one system and have older particles die off instead of old systems die off. This method would make it harder to add and remove particles however. Its not so much the particle system that slows my burning simulation down, spreading the fire over the mesh has a much greater effect on the speed of the simulation. My first implementation used a less optimized algorithm for the fire spreading effect. The way the fire would spread is by walking through each polygon on the mesh and seeing if it shares a vertex with a polygon that is on fire. The spreading feature added a loop of twenty fire polygons, which have up to sixty vertices, compared with each polygon vertex, which is up to sixty vertices as well. In other words in order to see if these polygons share a vertex I have to walk through each vertex of the polygons that are on fire for every vertex of the mesh that isn't on fire. As one optimization I am calculating the fire spreading effect as I am looping through the display function for the mesh. To clarify add a loop of worse case 60 * 20 for each vertex that is not on fire. The best case would be 3 * 20, as a polygon does not have less than three vertices, for each vertex that is not on fire. An code example is below:

5 if(obj.the_elems[i].isonfire == 0){ for(int p=0; p<static_cast<int>(onfirepoints.size()); p++){ if(obj.the_elems[i].points[k] == onfirepoints[p]){ if(firecount < firelimit){ obj.the_elems[i].isonfire = 1; system_t newfire = generics; partsystem.push_back(newfire); firecount++; break; else{ obj.the_elems[i].isonfire = 2; break; Optimizing this structure was what significantly increased the speed. After many different attempts I ended up having a circle collision test to see if the non fire polygon center was in range of the on fire polygon center. A code example is below: if(obj.the_elems[i].isonfire == 0){ for(int f=0; f<static_cast<int>(firepolys.size()); f++){ if(obj.the_elems[firepolys[f]].fuel < 20){ vector_t relvec; float dist; relvec.x = obj.the_elems[i].center.x - obj.the_elems[firepolys[f]].center.x; relvec.y = obj.the_elems[i].center.y - obj.the_elems[firepolys[f]].center.y; relvec.z = obj.the_elems[i].center.z - obj.the_elems[firepolys[f]].center.z; dist = relvec.x * relvec.x + relvec.y * relvec.y + relvec.z + relvec.z; if(dist < 1){ if(firecount < firelimit){ obj.the_elems[i].isonfire = 1; firepolys.push_back(i); system_t newfire = generics; partsystem.push_back(newfire); firecount++; break; else{ obj.the_elems[i].isonfire = 2; break;

6 Illustration 2: The results of my burning effect This increases the run-time significantly, consider if all of the fire polygons were at the feet of the mesh and this current polygon is on the face it will not be in range of any of the fires and will only need that one check. If it is in range you also only need one check if its in range then it will be set on fire. This is much better than having to loop through an array of all the vertices that are on fire to see if this polygon does in fact share one of these vertices. The piece of these two code examples that sets the variable isonfire to 2 is also optimizing the loop as now that polygon knows that it was close to fire but there were at the time too many fires to handle so it will wait until one of the systems dies and then insert

7 itself later on when firecount < firelimit. After optimizing this structure I was able to handle about seventy fires at once and about twenty particles in each fire. However no matter what optimizations I made to this loop the amount of polygons in the model still will greatly reduce the speed. For instance with a model such as the 57 chevy with about 14,000 polygons I am only able to run ten fires at once with ten particles and still notice some lag. The use of CUDA a parallel programming environment from Nvdia [3] would have significantly increased the effectiveness of my burning effect. Using this I could separate each system of particles and update them in separate threads. I am not sure how I would implement and optimize the spreading of the fire on the mesh using CUDA, I don't see how it can be split into separate threads, but I'm sure it can be done. I would eventually like to have the burning effect spread across the entire body and have at least half the body on fire at once. Which would be something like a thousand systems, depending on the model, of ten or twenty particles a piece. I have downloaded and looked at examples of particles systems using CUDA and am looking forward to using it in the future to create more powerful optimized projects. 3 Future Work My future work that relates to this project will include many more particle systems with hopefully a wide variety of different interesting physics and aesthetics. I plan to improve on my fire burning effect with different physics and the use of parallel programming. I hope to become proficient with parallel programming in order to harness its power and create more intriguing particle systems and other projects that need parallel optimization. 4 Conclusion Fire simulations come in all shapes, sizes, and complexities. In this paper I describe my method for a simple version of a fire simulation for use in games. The project also includes a burning

8 simulation to dynamically burn a mesh instead of just a static fire animation. In conclusions the project although simple and somewhat aesthetically pleasing still proves a intense computational problem with high polygon count models. Simulations such as my project could greatly benefit from the use of a parallel programming environment such as CUDA. References [1] Wikipedia.org [2] Jos Stam. Real-Time Fluid Dynamics for Games. [3] Nvidia.com