Optimization: object loading prioritization

I have a fairly decent bandwidth, low-latency connection. Yet, when entering a new area it takes quite a while for all the stuff to load. I was thinking the other day of a possible optimization that could be done to make things faster.

Say you're entering a sim with lots of buildings and houses. Wouldn't it make sense for the OUTSIDES of the buildings to be loaded first, and let the details load afterwards? That way, the basic shape/position of everything can load quite fast, so when you're flying through sims, you can see the obstacles/landmarks in a much more timely manner.

Ok great, but now how would it KNOW which objects make up the "important" or "outside" parts of buildings? I say there's no need for complicated algorithms... just let creators of the houses/buildings prioritize the preferred loading order themselves! Either by assigning an order to individual prims making up a linked-set, or by some kind of "important" flag one could set in the build menu, that would tag certain items to load first. Taking it further, this could be expanded to some kind of user-defined LOD system too with more flags/relationships than just "important" and "not as important".

So by offloading the prioritization to the builders, what's the incentive to even USE this feature? I think that there's plenty of incentive, since if the building loads fast on the outside, it has a higher chance of being loaded first when a passing visitor visits the general area.

Oh yeah, there's also the potential for abuse I guess, since a shopowner might flag EVERY prim in his shop as "important". Solution? Probably impose some kind of per-parcel, per-user numerical limits. It might also cut down on the server overhead in terms of structures. This is good if, later on, a more complex user-controlled LOD system is implemented.

Thoughts? Is such an (automatic) system already in place in SL that I totally missed?

It is a good idea, but as things in SL change so rapidly that players rarely keep their parcel descriptions up to date, I would expect it to get little use in practice.

The problem you speak of is endemic to SL and is a result of the system serving many times the size of the world it was originally designed for. There are many threads which discuss the topic of which this is one. I don't expect this problem to have an easy solution.

Interesting ideas. You answered my several questions as I asked them, "Ok, how do you know what's the outside of a building?" and "What if people just set everything high-priority to compete with their neighbors who're doing the same thing?"

The latter, I don't think you fully answered. A limit is good, but what happens when I rez a prefab house and I don't have any "high priority tokens" left on my plot? It fails to rez? Gives the user a cryptic and no-doubt confusing error message about priority limits? Quietly unsets some high-priority flags?

Uh, this is already how it's supposed to work. Larger prims and those closer to you load first.

Hm, I anticipated that might be a problem. There is an alternative, but it's harder to implement and not as straightforward as the original idea.

Instead of users manually specifying the drawing order, have the local SL client report back to the server with some statistics. After things are drawn, the client knows which prims are occluded (since it already drew them), and can keep track of a statistical average of which prims are the most drawn / most visible. This data can be uploaded to the server, from many users, from many vantage points, and itself averaged, to give a rough estimate of which objects really need drawing first. Worst-case is that a brand new sim with brand new buildings has no data collected yet, so things draw in the default order they already do anyways with no slowdown.

Advantages over manually setting the order: Can't be abused, no work needs to be done for existing buildings, and the data can be updated over time.
Disadvantages? Somewhat algorithmic, harder to implement, more data to send back to the server.