Do Megaprims cause lag?

My neighbor in the next region is an artist from Italy. She is fond of creating big, rotating globes with various images inside. They usually are full bright, emitting particles and have flexi attachments that wave around. I can't say I care for the globes too much, but I am an artist myself and I respect others' right to creative experimentation.

The latest addition over there is made from megaprims. I dont know the exact size but it is well over 100x100 m. It is up at 500 m high in the corner of a region and it is apparent from the mini-map that it extends out over the three adjacent regions about 30-40 m. Mostly over protected land, but a little over the edge of my home.

I can't even see this thing until I get up over the clouds and I'm inclined to just let it go but a friend told me that megaprims cause lag and she should not be allowed to push that lag over my home. (These globes are so frenetic, they *look* like they would cause lag)

So, my question is do you think Megaprims overlapping regions cause lag?

ps: I have sent IMs to my neighbor and gone so far as to translate my concerns into Italian, but received no replies.

A lot of evils get attributed to megas that do not apply, and one of those is often the assumption of lag by megas.

That said, the only ones that have shown themselves to be trouble are the spheres, especially the large one (particularly if they're not phantom). Overlapping sim borders can be an issue as well, and could lead to some troubles. Prim movement, flexi, heavy textures, and particles can also increase lag on a viewer's side of things.

Don't trust the mini map for prim boundaries, though: it's notoriously bad. If the prims are overlapping others' property, however, they are likely to face some issues with the GTeam.

No. Unless the prim center is within 10m of the sim edge they are not even in theory "seen" by the physics engine, and I don't believe that "historically significant" region is even involved in sim physics any more... I've not been able to get any indication via experiments that even *physical* objects (let alone non-physical ones) are handled across sim boundaries until they actually cross them.

All of this sounds more likely a cause for lag than it being the mega prim. All of these attributes cause both graphic and script lag.

*shakes head* Gah, nothing says lag like a rotating, full bright, texture changing (this include texture rotations, sliding, etc), particle spewing, flexi-prim.

Not even 400 prim flexi bling hair using three attachment points?

Only newbies make hair like that.. You can stuff 750+ sims into 3 attachment points!!

Yep. Hair that you can't drop onto an (new) openspace without maxing out the sim prim count.

Well... toss in a rotating script on two of those attachments and I'll say equal to it Of course, this would also say Blingtard and Prim Whore too.

"Graphic" viewer-side lag, definitely, but I'm not seeing anything in the list that would cause script lag. Nor even anything that would require a script to remain in the prim at all, if we assume the rotation is non-physical llTargetOmega and the texture changing is all a single call to llSetTextureAnim.

Of course, probably most of the prim "water" in SL still has a texture anim script still running in each prim, plus maybe a particle script--years after the functions were called their one and only time. (One possible upside of upcoming OpenSpace script limits: maybe folks will get in the habit of tidying up some of the "running" scripts that should have removed themselves right in state_entry.)

Qie, I have no clue about scripting. To be honest, I only put that in there because it popped into my head, because most of the stuff requires a script to be in there at least once.

I bow to your knowledge

And thank you for reminding me to remove the script from the fountain water when I am able to get back in world.

Actually, you can just open it and set it to Not Running and that's just as good. In fact, it only uses a very tiny slice of time even if it is left running--there's no event that can make it actually do anything, but somehow it still gets "noticed" by the scheduler.

(Okay, confession: I mention the option of leaving in the non-running script because I recently "tidied up" a prim assembly by removing all the texture anim scripts, mistakenly thinking I had a backup. And now I'm having trouble exactly duplicating the effect. )

File a abuse report! And italians never respond, its hard to handle them.

Totaly agree, they are so damned ignorant I am still AR'ing my neighbours stuff who is also Italian after several polite attempts with IM's and no response and everytime I walk within 20 metres of my corner plot I get spammed by several vendors.

Regarding the OP I would AR the mega's if they can be confirmed as overlapping borders as this is parcel encroachment.
One of the reasons as I understand that LL won't officially allow the use of mega prims is because they have not found a way to deal with parcel encroachment.

As for the lag issue, I recently rebuilt all my stuff to cut down on their prim count and now I have approx 20 builds with 4-5 megas in each, I have not noticed any lag whatsoever.

AR it. If it does indeed overlap protected land, the in world team will be all over it in a nano second.

I didn't know you could/should remove those passive scripts. What about sim restarts etc ?

I've never noticed any issues with megas. Been using them all along, even made a bunch and use them in builds.
Funny though, if megas were ARable on other grids, nobody would be there. They (other grid crowd) settled on 128m size limits. Which is, imo, the best option.

Stuff like particles, target omega, texture animations and floaty text are prim properties - they survive a sim restart. Actually, they survive just about anything except for a script that tells them to stop.

Restarts won't matter because the sim doesn't actually do anything to make the effect created by those functions; rather, the scripts set properties of the prim that persist and are downloaded to the client whether the script is still present in the object or not. There's quite a list of such properties, but some that seem likely to be in left-behind scripts are texture animation, particles, smooth rotation, and static hovertext. It doesn't create huge lag to have some of those left in the running state, but in quantity they have a measurable impact on sim script time despite the fact the scripts themselves never actually execute any instructions after they first run.

Of course, if a script changes these properties (emit different particles over time, perhaps, or maybe scroll hovertext) then those scripts are active and must remain to maintain the effect--but those scripts really do cause script lag, and some network load, too, as the changed parameters get pushed to viewers.

Megaprims don't cause lag. Large textures, multiple textures, multiprim builds, physical objects and bad scripts are main cause of lag. Bad scripts and physical objects in server side - multiprim builds and textures in client side. (I actually think that they might reduce lag, because large megaprim house have less polys and less data to transfer than same house made by normal prims.)

However - megaprims are great tool for griefers (allows to cross land boundaries) and current land economy is based to prim counts (it would be bad for landlords, if prim count would be less valuable suddenly).

Unless they're physical or volume detect'ed..

However some of them need to have the scripts remain in the object if they're going to keep the effect after a sim restart. I was talking in-world with someone a couple years back who had to go and re-script a bunch of content in one of his builds after a restart. I don't remember which it was, so I generally disable such scripts rather than remove them now.

... or shift-drag to copy

Oops -- I use a 20x20x30 mega to detect when anyone's in my shop. (Don't remember whether I used collision or volume: probably the latter -- is there a difference for lag?)

Would it be better tu use a sensor?

Thanks

That's creating a new object, though.. Add a VWR bug - I'll vote for it.


The sim uses a std:map to keep track of object pairs that are colliding. It ages things on the map every physics tick and pulls them out when they're old enough.

Normally, this is a really fast operation. The problem with mega prims is that, in a lots-of-collisions environment, these maps can get really big and drag sim performance down as the iterator has to chew through more and more entries.

Also, AABB is world-Axis Aligned. If you have a megaprim that's, say, rotated 45 degrees off the world cardinal axiseses, it's gonna have a big honkin' bounding box. Far bigger than you'd probably expect.

edit: and to actually answer your question: don't worry about it unless you've got tons of people walking around all the time. It's hard to find something more expensive than sensors. If you'd like to worry about it anyway, you'll probably put less load in the sim by having a number of vertical prims, megaprim or not, at strategic places instead of a single one on the floor. You won't pick up people who TP into an area then don't leave it, though.

So is drag from inventory for copiable object, but it nonetheless retains all the features you mentioned.

This is a very old, well known issue. I'm sure there's a JIRA already, but I might as well look it up.

OK, thanks, that helps. It's aligned (rotated 0 degrees), and not particularly busy, so I'll probably leave it, but maybe do something different next time. For a sensor, I'd only need to scan once a minute or longer, which would offset the cost.

Shift-drag to copy object does not copy all settings

http://jira.secondlife.com/browse/VWR-640