Object-object occlusion

I’ve been playing with an invisiprim. In case you don’t know what those are – if you’re wearing heels, you very likely have two on you right now. They are prims textured in a specific tricky way, that makes the avatar mesh invisible when seen through it, as well as any prim textured with a texture containing an alpha channel. In footwear, they are usually used to make the feet invisible when otherwise they would stick through the sole of the shoe. Normally, this is thought to be the limit of invisiprims, but I have found that it is not so. Later, I found out that the effect was already observed and described, but as usual, lost in the sea of information, and so, mostly forgotten.

When Second Life viewer draws what you see, it has in it’s possession the entirety of objects within the sphere delimited by your draw distance slider, because it requested their positions and parameters from the server. But to send the entire mess to the graphics card would choke even the best ones, so it tries to save a little. Upon converting the objects into triangles, it only sends those that it expects you to be able to see, and it determines it by calculating which objects cover which ones. Objects that are considered covered are not rendered at all.

This is a mathematically complex problem, so it prefers to err on the side of caution. A big sheet of invisiprim is still considered non-transparent by this process, so you can see just what it requires to make it consider an object ‘covered’ — that is, occluded — and observe the practical savings yourself.

And it is very obvious that occlusion is not determined per individual prim, but per linked object. If you only see part of my 252 prim glasses, your card still gets the full data on every single triangle that composes them. But the moment I step far enough behind a wall, this no longer happens, and they cannot possibly affect your rendering. If I am behind your back, you don’t see them either. Only the avatars directly and at least partially within your camera view affect your FPS.

Now, what happens if you’re inside a completely linked building? It will occlude the avatars behind the walls, but it will get sent completely to your card, every prim of it. As a result, the card will get information on the walls behind your back, and even though it will not need to draw them, it will have to process them too. Which means that depending on the surroundings, a complex build made of smaller linked chunks may actually be faster to render than a simpler build that is linked together as one unit.

Whether any FPS drop can be avoided this way remains to be proven, naturally, but it is something to consider. It is clear though, that practical rendering lag that corresponds to high ARC — what little of it is actually there — very much depends on where you are and how complex your environment is, but mostly, it depends on how many avatars you actually see at once. Much of the rendering load at the Hair Fair could be avoided completely by making less open spaces and higher walls.

On the kinds and sources of lag

The word “lag” taken by itself means simply “delay between cause and effect”, however, in Second Life in particular there are multiple causes, types and reasons lag can happen, even though all of them will be perceived as “lag” by the user. Whenever you hear, “X causes lag”, don’t believe it until they say which particular kind it causes and how, because then they just don’t know what are they talking about. And yes, Avatar Rendering Cost, I’m talking about you, missy.

Continue reading

Arbitrary Rage Cause

Or Avatar Rendering Cost, as they tried to call it, but that’s really what this parameter is.

Technically, ARC is supposed to measure the computational requirements of rendering a specific avatar with a specific attachment combination. But, it does this in abstract parrots — meaning that it’s units do not correspond directly to any computational power measurement I know of — and the abstract parrots fly wherever they damn well please.

When this topic was first discussed at the Forum Cartel hangout in my presence, Ordinal Malaprop demonstrated a ring that would bump the wearer’s ARC by a whopping 4000 — which is the base ARC of my primmiest complete outfit. The ring did not induce any noticeable FPS drop. Now that I have come in possession of a similar object myself — a lovely, very detailed pair of glasses consisting of 252 prims — I had the opportunity to finally track down a measurable FPS drop that can be attributed to the 2500 ARC that they add to my avatar.

It’s about 0.5 FPS. On an Eee PC 701. With it’s puny Intel GMA 900 onboard video card. And Eee PC only notices that difference because it barely renders anything at all, and is a machine woefully underpowered to run Second Life in any fashion, it can only do so with a generous amount of kicking.

Further experiments show that while an avatar wearing no prims has an ARC of 1 regardless of the type of system clothing they have on or absence of such, turning off rendering avatars completely on the Eee results in FPS tripling — 4 FPS to 18! — from when showing just one avatar.

It can be safely said, therefore, that no single avatar’s ARC can significantly affect performance of a specific rendering client, if running on a real computer, because either the avatar’s mesh itself or some accompanying computation are quite computationally intensive even with no prims attached to it. The number of avatars on screen matters far more than the complexity of rendering of every individual outfit.

So in effect ARC does little more than promote people competing who can get it higher, and causes lynch mobs when the lag actually results from poor server performance or excessive numbers of avatars on screen.

Update: See also On the kinds and sources of lag and Object-object occlusion for more on the subject of causes of lag and ways the ARC may or may not matter.