Some suggestions regarding particle scripting.

Hey. This is my first thread, so forigve me if I botch something in the ettiquite.

I've come up with a few interesting ideas regarding particle generators that I'd like to see implimented in SL. Now, before I start, I'll add the disclaimer here: I know that many of these ideas are not feasable as they are, either because they are overly complex, would put too much demand on the processor, or just because it would prove to be too much of a hassle to impliment. Nonetheless, I feel they're interesting ideas, and perhaps worthy of expounding on to see if anyone has input on how they might be evolved into something workable.

Okay. Enough disclaimer -- onto the ideas.

I'll confess I've only worked with the particle scripts for a short while, but it seems to me that to impliment a few of "special effects" I'm working on would be extremely cumbersome, if not impossible to do w/ teh current particle system, such as making dust motes that float across an otherwise invisible cone of light filtering into the room from a cloudy window (invisible because the cone would not reflect on anything, rather, it would descend into perhaps a long mine shaft off into infinity, or some such). This kind of reaosning has led me to wonder if a few things might not be possible with the right script.

Idea 1:
It's rather limiting that the particles can only be interpolated from one thing to one other thing -- for instance, a single alpha setting to only one other. Why not more? I'm sure that someone has thought of that before, but regardless, it would be very nice to be able to change the color and alpha and size and such of the particle more than once as it goes through it's path. Plus, it would mean people don't have to make as many particle emmiters to get the same effect. For instance, people that make "rainbows," (and I've seen millions of those) currently have to make multiple particle emitters -- one for each color -- in order to achieve the effect. With multilpe interpolation settings, that -- and many other things - would be easier.

The syntax I suggest for that would be as follows:

list SomeParticleParams=[<all the previous parameters>
PHYS_PART_COLOR, <vector color, 1st>, <float duration, 1st>, <vector color, 2nd>, <float duration, 2nd>, ... <vector color, nth>, <float, duration, nth>,
PHYS_PART_ALPHA, <float alpha, 1st>, <float duration, 1st>, <float alpha, 2nd>, <float duration, 2nd>, ... <float alpha, nth>, <float, duration, nth>,
<all the rest of the parameters>];

Or at least, something to that effect. Regardless, the syntax is simple.

Idea 2:
There need to be more spawning patterns. I have an idea that will create a huge number of spawning patterns in a way that's already implimented by the system. The first is a prim surface -- a prim with all the standard properties of a normal prim. It's just that the particles begin somewhere on the prim, and then go on about their merry way. This would be very nice for making some more phantom-esque objects and such, and for a number of other highly specific uses. Regardless, you could simply tack on a primitive properties list at the end of the particle generator and source lists, and have it use that as data. The second type of spawning pattern I'd like to see is having the particles spawn only within the volume of a prim with the same considerations as before. It might behove whoever impliments this to have a flag put at the end of the particle source list to say which kind of prim-based spawn pattern they wanted.

A suggested syntax would be like this:

RawParticleEffectsList = [<a bunch of particle effects>];
SpawningPrimPropertiesList = [<a bunch of primitive properties>];
SpawningPrimTypeList = [PHYS_SRC_PRIMTYPE PHYS_SRC_PRIM_SURFACE];
TotalParticleEffectsList = RawParticleEffectsList + SpawningPrimPropertiesList + SpawningPrimTypeList];
llParticleSystem(TotalParticleEffectsList);

That's the general idea. The enumeration of the SpawningPrimTypeList is completely arbitrary, obviously. As long as it's able to communicate to the engine what the prim properties indicate and such, it's all good.

