A nice article from Gwyneth Llewelyn about the technical limits of Second Life, both by design and reality can be seen at the link below. Gwyn discusss region sizs, prim limits, animation overrides, LSL and more:

Gwyn’s Home Blog Archive No More Limits!

My response was mostly about the Region limits discussed hence the post title:

Hey Gwyn, thanks for the post, hopefully it will educate some of the people. Your suggestion for in-world mesh creation is great, though today we need to go beyond meshes into bones and other modern 3D conventions. As for LSL, what can I say, it is putrid garbage. MONO doesn't get to be a saviour yet, until the Second Life functions are made into a library so standard .NET languages can be used it's still LSL. And there really needs to be a time limit on non-MONO script support since as long as the LSL engine runs the performance drag remains.

What I really want to talk about is the simulator. You know I am a big proponent of the contiguous grid, without it you don't have a "virtual world", you have a bunch of 3D rooms. I won't get into your Snowcrash analogies as it offends me each time people suggest that dude inspired anything. He wasn't even the hundredth guy to talk about virtual worlds or avatars. And while he may have used multiples of 16, the true computer building block (HEX numericals), I would hope programmers a decade later wouldn't be looking at that kind of math for inspiration. A connected grid is a must, it was the simplistic choices the Lindens made that got us into this mess. One side comment, a lot of your calculations are based on everyone setting their draw distance to 512 to see the entire region and that all the prims are on the ground or a level where they would be rendered, and I don't know where you got the 5 million polygons a second figure from, since polygos are an abstract and most 3D renders are calculated by the number of triangles per second. Neither here nor there, but Second Life has usually listed a robust minimum system requirement where the listed cards draw billions of polygons a second.

To get off the ground fast they chose as many off-the-shelf (or close to it) tools as possible. An awful 3D rendering package (ven awful RenderWare would have been a better choice), a broken physics engine (Havok 1 was never really finished for Linux, and Havok 2 was already announced and near completion with full Linux support in 2002) and who knows what for the IM infrastructure. Slap these things together and decide that one processor for one region gives them the best control of the simulation and the recipe for disaster is there from day one.

Even this bad choice could have worked better, and I want to throw up an example before explaining the infrastructure that should have been obvious from day one. That example is a little game for last generation's consoles called Star Wars Battlefront. Released in 2004 by LucasArts and developed by Pandemic, this game was designed for online play. While there were PS2, PC and Xbox versions, I'm going to talk about the Xbox version. The Xbox was essentially an i386 computer with a 2002 nVidia GPU, hardly state-of-the-art at the time. As for networking, Xbox Live uses P2P networking rather than a central server meaning all machines have to send avatar movements, vehicle locations, bullets and more to each other, far slower than a small upload stream to a server collecting the data and passing it down fast. Despite these limitations Star Wars Battlefront allowed the home user to host matches where 16 users fought alongside 16 computer-controlled combatants on maps (regions) four times larger or more than a Second Life region. The puny i386 was calculating AI for the NPCs, tracking mines laid, bullets shot, vehicles exploding and more. Before the old "user generated content" argument comes up, the only difference between Star Wars Battlefront's content and content on a Second Life server is the location, streamed from disc versus streamed from network. There is no magic in Second Life's distribution of content. So here we have an underpowered systm with no central server outperforming Second Life in essentially the same development window. Sad.

How could it have been done? How should have it been done? I don't want to get too technical or Prok will yell at me, but here goes. Distributed computing. They already did this with inventory but why not the simulation features. Servers designed to run the scripts communicationg with the ones running physics and others the objects on a region. When a region is unoccupied and not within anyone's draw distance resources are shuffled to support the active regions. No pre-determined region size at all, just contiguous land and distributed simulation calculations. It would have been much cheaper as there could be load balancing and it could scale. Just as there is only one google.com there are thousands of servers in the backend making us think there is only one. Empty regions with running scripts getting fewer resources. Local cache of regions so the server doesn't have to push all the polygons constantly with client-side occlusion. I could go on and on... unfortunately.

Last bit from this windbag comment: the Animation Override issue shouldnt really take much to fix. Of all the assinine development decisions that need repair this one is both a no-brainer and houldn't be much wok to implement. And client-side cache them as well.

__________________
"'PC Load Letter'? What the fuck does that mean?" - Michael Bolton, Office Space