 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| Jonathan Walter Richardson |
|
|
| CS 5610 Final Project |
|
|
| Fireworks scene with color communication |
|
|
| Overview: |
|
|
| As soon as I saw the option to do a particle system with billboarding as the final project, I knew that's what I wanted. It sounded like something that I could really wrap my mind around and enjoy. I decided on fireworks because: |
|
|
| You mentioned fire, so my I was already thinking in that direction. |
|
|
| I thought, is there a better combination of fire and particle physics than fireworks? |
|
|
| I didn't base my particle physics on any “paper”. The basic idea of how to do the physics soon started to sketch out in my mind. Soon afterwards, I got a notion which really excited my imagination and became the most visually pleasing part of the project: what I call “color communication”. |
|
|
|
What's this color communication? |
|
|
|
In a fireworks scene there are many many particles which are all light sources. I wanted to get the smoke in the scene to be lit in interesting ways, but I couldn't picture how standard GL lighting would be used to light a billboarded cloud. It's hard to define what the normal of a billboarded cloud is. And besides, there are only 8 GL lights, but potentially thousands of particles. |
|
|
|
So I began to work out a different lighting idea. When I created or moved a smoke particle, I would simply check every other firework particle and add a color contribution from it to the smoke, based on the inverse square law. Then, when it came time to render the smoke particle, it would just use the summed color contributions as it's color. |
|
|
|
Refining the idea: |
|
|
|
Of course, the first thing to hit my mind was how much work that was. For each smoke particle and for each frame of animation, I would have to go through n firework particles. |
|
|
|
So the idea that evolved was to sort of “hash” the particles. Perhaps “hash” is a bad way of putting it: I simply divided the world up into smaller cubes, and the position of a particle decided which bucket it would fall into. Each bucket had a linked list of the particles inside it, and also 8 color summations. |
|
|
|
Since it was already necessary to apply physics to each particle in every frame, I decided to, in the same pass, add them to the appropriate list, and also add their color contributions to each of the eight color trackers in the corners of the box they belonged to. |
|
|
|
So, as a smoke particle was being processed, it would inherit its color from the Color Trackers rather than the particles themselves. A linear interpolation would be made of the colors of the 8 Color Trackers of the box a particle belonged to, and so an approximation of the of the contributions of nearby smoke particles to nearby fire particles would be achieved without adding too much overhead. |
|
|
| Caveats: |
|
|
| The above method has the following potential problems: |
|
|
| Certain situations could make it so some smoke particles never see a contribution from a fire particle that passes near it. This can be remedied by one or more of the following: |
|
|
| a) Make sure that smoke particles are always processed last. So, they will get a snapshot of a steady state of Color Trackers. This helps but will not guarantee a fix. |
|
|
| b) Make sure that a particle will be within range of a smoke particle for at least two passes. This can be achieved by making sure the buckets are big enough for the given velocity of a particle, and the speed of the machine you are rendering on. |
|
|
| My solution assumes b). |
|
|
| If buckets are too small for your simulation, then color contributions might not have adequate “reach”. i.e. my current system does not support light reaching across more than two buckets. If you need to increase the reach, therefore, you have to increase the bucket size. The falloff from a light should be fast enough that moving outside the reach won't produce a shocking color change. |
|
|
| While increasing the bucket size helps solve some other problems, it decreases the accuracy of the color contributions. This could be remedied by increasing the number of color trackers per bucket. |
|
|
| Potential Improvements: |
|
|
| Make sure smoke particles are processed last, as briefly discussed in caveats #1. |
|
|
| Increase the number of Color Trackers for more accurate estimations of color contributions, as briefly discussed in caveat #3. |
|
|
| Memory optimizations. My system uses simple mallocs and frees, and so may lack beneficial cache behavior. Clever use of preallocated particles, processed in order, might be able to fix this problem. |
|
|
| My results: |
|
|
| I get decent speeds on my AMD XP 1600+, aiw Radeon 8500DV, with a few thousand active particles. Aside from that, I should just show some pictures, huh? |
|
|
 |
|
 |
|
|
|
Here is the zipped project (including source) |
|
|
|
(Actually, some aspects of my idea are not fully implemented in this version, though it produced the pictures above) |
|