World: r3wp

If you cut part of an image out, the rest of the image collapses 
in.

If you had a requirement to log a user out of an application after 
a period of inactivity... what's the best way to do this?

I don't know of a single best way. One of the key elements, though, 
is determining what constitues "activity". If you have a central 
command dispatch loop of some kind, and every command that indicates 
activity goes through that makes it easier. Then you probably have 
some kind of default state that is used when the app starts up, and 
you revert to that. Of course, if you have useful state that you 
throw away the user won't be happy.

Hmm... so no way to monitor view events

You could have the remote client app monitor its own View events, 
and when there are some within 5 minutes, send a "I'm still here" 
message to the server. If the server doesn't receive any of those 
for an hour, then logout that client.

Graham: >> help insert-event-func

thanks .. so I can use insert-event-func to monitor global events 
and just pass them on.  If I don't get any user events I can lock 
the screen until the user types in a password

perhaps you can set a rate on the window face.

I already have one that sends a heart beat to the server

you can also patch the wake-event for even more control, but insert-event-func 
should be sufficient for your needs.

In general, using chroma keying is it possible to vary the level 
of transparency?


I've been playing with cyphre's "Transparency window under View" 
script  and I do not seem to be able to change transparency levels 
when using chroma keys.


I know this script is using window's user32.dll and it's not using 
draw to do the effect.

it will depend on what you mean by "chroma keying".   most people 
in the PC world interpret it as a single color value becomes 100% 
transparent (like a .bmp).


in the VFX world chroma keying is a range using an alpha channel 
mask (like a .png, for example).  so yes it is possible.  


IIRC, windows supports an alpha plane to manage the transparency, 
but I have not played with this myself yet.

R2's chroma key effect  uses a single color as the transparency. 
 so you'd need to build an alpha image using a range based on luma 
or some other more complex algorithm... which you can easily find 
on the net.

usually, you pick a center point, and decide on a range.  you can 
filter out the transparency with additional parameters like luma, 
saturation and things like that.  

basically adding or removing from each previous step, until you get 
the alpha channel mask you want.

I wanted to create a near transparent window onto another windows 
app so I could draw/sketch over it like they do on tv during a football 
game.


playing with Cyphre's script the transparency works on the whole 
window including title bars and borders.
 

Perhaps I could use a chrome key to get full transparency on the 
area I want to see throught to and lay over that a draw based semi-transparent 
object to draw on....I'll do some experimenting.


Else I will need to make the whole project Rebol and not use this 
"cheat"

Anyone play around with particle/plasma generators on rebol...I think 
I remember a script that had like a plasma effect.


I want to try and mimick fire and smoke....does not have to be super 
realistic....

is this done as an interactive process?

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 ?