Old Particle System Conversion: Help Request
Tuesday, March 6th, 2007 at 2:26 PM by: Steve LindenFor those of you who have not been following the progress of the First Look: Render Pipeline Improvements project, we will no longer be supporting the old deprecated particle system after the next Viewer update. This includes llMakeExplosion, llMakeFire, llMakeFountain, and llMakeSmoke. This was not an arbitrary decision, but was made to improve Viewer frame rates (the deprecated functions are very inefficient), and to keep developers focused on improving the rest of the render engine instead of maintaining deprecated functions.
As it was brought to our attention that the deprecated functions are still in use, we are working on simulating the deprecated system as best we can. I made a request in my last blog posting for examples of the old functions done using llParticleSystem. Many thanks to eltee Statosky, KirstenLee Cinquetti, and Jopsy Pendragon for giving me specifc examples to base the following templates on.
Below is a first draft of how we intend to simulate the old functions using llParticleSystem. If you have scripts using the old functions, please try them with the functions below instead. If you feel any adjustments should be made, please post those here so that together we can come up with the best simulation possible.
Note: we are aware that we can not simulate the old functions exactly, in particular the ‘offset’ parameters and the inherit randomness in the system. Nonetheless we do not feel that these features merit maintaining an entire additional code path.
Cheers,
-Steve
fakeMakeExplosion(integer iParticles, float fScale, float fVel, float fLifetime, float fArc, string sTexture, vector vOffset)
{
// vOffset is ignored
llParticleSystem([
PSYS_PART_FLAGS, PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK|PSYS_PART_EMISSIVE_MASK|PSYS_PART_WIND_MASK,
PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_PART_START_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_START_ALPHA, 0.5,
PSYS_PART_END_ALPHA, 0.2,
PSYS_PART_START_SCALE, <fScale, fScale, 0.0>,
PSYS_PART_END_SCALE, <fScale*2 + fLifetime, fScale*2 + fLifetime, 0.0>,
PSYS_PART_MAX_AGE, fLifetime,
PSYS_SRC_ACCEL, <0.0, 0.0, 0.0>,
PSYS_SRC_TEXTURE, sTexture,
PSYS_SRC_BURST_RATE, 1.0,
PSYS_SRC_ANGLE_BEGIN, 0.0,
PSYS_SRC_ANGLE_END, fArc*PI,
PSYS_SRC_BURST_PART_COUNT, iParticles/8,
PSYS_SRC_BURST_RADIUS, 0.0,
PSYS_SRC_BURST_SPEED_MIN, fVel/3,
PSYS_SRC_BURST_SPEED_MAX, fVel*2/3,
PSYS_SRC_MAX_AGE, fLifetime/2,
PSYS_SRC_OMEGA, <0.0, 0.0, 0.0> ]);
}
fakeMakeFire(integer iParticles, float fScale, float fVel, float fLifetime, float fArc, string sTexture, vector vOffset)
{
// vOffset is ignored
llParticleSystem([
PSYS_PART_FLAGS, PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK|PSYS_PART_WIND_MASK|PSYS_PART_EMISSIVE_MASK,
PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_PART_START_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_START_ALPHA, 0.5,
PSYS_PART_END_ALPHA, 0.1,
PSYS_PART_START_SCALE, <fScale/2, fScale/2, 0.0>,
PSYS_PART_END_SCALE, <fScale, fScale, 0.0>,
PSYS_PART_MAX_AGE, 0.5,
PSYS_SRC_ACCEL, <0.0, 0.0, 0.0>,
PSYS_SRC_TEXTURE, sTexture,
PSYS_SRC_BURST_RATE, 0.5,
PSYS_SRC_ANGLE_BEGIN, 0.0,
PSYS_SRC_ANGLE_END, fArc*PI,
PSYS_SRC_BURST_PART_COUNT, 1,
PSYS_SRC_BURST_RADIUS, 0.0,
PSYS_SRC_BURST_SPEED_MIN, fVel,
PSYS_SRC_BURST_SPEED_MAX, fVel,
PSYS_SRC_MAX_AGE, fLifetime/2,
PSYS_SRC_OMEGA, <0.0, 0.0, 0.0> ]);
}
fakeMakeFountain(integer iParticles, float fScale, float fVel, float fLifetime, float fArc, integer iBounce, string sTexture, vector vOffset, float fBounceOffset)
{
// vOffset, fBounceOffset is ignored
llParticleSystem([
PSYS_PART_FLAGS, PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK|PSYS_PART_WIND_MASK|PSYS_PART_BOUNCE_MASK|PSYS_PART_EMISSIVE_MASK,
PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_PART_START_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.25,
PSYS_PART_START_SCALE, <fScale/1.5, fScale/1.5, 0.0>,
PSYS_PART_END_SCALE, <fScale/4, fScale/4, 0.0>,
PSYS_PART_MAX_AGE, 3.0,
PSYS_SRC_ACCEL, <1.0, 0.0, -4>,
PSYS_SRC_TEXTURE, sTexture,
PSYS_SRC_BURST_RATE, 0.25,
PSYS_SRC_ANGLE_BEGIN, 0.0,
PSYS_SRC_ANGLE_END, 0.10 + fArc*PI,
PSYS_SRC_BURST_PART_COUNT, 1,
PSYS_SRC_BURST_RADIUS, 0.0,
PSYS_SRC_BURST_SPEED_MIN, fVel,
PSYS_SRC_BURST_SPEED_MAX, fVel,
PSYS_SRC_MAX_AGE, fLifetime/2,
PSYS_SRC_OMEGA, <0.0, 0.0, 0.0> ]);
}
fakeMakeSmoke(integer iParticles, float fScale, float fVel, float fLifetime, float fArc, string sTexture, vector vOffset)
{
// vOffset is ignored
llParticleSystem([
PSYS_PART_FLAGS, PSYS_PART_INTERP_COLOR_MASK|PSYS_PART_INTERP_SCALE_MASK|PSYS_PART_WIND_MASK|PSYS_PART_EMISSIVE_MASK,
PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_ANGLE_CONE,
PSYS_PART_START_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_END_COLOR, <1.0, 1.0, 1.0>,
PSYS_PART_START_ALPHA, 0.50,
PSYS_PART_END_ALPHA, 0.25,
PSYS_PART_START_SCALE, <fScale, fScale, 0.0>,
PSYS_PART_END_SCALE, <fScale*4.0, fScale*4.0, 0.0>,
PSYS_PART_MAX_AGE, 3.0,
PSYS_SRC_ACCEL, <0.0, 0.0, 0>,
PSYS_SRC_TEXTURE, sTexture,
PSYS_SRC_BURST_RATE, 0.5,
PSYS_SRC_ANGLE_BEGIN, 0.0,
PSYS_SRC_ANGLE_END, 0.10 + fArc*PI,
PSYS_SRC_BURST_PART_COUNT, 1,
PSYS_SRC_BURST_RADIUS, 0.0,
PSYS_SRC_BURST_SPEED_MIN, fVel,
PSYS_SRC_BURST_SPEED_MAX, fVel,
PSYS_SRC_MAX_AGE, fLifetime/2,
PSYS_SRC_OMEGA, <0.0, 0.0, 0.0> ]);
}
March 6th, 2007 at 2:54 PM
offset is the only thing needed (like Really needed)….everything else you can fake.
might as well move on.
March 6th, 2007 at 3:12 PM
WTG!! Out with the old!!!
March 6th, 2007 at 3:16 PM
I know this is the wrong place for this but please consider llRezObject to transport a list instead of an integer to the rezzed object if in anyway possible … this would be i big improvement compared to this stuff i never used
March 6th, 2007 at 3:21 PM
So you replaced the old particle system with a wordier/lengthier and in theory less laggy one?
March 6th, 2007 at 3:35 PM
Hello,
Where was the vote on this issue? This is going to effect alot of people, its going to break many scripts. It’s going to cost scripters alot of time and end users more money. Clubs depend on functional scripting. If such are going to be implemented and code deprecated.. It should be voted upon. This is not satisfactory in my opinion.
March 6th, 2007 at 3:41 PM
would I use this in a make smoke script then?
bu replacing the old
MakeSmoke|| with the above code?
March 6th, 2007 at 3:42 PM
Bobbyb30 Zohari Says:
March 6th, 2007 at 3:21 PM PST
So you replaced the old particle system with a wordier/lengthier and in theory less laggy one?
Where you been? Almost everyone has been using llParticleSystem for ages now.
March 6th, 2007 at 3:44 PM
yeah if you read what the lil popup mouseover text says you can take those numbers and just plug it in to the appropriate areas in the particle system. Otherwise I am all for making SL smoother anyway possible, well almost anyway other then running around at the lowest possible setting and like having hexagon looking circles.
March 6th, 2007 at 3:59 PM
llParticleSystem has capabilities that more than make up for losing offset (you can fake that by placing the script in a linked prim). One is it’s far easier to use lists (those [] brackets) and loading them into llParticleSystem on the fly to make particles that change in fantastic ways (eliminates using many particle scripted prims to achieve some effects).
March 6th, 2007 at 4:00 PM
I’d like to remind the Lindens that there is a GIANT issue with llParticleSystem, namely particles do not appear at distances over 40m or so. It appears to be client side and can make things annoying.
The old llMakeExplosion shows up at much farther distances. Over 100M away. Same with llMakeFire and such. I have no CLUE why it does this, but it simply does.
This is why I still use the old commands for certain things.
March 6th, 2007 at 4:02 PM
Steve, stop wasting your time with whole “you can use ParticleSystem”..
I’m asking for OFFSET flag into ParticleSystem!
Come on!
Give me OFFSET flag!!!!
This proves that youre not reading my first post very clearly or just don’t want to admit that you or Linden Labs won’t give us the OFFSET flag at all. That’s not funny.
March 6th, 2007 at 4:04 PM
Has any thought been put towards fixing the “llParticleSystem([])” offswitch issue? Currently, a LOT of particle generators are not trning off when told to. There are some REALLY ugly hacks going on to try and patch this on the scripter’s level. Is there any hope that the “turn particles off” function will return soon?
March 6th, 2007 at 4:15 PM
Yay! My head hurts now, can i have an ANGLE_CONE with ice cream please
March 6th, 2007 at 4:20 PM
Thanks for publishing this; I’ll change my scripts
March 6th, 2007 at 4:22 PM
We are working on the llParticleSystem([]) bug. It is proving difficult to isolate.
To be explicit, we are not planning to preserve the ‘offset’ functionality. It breaks a lot of assumptions we make about the location/radius of a particle system (for example, how to calculate whether any of it is visible). The effect can be simulated using an invisible child object scripted to change its position.
March 6th, 2007 at 4:33 PM
WOW no more poofer type systems?
March 6th, 2007 at 5:12 PM
There is a workaround atm for the bug where you can’t turn off the particle system.
llParticleSystem( [ PSYS_SRC_BURST_PART_COUNT, 0 ] );
llSleep(0.5);
llParticleSystem( [ ] );
Works fine for me, without the sleep then it sometimes doesn’t work.
March 6th, 2007 at 5:17 PM
One feature that us “soldiers on the line” would really like, is a directional parameter. Right now, particle fountains on the z axis of the prim. By rotating an invisible prim fountain, we can change direction… We can affect the push of a particle, in terms of WORLD coordinates, but not in terms of prim coordinates. Normally this isn’t a huge issue. but creating a rocket motor out of a torus.. for example.. the jets issue out the side, rather than down the opening. The solution, in terms of jetpacks, is simple.. another prim just for the fire. But in terms od physical vehicles.. every prim counts.
The ability to speciy a rotation for the particles.. would be REALLY nice.
Put that on my X-Mas list.
March 6th, 2007 at 5:48 PM
So does that mean, 500 items we have are gonna be rentered useless again?
March 6th, 2007 at 5:53 PM
Thank You for depreciating old laggy code. Good Job.
March 6th, 2007 at 6:02 PM
Steve - is this more or less going to only affect new/re-compiled objects?
Seems to me that anything thats already been in bytecode will function just fine until mono comes along, which is when everything breaks again anyhow. Unless I’m completely lost in how the LSL system works.
March 6th, 2007 at 6:07 PM
Alicia, you can also use this to stop particle system, in more efficient way, I believe:
llParticleSystem( [ PSYS_SRC_MAX_AGE, 0.1 ] );
Basicly just set the source to turn off itself after limited time. I find this working pretty well.
March 6th, 2007 at 6:19 PM
This will not affect script compilation or behave any differently in old or new scripts; we will just quietly convert calls to the old functions into calls to llParticleSystem() at runtime (don’t worry, this won’t cause any additional overhead).
The only difference that people will notice is that any old particle calls with a non zero offset value will not be offset, and the effect may look slightly different. This difference in appearance is what we are attempting to minimize by tuning the conversion.
March 6th, 2007 at 6:25 PM
Phoeey on me and my llMakeSmoke obsession with the past. Go with what does work now, and with what will work then, with those who will be here then. Or there then, in that particular present tense, somewhere….
Whatever! The Future is Now! I’m already Here, too!… Except… I don’t know where or When I am…well, that’s not really true.
I know I’m here in Second Life. They wouldn’t call it Second Life without a reason. Doubtless there are Second Reasons for everything, too, so I probably already know why and where and how I’m here.
Urkle! I came here to Escape reality, not become part of it!
March 6th, 2007 at 6:47 PM
@ 16: Only if they’re really old items. These functions have been deprecated for a long, long time. Nothing made in the last year or two should be using them.
March 6th, 2007 at 7:11 PM
March 6th, 2007 at 7:14 PM
Wow. How did I manage to post an empty comment?
March 6th, 2007 at 7:39 PM
I found the llParticleSystem([]) bug only hits if you are generating particles from a prim other than the primary prim in a linked object. Relink your object so your particle generator is the primary prim and everything is fine.
March 6th, 2007 at 8:37 PM
Good to see llMake___ is not just going to be summarily pointed at a stub function.
March 6th, 2007 at 8:51 PM
Well, I just wished to comment that it’s always very nice to see you’re getting rid of “laggy” subsystems in SL, that’s definitely a “good thing”, even if it means breaking a lot of items that needed the offset thingy from the old particle system to work properly.
Sure, the “invisible floating prim” is an option, but it also means making things rather more complex — intra-prim communications, synchronising two or more particle emitters in the same object, etc. In my personal case, selling a simple item in packs of 20 for just L$3, it’s way too much work and complexity — I’ll just put the blame on you guys for breaking old functionality without giving a proper replacement, he he
Seriously, it’s good to see your policy of replacing “outdated” and laggy functions, and deprecating worthless code. I guess that the hundred or so items that still used those functions and their creators will “survive” the change, and embrace a new version of SL that handles things better on the rendering pipeline just because they can afford to ignore the old things
March 6th, 2007 at 9:12 PM
when i copy the makefakefire script… gives me a
(1,0) : ERROR : Syntax error message
… what am i doing wrong? Thanks.
/me wishes i had time to learn how to make scripts lol
March 6th, 2007 at 9:24 PM
Ooooo, count my vote with Winter’s, rotation on the particles would be very nice indeed….
No more poofer type systems? Hardly. My MESS is as messy as it ever was….
Every bit of code we don’t need jettisoned is a good thing in my book. Makes more room to stretch my legs out.
March 6th, 2007 at 9:29 PM
[...] Linden suggests alternatives to the deprecated particle system functions. It’s surprising how many people haven’t switched to the replacement system after more [...]
March 6th, 2007 at 10:23 PM
I don’t suppose anyone ever considered that it might have been better to just rewrite the code to make it more efficient, so that you can continue to use the old functions and it would just recomplile into better end code?
Broccoli
March 6th, 2007 at 10:26 PM
To anyone who’s complaining: for the entire time I’ve been in SL, llMake* have been listed as deprecated functions. I’m no newbie; I’ve been in SL for over two years now. Deprecation is an early warning that something will go away, so that means that LL has given us over two years’ warning that these functions are going to go away.
In short, no complaining, and no telling LL they’re horrible. You should have seen this coming, and I say bring it on!
March 7th, 2007 at 1:44 AM
Okay.. so what exactly is going on? It’d help if someone explained what was happening in ENGLISH, non of this “geek-talk”.
The partical system is going? Nomore particals?
New partical system coming? Partical system bug being fixed?
What exactly is going on, because some of us who know poo all about LSL do purchase objects and particals for ourselves, our clubs etc, so it’d help if we knew exactly what was happening in EVERYDAY ENGLISH, we spend money on these things so we deserve to be told clear on whats happening. YAKNAMSAYIN?
March 7th, 2007 at 1:50 AM
JUST a sentence?
“The whole partical system is going”
“… of the partical system is being removed”
“The partical system is being replaced with a more efficient version”
..please?
March 7th, 2007 at 2:01 AM
In non-geek talk. let’s have an analogy:
A long time ago we needed a different blender for each kind of fruit, bananas, apples, oranges. Nowadays (for at least a year or more) we have a multi-fruit blender which is able to blend any type of fruit. So no more three machines, just one. The old machines were still working but labeled as “deprecated”. You were advised to create new fruit blends with the new machine only.
Now, the old blenders are taken out of service, the new system will take over the work of the old blenders, producing results similar to or same as the old did.
March 7th, 2007 at 4:05 AM
If you can’t even spell ‘particle’, you probably don’t need to worry about it. The ‘geek talk’ is just explaining what is really happening. If you don’t understand it, maybe you should learn.
Meanwhile, bravo to the Lindens for continuing to improve SL and sorting out old, unnecessary code.
March 7th, 2007 at 4:35 AM
It is good that this is being done. however what do you plan on ding about linden library content that still uses these features such as the popgun?
March 7th, 2007 at 5:46 AM
Alrighty, vote it up.
JIRA track: MISC-36 “Add OFFSET flag to llParticleSystem”
https://jira.secondlife.com/browse/MISC-36
It’s still an issue for me and few others.
March 7th, 2007 at 5:50 AM
I find it amusing you knew that partical was a typo for particle, so what’s upw ith that, you still understood me, clearly. I really don’t see your point in trying to get all clever, cocky and defensive over it.
Thanks Zi Ree
“The old PARTICAL (zomg) system is being replaced with a new one” - would have been just as good :>
March 7th, 2007 at 5:55 AM
What is adding OFFSET flag to llParticleSystem.
“If you don’t understand it, maybe you should learn.” I learn by asking, as I just did, and Zi Ree answered, explained to me very well in a simpler form :>
“If you can’t even spell ‘particle’”
Well, if you can’t even learn how to use grammar correctly before trying to talk about someones spellings…
Names do start with capital letters
March 7th, 2007 at 6:41 AM
If I get old stuff, for example from Yadni’s Junkyard, how can I tell whether or not the newer particle rendering system is going to break them? I don’t know how to script and I often take parts from freebies and use them in things I cretae.
Is Particle Generator going to break?
March 7th, 2007 at 6:59 AM
Ok, thanks, one of my main products won’t work yay!
March 7th, 2007 at 7:08 AM
@The Black Box:
“please consider llRezObject to transport a list instead of an integer to the rezzed object if in anyway possible”
I think passing a 256 character limited string would be more efficient, less memory intensive, more flexible, and equally as useful
March 7th, 2007 at 7:17 AM
I don’t use llMakeSmoke, I’ve always only used llParticleSystem… so why is it that the things that spit out particles made to look like smoke I make started working poorly recently? What used to be an awesome steady stream of smoke, (using llParticleSystem mind you,) is now but a pythetic puny few puffs.
I’ve updated and changed my Particle system accordingly to compensate, but I didnt think that this product would be affected, yet it was.
March 7th, 2007 at 8:23 AM
Steve Linden said “… To be explicit, we are not planning to preserve the ‘offset’ functionality. It breaks a lot of assumptions we make about the location/radius of a particle system (for example, how to calculate whether any of it is visible). The effect can be simulated using an invisible child object scripted to change its position.”
This is a bogus argument. Have you even attempted to gather stats on what magnitude of offsets are being used in existing content? When you do you will probably find that the offsets aren’t very much in comparison to the size of the prim. Implement the offset feature, cap the offset distance to some length proportional to the size of the prim, and ignore it’s affect on location/radius.
March 7th, 2007 at 8:35 AM
“… To be explicit, we are not planning to preserve the ‘offset’ functionality. It breaks a lot of assumptions we make about the location/radius of a particle system (for example, how to calculate whether any of it is visible). The effect can be simulated using an invisible child object scripted to change its position.”
This is not a very good argument. Have you even attempted to gather stats on what magnitude of offsets are being used in existing content? When you do you will probably find that the offsets aren’t very much in comparison to the size of the prim. Implement the offset feature, cap the offset distance to some length proportional to the size of the prim, and ignore it’s affect on location/radius.
March 7th, 2007 at 9:41 AM
@15
Steve: As long as you’re going with a transparent translation from the legacy system to the new system, would it be conceivable to simply spawn an invisible child prim at the offset position with the requested particle effects active? Should be doable transparently.
March 7th, 2007 at 10:07 AM
Just when does this take effect? Today, or another day?
March 7th, 2007 at 4:57 PM
@Lozlo who said: ““The old PARTICAL (zomg) system is being replaced with a new one” - would have been just as good :>”
No it wouldnt because that would be mistaken.. The point is that the function called ParticleSystem is *not* “new”.. it’s a few years old now.. it’s just that the collection of functions known as Make(whatever) are even older and less efficient and LL is saying bye bye to them after a few years of saying “don’t use this coz its going away someday.” They finally getting the stake of obsolescence.
Life is impermanence.. embracing that is the key to SL satisfaction as well as inner peace in general. Everything becomes obsolete at some point.
March 8th, 2007 at 11:31 AM
after uploding and restoring SL, i can”t see my self anymore on the screen.
Tried eferythinh to solve the problem, like reinstall, but the problem is still there.
i can’t see myself??
March 12th, 2007 at 4:54 PM
while i’ve only been using second life since mid 2006, and only recently been logging in on a frequent basis, as a ‘first life’ developer and programmer, i can definitely understand removing deprecated functions; especially when it results in less lag / better performance. kudos there. yet more kudos for providing workarounds for those of us who get their hands on out-of-date documentation.