Why do far away things rez before nearby things?

It seems like the SL client has it backwards, when you log in or tp to somewhere new, it rezzes far away things first and the nearest stuff last. Isn't this backwards?

It seems like the client should rez the nearest stuff first, because we care most about the near stuff and because many of the faraway things won't even be visible when the nearby walls are filled in. It just doesn't seem efficient.

Anyone have a reason or theory why they did it backwards?

I'm not sure it's as orderly as "backwards" actually. Prim rezzing within draw distance seems as near to random as makes no difference, far as I can tell. I'm pretty sure that in contrast, texture download follows some arcane combination of heuristics involving what's close, what's selected, what's under the mouse, and... well, that wasn't the question anyway.

But maybe it's kind of an illusion that stuff appears to rez far-to-near, because when near stuff rezzes, it hides the stuff rezzing in the distance? I mean, if it were totally random, it would *look* far-to-near, I think, if anything in view occludes anything else.

Does it have to do with with not wanting to take the time to sort the items by distance before drawing them?

I've wondered this too, reducing your draw distance can help of course!

/me offers a completely naïve idea, could it be that far away objects are faster to render, while nearby objects take longer for all their details to come in?

sounds like just a random thing to me, it'll only rez whats in your draw distance, kind of like looking at a webpage, always that picture you want to see is the last thing to load up. murphy's law perhaps.

-Crunch

"rez" has two possible interpretations here:

OpenGL does *draw* things back to front same as one would theoretically paint oil on canvas. Draw the mountain range, then put the trees in front of it, then the house, then the lake then the bushes right up close. GL has no way of really knowing for sure if the wall *totally* blocks the objects behind it. What if it has an alpha window? It's not possible to draw the wall, realize it has a window, and then figure out only what cropped area is visible thru the window. It draws the background, then draws the wall over it letting the alpha decide what does/doesn't get covered. The only way to go in the other direction is ray-tracing, which is actually MUCH slower.

As long as you have a reasonable video card however, that should literally be done in the blink of an eye. If you have a crappy card, this would appear as the wall flickering, with distant objects "ghosting" thru.

The other option, there does seem to be some randomness to how object data gets downloaded from the server. That has a more human-noticeable effect unless you have a really "phat pipe" to the internet. The methods behind object data serving I can only guess. The servers seem to provide info on a "lottery" style system bets I can tell. I think it may just be that trying to figure out what is closest to you *server side* would further clog an already failing hardware. The client cannot possibly fathom what is closest to you until it has all the available data, aka until downloads it all. So client side is impossible.

The later (download lag) is prolly what you meant by "rez"?

I didn't write the code so I may well be in error, but ...

Take your typical scene. You tp in, there are trees in the distance, a house nearby and you are standing on a walkway to the front door with a lightpost near by. The order all these things are drawn by the computer if fartherest to nearest. The trees drawn, then the house is drawn. That way the house covers prt of the trees. Next, the lightpost is drawn on top of the rest. Even tho the trees are mostly blocked from view by the house, it is easier and faster to draw the whole tree and paint the house over the top than tryto calculate just how much of the tree is visible. The same goes for the lightpost. It is painted right over the top of the rest of the scene.

So here's the guess. When you first to in, you need to downlaod all these things for them to rez. Meanwhile, your graphic routines are busy trying to draw with what they have. Because it wants to draw the far things first it is asking for priority for these. It needs it NOW. As people we know that what is near is more imotant and so the programmers will try to assign priority to those things. Finally, what ever you have your cursor on is given higher priority as well. If the near stuff has not rezed, then your mouse is over what ever is behind the non-rezed stuff onto whatever is. There are probably other priority items as well, like physical, moving, scripted or anything else that your client needs to know about so you can interact with your invironment sooner. All these things together give the popping in from differnt distances until your client knows everything in your area.

Or maybe they are just downloaded alphabetically by UUID. Like I said, I didn't write the code so I don't know for sure.

