LL Blog: Avatar Rendering Cost

Agreed

I don't see any basis for saying that it is or isn't.

Given that most content is created by users, and not LL, there's going to be some amount of social engineering involved. Personally, I don't have much confidence in any sort of speculation about whether this will or won't work. Perhaps you're right. But perhaps it will spur content developers into advertising their rendering costs, till that snowballs into a significant change.

Here's another analogy: The official MPG ratings for cars have evolved over the years to become more meaningful. When they first came out, people complained, joked, criticized because they didn't match reality. Nevertheless, the first set of MPG standards had to be issued before we could get to the current set.

Well the biggest indicator is the freeform user development content model without considering the implications long term. You cannot give people everything, all at once, all the time in this atmosphere without realizing you cannot support it, then point to a user development aspect as a reason for struggling to support it....or, well you can, but it looks kind of odd.

I mean, you plan for this stuff when you advance your business model, and their are plenty of successfully engineered platforms and online environments to learn from. The only difference with them is that they built necessary controls into the worlds.



Absolutely agreed, and I will freely admit my own speculation is simply based on past pattern analysis....in expecting people to exercise self control in an environment, user development and otherwise, where lack of control is a feature. How many people for example, cleanup their inventories regularly or economize their products now, though it is apparent they affect performance ?



But I am not sure what the standard is when it will not be enforced by a tangible control method. Peer pressure is not gonna work too well, and is already inspiring backlash. I mean the logical conclusion is that your computer is inadequate to see their marvel in it's glory, and it is another users fault, and see, look this is why.....while not taking into account that your own settings maybe too much for your machine, or the griefer standing behind you is floating singing self replicating boxes en masse, as the asset server is dying again because it is struggling to register an unlimited amount of unique uuid's from 10,000 people learning to place box prims and accumulate freebie prim clothes.

I just think the bells and whistles department is cheerfully charging ahead, when the bells and whistles are not so much the issue.

Wow, and I thought when textures were "baked" that they combined all worn textures together somehow, why don't they do that?

Baking does do that, but it doesn't apply to attachments, only the base clothing layers.

I have prim flexi alpha-textured hair and prim shoes and no invisible scripted attachments, and I think I look fine. My ARC is just under 400. It shoots up to 666 (lol) if I attach my scripted cock. I was expecting the ARC to shoot up even more when I put on my furry horse av with the 200+ prim head, but it actually scores 50 less than my normal human av.

I have a "no attachments" version of my avatar, which I set up once last year when SL was lagging so badly it was impossible to teleport without all attachments ending up stuck up my ass. ARC on that one is only 1. But even with my second-best prim hair, a good skin, and a pair of good but non-prim Converse shoes the ARC is only 16 and still looks absolutely fine, definitely not like a noob.

But according to the original BLOG entry "5 Points for each unique texture on the avatar". That would imply that baking is ignored and each clothing item counts as 5 points. It doesn't make any sense, but then again not much that LL does anymore.

Baked textures don't count because *everyone* has those. It doesn't matter if you make your avie into a tiny ball and hide it with an invisiprim, you'll still have your baked textures same as everyone else.

What they meant to say is "5 points for each unique texture across all attachments".

wow alot to chew on here, I think alot of folks have covered what I would say, so I'll just throw my votes into the poll:

I think this is a great *idea*. IMO the choice of metrics used is incomplete, and the values assigned seem rather arbitrary. But I think it could be useful with some tweaking.

I think the over-head placement/coloring gives it an unwarranted sense of importance. There are many kinds of lag and it varies greatly from machine to machine which kind is your personal Achilles Heel. This number should be a line item in the Statistics Panel, perhaps one for your ARC and an "others" sum ARC just for reference. But one needs to consider all the available info to have any chance of seeing the real "lag" picture. Even if calc'd right, this number will be of most importance only to those with very low end GFX cards.

Apart from that, the *best* thing I can see coming of this in it's current state is that just maybe it will help raise awareness of this:

I think many people just do everything in 32bit, "32bit is better ain't it?" Uhm, no. In most cases less is more. But this applies to buildings just as much as attachments. If you are making something which has a completely "solid" texture, then PULEEZE save the file as 24bit!

For anyone curious of the technical why's, the following is as brief as I can, will gladly answer any Q's in even further detail.

24bit: 1Read (the appropriate 24bit pixel from the texture)
and 1Write (to the correct pixel in the page frame aka "canvas"
tho somewhat simplified that's essentially it, copy+paste.

32bit: Read the pixel from texture (32bit). Split that (24bit color / 8bit transparency). Multiply the color times the alpha. (store this value) READ the pixel color from the page-frame thus far ("background". Invert the alpha and multiply. Add this with the previously calc'd texture weight. Write the result into the page-frame.

Note even if the alpha is 0%, if the alpha byte exists, it still goes thru all those calculations anyway. Always save as 24bit if you don't need alpha channel.