Particles in an Elliptical Pattern

Is there an easy way of making particles emit in an elliptical (non-circle) pattern? I'm trying all kinds of craziness with timers and changing values for the particle effect and am having absolutely no luck.

Nope. The best you can do is a circular/spherical subset (arc/cone).

Ugh. I figured as much. I'll just have to fake it somehow. I was hoping to keep it to one prim, but I could do a multiple prim approach with PSYS_SRC_ACCEL and targets for them.

I tried a few methods. Making a prim orbit a root prim with llTargetOmega() sort of worked, except the orientation of the ellipse is kept changing and would be completely frustrating to figure out otherwise. I tried a script with a fast timer to change the radius on the go as it made particles, but that did not prove an easy route either.

A friend suggested I could make the prim move around in the desired ellipse pattern while emitting particles, which I could do if I could figure out the math behind it.

I did make some interesting patterns by mistake doing this, so I suppose it's not all bad.

I got your eliptical path in one prim

set up your emiter to spray a a certian range, narrow arc

vector vgVecRegionOffset = <.0, 1.0, .0>; // lengthen our circle by 1m north
integer vgIntArc = 12; // should be above 6
rotation vgRotArc; // where we'll store the calculated arc
integer vgIntCounter;

default{
  state_entry(){
	vgRotArc = llEuler2Rot( <.0, .0, vgIntArc > * DEG_TO_RAD );
	vgVecRegionOffset *= vgIntArc / 180; //-- the fraction we'll move to make a smooth ellipse
	llSetTimerEvent( .01 );
  }

  timer(){
	llSeTimerEvent( .0 );
	vgIntCounter = 0;
	do{
	  llSetLocalPos( vgVecRegionOffset );
	  llSetLocalRot( vgRotArc * llGetLocalRot() );
	}while (++vgIntCounter * vgRotArc < 180 )
	vgVecRegionOffset *= -1;
	llSetTimerEvent( .01 );
  }
}

play around with the starting offset, heck if you're using target omega you don't even need to set the rotation, but it'll be hard to synch it to the motion

(warning I wrote this on the fly, may contain errors and/or illogic =)

Thank you very much. I will test that when I get home from work.

My own attempts at creating an elliptical pattern have been a pretty unconvincing ~ I can create the basic shape but not control the diameter at the widest point with any reliability. At best it is a tall, narrow double bow-like shape; attempts to increase the width at the widest point have resulted in the total collapse of the elliptical pattern.

So, I was interested in results that the supplied code would have. The code itself unfortunately contains quite a number of syntax errors and even makes use of an none-existant LSL function ("llSetLocalPos( vgVecRegionOffset )" but I assumed that this was meant to be "llSetPos".



However, upon compile the prim flew-off somewhere or other & I still haven't located it yet!...lol...nevermind.

So, if any has a tested and proven method of "making particles emit in an elliptical (non-circle) pattern" I'd sure be interested in seeing it

Thanks

Aye, it is probably most helpful if folks would test out solutions before posting them. Half-baked ideas which are obviously not even tested don't help, and may serve to increase the frustration level of those seeking a real solution.

Pseudocode is one thing, but something presented as an implementable solution should be so.

yeah, that's what I get for writing while half asleep.. that prim is located about 10 meters towards the regions sw corner =X

it should have been llSetPos( llGetPos() + vgVecRegionOffset )
and I spot a missing semicolon in the timer do loop, oh and given the offset I used, the object should start at -90 degrees z

the concept is simple, but looking back I'm thinking I missed what the OP was wanting... they wanted an eliptical spray, and what I was doing was tracing an eliptical path... very different things

for tracing PSYS_SRC_BURST_RADIUS need to be set at a distance... 2.0 works for a test case... PSYS_SRC_ANGLE_END should be 0.0, PSYS_SRC_ACCEL at 0.0

as the emitter movers and turns, the distance described by burst radius forms an elipse (initial facing must be away from the line of prim movement)

you could also do this by moving a prim in an eleptical orbit and dropping particles behind it by doing the following.

tilt prim +30 on y axis.
set particles to drop from the emitter and not move
use the following formula to move the prim

offset = <1, 0, 0>;
arc = llEuler2Rot( <.0, .0, 6.0> * DEG_TO_RAD );

now = llGetPos();
next = now + (offset - offset * arc) * llGetRot(); //-- this gives a local rotation circle around a point 'offset'
next.z = now.z; //-- this ignores z to keep it in the same plane
llSetPos( next );
llSetRot( arc * llGetRot() );

if I have a moment tomorrow I'll throw both examples together and drop them on everyone interested

@Talarus:
what, you don't make typos or occasionally write a function name wrong? =) and I *DID* include a warning at the bottom

No, most of the time, I have a policy of posting only tested code that I have at least gotten to compile, and that performs the function in a rudimentary fashion at least.

Otherwise, I post snippets or pseudocode, and yes, occasionally I do make typos in those, but they are never intended to be an example implementation in and of themselves.

just for you Talarus, a newly written sig w/ disclaimer =)

