Destroy all megaprims

Saturday, October 13, 2007

The latest news that has the SL community in an uproar is Friday's blog post from Michael Linden about the possibility that Linden Lab will do something about the Megaprim problem.

Reaction has been somewhat mixed, but I'd say the most vocal opponents are all outraged over this, and popular sentiment seems to oppose a megaprim ban.

I say, tough. I want Linden Lab to delete all megaprims.

What most of the posters don't seem to realize is that prims are a resource utilization metric. They're the size they are (10x10 max) for a reason. They measure how much of the overall grid you are using. It's not just some arbitrary size. The more prims you have, and the more volume you cover with them, the more network bandwidth you use (to send geometry and texture information to everyone who sees them) and the more CPU cycles you use (to calculate occlusion, collisions, physics, etc). When you use megaprims, you're using more than your fair share of resources.

The arguments for keeping megaprims seem to fall into three or four broad categories:

"They're too useful to get rid of! Without megaprims I'd never be able to build my house/RPG sim/ amazing sculpture and keep it under the prim cap"

Well, duh. There's a reason for the prim cap. Just because megaprims let you cheat your way around it doesn't mean you deserve to keep them.

I see post after post of people saying "I used megaprims to build a floor that would have taken much more prims otherwise! So it actually saved prims and uses less resources." Maybe that would be true if all you built is a floor. But did you stop with that? No. You kept on building, using every last prim -- much more than you could have if you didn't have that megaprim floor.

"I used megaprims to build my amazing sim that everyone loves, and if megaprims went away I couldn't rebuild it."

Guess what? You have only yourself to blame.

Unlike WarpPos, or the llSetLinkPrimititveParams() move trick, megaprims are a hack. Not the "clever way of using LSL" kind of hack, but the "try to defeat planned safeguards" kind of hack. There was code in the viewer that explicitly tried to prevent you from making these giant resource hogs! The only reason they exist is because one person hacked around the safeguards.

Megaprims were always shaky. From the day Linden Lab patched the server to fix the megaprim exploit, users were warned, "these might go away at any time." If you constructed your build around a feature Linden Lab explicitly warned you was flaky, then it's your own fault if it comes tumbling down.

"I've never seen Megaprims cause any problems for anyone"

Excuse me, do you have the statistics on bandwidth utilization from Linden Lab? Can you tell me how megaprims affect the visibility culling algorithm from across sim boundaries? No? Then quit talking out of your ass. When the megaprim hack first appeared, the Lindens said they would study it to see if it impacted grid stability too much. Guess what -- they do!

"Don't ban the tools, ban the people"

This isn't about griefing, or good versus bad uses of megaprims. It's about keeping the grid stable for everyone. Megaprims hurt everyone, by destabilizing the resource metrics.

Perhaps someday, with increased bandwidth and CPU capabilities, we will be able to have megaprims for everyone. For now, though, I will be very happy to see them erased from the grid.



private sim

scohp said...
October 13, 2007 at 7:42 PM  

Thank you, thank you, thank you. I fully support every word you said.

The script-kiddies and heedless metaversal service agency myrmidons touting this resource hog are the usual suspects -- remember when Aimee Weber wanted "no push" to be an option adding another confusing slider to avatars themselves, rather than to the land?

I don't believe the mantra about "ban people, not grief tools" is at all sound. Please do a very thorough inventory and analysis of how these push commands are fact really, really used in SL such as to justify them. Um...the 17 elevators used in SL where people Now explain to me again why we need to put up with that crap?

Megaprims have absolutely no business on the mainland, whatever case you might make for them on islands. They are used far, far more for griefing than "good" uses and even "good" users constantly whack them around accidently griefing neighbours and lagging sims anyway. I simply don't allow them in my rentals because experience has shown me that they always end up harassing everybody else, even when not griefing per se, and they raise real questions about the resource issues and lag.

I don't see why I need to subsidize the careers of mega builders and griefers at the expense of what little CPU there is to go around in SL.

Prokofy Neva

dyerbrookME said...
October 13, 2007 at 9:56 PM  

mega prims are not the biggest contributor to sim lag. that award goes to one and only one LSL command and that would be llSleep. this command uses so many cycles that it's insane, it's 100 times laggier than a .1 second timer(get sim tools or a friend with them). the sad part is that it's used by 99% of scripters and to magnify the problem nearly the same number of scripters don't know that it's a problem.

as for using a large percent of resources. the most used megaprim is a cube which is one of the simplest calculations for physics stuff. so even if for some odd reason it does use more resources it would most likely be the same as a tortured prim.

as for arguments for removing megaprims from mainland I see no argument against it. people renting there already know that the land is heavily managed by LL.

however in the case of private sims LL should take a hands off approach if they do end up having any issues with them it's the sim owners problem not LL's.