Now, at first glance, it would seem that you truly would only need position, rotation, and geometry of the spawning prim in order to get the job done. But, I have one use for the texture applied to the prim... and this is where the idea gets *very* complicated to impliment. I recognize that what I am about to suggest is probably far to complext to impliment, but ... it would be neat if it was. Anyhow, the idea is thus: you have a texture that has color data on it. You can then use that color data as a probability field to say where particles are more and less likely to spawn... for instance, one idea (and it's just one) would be to use the blue color channel of the texture as a measure of likelyness. Darker areas would be more likely than lighter areas. And, before you finished the texture, you would be able to apply a solid alpha channel to it that makes it *look* invisible to a viewer, but still retain color data in terms of what the engine is thinking about.

Being a math-y kinda guy, I know that'd be nigh on impossible. Nonetheless, I felt it needed to be said to at least be suggested. I apologize ahead of time to the helpstaff if that idea ever gets implimented. *grin*

As a note. I purposefully did *NOT* use the prim data of the object containing the particle script for a number of reasons. The first is simply that you may not want to use it, and it would be restricting to impose such a condition. Second, as I will mention shortly, there are a few other ways one can use prim data in the particle scripting ideas. I suppose, however, that it would be useful to make the script *capable* of using the geomoetry of the prim it's set in. Regardless, that's a fine detail of the bigger picture.

Idea 3:
This idea is perhaps the least-well thought out of them all, and has the most options. It basically is with regards to governing the path of the particle once spawned. Essentially, I'd like to be able to do a number of things. One, I would like to be able to bind the particle into the confines of (a) prim(s) -- for example, have the particles spawn however, but not be able to travel outside of the box. The primitive paramters would be pumped into thet particle list just as the previous prim data was, though with flags and such to make sure things are kept track of properly. Also, having the ability to control what happens to the particle once it hits the boundary (does it bounce? Does it simply die? does it stick and live out the rest of it's seconds in that one fixed spot?) would be nice, especially if you could control them based on which way they were moving in comparison to the normal of the survace it touched (A possible scneario would be: a particle would spawn at the center of two boxes, one bigger than the other, go straight up, pass through the inner box's boundary just fine when it's going up, but reflect off the outer box, down against the inner box -- and be reflected back up, because the inner box was set to let things pass through on the way out but not go back in). All of the various prims would have to be organized w/ the script with appropriate enumerated variables.

Another complimentary idea would be the ability to effect force fields (like, an electric field) or some such on them. Now, I'll confess a bit of ignorance -- I don't know exactly what one can do with "wind" and having the particles move around in sympathy to it. But, I don't think it'd be able to pull off what I have in mind. Basically, just some way of controlling the path of the particle, either by a function or by putting it in a vector field. I have no idea how to do that, but I know that it'd be REMARKABLY complicated. So, I'm not too hopeful for this idea. I know that you can apply an acceleration to the thing, but ... oftentimes, that's just not good enough. I'd like some angular velocity and torques and other stuffs. Regardless, it's just an idea.

The last idea I'll inflict is a simple one: targets. It'd be nice to have particles that dont' travel for the *center* of a target, rather, having it travel to perhaps the target's surface or some such would be nice.

Okay. I'm really really tired at this point. Anyone reading this probably noticed a bit of slippage in terms of coherency near the end there -- that's because I'm beat. If anyone read my thesis of a post, well, feel free to comment. And hey, Lindens? Feel free to implment!

Be well folks.

-- "I have never understood the desire to not understand."

that's more than i could possibly read about particles hehe, but i wanted to say you don't need more than one emitter to make a rainbow stream of particles.

liked your prim volume idea.

Yeah, I thought about that after I finished typing the thing up. Heehee... my bad.

Don't let some currently perceived problem stop your ideas.

Today's problem may disappear tomorrow, or a problem may be overcome today by someone with a novel solution, or simply by compromizing on some aspect or other.

As regards "too much of a hassle to implement" ... the market will take care of that. There is a price to pay when a company decides to not implement a good idea, and it can be a terminal price. Just because LL can't be bothered sometimes, or isn't listening, doesn't mean that ideas expressed here die without a trace. A lot of people are listening.

Sorry, i have the attention span of a nat. I couldnt read it all.

ignore

well as a sorta defacto particle guru i will say almost everything ya've asked for is pseudo-redundant.. aka can be fabricated satisfactorily in the current system... with enough of an understanding about how particles work hehe ^.^

i will add two basic requests for things which cannot currently be done at all by any means in the former case, and cannot be done without severe lag in th second case...

