Jump to content
Sign in to follow this  
Conifer Dada

Avatar Rendering Cost

Recommended Posts

Recently I've been turning on the avatar rendering cost at clubs I visit.  'Perving' people's rendering costs is quite informative.  Nearly all the ARC's are red.  The highest I've seen was over 30,000.  Mine was lowest, at 830 one day and a bit higher, but still under 1000, another time - and yet I don't feel aesthetically challenged!

Is it possible for land owners to set a maximum rendering cost for individual avatars on their land?  If not, it would be useful.  If you tried to TP somewhere and your ARC was too high, you could get a message 'Avatar rendering cost too high, limit for location 10,000' or similar.

Share this post


Link to post
Share on other sites

Oh, that would make me mental. I'd just stay home. :smileyvery-happy: I have no idea what my rendering cost is, but it's probably too high.

I think that wouldn't be very good for the SL economy if you look at the big picture. People would be sim traveling a lot less I think if they're banned from getting in somewhere until they change.

Share this post


Link to post
Share on other sites

I agree it would initially have an adverse effect on the economy of the malls associated with clubs that impose an ARC limit, but if those clubs are less laggy as a result there are still lots of people happy to get by with a lower ARC for most of the time.

Some clubs impose no-fly zones or other restrictions and that dosen't seem to harm them.   And some clubs ban giant avatars for obvious reasons, so an ARC limiting option would probably find some use.

The problem I have with super-detailing of avatars is that by the time you get up close enough to see those details fully, you can also see all the imperfections in the mesh!

Share this post


Link to post
Share on other sites

I run a pretty busy Ballroom . Where the ladies have a boat load of prims (high ARC) LOL' Most of their arc is half way decent. But some people end up wearing a lot of jewelry which can really shoot that Number up high,,  But that is more of a rendering problem for viewers and not sim lag... If all the prims have resizer scripts in them. Then you have a serious lag issue for the server and everyone's comfort

I do not impose and ARC limits. I worry more about the massive scripts an avatar has attached to his/her avatar in all those prims

 

I think some clubs target the wrong thing when it comes to ARC. They seem to see they may be helping lag. But in all actuality limiting the arc/prims also limits the scripts a lot of those prims had in them..They should lean more towards getting people to lower their script count to ease the lag on the server..(hopefully LL gets script limits going soon)

Ask the vender for an updated item that uses 1 resizer instead of 250 resizer scripts hehe

Or using the menu option on the item to remove the scripts after it is resized and fitted...

Viewer lag is easy to help by educating a busy crowd to not all stand close together. Spread out a bit. it helps LOL'

 

You will be shocked to know that some residents have upwards to 800+ Script attached to them.I have seen some avatars using up to 20MB memory in script usage.That may seem small to you. But it ads up if you had 50 avatars using the same or close to on the same region

It is my understandi8ng the regions run on 800 megs

Get 50 residents on a sim with using up 20 megs per avatar. = Death to the sim comfort lol

 

Share this post


Link to post
Share on other sites

One thing about ARC though: every viewer seems to calculate it differently! :x

It's possible that an ARC in viewer A is much higher/lower than in viewer B, and not in the same proportion when compared to another avatar. In fact, it's very much possible that avatar 1 has a higher ARC than avatar 2 in viewer C, but lower than avatar 2 in viewer D.

Share this post


Link to post
Share on other sites

YEs you are correct Azura.

I remeber when Emerald Decided to change that completely  on how it was calculated from the Original LL calculation.

It  Made Numbers jump really high and a lot of drama was caused because users being klicked out of places because some places using it as a metric to help their lag . Wrong move..lol

 

Share this post


Link to post
Share on other sites

There is quite a bit of misinformation out there about Avatar Rendering Cost.  When LL first introduced it, they indicated it was an estimate only and not a completely accurate figure.  That's why one viewer will show one number, another may show a completely different one. 

In truth...ARC does not cause sim lag, it creates client lag.  Especially if your graphics card is on the lower end.  So, that persons hair across the dance floor from you that looks like it has 10,000 flexi prims is NOT causing YOU lag. 

I posted the link to Ana Lutetia's blog post about lag in another thread, but it is such good information that HERE it is again.  It is rather long, but the information in it is excellent and everybody should read and understand everything inside.  There's even excellent information for store owners on how to set up their store's layout to help lower the lag in and around their place of business!   

Share this post


Link to post
Share on other sites

ARC is pretty meaningless, in my not at all humble opinion. It gives an idea how GPU-intensive it is to render a specific avi, nothing more, nothing less.

Perople already have a tool to make sure they get decent FPS in busy venues: Limit the number of avatars rendered. It may not look as "pretty" but it is guaranteed to get FPS up.

My bigger gripe are script-heavy avis, usually people who aren't even aware that they basically lag the sim to hell. That's the same people who complain about sim crossings, teleport problems etc.pp., so in a sense they get what they deserve - IF they'd actually KNOW that they lug gobs of scripts around.

Here's a free fullperm script, inspired by code from Void Singer. Drop it into a prim, attach the prim to your HUD. I have mine sized x:0.1, y:0.2, z:0.01 and attached to the bottom center of my HUD. Or pick up a free copy here: http://maps.secondlife.com/secondlife/Dura/83/245/33

