Particles, Sims, Clients, Servers, and Crashing

heyas;

okay, as everybody 'knows,' particles are rendered on a client and don't cause any server-side lag. (client-side lag is another story.) now, the other day, somebody told me that somebody told them something about sims having a particle limit. and i was thinking: how the heck can a sim have a particle limit? particles don't even EXIST in a sim. unless it is a particle emitter limit? would this be on top of the general script limit for a sim?

meanwhile, since we all 'know' particles don't cause any server lag, how come we also 'know' that any time there's a class that has/teaches particle effects, that it's very likely everything will grind to a halt and the sim will crash when everyone activates all their particles?


the reason i ask is, i want to hold a particle class. and i want to set it up so it is least likely to crash everything.


i'm also curious about things that cause lag -- lag in general, and client lag as well. for example, one nci teacher explained that having other avatars in your view causes your client to have to process a lot of information -- all their positions, clothing, animations, attachments, flex prim hair, etc. and that staring at the floor or a blank wall makes the client run more smoothly.

i tend to believe this. not only does it make sense (whereas particles crashing a sim doesnt), but i have noticed that in big, laggy classes, i don't experience any lag at all. usually my camera is focussed on my build, and i dont see anybody/anything else in my view. i can attest i build lag-free in most classes, even classes where other students are waiting two or more minutes for their prims to even rez.
i also notice that as soon as i move my camera -- if i pan around or zoom out -- my hard disk starts grinding, and my frame rate plummets.


what about other lag-inducers? myth or truth?

bling: how can bling cause lag?

AOs: somebody said it causes others to have to download custom animations.

flex prims: again, a client-side phenomenon only. while taking off your dress might give your neighbors higher frame rates, i don't see how this can cause actual lag.

attachments: aside from having to load them when they first rez in view?

scripted objects: now this i can believe, as the sim assigns timeslices to every active script -- whether it is actually currently DOing anything at the time or not.

