I've made a Adobe Flash simulation of smoke that follows Brownian motion. I wondered whether it would actually be possible to create something that looked relatively smoky by using particles (represented by circles) without running out of memory. Turns out that it works, just. 
What do you think? Any questions?
Linky. I can't get the controls to do anything. Am I doing something wrong? 
| Gagnar The Unruly wrote: |
| I can't get the controls to do anything. Am I doing something wrong? |
Oh yeah, press enter after you change the values. Good point, I'll add that to the page.
EDIT: There, I added that to the swf. Should have added that before - it wasn't clear!That is a really interesting application. I'll have to bookmark it! Nice job!
| Afaceinthematrix wrote: |
| That is a really interesting application. I'll have to bookmark it! Nice job! |
Wow, thanks! Getting comments like that brightens my day (and gives me a little ego boost). Yeah, that's really cool!
Yep - nice little app. You seem to be turning out quite a few nice little apps like this. Have you any plans for them?
| Bikerman wrote: |
| Yep - nice little app. You seem to be turning out quite a few nice little apps like this. Have you any plans for them? |
Thank you! And Gagnar The Unruly.
I haven't any real plans for these at the moment - I just enjoy creating them. In the long term though, I am interested in accurate real-time physics simulation and would hope that one day I could make something of use in industry somewhere. We'll see though, I have a long way to go!
I have a couple more simulations to put up after I've sorted out some kinks.Can it be a random Brownian motion pattern if none of the particles ever travel down in the negative y direction? They only travel in a positive y direction.
| jwellsy wrote: |
| They only travel in a positive y direction. |
That's not true, you just have to start them with a fairly low initial velocity to see them reverse direction and go down. | Gagnar The Unruly wrote: |
| jwellsy wrote: | | They only travel in a positive y direction. |
That's not true, you just have to start them with a fairly low initial velocity to see them reverse direction and go down. |
Yeah, if they didn't have the strong upward movement, it would expand in all directions, instead of rising like smoke.being a Actionscript Programmer myself, I'd say it is amazing the way you made the program. I think there is a way of lessening the load on the memory: you can try to:
1. shortening the variable names
2. shortening the calculations. IE: if you say
var Iv = Vspeed;
var Ix = Hspeed/2;
var Dis = Iv+Ix
.then it's much easier, if you don't need Iv or Ix and only need to calculate them for Dis. so shorten it into:
var Dis = Vspeed+Hspeed/2;
and
3. make the smoke particles smaller.
4. use actionscript for smoke generating. randomly connect three dots (close to each other) with grey lines and filling it with grey should work okay with fewer particles.
There's an example in a game. It uses extremely large amounts of particle physics without lagging too much. The game is called Ether War. search it on google.
In Ether War (a top-down space shooter), every enemy has a particle trail behind it that has a similar brownian motion( i think). Every enemy killed explodes into particles. So the screen is a mass of flying particles with motion blur.
It's amazing because it don't lag. normally a 600pxls+ game is really laggy. check it out and see if you can get inspiration from it kay?
Xrave, I can't tell whether you're criticising my simulation or not.
A few things. Firstly, a question, does shortening variable names increase efficiency in time? I believe that variable names are converted to references that are all the same length, so to speak, when you compile. I'm not sure exactly how the flash compiler deals with variables, although I can say that it treats [essentially private] variables declared in functions differently from variables declared on the frame.
Your second point is true. Although, I would put it as: for greater efficiency, minimise the total calculation per frame. I'd like to point out that it would be more efficient to declare a variable type (so that the compiler knows how to deal with the variable, ie: var Dis:Number = Vspeed + Hspeed / 2; ). One thing many people don't make more efficient is calculations that produce a constant result either on every frame or perhaps for every iteration of a loop or even once for each direction (ie x and y), that's always something to watch out for.
Make the particles smaller? I decided to allow the size of the particles in my example to be variable so that people could play around with the effects. It is true though that the less drawing Flash has to do, the quicker it will be, but that's not what I was going for.
I don't really understand the point to your final point. I do use ActionScript to generate the smoke. There's one MovieClip in the Library, some text boxes on the stage and fewer than 40 lines of code that actually handle the smoke (the rest dealing with the input and validation of the text boxes). That's it, no animation... Also, I create smoke in groups of particles (to make it more efficient), each group being moved with a single velocity. Creating some particles, then joining them and filling the space between them would be the same, and less efficient, as creating larger particles. So I'm not sure what you're going for with that one.
The way the particle effects are done in that game are nice, and very efficient. Although, if I right click on the flash movie then my browser freezes, as it does with my simulation. I don't know whether my simulation is efficient as their particle effect. Check this out: example. I can't be bothered to make particle trails, but this simulation works very efficiently for me. That uses exactly the same code as my smoke simulation.
The effect isn't what I was going for, though, as I wanted to simulate smoke. That I think I've done pretty well.
EDIT: One thing I've noticed is that I use Flash 8, while Ether War was created in Flash CS3. ActionScript 3.0 is more efficient that AS2.0, so that's one thing I need to get around to buying.
EDIT Again: Ooo, I just ran a test to see how many particles the simulation I linked in this post to was dealing with and on average there are around 750 particles on screen at one time. That's better than I'd thought! you're right, actionscript 2.0 is less efficient than 3.0. the :uint type really rocks. I have CS3 as well, I just don't use the AS3 feature (partially because I'm too stupid, partially because I'm lazy to learn it) :p
NEWS!
I've updated the simulation to AS3 and Flash Player 10!
On the default settings on my computer this increased the fps by around 10. However, I have made further optimisations and increased the fps by, on average, another 10.
So it's now 100% faster than it was before - double the speed! That's pretty sweet. What are you going to do with it beyond make a smoke simulation?
| PatTheGreat42 wrote: |
| That's pretty sweet. What are you going to do with it beyond make a smoke simulation? |
At the moment, absolutely nothing.
I plan to make a far better smoke simulation some time - or at least to have (another) go. It would be nice to end up combining simulations from many of my projects into some major production, but that won't be any time soon as I have so many sub-projects going on.Pretty neat to play around with that. 
Nice job.