Each sim maintains an "interest list" per avie on it (and likely for any "child agents" who are not on the sim but looking into it) which as far as I understand it the client has very little control over (it can indicate draw distance, but that's it).

The individual interest list is primarily based on distance from the avie's position and the size of the object (small linksets/individual prims won't show from a short distance even if they're well within draw distance).

(It's been a while but, if I remember correctly, whenever you tp the viewer will actually show the "tp screen" for a little longer than it has to (same for the login screen), probably to give the sim some time to send objects so the viewer has at least *something* to render as soon as you arrive)

As you move around the sim will add or remove things on your individual interest list and send subscribe/kill messages to the viewer (even if you're standing still you still receive object updates on everything in your interest list as well).

[wild guess]
They wouldn't want to burden the sim any more than they have to, and since all the objects in the interest list need to be sent to the viewer anyway in the end, they might not have felt that having the sim spend time to sort the interest list based on distance would be worth it since it doesn't take that long to send all of it in the first place.
[/wild guess]

The order textures get downloaded in is something the viewer does have control over: "Textures are prioritized based on how many pixels they cover on the screen, and the priority is 'boosted' based on different flags " (short quote from Dave Linden)

---

If you find that you have to wait excessive amounts of time (on a non laggy sim) before everything/most will rez in, make sure your bandwidth slider is set appropriately (too high will just saturate your internet connection so watch out for that) and set your draw distance to a realistic amount (96/12.

SL does have peaks where things "rez" (either appearing grey but there or full rez with texture(s) applied) slow, but for the past few weeks most places are rezzed as soon as the tp ends (save a few small gray prims), or for busy/high prim builds it's no more than 10-20 seconds before everything but a few textures on small prims rez in.

Oh - that triggers a question I have had for aeons: From time to time I find that after TPing the rezzing of the environment around me isn't just slow but literally slows down to a crawl - about one or two prims per second (!) , often at the brink to stalling. When I look around see a wall being drawn here, a tree there and a piece of a floor elsewhere - in that speed. The crazy thing is that I can bring that up to speed again by just playing with my bandwidth slider - regardless in which direction! Normally I have my bandwidth slider set to a little below the maximum (I'm on a 3 MBit/s line). When this happens it doesn't matter in which way I move the bandwidth slider, just juggling a bit on the slider helps and the drawing instantly gets up to normal speed and normally stays that way.

As this happens not all too often (but more often over the last tweo weeks or so) I could't find a pattern or a explanation for this behaviour. Ideas anyone?

The viewer and sim negotiate a dynamic throttle on bandwidth; this is totally a guess, but maybe, possibly that gets kinda "stuck" at some low level and jiggling the slider forces them to restart the negotiation at the maximum you set? If you watch the command / shell window while SL is running, you can see the bandwidth throttling as it occurs, so one could possibly test this.

I've noticed a similar effect.

I actually had to reduce the length of my penis because the tip was rezzing long before the orifice I was attempting to enter with it. This resulted in some serious navigation and docking mishaps.

I logged a support call but as yet have had no reply.

Any practical help would be appreciated, since as a "man" in SL, my self worth is initimately linked to the gross weight supported within my leopard skin thong.

Thanks in advance.

Hoy! I'm the one that does the stupid replies around here!!


I suppose I'm gonna have to answer seriously now.

Here goes:

If something is already in your cache then it would be logical for the viewer to rez the thing rather than wait around for all the nearby stuff to download.

I suppose my theory could be tested by clearing the cache before entering a sim, but I can't be bothered. It's not like we can do anything about it other than start forum threads that mock the Lindens. I've tried that many times already and it just seems to make SL worse.

If (Resident=="2k Suisei"
{
llAddBugs();
}


I'm onto you, Linden Lab!!!

My Guess:

LOD, or level of Detail.

Stuff in the background has fewer bits of geometry to render so it pops in first. As you get closer more detail is rendered.

tip #1
lube up next time...that will buy some time for the rez to finish and you won't have docking issues.

tip#2
when rezzing to a new area, try not jumping onto the first thing you see....or may get a surprise

I've noticed this too and not just with TPing. When you enter a new area the throttled connection is suddenly noticeable, but it has prolly been that way some time already. Best I can tell, the "dynamic" throttling only works one way. So basically every time you get a lost packet, regardless of the reason (sometimes it just happens even on a T10) it cuts back the rate at which the server sends you data. But I don't know how, when, or even if, it ever tries to go back up again??? It appears it doesn't. So fiddling with the slider manually resets it to "gimme this much". Which even tho you may be moving the slider down from it's last *set* position, this is likely much higher than the internal "dynamic" value its arrived at. I've also found that different values work for different sims anyway, so I constantly poke at my bandwidth setting all the time.

great excuse to get some of the load of your servers tho if you are LL

does anyone know if "dynamic throttling" can be turned off?

Remembering back to when I programmed graphics, it's necessary to draw the far things first, because the near things are drawn on top of them. i.e. first the background, and then what's against the background. If nothing ever moved, including yourself and/or your cam, doing it differently might work, but even then it's still easier to draw the foreground on the background than to draw the foreground and then work out what parts of the background to draw so that they don't draw over any of the foreground. So it really has to be far to near.

You can also set your draw distance below 64 in Debug Settings (it's called RenderFarClip in there). It's great for TPing to someplace you know, you can set it to 20 or so, quickly see the poseball or chair or gift and then move on or raise your draw distance back again.

I've done this arriving at live music events and visiting random gift giving Santa's last holiday...

That's totally different, Phil. The OP is asking why nearby objects aren't rezzed first. It has nothing at all to do with the rendering engine. and these days with the introduction of fancy things like z-buffers the items closer to the camera are rendered first.

Ok. I'll believe you I did say I was going back to when I programmed graphics - and that's 15 years ago

Maybe there is confusion here...

You see, that "far away thing" might be a small thing up close, and that "near thing" might be a big thing far away.
- hence all the confusion about the rezzing order.

Lookit! It worked for Father Ted and Dougall, so it works for me.