llParticle System causes FullUpdate. Why?

Ok. Here's a question I've always wondered. Turn on Show Object Updates in your Debug menu.

See objects with the blue cone? That a partial object update, used only when something small about an object changes, like it's position, or it's texture, rather than the whole object changing through something resembling llSetPrimativeParams, or it being rezzed initially.

The red cones are full object updates. EVERYTHING about that object is redownloaded to the client. Size, position, texturing, everything.

Why is it when I call llParticleSystem, that an object does a red cone rather than a blue cone style update? I'm not changing the size, color, texture, or anything else... Just the particle system.

Good Question. Do you think that is why particles lag so?

i might be way off but i think particles cause frame rate lag just cause there's so many of them dancing around. they shouldn't cause much network lag or server lag because it's a one time thing. they start and then it's all client side right?

Particles don't really lag me. But I think it's part of the reason why frequent particle system -changes- cause slight network lag.

My guess would be that the default way of handling things is to do a full update and that things the Lindens feel might happen a lot get optimised so that they only do a partial update.

The question then becomes not "why does this do a full update" so much as "why hasn't this been optimised to do a partial update". The answer would probably be that it hasn't got to the point where they feel it is a big payoff for the work required: after all, most particle systems probably only change very infrequently.

Changing the floating text above an object seems to do a full update too, and my guess is for the same reason: they just haven't got round to it yet. Which is fair enough, most floating text is completely unchanging and you might as well remove the script from the prim after you've set it. I did see one (advertising) object that was doing scrolled floating text by changing the string a couple of times a second and was therefore doing a full update just as often. Fortunately that kind of thing seems to be the exception.

I'm pretty sure that your observation about particles not causing server-side lag but only client-side lag plus network traffic for any updates is right.

Just a quick note on particles and how they affect client-side FPS (or cause lag as some people describe).

Particles are not rendered the same way as normal 3d objects. The biggest factor in how your 3d accelerator handles them is called fill factor. This is basically the rate your 3d card can "fill" surfaces with textures before sending the final image to the display, and it is directly related to the amount of bandwidth your 3d card has available internally. The higher the fill rate or fill factor, the better your computer will display scenes with many particles.

The reason I bring this up is because... oddly enough... a few 3d cards out there actually increase FPS as the percentage of the screen taken up by particles increases. This is because they have less relative processing power to calculate 3d objects than what is normally required to fill surfaces once they're calculated.

My laptop happens to be one of these. Its 3d accelerator is a nVidia geForce 4 Go, and it's pretty slow until the screen fills up with particles, at which point it speeds up to match my desktop computer. Fun stuff.

Sorry about the off-topic post. Just had to get a little rambling out of the way.

Haven't tested this lately, and this thread is old, but wanted to follow up anyway.

I would expect a full update from each of the following actually:

llSetPrimativeParams(), llParticleSystem(), llSetText, llSetTextureAnim()

Each affects a prim in ways that persist, even if the script that set that attribute
is removed. I would presume that some sort of 'reset' has to happen on that
prim to clear the previous setting (if one exists), and that it may be easier just
to drop prim completely and issue a complete new definition for that prim
rather than some differential.

I kinda wish the editing widget had 'clear all other attributes' button, that would
kill hover text, particles and animated textures... instead of having to script
in off buttons... but I can be incredibly lazy at times.

I once saw a guy wearing a bracelet that glowed with the llParticleSystem() function and caused nonstop red updates. I was able to make a bracelet that glowed that only caused a red update when it loaded.

The difference? His was set on a timer to continually call the llParticleSystem() function to change the colors of the particle effect so it goes from yellow to green to red to blue to purple to white... and so on.

Mine simply stayed the same color, but I could make various versions of the bracelet that are different colors.

Since the SIM we're on has had a history of script problems (we're cleaning it up now), I asked the fellow to remove his bracelet and made the non-color-changing bracelet for him. It brought our Run Agts time from about 20ms to about 10ms on average. That's a pretty big drop.

- Obsidian Stormwind

Just out of curiosity, how often was his script changing the particle colors?
I have some objects that change particle colors on command, but otherwise
the particle system is constant. Just curious how much a single call to llParticleSystem()
will add to load.

Also, I somehow have ended up doing an empty llParticleSystem([]) call prior to initializing with the new colors. Don't know at this point if I should keep that or
just call with the new parameters. Any difference???

The calls were about every quarter of a second, since it made gradual changes from one color to another.

- Obsidian Stormwind

I guess you could make a script with a clearer for each attribute on state_entry, that then deletes itself. Just drag it in to each object, and presto!