Avatar Rendering Cost: Change Your Habits?

looks like a bad implementation of the concepts of reasonable and simple from the user's end


More seriously, having worked in the game design sector i welcome this new tool. Professionals usually work on tight "resource budgets" to create the characters objects and universes that makes popular 3D games.
Resource wise SL was a free for all low FPS heaven where a single avatar can wear more than half a sim worth of prims and affect not only the sim he is in but every single viewer that dare to be around.

I think this ARC value is a simple, (unperfect of course) yet usefull way to make peoples that aren't into game design about rendering costs and how to better your own experience and the experience of others.

In most cases of high ARC there is always a better ways to build/texture your avatar that will have a minimal visual loss and a maximal performance boost.

My little advices for the peoples that are afraid to lose the details that makes their character beautyfull & for the designers:

-in 90% of the cases peoples will either watch your face or your whole body, if you need small details better focuse on the face (in pro games the textures for the face are usuall equal in size if not bigger than the total amount used on the whole body.

-nicely pre shaded textures add more perceived details and relief than any amount of prims (the sl lighting engine is designed to be fast and it makes it a bit crude too, so better enhance this.)

-a lot of designers will add prim details because prims are free while textures cost L$

-today with the sculpted prims you can make the best haircuts with as much as 5 prims.

-flexi hairs where every strand is an unique prim not only are a real drain on the hardware but they usually won't ever look smooth because the flexi prims code is designed so the CPU will cut corners to prevent the flexi prim calculation to slow down the rendering.

-for hair designers, when you have the occasion have a look at games like final fantasy and the unreal tournament serie, there is a whole lot to learn in the techniques they use for assembling the hair strands like scales and give the illusion of fluff and volume, these techniques can be reproduced with sculpted prims for a very small prims and texture cost.

The biggest joke is people who ignore both the minimum and recommended system requirements for running SL then complain about lag. I was simply amazed at the list of some of the graphics cards LL put out awhile back and shaking my head thinking that some people were actually trying to connect with some of them.

As technology gets better, the platform must follow suit or it runs the risk of becoming obsolete. When I buy a new game, I do not complain to the maker of the game that my 4 year old computer can't play it. That would be utter nonsense to do so.

Instead of informing people that their systems may not be sufficient to really enjoy SL with reasonable frame rates, we instead get a vague tool for those whose computers can't handle rendering much to begin with to start accusing others.

I will never ban someone because of a high ARC score. The client settings can be sufficenty modified to deal with most cases of lag due to graphics rendering. If you already have your client settings turned all the way down and still having issues, seriously, you need to upgrade.

Anyone flipantly banning people like that is probably already banning people for silly reasons anyway.

Well the ARC value isn't made for peoples that are below specs, it's geared to improve the global user experience by putting some "sense" in people's heads when it comes to attachment bloat.

Sure as tech get better, however you can't think that as long the engine can swallow it everything is fine. In every 3D engines there is a point where the resource cost grow exponentially as you add more stuffs to render.

Sadly LL never had the guts to force an upper prim limit on avatars, beside the max link size for each attachments.

you do realize it only seems to be based on textures and not prim counts from all I've seen and experienced.


I've seen malls that will kill a system that exceeded the reqs because of the textures used in the build...and yet been screamed at because I had a low ARC furry avatar

I have no problems with building efficiency and welcome it. The issue is how vague the tool is. Is it really useful? I don't think so. The only thing it confirms is yes the person with the 5000 ARC is lagging the client running a P3 and 64mb video card. Not the person with the Quad Core computer and an 8800GTS.

Do you need an arbitrary score to let you know you maybe need to turn down some settings? If it were truely a tool for your own personal use designing your avatar, then we shouldn't be able to see the score of others. Only our own.

Not to mention it would make the tool itself a lot less laggy if it only showed our own scores rather than everyone elses as well.

You are either a professional game designer or someonw who whats all us none pros to beileve you are. It matters not one iota.............SL is built with user creator content created by users (who most difinitely, as a whole, are not pros) in mind to make the world what it is. Tools were allocated to us to achieve that goal of LL to "create" a virtual world. No where did I ever read that you must be some proven game designer to upload textures, make clothing, build, or script. The present issue of lag is created by LL....not the novices doing exactly what they were invited us to do. Which is to build "our world". You cannot come back after the fact and point a finger at those who merelly took what was said to haeart and did exactly what you wanted them to do. If you made a mistake in allowing amateurs to build your world, live with it..........or discontinue the tools you gave us in the first place.

It's really that simple........don't point a finger at us.

God, I hate arguing with "experts"........they are so much more of a brat than I am. Look beyond your "education" and apply some common sense.

I'll say it again...........my ARC is something below 2000. If that is too hight then maybe we need to abandon this project and go with WoW or something.

That reminds me of a question. I have some of this sculpty hair, and it's not bad-looking (if you don't miss flexi), but it can take five minutes on a nearly empty sim for my hair to rez. Now, I think textures rez painfully slowly these days despite my fibre connection, but on both Linux and XP I can rez literally THOUSANDS of textured prims in the time it takes to rez a single scultpmap. (In the meantime, the appearance isn't appealing, to put it gently.) And then, once rezzed, even a low-res sculpty seems to delay cam operations and frame rate equivalent to dozens of regular prims. The rendering hit makes sense, I guess, given the number of faces actually represented in the sculptmap.

So my question is: Does ARC penalize sculpties even remotely as much as they lag the client?

(To be honest, at this point I think I'd prefer if there just were no sculpties at all. I keep buying them, and I've made a few--and I keep thinking somehow they'll get less painful. But really, I'm finding that they're just not worth the aggravation anymore. I just never wear my sculptie hair or shoes now because I don't want to look like I have some weird fungus problem for the first five minutes after I TP anywhere.)

I heard there is a problem with lossless sculptmaps and they laod really slowly compared to lossy ones, maybe that's your issue?


The arc is vague sure but you can still use it to compare different items and make an educated choice in what you are wearing, and this without having to be a game designer or knowing anything about 3D engines, textures and polygon count, isn't that great?

The ARC is your avatar budget if you want things to run closer to how LL expect them to be, lets take a game like doom3, based on the average amount of monsters visible by the player at a defined time and the limitations of the engine, when making the game the designers made a budget for every elements of the game, like, light fixtures should be no mare than x polygons and 1 texture, the main characters are important so we will give them a higher budget than small monsters, etc...

now LL didn't tell us what they think the "optimal" ARC value or budget per avatar is in a 40 peoples sim, but now we have a metric that inform us about what wasn't always obvious before, sometimes you discover that this gun you liked use a ton of textures instead of recycling some that obviously look very simmilar, or that the creator uploaded them in 32 bits instead of 24 thinking he would get more details (it happen when you don't know) .

As every metric it will create some kind of "pissing contest" but in general it will makes everybody more informed about avatar load.


As for the comment about the fact buildings have no ARC score, well it's because the primcount in a sim is constant on a square meter basis so you can't go overboard like with an avatar (which i remind you can wear half a sim worth of prims on less than one square meter, talk about load!)

It doesn't count prims for your ARC score

And there needs to be a gauge because many sims have huge open areas and everything is built up into a small area of the sim... plus it is easy to do far more lag on a sim build than with the majority of current avatars out there.

For a high prim object to have the insane arc score you expect every prim would need a separate texture. ... but as pointed out a 255 prim attachment consisting of micro prims and no textures... barely registers on the ARC rating

Hey i never said the ARC is perfectly tuned yet but it's a start, i hope they will add every prim types with a cost for each of them that reflect their laggyness.

I also hope they make alpha 100% a non rendered surface... because if it's still an alpha it's silly.

The problem is there are people relying on a single tool that is imho barely into alpha as reasons for banning and hassling people.

So I cannot make a wall using an uploaded texture that contains a window? I must use more prims to get my window for my small house on my 512 meter lot? No such thing as saving prims by using alpha? Strange, I remember reading at the Ivory Towers of Prims that using textures with transparent windows was (and is) a good way to save prims. Yes, I know about alpha sorting in openGL.

That's what I'm hearing Mr Professional game develolper. What a perfect world game developement must be.

The solution lies in computers that have the power to do what LL wants us to do.......not in us becoming graduated software developers. I do not have what would be considered a high powered computer......just a little above what most would have. This is a high tech game....you need reasonable equipment to run it successfully. If you don't have that equipment then I'm sorry. But LL has given us a "tool" (with this ARC score) for those who do not have a computer capable of doing what LL wants it to do to be able to point at "problem children". I'm afraid I will be labeled as such........and I do not believe I am.

Sorry, for being so blunt. I think you are full of beans.

At least a third of the residents today are not software engineers or graphic artists (and that is my own wild guess with nothing at all to back it up). Most of them haven't a clue what ARC is nor would they know an alpha texture from a sculpt map. And, you know what? They don't WANT to know.

These folks want to turn on their computer, click an icon, come into SL and chat, dance, shop or whatever. They see something they like in a store and they buy it and they wear it. PERIOD.

So, now someone comes along and shows them this nifty "tool" that puts a bunch of color coded numbers over every avatar in sight and says, if it ain't green it's bad.

So, while standing in the middle of some big store with dozens of scripted vendors and a gazillion textures plastered to the wall, they single out little miss 1250 ARC for their rant about causing them soooo much lag.

Thanks, but no thanks.

I think the meaning was that if something is 100% alpha'd -- nothing visible at ALL -- that it shouldn't be rendered at all. The way it is now, a texture that has been alpha'd 100% is still rendered, but invisibly. It still takes time & system resources to render it, though you never see it.

I don't believe the suggestion was to take anything that had an alpha in it and make it non-rendered.

Agreed. But unfortunately, it seems we are the part of the customer base that LL is more than willing to leave behind.

Totally agree that that's what Kyrah meant but are you sure the viewer spends time rendering things that are fully transparent? I have no idea - just asking.

physics maybe

It still needs to know they are there

Avatar script load would be a more appropriate use for a tool like this since everyone in the sim would be affected not just an individual client.

not likely to happen, only sim owners get access to that information... but mentioned that before. A person with low arc can script lag the sim to a standstill

The question is just if an avatar wearing an 100% invisible prim costs more to draw - not sure physics come into it (but it's 2:30am so I could be wrong). Avatar attachments are always phantom, too..

Er.. Yes and no.. A malicious (or just really baddly written) script can starve other scripts but it can't really lag the sim itself, I think. The sim does all the other stuff it needs to do _then_ gives all the remaining frame time to scripts.

Well the trick with the invisprims is it has to resolve them with show transparent filter, as well as handle the rendering of things through them. So it's still there saying hi I'm at 100% transparency so render such and such through me but remember to color me reddish if render transparencies is on

As for scripts it does depend on how many there are running in the item... I've seen griefer objects affecting the sim performance with max scripts in every prim running timer functions every .01 seconds.

Not really, a sculptmap does count as a texture but that's it.

Prim savings don't necessarily compare to a more performant build though, especially when it comes to alpha.

If you're standing in front of an alpha-based wall, it won't matter if you're looking through the window or at a "solid" part of it. In both cases the viewer has to render everything behind it because an alpha wall can't act as an occluder and can't get added to the depth buffer. If it was made up of distinct prims everything except the window could act as an occluder. If it was opaque on the outside (one way see through window) noone on the outside would ever have to render the inside at all.

Whether it's going to practically matter or not depends on the context and most peple wouldn't care either way. They'll prefer a low prim laggy build and praise the builder for making a low-prim prefab while complaining to LL that their fps is low.

We do have a lot of building freedom in SL and we'll generally prefer visually pleasing over efficient, but that doesn't mean anyone who builds should just be blissfully unaware of a few basic facts, especially if they'll be selling what they create.

Indeed. And I have no reason at all to think that rendering one alpha'd window wall texture would take more work than rendering all the surfaces of a bunch of separate prims that make a wall with a "window" hole in it--especially considering all the lighting effects that get applied to those surfaces.

And I wonder about the validity of comparing build rendering costs with those of attachments, anyway. Now, I'm most certainly *not* a game designer, so this is really a question, not some received wisdom or anything, but seems to me, it's gotta cost something somewhere in the graphics "delivery process" when avatars *move*. Now, of course, it costs a whole bunch when the avatar's *agent* moves--actually walks or flies around, etc., because even Havoc gets involved figuring out what s/he smacks into and stumbles over. But I really mean, even for a stationary agent playing an animation--there's all this very dynamic stuff happening. Usually it happens very smoothly, so I'm guessing this is pretty efficient and implemented at a very low level, so I'm not sure "rendering" is even the process involved here. But *something* is making that motion take effect on the screen, and the avatar's lighting definitely corresponds to its animated position and orientation, so...

Anyway, the point is that builds don't usually dance. Sometimes they have animated textures and flexis and bits that twirl about with llTargetOmega--and we've all experienced client lag from such shenanigans, too. And once in a while doors open, etc., but generally speaking, the scene doesn't change because the build is *doing* stuff. So, if there is an extra cost to depicting motion, then fretting more over avatar rendering costs than build costs makes sense.

From a marketplace perspective, special attention to avatar cost makes sense anyway. One thing SL really needs to be able to do is to comfortably handle much, much larger gatherings of people. I've been to several of these "corner of four Class 5 sims packed full and then some" events, and it's not a very pleasant experience, even when the sims' settings have been tweaked such that there's very little sim-side lag. It just takes forever to rez everybody and then moving the cam is like piloting a barge: plan well in advance. Handling larger events gracefully would make SL far more appealing to business and non-profits.

In almost all cases there will be something to render behind the wall though. In the case of an alpha based wall, it first has to render as if everything alpha simply doesn't exist, then it sorts all the alphas and renders those back to front (or that's my vague understanding of the process anyway).

The following piccie is a side-by-side of an alpha-based wall, in the left version I just use the wall as-is, in the right one I used what I know of how alpha works to compensate for the performance cost: .

On my older puter the left renders at 5.5fps, the right at 9.5fps.

The reason for the relative big difference in fps for something that looks exactly the same is because I put prims "inside" the wall to act as an occluder in the "optimized"version. As an illustration of what is happening, the next piccie is probably close to what SL has to render before it finally renders the wall: . The difference in fps comes from rendering a flat white surface in the right one vs rendering everything that's behind the wall that I know will get obscured anyway.

The difference when you're not looking out the window is even more pronounced since the hidden wall can occludes everything on the outside. I only made one piccie since they both look the same anyway: .

The "as-is" version renders that at 8.8fps, with the occluder one it jumps to 17.7fps. Again, that's for something that looks exactly the same and with one simple adjustment.

The relative differences in fps are rather meaningless in the general case, but the performance difference between an alpha wall and an opaque wall comprised of multiple prims is considerable simply because one covers up what's behind it while the other doesn't.

And while the above doesn't really relate to ARC since it's about general building, it does illustrate my point that it's always better to explain things and point out how things work (even on a high level simplification). If I didn't know how alpha worked, I wouldn't ever have realized that hiding prims inside the wall to act as an occluder would largely negate the cost and I certainly wouldn't have realized it from a number that doesn't tell you anything (and a metric couldn't account for the fact that the occluded version is far more efficient).

It's sad that the guidelines that do exist are largely focused on "saving prims" and ignore the performance aspects and LL really does need to make an effort to just put information out there. It will have a far more noticable impact than any metric they can come up with to "shame" people.