World: r3wp

game engines use this simple system.


-create very transparent images with a gaussian fall off.  actually 
give the prefered shape to your image... so if you want a triangle-like 
flame, generate a smooth triangle with alpha/color falloff.

-create a block which will store a list of pairs, each one holds 
the position of a single "particle"

the idea is that points are inserted/removed in lifo order, with 
the order determining age.

decide on a number of particles, lets say   count: 20

decide on a particle life time... lets say  life: 10

then go over the list, picking up count amount of particles at at 
time with life number of interations.
the life iteration is used to calculate age: life / life-counter

then based on age, move the particles according to some simple randomized 
algorithm.  try to use something to ground their direction... sometimes 
refering to previous particles allows you to make movement constant... 
so lets say:


new-position: current-particle + 0x5 + random  either greater? last-particle/x 
current-particle/x [5][-5]

then move the particle to the appropriate position in the face.

as they spread out, they will disapear.

all is left, is to add/remove new pairs to your list, basically, 
the last iteration knocks off old particles from the list and inserts 
new ones at your fire origin.

if you want smoke, just add the "dying" particles to a second list, 
using the same process, to animate them but with a bigger/softer 
image.  

the dying fire becomes the birth of the smoke.

for the particles, either pregenerate (and simply offset) small faces 
with an transparent image or build an AGG block at each refresh.

you can even blur aging particles by adding an effects block to them 
as they age.  but that will probably kill the refreh

they only unknown is how many particles you can have before view 
really starts to slow down

also make sure to only call show on the region of your graphics which 
will really contain particles... there no point in blitting the whole 
house if only the window is on fire.

the plasma effect you saw used repetitive blur to an image, with 
new particles added and some offset added to the previous image.

the problem with this is that you cannot change the color and the 
fact that the whole image gets faded.

it could work if R2's effect system also managed the alpha channel 
but it doesn't AFAIK.

Hope this helps!

for more control, you can also store two sets of pairs for your particles... 
one being the position and the second being current velocity... this 
has the advantage of guaranteeing particle movement direction.  in 
your loop, all you do is add a bit of variation to the velocity and 
then add the velocity to the position.

Very cool, Maxim...thanks. 

is this done as an interactive process?

Not sure what you are asking but stage 1 would be to allow these 
fire "objects" to be placed on top of an image via drag and drop 
and allow for some editing such as sizing. (Later versions would 
allow adjusting those other variables you mentioned above). 


Stage 2 would allow for some transitions from one set of settings 
to another so for example the fire can become more intense over time 
or when clicked on or a button is pressed. 


I just had a week of training on a flash based system...its cute 
and does teh job for what we are going to use these "simulations" 
for but I thought it was a little too complicated for your average 
fireman to use if he wanted to create his own sims for drill purposes.


The flash extensions used all those variables you mentioned above 
to allow for a great degree of controll of the effects.

by interactive I mean will this be rendered or running live?


with a rendered system you can crank up the particle count and just 
pregenerate the whole data set as a series of images.  then when 
you need to see it, just cycle the image of a face.


usually, people use a few particles for preview... then generate 
"flipbooks" which are just rendered images and include thousands 
of particles with their alpha channel density reduced to practically 
nothing (like 2% visibility)  this generates very pretty effects, 
but at a cost of rendering time.

interactive? depends on the quality of real time...it does not need 
to be super realistic....I'll play with it...thanks

If you can get the basic system setup, I'll help you improve it. 
 just give me a link to download  :-)

funny... I'm just working on smokes, but in my dialect..:
http://box.lebeda.ws/~hmm/rswf/temp/smoke.html
http://box.lebeda.ws/~hmm/rswf/temp/smoke.rswf

this version is using only one bitmap so far with 100 precomputed 
particle paths

I would like to optimize it now to have the fading+scaled bitmap 
prerendered as this version is still quite slow on Wii where I need 
it. The problem is, that I must have is as small as possible so I 
cannot prerender too much

(it's not slow as stand alone, but with game where I need it it's 
noticable)

nice

you could render it as a single plane mask and use it only as transparency 
(alpha) for another image.

this even allows you to have different colors and scales of smoke 
re-using the same data

doesn't the wii actually have particles?

I mean a particle system built-in the engine...

If my I'm not doing a wrong guess, your WITH function bind its block 
each time it's called. That may be quite slow.

But maybe, it's just a dialect, not something evaluated by Rebol 
in real time...

the wii is too slow for that? interesting

Oldes, how many particules do you process in real time ?

instead you could process a cluster of particules with the same path 
(tough, the look an feel may be less impressive)

better off having an image which simulates the cluster to begin with.

yep

The problem is, that we have only 40MB for complete game so I cannot 
prerender the smoke effect into sequence of images and I cannot do 
it even during init time as the engine has some problems with premultiplied 
semitransparent images. But I want to do some improvements.. also 
it's possible to make (pregenerate) a classic animation for each 
particle so no AS would be used to traverse the block with positions 
which also slows down a little bit... and no, the engine is not slow 
for that, but you must have the game itself running as well under 
the smoke effect:)

I just wanted to show amacleod how it's possible to do that. This 
was first attempt imho. In the PC version we used just some morphing 
blured shapes. But the engine on Wii has no blur support.

Thanks Oldes. But I did not want to use flash...wanted a pure rebol 
solution.

http://anton.wildit.net.au/rebol/demo/rebol-on-fire.r

and solar-refractor.r

and blood-light.r

Thanks Anton. I'll look over the code of those

Or you can prerender the smoke and do something like that: 
do http://box.lebeda.ws/~hmm/rebol/vid-anim.r

(huh.. it was years ago I did something like that in REBOL - I even 
had to google to refresh my memories)

I'm working on a little particle generator... I coudn't resists.

its strating to actually produce interesting results  :-)

I'm managing 1000 particles via Draw at about 50% of one core.  not 
bad  :-)

the particle engine is done, I'm now building a view interface to 
control the various properties like wind/turbulence.   you can even 
ignite your own fires & smoke with a click of the mouse.  

won't be long, I'll put it on rebol.org.

you are the man Maxim....I hate to distract you from your other distractions 
but thanks