(some of us post warnings with untested code, not reading warnings is hazadous to your sanity =)

I like to offer concepts along with tests, even if the code isn't perfect someone may pick up the concept and make it workable, precision may spread code, but it's not always best at spreading ideas... that's my theory anyways (and why I warn people if it isn't tested)

I was jealous and had to add a disclaimer to mine now too.

::grins @ Jesse::

ok so as promised, the example script for eliptical path

 vector   vgVecOffSet =  <.0, .0, 3.0>;
 float	vgIntDegrees = 6.0;
 rotation vgRotDegrees;
 integer vgBooIsOn;
 
 default{
 	state_entry(){
		 //-- this line is just to give us an angle for the circle to flatten
 		llSetRot( llEuler2Rot( <.0, .0, 45.0> * DEG_TO_RAD ) );
 		vgRotDegrees = llEuler2Rot( <.0, vgIntDegrees, .0> * DEG_TO_RAD );
 		llParticleSystem( [PSYS_PART_FLAGS, PSYS_PART_INTERP_COLOR_MASK,
 						   PSYS_SRC_PATTERN, PSYS_SRC_PATTERN_DROP,
 						   PSYS_PART_START_COLOR, <1.0, .0, .0>,
 						   PSYS_PART_END_COLOR, <.0, .0, 1.0>,
 						   PSYS_PART_START_SCALE, <.25, .25, .25>,
 						   PSYS_PART_END_SCALE, <.25, .25, .25>,
 						   PSYS_PART_MAX_AGE, 0.0,
 						   PSYS_PART_MAX_AGE, 30.0,
 						   PSYS_SRC_BURST_RATE, 0.0] );
 	}
 
 	touch_start(integer total_number){
 		vgBooIsOn = !vgBooIsOn;
 		llSetTimerEvent( .35 * vgBooIsOn );
 	}
 	
 	timer(){
 		vector vPosCurrent = llGetLocalPos();
 		vector vPosNew = vPosCurrent + (vgVecOffSet - vgVecOffSet * vgRotDegrees)  * llGetLocalRot();
 		vPosNew.y = vPosCurrent.y;
 		llSetPrimitiveParams( [PRIM_POSITION, vPosNew,
 							   PRIM_ROTATION, vgRotDegrees * llGetLocalRot()] );
 	}
 }
 

since no one posted back I'll assume no one wanted it dropped on them

Thx Void...I'm interested! I'll pick this up later today & have a play

I think you misunderstand my point.

Ideas are spread, either with pseudocode or real code, or even with simple discussion about the problem. The difference is, if you post real code that contains gross errors, the effort spent trying to figure out what and where those errors are by those you are trying to help often obfuscates the idea you are trying to get across, not only because it is frustrating, but also because they can't cross-reference things like non-existent functions.

When you're posting code as an example implementation, take a few mins and drop it in a prim first to make sure it at least compiles. Otherwise, it is just being lazy. It doesn't have to be a perfect solution to the problem, but it should at least be /a/ solution to the problem (or something as close to a solution as possible to give them a direction to go in).

Remember that not everyone is as smart as you are on the subject, which is why they are here asking in the first place.

I would still have to disagree with this. Bet 90% of the scripts here never saw the light of of a simulator before posting. Better to screw up every now and then and answer so many questions right as Void does then only help a couple of people a week. ANyway we can sometimes learn just as much from mistakes and how not to do something.

I do know my contribution would be sharply curtailed it I was forced to sign into SL. As it is I answer questions every single night and only sign in a few minutes a week to the MG.

What fun! I'm just beginning to play with particles and this was quite helpful! Just by chance I chose a ring for the prim and after the first loop it looks like it eats the particles and shi I mean spits them out the back end!

Thank you,

Doug

As long as folks tell us it hasn't been compiled, or tested, or whatever, then the reader has full knowledge and can make the choice.

Feel free to disagree with it all you like. I happen to disagree with that 90% figure, because I know several folks here who do try, or copy/paste from working code they use, myself included. This even extends to LIBRARY code, as there have been a number of posts that I have seen where the posted code doesn't even compile, let alone run correctly, because someone got into a hurry and posted it.

It doesn't change the fact that it WOULD be *MOST* helpful if people would take the time. Let's not go into "I've helped more people this week than you!" crap, as that is soooo sophomoric, ok? All of us here do our best to help out; I am only making a conceptual point that a little bit of extra effort would save a lot of people time. There are also quite a few folks here who can and do help out regularly, so there is no need for a race to see who can throw out answers the fastest, either.

I'm sorry, I don't buy the "quantity > quality" argument. Never have; never will. Even in this thread, the final version is what answered the question, not the half-baked one, so double the effort on Void's part and wasted time on the part of people trying to figure it out. I don't see how that is "better", myself.



I highly doubt any such thing, and I NEVER said anything about "forcing" anyone. It was a suggestion of improving the quality of answers. If you wanna post crap, and feel justified and empowered to do so, because it is expedient and you can do it four times faster than posting something useful, please do.



..and I have never said otherwise.

That doesn't change the fact that a little bit of extra effort makes for a better answer.

