Thank you for writing all of that down. I’ve been in SL for just over a year (I’m posting as my RL avatar here), and have dabbled with building and scripting. However, I’ve never had a good grasp of what was going on. …and I still don’t, but I’m closer thanks to your post.

Can i raise the point of gestures and chat. You can go to some places and people overdose on gestures. I’ve nothing against gestures and chat per se but it astounds me that people dont understand the effort involved in the background in punting each and every line to all the people in range of the speaker. The proximity calculations needed to work out whether an individual can ‘hear’ a line or not must be responsible for some lag on a sim.

A 10 line ASCII art gesture in a sim of 30 people needs to make upto 300 proximity calculations (Obviously there are possible optimisations – dont know if they are being used) – shouting makes the issue worse because its over 96 meters and then theres the actual effort of pushing the lines to each client.

lots of lag?

Or am i missing something?

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.

As to the issues of prims and meshes, your solution is excellent. The question would then arise as to how these exported meshes would be counted in the prim economy. Many have advocated moving to a polygon economy, although the difficulty with that would be that it would be difficult to transition.

A sensible solution would be to replace prim limits with rendering cost limits. The current system of avatar rendering cost (“ARC”) should be extended and applied to all objects (with adaptations as necessary). The scores generated by objects should roughly equate to their current prim values, and the limits per server should also roughly equate to the current prim limits. The uploaded meshes would have a specific cost (which might well be substantially lower than the equivalent prim cost), which would be based on textures and scripts as well as polygons.

On the subject of scripts, it would be sensible if each script was given a cost rating based on the performance that it will require, which cost rating might be a far more effective way of undermining griefing activities than arbitrary limitations applicable to all scripts.

Returning to server limits, one useful architecture to develop would be a system in which servers can assist the rendering of other servers, enabling estate owners to increase the sim’s prim limit one prim at a time, for a proportionate cost. Simultaneously, new rendering options could be developed to reduce the impact on client-side framerate dropouts, including a distance simpling system whereby the geometric complexity of rendered objects falls off at a variable distance depending on the overall load placed on the graphics card, and likewise with the texture resolutions.

Scripters ought have the option of making certain scripts run client-side only (which would be useful for circumstances in which it is not important that the object is displaying the same state to all users), and, for client-side scripts, they could also be deactivated by distance in the same way.

Estate owners ought have the option of disabling certain features on avatars with an ARC over an amount prescribed by the estate owner: for example, “if ARC > 1,500, disable all shiny effects for that avatar”. That should be scriptable so that the limit value can be changed or the feature turned on and off in computationally determined circumstances, including ones that relate to the combined total ARC value on the estate, and the total number of avatars on the estate.

Many of the resource limitations could be reduced substantially in their adverse effect if the limited resources to which they relate were managed more efficiently, both as you suggest in your article, and I suggest above. Alas, efficient resource management does not appear to be a strength of Linden Lab (or, indeed, very many people at all).