10-meter Prim Size Limit - Why Not Change?

I don't know if this subject has been discussed in depth before, but the long-standing 10-meter size limitation on prim dimensions seems a bit arbitrary to me.

Since many people like to build structures much larger than 10m - especially where buildings, bridges, monuments and the like are concerned - it seems as though permitting a larger dimension on some or all prim types would help to reduce prim counts, and thus improve performance.

Has this limitation always been the case (say, before Beta?) Can anyone expound upon any relevant technical reasons why this 10-meter limit is in place? What's it all about, Charliebrown Linden?

Obviously the interface itself is already geared to accept a double-digit number before the decimal point, so why not have the upper limit be 12? or 16? (Something divisible by 4 would seem appropriate due to land parcel sizes, as Eggy Lippmann has pointed out in the past.)

I know that I'd like to have bigger prims available. Now, much as I'd rather not encounter 16-meter-based penii (as opposed to the current 10-meter-based ones... ), there must be a better reason for the current limit... isn't there?

=Monumentally,
=Sinclair

As much as it seems unrelated, I believe the reason for the 10 meter size limitation is due to the amount of simulator overlap. I *think* LL wanted to reduce the effects of the phantom-over-boarder anomoly, which occurs when a prim's center is in sim A and it overlaps into another simulator, sim B. As far as I know, since the prim's center is not in sim B, the prim does not exist in sim B.

This anomoly is very bad for vehicles on which you stand on, and a nuisance for traveling objects that serve purposes other then being something that is sat on.

==Chris

This last part is true, and is not hard to demonstrate (hint: a 10mx10m square is over 14m along the diagonal).

To my mind the cure is worse than the problem. We are already living with and working around much more problematic issues than this.

I tell you what. If they let me rez bigger prims I'll be a good girl and won't put them across sim boundaries. Promise. Okay, now?

Actually, I'd be just fine gluing 10x10 squares together if they didn't each get a separate (apparently random) level of illumination, making the whole thing look like a badly designed quilt.

Please either fix the lighting or let me rez bigger prims.

--Almarea

Hmmm - if the "overlap" problem was the main issue, it seems like it would be possible to deal with.

Say by preventing script executions in prims over a certain size, or checking for the sim edge on move/edit operations... but I ramble...

Anyone else have a theory?

=SV

It's been stated at various times in various places by various Lindens that the overlap problem is the reason for limiting prim sizes.

Can anyone point me to more info on this? I had no idea that the prim limit was in any way related to the overlap.
It seems counterintuitive.
It wouldnt hurt anyone if they would just disallow building a prim across sim borders. if you have a house on a sim border you can just build symetrical, independent halves on each sim. And fall through the floor too

I've never seen this phenomenon of which you speak. I've run SL on 12 different computers in the last 6 months and I've always seen objects composed in this way appear to be seemless (assuming the prims are lined up properly and all have the same texture, of course).

I would be willing to bet, Alma, that the problem lies either in your video card or in your display settings. I'd be curious to hear what hardware you're using, but to me the most obvious culpret that comes to mind is perhaps your bumpiness draw distance is set too low. If it's very low, then prims with their ceneters near the camera may appear to be lit very differently than prims that are centered further away. Turn it up, and things should even out. Also, make sure you have the latest version of DirectX (assuming you're on a PC) and the latest drivers for your video card and monitor.

Sounds like Almarea has "Local Lighting" on... I get the same thing occassionally, it's a problem with the way lighting works right now I'd gather.

Ah crap that's why they aren't bigger yet? Well that sucks. I agree that the current LL solution IS worse than the problem though. People will learn not to build floors across sim borders fast enough when they start falling through them.

I don't think it's a big issue with building...for vehicles, I'm not sure what kind of effect it would have.

Also the issue with bigger prims is the need to draw prims that are further from frame the av can see. Example: when you fly over large pine trees the tree disappears.

I believe that the restriction on the scale of a given prim isn't so much technical as aesthetic, historical, or perhaps just a matter of proportion...

Aesthetic: Although in some cases, larger prims could be used for good instead of evil, much of the time, they would be eyesores. Granted, it's an incovenience to fashion larger prims out of smaller prims, but how would you like 20x20x20 rotating orange cubes in your back yard?

Historical: Back in beta, the only cap on the number of prims you could have was how much cash you had. $L10 per prim. I think the size limitation put a then-necessary limitation on how much prim volume users could afford.

Proportion: Limiting factors shape architecture. For example, humans fall into a particular range of dimensions that set a height for ceilings and width for doors. Buildings can only be built to a certain height within practical limitations due to limitations of materials in real life. This makes for a relatively level city-scape. Limited scale on prims may serve to establish restrictions similar to those placed on RL architecture.

How well any of these explanations hold is up for debate, but they're the only real explanations I can think of.

neighbors?

a prim can stick out into a neighboring plot by less than half its size and not be deletable/removable from the neighbor... with a max of a little under 5m now its not THAT critical... with a max of say 30m you could literally just pave over someone else's plot without a whole lot they could do

not that its not an insurmountable problem (jus don't allow overlap at all.. or allow people to delete with ANY overlap, not jus >1/2

its jus one more layer of complexity keeping the system as is for now

Why not abolish prim size limits completely, but restrict them entirely to the confines of a player's land?

I don't think that there are any plots of land that cross area boundaries, (I'm new here, correct me if I'm wrong) so this would solve most of the problems presented.

For scripted objects that can move, would adding a shadow area around each sim where prims are rendered in both (Or, if possible, rendered in the one the viewer is in)


In terms of speeding things up, using an occtree for non-scripted opaque prims would give a noticable boost to framerate, seeing as how many people build enclosed structures.

What sort of characteristics does an octree have when objects may be inserted, removed, or moved at any time? Do you need to rebuild the tree from scratch? From a near-root node? Or can you just make local modifications?

Great resource -> http://www.gamedev.net/

A relevent thread -> http://www.gamedev.net/community/forums/topic.asp?topic_id=138216

Summary: Depends how you impliment it.

Worst case scenario, you leave-out objects that are scripted or being edited from the tree, and recalculate every time something changes to the inactive state. Even in an environment where everything is moving, the terrain will give a speed boost. Octrees are fast.

---Edit---
A basic, standard octree with example pictures and psudocode -> http://hpcc.engin.umich.edu/CFD/users/charlton/Thesis/html/node29.html

http://www.gamedev.net/ w00t!

(Hey, it's a good site.)

I'm not sure I like the idea of not letting prims sit across owner-borders. Then again I like the idea of undeleteable prims sitting halfway on your land even less.

I like the speed boost it would give