listeners: right, scripts that take up lots of timeslices parsing everything people say! (if they're channel 0 listeners). next to bling, listeners are on my list of things that must die.



oh, one last thing... i have a diagnostic tool that shows sim time dilation and fps. usually the dilation is 98-100%. now somebody tell me i am misunderstanding script time dilation. to me, in the normal world, dilation means opening/expanding, and 100% dilation would be the GREATEST difference, and thus mean the scripts are lagging the sim time-frame as much as is possible. and 0% dilation would mean things are running smoothly and on time.

what does it really mean??

thank you kindly for all input and advice!

Ever play with Show Updates? Toggle it on & off with ctrl-alt-shift-U. It might something to bring up in your class. If you haven't seen it, it causes colors to appear over objects as they get updated by the sim: green for an object deletion, blue for a position/rotation update and red for a full update of the object.

I haven't played with this in a while but it used to be that any call to llParticleSystem would cause a full update of the object. Calling it a lot - having the object frequently say "send a new copy of all my prims to everybody!" - would probably contribute to server lag, especially on an object that has a lot of prims.

This, I think, would be a good way to show people in your class the importance of using age settings correctly instead of timers and turning the particles on/off.

I believe most of the problems with 'bling' and AOs lie in the fact that they *often* contain open listeners. When you're in a club and you see in chat history a stream of people typing "/bling on" and "/ao off" that means that these things are listening on channel 0. Even if they listen only to their owner, it still means every single thing that Av chats has to be parsed by the AO or bling script, to see if it contains relavent commands. In other words, it's not the animations, or the particles, it's the poor scripting that runs the thing.

In my experience, both from what I've read, and from testing I've done on my island where I could monitor individual objects via the estate debug tools, I have found the following...

llSensorRepeat is a lag-contributor, particularily if it's set to repeat often, and especially if it is used in a script that also uses llSetTimerEvent. llSensor on its own is much, much less laggy. I am guessing it's because the Repeat function means a whole separate timer is being used just for that one function.

llListen(0,"","","" is particularily bad IMHO because the listen event then has to parse every single thing it hears. Personally if I was designing the LSL, I'd have made it impossible to launch llListen on channel 0, just like they've made it so llRegionSay can't use channel 0. (forbidding channel 0 on llListen would also make chat bugs nigh impossible, as an added bonus.)

Timers themselves are not inheirently bad, but putting a lot of functions within a timer event and having it fire very, very often is. Using llSleep is less laggy if you can get away with it, the trade-off being that it puts the whole script to sleep so it won't respond to new events till it wakes, whereas the llSetTimerEvent keeps the script active so it can respond to events while waiting.

I can understand turning particles on and off would cause *some* network lag and maybe *some* server lag, simply because particles are an attribute of prims, not scripts. Every time you call llParticleSystem() you are changing properties of the prim, and as Meade has pointed out, that means the prim/object needs to be updated and sent to everyone who has it within their draw distance.

That's about all I can think of at the moment, based on what I've learned.

-Atashi

You're correct - there is no simulator limit on particles - its all client-side.

However, there is a client-side particle limit, as set in "Max Particle Count".

If you have enough emitters around you that exceed the Max Particle Count set in your preferences, some of them wont display, or will display erratically.

FYI: Jopsy Pendragon is a guru on particles. Providing he's willing, he'd be an excellent resource to ping with particle questions, or go visit his Particle Laboratory.

Time Dilation is the ratio between physics FPS and sim FPS. Sim FPS itself is the inverse of Total Frame Time. The higher TD is the better. See http://secondlife.com/knowledgebase/article.php?id=174

A word about scripts: the sim does not "assign timeslices" to scripts. This is not a real-time system, unfortunately. The processor can't interrupt scripts to preserve frame rate. Bad scripts (I suspect paranoid security systems) can hog a sim, with scripts time growing over 100mS and TD falling accordingly. This is why you can see empty sims with TD dips every minute or so, and your avatar running into molasses.

I work at a sim where we tested for almost a year. What everyone "knows" is wrong.
Particles cause lag.

a lot of people complain of lag with this stuff but a lot is client side

bling and AO's the cause of lag is actually the open listeners.

I had a situation where everyone wsa in a store and a guy came in with clothing that was full of bling and we all got stuck and crashed and the guy with the bling was busy complaining about the lag and I told him to take all his jewelry and boots and everything off he refused but left and the moment he left we could all move again it was pretty funny.

Some items I have seen are so heavily scripted with listeners its not funny shoes for example where you can change the colour of every part 20+ listeners in some cases two pairs of shoes with 20+ listeners in a place already running scripts its like death hehe

Many people dont understand this and buy this stuff not realizing and those who use the script with open listeners well they really should be using something that uses a menu and messagelinked instead but they dont know any better I think?

Anyhow I tend to avoid buying anything with colour changing and bling even if i can turn the bling off in case it uses a script that uses listeners.

the particles and flexi's etc are client side but lag is being induced on the client side and I suppose if your being subject to it you can't really tell the difference. I have been asked to put out my virtual cigarette because its causing lag and I turn around and tell them to turn off particles and many don't even realize they can turn them off.

If I have a pair of color change shoes, and I like the shoes but I just want to turn off the listen part of it, can I do that? Or is that part of the original script? They're written to listen on channel 5 and as far as I know, by reading the notecard that came with them, there's no "off" function. The shoes are no mod, so I can't open the script to read it. Is there another way of turning them off? Besides not wearing them

You tested for almost a year and all you've got is "particles cause lag"???

Sims do not have or enforce any kind of "particle limit". The *client* has a particle limit of 4096 (by default), but you'd be hard-pressed to get any client to render that many particles. Particles are a low priority in the rendering pipeline, and many times, will not generate near as many particles as the particle system requests. Even an emitter which generates 1 particle per second with a life of one second will occasionally fail to generate a particle at the appropriate time.



I've never witnessed this (actually, the first time I have ever heard about it). Now, some *clients* may grind to a halt because of people running on really slow computers with outdated graphics, and a sudden load of particles turns their otherwise 2-5fps into a slide show, with time for a John Madden play-by-play analysis of each frame. Even if everyone (up to 100 people) turns on a particle emitter, that's only 100 prims that need to be updated. Definitely not a serious hurt on a sim's performance, unless it is already at the very edge of oblivion and any significant event would push it over.



Way cool!



Yep, for the most part, if you minimize the amount of stuff in view that the video card has to render, any lag caused by an underperforming video card will be minimized. Lag comes in many different forms, and affects each system and subsystem differently. Lots of geometry, prims, particles, textures, etc, generally chokes the video subsystem. Flexis, animations, etc take processing power, so if your CPU is a bit slow, it can seriously impact your performance, if it is computing new positions for everything. Flexi hair is especially awful, because it is usually comprised of 50-100+ separate flexi prims, and the computation cost for even just one head of that stuff makes baby CPU cry.



Poorly-designed bling can cause a minor amount of lag. Bling using "brute force" (ie, some particle system someone inexperienced with the art came up with, based on the premise "more is better", and having it generate thousands of particles for a tiny cosmetic effect), or rapid updates to llParticleSystem is especially odious. Generally, it is a client-lag issue, because bling is still a particle effect. The server doesn't even notice. The general complaint that I think most people have about bling is that it is distracting, though some people dress up their requests with a "lag" reason to make it more palatable to the bling wearer and to get his/her compliance to remove it without a hassle.



Everyone within view of an avatar running a custom animation is forced to download said animation. That's not generally a huge problem, unless everyone present is all running new animations all the time. Generally, most folks don't use AOs, or use AOs with fairly common / popular animations (if Nancy is running slinky_walk, Betty coming into view running it as well won't require an additional download). Animations are fairly lightweight as well, so this doesn't tend to be a significant problem unless it gets excessive.



As described above, causes client-side lag or performance issues.



High-prim-count attachments add to the geometry load on the client, esp if they are made of complex shapes, like torii. In many cases, said attachments also contain scripts in every prim for color/texture changing, which is a serious source of server-side lag.



Yes, this is one of the major contributors to sim lag and crashes. It's not usually obvious, because the worst offenders are prim avatar attachments (speaking as a Dragon who wears a full-prim avatar, I know this firsthand). The script time for avatar attachments doesn't show up in any of the estate tools, but its impact is felt as well as noted in the sim statistics (Ctrl-Shift-1, Sim). Every script allocates 16kb of memory (plus overhead), and is checked frequently for queued events ready to run.



Well, understand that listeners, by themselves, are not inherently evil. Scripts do their worst to lag when they are running doing something and, in the case of lots of channel 0 listen scripts, are frequently doing something if there is a lot of people present chatting. Otherwise, a channel 0 listen script is no more lag-inducing than a channel -1000000 listen script, if no one is chatting nearby. That said, it is obvious that channel 0 listeners, which have no real reason to listen to channel 0 chat, other than laziness on the part of the scripter, should be shot. AOs are notorious for this, and there is no reason for them to have to listen to channel 0. "/1ao off" really isn't that much more inconvenient than typing "/ao off", but there are a lot of common free AO scripts out there which still listen to channel 0 for commands.



Time dilation isn't really just about scripts; it is everything about the sim, and it is simply defined as the ratio of simulator time passed to real time passed. Since the simulator cannot run faster than "real time", its value can never be greater than 1.0, but in the constant battle with the Lag Monster, "time" in the simulation will pass at a slower rate than real time. It's not really representative of that concept, though; it is more of a health indicator of the simulator process itself.

Lastly, here's some advice on what to ask attendees to do to help alleviate lag at your events, with some explanations:

1) Remove unnecessary attachments. Reduces simulator/script load, as well as geometry load for folks with lower-performing systems. People who wear non-human prim avatars might get a little upset (I don't even have a human av anymore), but just ask them to kindly pick the least primmy of all the avs they have that they would like to wear.
2) Turn off or remove AOs. Beyond lightening the script load, the added load of downloading and running everyone's changing animations is kept in check.
3) Turn off / remove bling. Not so much to reduce lag, but to reduce distractions.
4) (specifically for your class, but also helps in general for some slow client systems) Remove / turn off particle-emitting objects/attachments (including bling items). The less extraneous particle systems that are running, the better for your students to actually see what their creations look like.
5) Remove/de-rez flexi attachments/objects. ESPECIALLY flexi prim hair. Nothing attracts the lag monster like flexi prim hair.
6) For attendees who have lower-end systems, they can specifically turn off many rendering subsystems which cause lag. Generally, I recommend turning off particles (not relevant in your case.. attendees need to see their particles!), flexis, Bumpmapping, grass, trees, animated textures, clouds, etc. They can do this via the Client menu (type Ctrl-Alt-D to bring it up at the top of the screen if it isn't there), then the Rendering submenu. They can also go into their Preferences under the Graphics tabs and change things like View distance, mesh detail, turn off bump/shiny, etc. Whatever it takes to get a decent frame rate when in a large group of people.

Threshin,
I've been to that sim when no particles were running. No offense intended but that sim is lagged not due to particles but due to all the prims. Each individual prim has to be rendered, even those that aren't openly visible (such as behind a wall or under a floor). It was laggy before the island was rebuilt. That's why except for extremely unusual cases, I almost never come there anymore..... just way too laggy.

no you can't turn of listeners unless there is a build in menu the only option is to remove them.

heyas;

thanks guys, i feel much more educated, now :)


oryx: unfortunately, because the shoes/scripts are no mod, you can't even stop the script from running with the tools menu. you could *try* deleting the script, if you're sure you never ever want to change the shoe colours again. i think i managed to delete a particle script from a no-mod avatar part. sadly, i couldn't then put in an empty particle system call to actually remove the particle emitter! d'oh!
at any rate, listening to channel 5 isn't too bad. at least it isn't trying to parse everything that everyone says.


is there any tool -- radar hud or debugging thing -- that would let me scan someone for active scripts? that' be kinda cool. 'yo, joe newbie, you are currently running 556 scripts in your prim hair alone!'

There's a beacon for scripted objects but it won't give you that level of detail..

Even if you turn off particles in your rendering and no longer see them, your system still tracks them, is still lagged by them.