'High Prority' for Prims

Perhaps some sort of ranking method, whereby people can assign priorities to primitives. (Perhaps at some sort of cost).

I don't mean they load before everyone elses, I just mean, eg, walls and large prims that are parts of a buildings architecture would be rezzed first (downloaded priority) and then the decorations, etc, inside, would be downloaded after that.

So if you're building a house, you'd set your walls and stuff to be high priority and your furniture and such to be low.

Then as people flew around the furniture wouldn't be visible through translucent still-rezzing walls, and the important, large structural collidable polygons would be loaded first.

Perhaps a scale from 1 to 10 how important a particular prim is, as part of the properties of a prim.

Note that it shoudln't allow someone to stuff all their prims to max priority... So if 50 prims need to be loaded from Joe Omega and 50 from Sue Black, if Joe had all his prims on max priority, and Sue had her walls only on max, then it would still rez both Sue's and Black's stuff at the same time (as always right now), but Sue's walls would rez first, making it look better and such, wheras you might still run into Joe's building while it is still invisible (as you can already).

Note that the distinction between 'architectural' and 'decoration' objects is not new. Most games have some sort of distiction, for very similar reasons.

Other ideas include prims having a max draw distance on themselves. So if you have a flowerpot in a basement somewhere, that you can only see when you're IN the basement, you can set its max radius quite low.

Alternatively, this can be AUTOMATICALLY COMPUTED! For example, whenever someone sees a prim, (or every 10th... or 100th... or n'th time... to save cpu / bandwidth), the client tells the server how far it was away from the prim when it was seen (unless it turns out to be behind a wall or something.. I know this can be detected because you can click on walls and things).

The server simply waits until a couple hundred 'seen' requests come in, and then sets the prim's max distance to the maximum distance it was seen at. TADA: Automatic distributed visibility detection. Moving an object would reset it to max. After it was 'seen' and transmimtted to clients, the 'seen' computations would still carry on, narrowing down the range (or if a client moves back and glimpses it from even farther than before, widening it). The seen computation would not hide objects on clients, (maybe?) merely decide when to transmit object....

What makes this particularly nice is that over time, static objects become very accurately computed. A vase thats inside a room with no windows very rapidly becomes restricted to just that radius in which it can actually be seen. And it cost the players nothing anyway, and certainly not lindens. Basically a distributed optimization technique...

Just some stuff to mull over...

I like this idea! Perhaps have maximum priority's actual "wait time effects" be weighted using a number-of-prims-set-to-maximum calculation. Perhaps once the owner sets more then a certain number of max, or higher-then-normal priority prims on his or her parcel, the "effectiveness" of the higher priority is reduced.
==Chris

Eh, just have it done automatically by having the larger prims downloaded first. Simple.

Some of the randomness of the current load order is due to TCP packet meanderings in the internet. There's not much to do about that.

there already is LOD priority (level of detail)... it seems to kick in somewhere around 1.5x1.5x1.5sqm

about 96m out things smaller than that can start disapearing or not actually rendering in in the first place (unless they are linked with something that is bigger)

some study could be given to that to figure out exactly rhe size thresholds, and exactly the range, i haven't really bothered myself

LOD is only for display optimization. The whole object description was sent (sphere, 10x10x10, blue, here, etc) as soon as it was within your view. Level of Detail will just reduce the number of verticies in the sphere when it is very small on the screen (small in size and/or far away) to speed up rendering of the scene on your 3D video card.

As for ordering the objects being streamed to you...

If you have a flowerpot in your house that is not seen by anyone passing by unless they glance in the window, then to make it automaticly low-priority, everone that flys by will have to report when (and if) they see it. All the time... For EVERY object. That's a lot of extra data that's hitting the network.

And if I had to hand-prioritize every object I own, I'd go nuts. Sure, you can have a default priority so you only have to set the few things you REALLY want to load first, or last... But even if it costs L$ to change, my (hypothetical) shifty neighbor may max-priortize every prim in his shop, just to improve business. It would probably be worth the investment, no matter the cost.


Anyway... Unless there are network problems, everything shows up within 2 seconds of looking at it for me. Only textures take longer to load, and because they are wavelet compressed, they load gracefully. I'm happy enough with what we've got that, though it was good idea in general, Mezzanine, I'll have to say that I don't think it's gonna happen or even CAN happen.

nah theres an aspect to LOD dealing with draw-distance... objects below a certain size have a different draw in (and send threshold) than larger objects... try rezzing a set oc cubes from 0.5m to 5m in .5's and then fly away so they're off screen... then slowly fly towards them again...

(i ran into this problem with my particle spotlights whos emitters were so small they would actually dissapear before they were anywhere near the draw distance)

Yeah, the way the LOD is implimented is a bit of a pain. Create a particle system with a target that is 0.01x0.01x0.01 in size, then fly away and come back. The particle system won't have a clue where to go, half the time.

I'm currently more curious about the distributed maximum range computation than the prim size priority...

We could throw in the options a threshold like "Prims with less than X in volume will only be sent to the client if we stare at them for Y seconds".
It would really make exploration less of a pain. When I'm flying around, all I care to see is the buildings, not people's furniture.
SL will be REALLY fun when people can feasibly keep their draw distance at 512 meters.

512? More like 2048.

I proposed variable draw distance by type (prims vs land vs clouds etc) a while ago, dunno if LL ever considered it.

Yeah huns I would like that too. It's a shame that most of the time you dont get to see the clouds at all. I think they really add to the feel of the world.