1) allow arbitrary rotation of particles as its own 'omega' value.. just a pair of floats.

RotStart would define a particle be spawned at a given rotation from the vertical, 0.0 being standard, PI being a full loop to once more appear standard (pi/2 being inverted) etc

RotRate would affect how many revolutions per second the current particle would make. a value of 0 would be as they are now, a value of 1 would be one revolution per second, etc. This would allow for alot of interesting, currently impossible effects.

2) Allow 'volume' spawns via radius_stop. Heres a *REALLY* simple one... again rather backwards compatable, it could simply be added in and if not passed, assumed to be equal to radius for current effects to remain unchanged. Adding it in though would allow you to set a 'space' within which particles would spawn. a simple sphere of radius 0, radius_stop 10 would allow particles to spawn anywhere within that 10m sphere, not simply along its outside, as a sphere of radius 10 would currently produce.

this could be amended to jus have the current radius, then have a start radius and a stop radius as well, more like how they altered angles as well.

its 'possible' to get volume effects now but it basically involves a continual loop across the radius with a change and a requisite object update... thats not good for *ANYONE* though as it jus leads to massive lag in busy areas for something that *should* be all client-side

Er, there may be *some* redundancy in the ideas I presented, but not that much. The first idea *cannot* be achieved by any means in the current system, no matter how complex. Yes, it is true that you can set a loop that changes the particle effects alpha and color and size and all of that stuff over time, *but*, that only changes the spawning parameters and not the parameters through the life of the particle. For instance, one of the effects I want is to have is a field of dust motes traveling across a volume -- let's say, for the sake of arguement, a cube. It would spawn particles on the surface of the cube, and have them all travel in the initial direction of the center, and not stop untill they reached the opposite side. At the beginning of their journey, they'd have an alpha setting of zero. At the middle of their journey, they'd have an alpha setting of, say, .50. And, at the end of their journey, they would have an alpha setting of -- once more -- zero. That's two changes in the life of the particle, something that can't really be done in the current system. And, if it *can*, then please tell me how, as I would really like to know.

As to the second set of ideas -- eh, you *can* do it, kinda, but not in any satisfactory way that I've discovered. Yeah, you can move the object that's spawning the particles around in a pattern that makes it look like a shape, but most of the code I've found to move an object is slow (not smooth at all, moving once every tenth of a second, which isn't nearly fast enough), and moving it in any shape save for the *simplest* of primatives would be unweildy at best, impossibly complicated at worst. And I *certainly* don't know how to make a particle interact with a prim in any way (save for the limited use of a target), and the ideas regarding the direction-based prim side interactions is probably far beyond the scope of the current system. But, that's not to say I'm a god at the particle stuff here -- if you have any ideas on this, let me know, as I'd be curious as to what's possible now with the system.

I like the idea regarding the rotations of particles, though I would add that perhaps there should be a variable torque added there, so that it could be accelerated? Perhaps in a way that's time dependant?

As to the second idea, I couldn't parse it. Sorry.

heh lets just say if ya have enough experience, you *can* fake alot of the things you had asked for, within a single set particle call... its juts not necessarily easy hehe

Alright -- how?

well i can't just go around revealing all of my secrets now can i? hehe

lets just say i have gotten three color particle effects, as well as fade in->out effects, custom rotation effects, as well as the ability to project particles in ways that about 85% line up with what you requested.

Just think outside the box a lil.. be willing to do somethin to x to achieve an effect thats actually using paramater y... there is *ALOT* of room for creativity and inginuity in particles.

Uh ... well, I don't know what to tell say, then. Withold information doesn't lead to meaningful conversation, especially on a forum whose existance is to share information, so ... *shrugs* You'll forgive me if I don't take your word for it, Eltee. Nonetheless, I'll keep trying, as you say, and will post the results to this forum if I figure anything out.

Anyhow, does anyone else have any ideas?

I'd like to expand/clarify one of Beigh's ideas and suggest patterns of PRIM_FACE and PRIM_VOLUME.