scohp said...
October 14, 2007 at 7:35 AM  

Sorry, Rifkin, I'll have to part ways with you here.

No, I'm not Linden Lab. But we have done quite a lot of resource testing in Suffugium out of simple necessity; our various automatic systems (the police drones, cars wandering the streets, and interactive stuff all around) are rather resource-consuming.

It was our testing that first found that a script in an object that is idle but 'running' still consumes time on the scheduler. While I can hardly claim to have exhaustively tested every possible scenario, megaprims are no more resource intensive than a 'normal' prim of the same type... save only that they aren't culled.

This does not say "delete all megaprims" to me. This says, "fix the culling routine".

Aliasi said...
October 16, 2007 at 8:42 PM  

Mega prims take up no more resources than normal prims. In fact it uses the same. A prim is a collection of numbers Position, Size, Rotation and the various othe settings along with a referene to a texture (not the texture itself) and texture settings (so and so forth, whats avalilable in the build menu). That never changes, the amount of data that is processed is the same for a 36km2 prim as a 0.1m2 prim. These numbers are passed to the client. The client feeds these through some math routines to generate a mesh. (the 3D representation of the object) And again, the same number of triangles created regardless of the size of item. (at least with flat surfaces, it may be different with spheres and cylinders, but I don't think it is, as small spheres use for too many vertices for what they are).

The only potential resource problem with Megaprims is when the new havok4 system comes in, and thats due to the "collision islanding" it does. If someone put a sim-wide prim down, the new havok4 can't create little "islands" of objects in its memory structure to do less collisions as it would all be one big "collision island". And worse that does, is make Havok4 perform like Havok1 for a sim.

The resource hog that lags sims, are scripts, both those in rezzed items in the sim, and those worn by avatars.

And the number of prims affects performance too (a larger list to check through when trying to decide what to dish out to each avatar).

So infact megaprims help performance. "Less prims, less data, less data to pass on along the network, less data to feed through functions = greate performance".

Nik Radford said...
October 17, 2007 at 7:47 AM  

I think the culling problem isn't so much of a problem. Really a megaprims culling takes place from the center of the prim so, like the sign on the mirror "objects may not be as close as they appear". A bigger problem with megaprims is that at low draw distance you may be too far away from the center point to see a mega that you are colliding with. Anyone who uses them for building soon enough discovers these things and works around them.

Megaprims take away the issue of high bandwidth requirements of rendering many many prims for a simple surface which, as your object increases in size, tends towards increasing the geometry requirements on the client and download bandwidth by a factor of six.

It's very easy to see this effect in say the greenies sim by poppin in there and watching how long it takes to render the entire wall/floor/roof surface as opposed to the kicker rails and other geometry in the area. Megas are a clear winner.

The only people who will find geometry lag by the use of megaprims are those who insist in seeing the maximum half kilometer draw distance in sl. Those folk are just asking for lag as they're expecting to be able to see up to 9 sims around them. When it comes to occlusion based on size megas are going to win hands down, which isn't such a bad thing considering they're... well... big.

Pavig said...
October 28, 2007 at 3:13 AM  

I use mega prims. I don't use zero prim rezzers because I think they probably create more lag and also are more draining on resources. I'm not a prim capacity so it's not to squeeze every last drop out of the land I own. I own on main land because unless you own your own private island, there's no guarantee you will have more rights than you would on mainland. *shrugs* I could be wrong. Also I don't use mega prims as a mere resource saving exercise, I use them because of the ease of working with larger structures. I'd like to see some independent stats that contain data about the testing environment before I'm convinced they are good, bad or neutral. For now, they're convenient.

Moggs Oceanlane said...
June 5, 2008 at 2:34 AM  

OK, This is BS. I love megaprims. They are the gold of SL

Chris said...
August 20, 2008 at 10:30 PM  

I believe what Chris says is acctually true (the BS part), first off, megaprims are about the least of the problems around SL so this kind of discussion is most very pointless due to the fact of the ammount of bugs in SL, which also means if megaprims are taken away then SL loses alot of sim buyers, also let me make it clear that with megaprims i think you will find the lag is less, however lag is used as an excuse but the main reason is infact the prims, which means people want sims with less prims *aaww*, however if people were not to use megaprims, then you will find walls and floors and ceilings with scabby black lines which brings noyment and also DOES cause more lag as SL is loading more than 1 prim for a wall, which means longer loading time, only reason i know this is because i've been behind the engineering of other games.

"Well, duh. There's a reason for the prim cap."

"Guess what? You have only yourself to blame."

"Excuse me, do you have the statistics on bandwidth utilization from Linden Lab?"

Thats no way to convince people of this matter.

If you have any proof, statistics, anything, please share, none of what you wrote makes in sence.

Anonymous said...
January 23, 2009 at 12:22 PM  

Post a Comment