The Megaprims Hit the Metaverse
A single prim hacked to enormous proportion in Second Life
The fundamental building blocks of the virtual world of Second Life are known as “prims” (short for “primitives”), and for various reasons come in sizes no larger than a 10 meter cube. But with the efforts to reverse-engineer the Second Life client going on over at libsecondlife (efforts recently given the stamp of approval by Linden Lab), it now seems something more is possible. Someone, reportedly someone at libSL, has been able to hack up a single 60×60 meter prim that not only doesn’t seem to require a script (which has been used in the past to make a small prim appear larger) but is copyable, transferable and partially modifiable to boot. That’s me up above, standing on the lower right corner of one I was given the other day. (Click the shot for a larger image.) While it could be very cool for builders, Linden Lab is reportedly concerned about the development for a number of reasons, and is trying to make the megaprims go away.
Just having a 60×60 prim to play with is pretty cool, though. While you can’t change the dimensions, you can alter other parameters such as texture, shape, hollow, twist, etc., making a certain amount of novelty possible. Here’s another shot. You can just make out my neighbor Will Webb standing on the opposite corner. (You might have to click it for the larger image to see him.)
Normally, it would take 36 ten-by-ten meter prims to cover this much ground. Since the amount of land you own determines how many prims you can support, hackable prims such as this one (or other versions hackable into other sizes) could have a small impact on the economy. Many people purchase “prims farms” — i.e., extra plots of land that may lie in odd spots of a sim, but which add to the number of prims they can support at their main build — in order to have enough prim resources for the projects they want to complete. Think of a ten-story building with a 60×60 footprint. Rather than needing 360 prims for the floors, you would only need ten. Since each 512 square meter plot of land can support 117 prims, that’s a savings of more than 1,024 square meters, which could save you $10 a month or more in tier fees. And that’s for the floors alone.
Economically, though, the impact would probably not be that great. (Although if you could hack the prims into any size you want, it could have a larger impact.) Still, one resident tells me that Linden Lab is aware of the megaprims and is working to plug the hole in its code that allowed them to be produced. Their more urgent concern may be griefing. A resident in possession of a 4×4 meter plot of land, the smallest available, would be able to cover a lot of ground with a 60×60 meter prim, since only the center of an object must be on land you own in order for you to retain control of it.
So don’t look for a megaprim near you. (I will not be giving out copies, so dont’ ask.) What could be interesting will be to see whether Linden Lab at some point loosens up its restrictions on prim size, perhaps by finding a better way to control prim griefing and the problem of other people’s prims hanging over onto someone’s land. For now, it’s an interesting experiment in supersizing the atomic particles of the virtual world.
Feeds
I was just thinking the other day about how the prim size limits impact a number of legitimate uses. People have been asking for better sizes for some time, and now we get holes plugged to prevent it.
Rather than DRM this the way Sony might, why not find a way to give people with legitimate reasons for large prims the ability to create them? Their current approach adds lag through the automatic increase in geometry and inhibits legitimate builders… apparently to prevent potential abuse. Boy, does that sound familiar or what?
Well, that “people with legitimate uses” part is going to get sticky fast. Maybe there’s a happy medium. You ought to be able to kick individual objects off your land even if their center isn’t located there. I suspect that’s computationally not feasible, however. And any verification process that megaprims have to undergo on a dynamic basis would also quickly bog everything down.
“megaprims” are known as something else in most MMOs. They’re called “normal”. Go into WoW or EQ or just about any video game and you will realize that big blocky objects are made with big blocky prims. Is there a reason why a 100m x 100m cube made of 800 prims is better than 1 prim? No, the other way around. Linden Lab, I’m told, has the restrictions in place because Havok can’t handle physics collisions with certain types of very large prims. (Sphere, for instance.)
But imagine something like, say, Midnight City, where the giant set-piece buildings could be replaced with 1 prim in their 2-triangle-per-side glory. Or, as you have pictured, entire grids of floors can be replaced with 1 efficient prim.
Of course, there’s a downside. Most lighting algorithms only calculate down to a triangle, so larger prims that are lit by a bright light source may do some unpredictable things. Then again, lights shine through objects into objects that are occluded, so, hey, in my opinion, it’s already pretty unpredictable. (Though the last lighting patch was a great improvement!)
So, I’m wondering if Cory Linden is going to order the destruction of megaprims via server-enforcement, or if libSL is going to open the door for those people who don’t use libSL for megaprims?
I have a hard time believing it’s computationally too intensive to determine whether a prim edge is over a land’s boundary. Calculating whether an edge violates a border shouldn’t be a big deal, especially if they just use bounding boxes such that they don’t need to check on the edge of a tortured prim. If I have a box 60w x 22l x 2h, both the centroid and edges of that box are easy to calulate. Does it add to lag? Sure. However, having more prims also adds to lag; as does having a bunch of poorly written scripts. But LL doesn’t handicap script writers (e.g. eliminating the ability to replicate which is how almost all grid attacks occur).
I’d like to hear the real reasons for this limitation.
“Linden Lab, I’m told, has the restrictions in place because Havok can’t handle physics collisions with certain types of very large prims. (Sphere, for instance.)”
I suspect this is the problem. The visual subdivision of the parametric shape can get pretty fine and certainly helps curvy prims look pretty good. The collisions on the other hand would likely have issues. Which is why the most likely use for megaprims - big rectangular blocks - is also the best suited. Why not limit shapes with curvature (spheres, toroids, aso) to current sizes and open up the limits on flat-sided prims (cubes, pyramids, aso)? That would be a win-win it seems.
The reason I heard given as why megaprims are frowned upon has to do with llPush — as super-massive prims obviously pack a super-massive wallop.
“Why not limit shapes with curvature (spheres, toroids, aso) to current sizes and open up the limits on flat-sided prims (cubes, pyramids, aso)? That would be a win-win it seems.”
Except in the case where a 40×40x40 sphere would be really handy, like, say, in a planetarium, for a simple example. Thing is, when these prims become something you can use to design with, they become valuable; they open doors in design thinking methods that would otherwise be nearly impossible.
I’d just like to point out that Alpha Zauis on the Teen Grid has made a 256×256 cube (that’s the size of a sim).
“Except in the case where a 40×40×40 sphere would be really handy, like, say, in a planetarium, for a simple example.”
I didn’t say it wouldn’t be useful. I’m simply acknowledging that the coldet issues for curved surfaces might be serious enough to not change the limits on them. You need to read that sentence in the context of the paragraph.
Additional potential economic impacts of this development lie in the marketable expertise currently required to build the equivalent of mega prims, as well as in the sale of scripted builder’s tools developed to assist in the process of working around the 10m limitation. For example I used the (in this case free and well-known) Ringmaker tool in the design of the Mauve Infohub to create a circular platform 30m in diameter.
Csven, don’t tell me I need to read in the context of the paragraph. I did that, and commented accordingly. It’s the win-win part that I don’t agree with.
It’s not a win when you can’t use all the possible tools to design with, especially since there are already massive spheres in existence on the grid. Since collision events == screwy with Havok 1, I’m doubting it makes much difference if they’re a bit more screwy with spheres than with blocky prims. In other words, not serious enough to not change the limits on them.
“Csven, don’t tell me I need to read in the context of the paragraph. I did that, and commented accordingly.”
First, I’ll advise you to keep my comments in the appropriate context whenever you feel the need to quote me and reply to me directly; especially when you take exception. Deal with it.
Second, I disagree that you responded in context. You imply in this statement -
Thing is, when these prims become something you can use to design with, they become valuable; they open doors in design thinking methods that would otherwise be nearly impossible.
- that I don’t see value in curved shapes having larger sizes. That suggestion is ludicrous considering my vocation for the last 12 years.
Third, I disagree with your logic. Here’s why:
- It’s a win in that it accounts for the current, unfortunate coldet limitation (which is unlikely to change any time soon).
- It’s a win in that it provides for better prim sizes for those that may not be limited by the current physics engine (not the best) prim sizes). A small win is still a win.
My opinion is that a series of small “win-win” situations is better than all-or-nothing. Apparently you believe in holding your breath until you get what you want. Knock yourself out.
No point arguing with you, since you’ll read into what I say things about yourself, when that is not really the point here.
But —
“Since collision events == screwy with Havok 1, I’m doubting it makes much difference if they’re a bit more screwy with spheres than with blocky prims. In other words, not serious enough to not change the limits on them.”
Well, we don’t know it’s the coldet that’s the issue. Hiro just raised the possibility and I can see why that might be a problem. And I’m not sure it’s just Havok that’s contributing to this possibility. Even so, based on your comment, I suspect you don’t really appreciate the point he’s making because there’s potentially a significant difference between curved surfaces (spheres) and flat surfaces (blocky prims) depending on how they’re handling collisions. If I remember correctly, avatars use a collision sphere (or a pair of them). That suggests they’ve simplified things quite a bit. Depending on how LL is generating the coldet for prims, there could very easily be some issues. But until they inform us, we only know that there could be a problem which might prevent them from increasing prim sizes.
The one conclusion, however, remains: if they can increase the size of some prims and not others, I see no reason why they shouldn’t do so. But the more I think about it, the more I suspect there are additional issues here beyond just collisions. Because if they could, it makes sense from a lag standpoint to make cubes much larger to reduce the overall number.
Perhaps you’re right, and there are more issues than just the coldet. And I may not apprehend all the factors that are keeping megaprims from common usage, but I will say it seems like a possible solution that would satisfy both the limitaions (whatever they might be) and the desire for larger prims would be to make the curved prims forced phantom, similar to flexiprims, so that they don’t have to interact with Havok and bring the grid down in flames. As a side note, all of the megaspheres I’ve seen in-world are phantom already (I’m guessing for some of the reasons you’ve pointed out here). That way, I get to use them to design spaces, knowing the limitations of having a phantom prim, and you can still extract real geometry with ogle (something I think the flexiprims don’t quite allow). Plus, the orthagonal megaprims which can interact nicely with Havok can be allowed, thus paving the way for a decrease in overall prim usage.
Doable?
They could be used for terrain, skys, and noncomplex buildings to great effect; but they would have to be limited to estate and sim owners.
And these objects won’t render if their center is not inside of your view distance, which would be troublesome for lower spec viewers.
But the tools just aren’t there now, and perhaps we can remember this technology in the future when they can be.
One of the reasons I remember hearing for limiting prim sizes was because of server-server communication with prims at the edges of sims. if you have a megaprim at the corner of a sim, that means clients much further from the border of the sim will cause server-server communications to determine what objects are there.
Megaprims cost you in 3D fill-rate. Two of the most important measures of the performance of a 3D card are pixel fill-rate and vertex bandwidth. The larger a prims the more fill-rate is used - slowing down rendering performance for everyone (one of the things that contributes to that catch-all term ‘lag’).
While, the same area covered with a meta-prim or multiple 10×10 prims will require the same fill-rate, the visibility and LOD algorithms in the client will have less flexability to selectively omit rendering unseen prims if there are less due to the use of meta-prims.
Bottom line: meta-prims = more lag for everyone.
Not even a link? Awww Mark, I’m disappointed.
http://slpodcast.com/?p=119
ah, my apologies, Jeremy. To tell you the truth, I was reluctant to link you because I didn’t want to get you in any trouble. I’ll fix you up in the post itself, since it was indeed on your blog that I first spotted the big ol’ prim. Cheers!
I figured that was it. But being a blogger, I throw caution to the wind for a link. :-)