With PRIM_FACE, you also provide a face number or ALL_SIDES (-1). This will define the start region for the particles to be anywhere along the surface of that face. So you could have a 0.5 meter cube with particles lifting up off the top face corner-to-corner and across the whole surface. Or shooting out of the end of a cut torus. A prim with ALL_SIDES set as the chosen face could have static glitter all over it's surface.

PRIM_VOLUME would start each particle at some random point within the object, taking it's cut or otherwise modified shape into account. Done in an invisible prim, you can make volumetric effects like a room full of random magic sparkles. Things that would be difficult due to sharp corners with our current system.

EDIT: (And wheather eltee can do it or not doesn't matter. It's what Joe Average can do that counts.)

well thats why i do push for things that are unreasonably hard to do, to be made simpler.. hence my first post... and i would be happy to help give you ideas about where to look to do certain things... i tried to hint there before... alot of the workarounds that i've found use some other part of the particle system to cover for the missing one...

i will give a concrete example if just to help you see what i am talking about.

it is not possible to directly 'fade in' anything within the current particle system.

it is however possible to make something *appear* to fade in... without using the alpha controlls at all, but using size. Its possible to tweak the start size of a system in just such a way that a particle starts out less than a pixel wide, and then slowly expands out, thus, visually starting from nothing, and 'fading' into existance... then as the particle ages, it can use the actual alpha controls to fade back out.

Its tricky to get just the right sizing to make the effect convincing as too small a start size, and it won't render at all, and too large a start size and it will appear to 'pop' in and not visually 'fade' into existance....

I have made a pulse shield effect that uses this trick in a rather effective way.. you see a seething geometric lookin mesh of 'force lines' that never really seem to 'spawn' or 'die' jus sorta slowly shift around as the specific particles perceptably fade in, then back out.

i don't remember the exact number you need to work with to get that effect... but its very small.. somewhere around 0.03m.. but just on the one size... the other, either x, or y, should be 'normal' sized aka say mebbe 0.1m or 0.5m whatever the effect yer looking for



in this case, i'm using a specific quirk of particle sizes, to essentially cover for a 'missing' aspect of particle alpha. And in many many instances it does work... its not 100%, but its definately something, and may be quite useful, depending on the exact particle effect you have in mind

*nods* Ah. Well, fair enough. While that is a very interesting solution, it isn't a very robust solution, and is limited in what you can do with it. I still believe that my suggestion holds a lot of value, especially if you wanted to create more complex effects. But thank you for at least telling me what it was you were talking about.

theres alot more... as to the specific rainbow effect you were talking about i think thats probably complex beyond hope of implementation.. heck i wrote one'f the more popular particle access scripts and i have NO idea how i'd implement that, in a way other people could understand it... i think the best we could reaosnably hope for would be hue settings... aka start hue and end hue, assuming the lindens wouldn't mind creating a H/S/L color space interpreter where then you could loop across multiple colors

it wouldn't be perfect and would still be a little limited, but it wouldn't be *SUPER* complicated from an implementation, (and day to tay usage) standpoint. then again most people don't really 'get' HSL color so that may be abit over the top anyway...

as to prim based particle stuff... i don't really see the advantage there.. the only thing we can't do now is automatcially fill a volume.. and i think honestly havin jus a start/stop radius with the current system would be more than adequate to the task, and be much much easier to implement and 'understand' as it were

Well, as to the rainbow effects, the best way to do it is to have a single particle generator, set a timer to about .1 seconds, and then make a loop that cycles through different particle generation states, one state for each band of color in the rainbow. For instance, make it create, say, fourty particles for the blue band, then after the timer hits, have a new set of particle parameters that makes it move outward a little bit and make the green band, and so on and so forth. Not hard, but cumbersome. And still, it's just one of many examples of what needs to be fixed -- exhaust smoke (or any other kind of smoke for that matter), the sparkles that water make when splashing over a complicated surface (like a jagged rock), and many other kinds of effects would benifit from such a system. Those are just a few examples. For many, there is some kind of workaround... but still. Workarounds are still limited in their robustness.