Avatar Rendering Cost qualities?

After reading, http://www.massively.com/2008/04/12/1-20-changing-your-mind-about-avatar-lag

I don't plan on subjecting myself to that viewer (happy with the Cool viewer tyvm), but the article makes it sound like what slows things down isn't obvious, with some high prim things not nearly as laggy as subtle nearly inconsequential things...

Has anyone done a comparison to figure out the qualities that slow things down?

Do I get to keep my fav hair?

As far as I can tell (making changes to attachments currently crashes you and anyone else around you with ARC turned on) it's a combination of prim count, the amount (and probably size) of textures, whether they're alpha or not (alpha is a lot more costly) and some prim attributes like flexi.

A 10 prim attachment where each prim face is using the same texture would be less costly than a 5 prim attachment where each prim has a different texture on it which would in turn be less costly than a 3 prim attachment where each prim has a different texture on it and where all three prims are flexi.

I couldn't help but try it anyway and the example does work in practice (each texture is 512x512):
10 prims - 1 opaque texture - no flexi = 15
5 prims - 5 opaque textures - no flexi = 35
3 prims - 3 opaque textures - flexi = 44

Contrast that with:
1 prim - 1 alpha 32x32 texture - flexi = 47

---

I have a nagging feeling that they might tie "avatar rendering cost" to the "Avatar detail" slider and render anyone who is above a certain "cost" as an avatar imposter permanently, whether you're close to them or not.

(Edited since I tried the example I gave in practice)

Is there any reason to think the numbers are vaguely accurate?

It seems to ignore prim count actually.

(Edited since I looked at the source which is more accurate than trial-and-error)

There have been many times when the Stats display would show that I was getting, say, 5 client side FPS when the display was actuallyl a slide show where each frame lasted more than a second before it would change.

The old much missed packet loss indicator used to read incorrectly a lot of the time, according to my memory of folk's reports.

I suppose the formula to generate the number is in the source code.

How would one measure the accuracy of the number? Use a program execution profiler to determine how much time is actually spent rendering avatars?

Why not add some sort of "Rendering Cost" as a property displayed in the inventory?

There's no source drop for 1.20 RC0 yet... I think .

It doesn't have to be accurate depending on what they'll use it for. If it's what I *think* it might be for then it only needs to be able distinguish between "acceptable" and "unacceptable" based on current performance and render "unacceptable" avie differently (as an imposter for instance).

---

If someone's going to the next WindLight office hour, please ask what they'll be using it for .

Hmm, I hate the imposter rendering. It would be tolerable if it had about three times the resolution it has now.

cant you just turn off transpareny in the debug settings and not render bumbmaps or vrtex-glow for a speed boost?

It's actually referred to as avatar "shame" in the source rather than avatar "cost" .

---

My interpretation is:

"Shame" base: 1

Avie global: +5 for each unique texture (includes sculptmaps)

Per attachment: +10

Per prim:
+ 8 - Flexi
+16 - Particle source
+ 1 - at least 1 face is in the alpha draw pool (no idea )
+ 4 - uses bumpmapping on at least 1 face
+ 1 - uses shiny on at least 1 face
+ 1 - uses glow on at least 1 face
+scale - size.X + size.Y + size.Z (in meters, rounded down per dimension)

Per prim face:
+ 4 - has alpha texture applied / transparency > 0
+ 4 - animated texture
+ 1 - planar mapped

---

Weirdness:
* a prim only seems to count if it has one dimension larger than 1m, it doesn't matter if there's 1 or 1000 or if they're tortured, twisted, cut, etc
* (opaque) textures are all equal, whether it's a 32x32 or a 1024x1024
* attachments that are completely invisible are *very* expensive... a 40 prim attachment made up of cubes with opaque textures would add 960 (40 prims * 6 faces * 4/transparent face) when you hide it

I wonder how bad light sources are (if they are accounted for). That, coupled with alpha (face lights being alpha-ed out) would be interesting to know.

Which makes me wonder: many people feel a need to make their avatar look better to them using face light. Setting side the issue that not everyone is going to see what they see, etc., and knowing that a face light is a compensation for SL not having a difference between indoor and outdoor lighting, I wonder if these face lights also end up affecting lag for those who use them, making their SL experience that much harsher. To that end, I wonder if face lights cause people to assume "SL (the product) is laggy," when it is possible that their choice of attachment - in this case, a face light - that causes or contributes to their issue.

Of course, I can't check any of this, because logins are down... :-/

Mari
(Whee! I'm a 1600!)

Thank you for researching so much Kitty! Would you welcome putting this info on the wiki somewhere? I don't know what it could be called, Avatar Rendering Cost doesn't seem like something anyone would search for. I'm surprised there isn't a page on "lag". The "Attachments" page seems to be about testing, not info. LOL! Here's proof bling is shameful?
So it sounds like it will help to not wear both flexi hair with skirts or both sculpty hair with sculpt shoes at the same time, especially alpha hair with skirts with transparency... (* - I added)Oh wow, I don't have much of these (my Multi Gadget being one that can't live on my HUD instead), but it sounds like those that do wear dance balls or other erm, types , might be more considerate hiding them within their bodies rather than making them invisible?

Wouldn't it be nice if they were scripted to do that instead?

I think it would be better to wait until it's something more definite?

It could change a lot during the different RCs and it would better to "document" it when we have an idea what LL is planning to use it for.

If anything right now it needs a big disclaimer that it's not very representative of the actual render "cost" right now since it leaves out a few essential things (in my opinion anyway ).

---

What probably would be good is explaining why some things are costly and why they should be avoided. I didn't know alpha/transparency would be "costly" until I read the explanation of why it's so "costly" for instance.

Or another example: ARC adds +1 for every face that's using planar mapping which suggests that it's slower than using default mapping. I never thought about it, I always use planar since it's just soooo much easier to me to align textures across multiple face/prims.

Lindens have posted "building guidelines" on the SLdev list a few times when it was relevant to a topic, but it was always followed by "but we don't think we should tell residents how to build" which I think is a big mistake. If there are things their renderer (or that apply to all 3D modelling) likes better then that should be documented and explained so that content creators can keep it in mind when building.