It's not meant to be the perfect script, and it has a few limitations: Only the closest 16 avis get checked every 10s, and only about the top eight or so worst offenders of these 16 get shown. I made that decision so it wouldn't create additional lag in busy venues. And it has a harmless bug or two. :)

 

list lTemp;key kTemp;string sTemp;string sHoverText;string sDisplayName;string sUserName;key kDisplayQuery;integer iIsActive=TRUE;// ===================================================================// Try to force-get display namestring uGetDisplayName(key kAvi){    integer i=0;    do {        i++;        sDisplayName=llGetDisplayName(kAvi);        if(sDisplayName=="???") llSleep(0.2);    } while(sDisplayName=="???" && i<3);    return sDisplayName;}// ===================================================================// MAINdefault {    state_entry() {        llOwnerSay("Area scan enabled. Scan interval: 10sec. Click green bar to disable.");        llSetColor(<0.0, 1.0, 0.0>,ALL_SIDES);        llSetText("Initializing...",<1.0, 1.0, 1.0>, 1.0);        llSetTimerEvent(10);    }    no_sensor() {        sHoverText="-=> SCRIPTS/MEM <=-\n";        if(llGetAttached()) {            sHoverText+=uGetDisplayName(llGetOwner())+": ";            sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+"/";            sHoverText+=(string)llFloor(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0)+"k\n";        }        llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0);    }        sensor(integer foo) {        lTemp=[];        do {            kTemp=kTemp=llDetectedKey(foo = ~-foo);            lTemp+=llList2Integer(llGetObjectDetails(kTemp,[OBJECT_SCRIPT_MEMORY]),0);            lTemp+=llList2Integer(llGetObjectDetails(kTemp,[OBJECT_TOTAL_SCRIPT_COUNT]),0);            sDisplayName=uGetDisplayName(kTemp);            sUserName=llKey2Name(kTemp);            if(llSubStringIndex(sUserName," Resident")!=-1)              sUserName=llGetSubString(sUserName,0,llSubStringIndex(sUserName," Resident")-1);            if(sUserName!=sDisplayName) lTemp+=sDisplayName+" ("+sUserName+")";            else                        lTemp+=sDisplayName;        } while(foo);                lTemp=llListSort(lTemp,3,FALSE);                sHoverText="";        if(llGetAttached()) {            sHoverText+=uGetDisplayName(llGetOwner())+": ";            sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+" scripts / ";            sHoverText+=llGetSubString((string)(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0/1024.0),0,-5)+"mb memory\n~*~\n";        } else {            sHoverText+="Name: Script count / Memory use\n";        }                do {            sTemp="";            sTemp+=llList2String(lTemp,2)+": ";            sTemp+=llList2String(lTemp,1)+" / ";            sTemp+=llGetSubString((string)(llList2Float(lTemp,0)/1024.0/1024.0),0,-5)+"mb\n";            if(llStringLength(sHoverText+sTemp)<254) sHoverText+=sTemp;            lTemp=llList2List(lTemp,3,255);        } while(llGetListLength(lTemp)>0);                llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0);    }    timer() {        if(iIsActive) {            llSensor("","",AGENT,96,PI);        } else {            sHoverText="-=> SCRIPTS/MEM <=-\n";            if(llGetAttached()) {                sHoverText+=uGetDisplayName(llGetOwner())+": ";                sHoverText+=llList2String(llGetObjectDetails(llGetOwner(),[OBJECT_TOTAL_SCRIPT_COUNT]),0)+"/";                sHoverText+=(string)llFloor(llList2Integer(llGetObjectDetails(llGetOwner(),[OBJECT_SCRIPT_MEMORY]),0)/1024.0)+"k\n";            }            sHoverText+="AREA SCANNING IS OFF!";            llSetText(sHoverText,<1.0, 1.0, 1.0>, 1.0);        }    }            touch_end(integer p){        if(llDetectedKey(0)==llGetOwner()){            if(iIsActive) {                llOwnerSay("Area scan disabled.");                llSetColor(<1.0, 0.0, 0.0>,ALL_SIDES);                iIsActive=FALSE;            } else {                llOwnerSay("Area scan enabled.");                llSetColor(<0.0, 1.0, 0.0>,ALL_SIDES);                iIsActive=TRUE;            }        }    }        attach(key id){        if(id) {            llResetScript();        }    }}

 

 

 

Share this post


Link to post
Share on other sites

We have had this debate for eons, with newer people saying its the amount of prims you wear..... the fact is, it is the alpha texturing that will make the ARC higher. As an experiment within a combat sim that I am involved in (as ARC levels were the major argument of the combat users), we showed, that with one change of hair, with less alpha textures in it, was enough to bring an ARC down from 5600 to 831.... that was a huge reduction. An alpha textured, prim item of clothing was then worn and the rendering cost jumped back to 2100. Yet we replaced the texture on the prim item worn to a non alpha, cloth texture and the ARC went down again to 831.

It's just that some people don't realize the major causes of lag, especially for script enabled combat sims, is extra scripts. Most of the time, resize scripts are a major contributor, especially in prim belts, and jewelry, where the prim totals have a script in each prim, sometimes this can total over 200 individual scripts.... a good reason to resize and then delete the scripts.

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

×
×
  • Create New...