Repeat after me, class: "Quality is better than Quantity."

Well, while we're all offering & sharing our views on this...

In RL I design & test software, and part of the job role is putting the specifications out to tender to Developer's for pricing, suggestions and frequently the submission of a working-conceptual models...

It is inconceivable that a Developer would be awarded a contract if s/he submitted code that didn't compile, contained non-existant functions or was based on vague ideas of "this is how it might be done".

Now, I understand that this is not a commercial RL environment, but SL. I totally understand that it is neither possible nor desirable to attempt to impose RL Software House quality standards on anyone in SL but, nevertheless, where ever possible (which is, in fact, more often than not) I do try to take aboard those standards & apply them to my own SL work.

As such, my own "policy" for posting code on the forum is that it will have *always* have been compiled in-world and tested to the best of my knowledge and ability. That doesn't mean there are not better solutions than what I might provide, but at least I have the confidence that what I do provide works as described. If I don't have the time to compile and test to my own satisfaction then I will not respond to the post. Simple as that.

It is my experience from managing teams of Developers, testers and most other IT specialists (as well as having been a Senior Analyst Programmer myself for far too many years) that as many bugs get introduced to a system from an attitude of "its only a one-line change" or "oh thats so simple, I'll knock out the code in 5 mins" or "we can bypass testing of this because if it worked over there and so it will work here" as probably any other cause. Usually the Developer was trying to be helpful, or help meet a deadline or SLA, whatever.

So, clouded by those experiences, but certainly having no wish to see them imposed upon any other SL player or LSL scripter, I definately take the same, seemingly minority, stance as Talarus:



Thats' my tup-pence worth...

WOW Pretty harsh don't you think?

And this is doubly funny because Void solved the problem and yet post #2 in this thread says that it can't be done.



So you might want to rethink your position or at least keep crap comments like you said above to yourself. I never made an attack against you.

Did you not post the following as an attack?



It sure sounded like one to me. Like I said, we're all volunteering helping people here; I'm not going to get into pissing contests to see how many people I can help in unit time. If someone helps just one person, one time, ever, that's one more person helped, as far as I am concerned.



Perhaps. Perhaps not. I am quite aware of the "solution", as I have made several particle-based items which use a similar technique (one using llSetPos/llSetRot; a couple others using llTargetOmega). I have ended up not using the technique much, as it has been prone to network lag and packet loss, and the scripted movement version is sub-optimal for avoiding sim latency issues, because it depends on a prim moving continuously via script.

That said, I don't criticize that someone posted an alternative. On the contrary, I think it is great. However, that doesn't change my stance that a little extra effort makes better answers.



In the context that I answered the question in, it was a factual statement. You CAN NOT make particles go in any other path other than what I stated, using llParticleSystem alone. It just is not flexible enough to do it all client-side, which is what I understood the question to be.

I did error in that I did not include that context in my response. For that, I apologize; it was an error, and I have been aware of it throughout this discussion. I thought about posting it previously, but I felt it was very obvious.

If it matters at this point, I thank you for pointing it out.

That's right we are all here helping but you have come out and chastised one person who does an admirable job here helping others and then made a disparaging comment against another.

The weekend is here. I plan on having fun, working on getting a list together to hopefully bring some attention to the forums and finally I plan on helping solve some problems. As many problems as we are having in the forums it is ludicrous to start going around attacking each other.

I am extremely pleased with the work Void is doing and I know many more feel the same way. Hopefully he will never change his ways at all.

I have chastised no one. I didn't name names, I pointed out a truism. Better quality answers are more helpful. Just like you said, it applies to me just as much as Void, or you. If you disagree with that premise, that's your business. When you turn it into a thinly-veiled attack, I am quite happy to point it out.



Then don't start, k?



I am happy that he(?) is (and you and everyone else are) here helping as well. As with anything, no one is perfect, and if we can't take suggestions for improvement from one another to heart without letting our egos get in the way, well, I guess we'll end up with bruised egos. *shrug*

FWIW, I'm in awe of anyone who can just type a response containing code that looks even plausibly compilable. And I'm equally in awe of folks who can speak with authority, precision, and accuracy when they post.

But if I tried to do either of those, I'd never press the "Submit" button on a reply. And maybe I shouldn't. But sometimes I figure a timely if possibly flawed response might be worth the reader's time, so I muddle on, hoping somebody who actually knows something will straighten out the stuff I get wrong, and hoping I haven't made that more difficult by introducing too much confusion.

Ah everything is alright now Qie. Guess we both had a bad day or something. I read more into it etc. Anyone who makes even one post in any of the forums trying to help someone else is to be admired. No one can deny what Talarus has given back to the community. And then there is me....... I help and come up with some rather brilliant code every now and then and yet every now and then..... Whew, the Red Sphere/Blue Sphere thread a couple of weeks ago will go down in the history of the forums as one of the dumbest ever. All due to god knows what, but my brain was definitely not firing on all cylinders. Took two pages before I finally spit out some good code there Talarus and I have both gone on to having a fruitfull discussion concerning IEEE 754 standards.