Jelly babies

[Polymath Snuggler]

That's a really interesting assertion. I have only been in SL for a little over 2 years.  But I'd like to see the documentation about this!!  Because I've been on VERY laggy sims before with high script counts and almost zero physics collosions taking place ( think any shopping event on SL )  Tons of vendor scripts, tons of avatar scripts, lots of people wandering around, but not doing much else.  The lag on those sims is always very very present.  Not FPS based lag ( there's that too ) but the inability to walk in a normal manner,  sort of "snapping" back to your previous location as if on a leash, etc etc.  So I'm curious ~ if the lag doesn't come from the 1000's of scripts running at shopping events, then ~ where does it come from?  No one is colliding, people can't really move to begin with.  We're mostly just standing around camming vendor stalls.

So ~ the material evidence says you're not quite correct, I'd really like to see the documentation though!

[Drake1 Nightfire]

All of those vendors usually have multi-panels that keep changing via a script. Each time the image changes it has to load. 99% of those small images are 1024x1024 to "capture the awesome detail." What they don't realize is that image has no more detail than a 512 would. They are heavily textured and that is the cause of the lag. Worn scripted items cause lag for the wearer, not anyone else.

[wherorangi]

---

Conifer Dada wrote:

What I wonder is how to get the message across to people that if they load their avs with too much stuff, some of the people they're trying to impress will see them as jelly babies!  

---

Weeell  it just doesn't work that way ok !

Dahlinks !!! if you are too poor to afford to view my gorgeousness then I am sorry ok. But yanno !!

Is like the signs at some fashion events: Please to remove all unnecessary stuff to help reduce lag

Fashionista goes: hmm! I am not wearing anything unnecessary soooo! and then goes I wish all these obviously unfortunate people would just like leave, so I can get my shopping done !!

just a story about this from back in the day

prim eyelashes. At least 40 prims for each top and bottom times two. 160 prims minimum. 200+ even. Each of them edit moved individually and positioned. Would take hours to get them exactly perfectly placed

a guy at the time asked: What !!! 160 prims just for  eyelashes. Who does that ?!?

and his partner replied: I do dear, because I can

 

[Phil Deakins]

---

polysail wrote:

No no! ~Script count 

still matters

.

---

Nova beat me to it, but just so you know that it's true, the time alloed to run scripts in a sim is limited. It's capped. If all the scripts don't get time to run, it's the scripts that will lag, and not avatars.

ETA: Since I posted this, I read your next post which says that you don't believe it. Do some research because it's perfectly true.

[wherorangi]

---

Phil Deakins wrote:

it's perfectly true.

---

and the good thing about it is that since the change, coders are now writing really tight and efficient scripts for the top end products

that when all scripts are lagged then those scripts that can execute and complete in the tiny time available to them each, massively now out-perform the scripts that are inefficient. Which is a good thing  

[ChinRey]

---

polysail wrote:

That's a really interesting assertion. I have only been in SL for a little over 2 years.  But I'd like to see the documentation about this!

---

Sure. Here is a snapshot of the stats from Uber August 2015:



[Aethelwine]

---

Theresa Tennyson wrote:

---

Aethelwine wrote:

---

Theresa Tennyson wrote:

---

Aethelwine wrote:

Chimney, I am curious to know where you got those numbers and if there is a more detailed explanation anywhere for how the ARC Is calculated. The reason I am curious is because I have seen a comparison of mesh bodies and heads where the ARC value is very different from the complexity of the mesh measured by the number of vertices. The relationship between the two figures was the inverse of what you would expect.

---

My understanding is that the rendering cost is how hard it is to render an avatar

in any given frame

. Many of the bodies that have high polygon counts but low ARC's have many additional triangles that aren't normally textured and visible - for example, alternate hand poses, etc. The rendering engine automatically ignores these triangles when it's rendering a frame but that data still needs to be sent to your viewer when that avatar arrives. It will take longer for that avatar to show up the first time because more data is sent, but it won't necessarily be difficult to draw (i.e. reduce your graphics framerate) it when it finally arrives.

---

The Catwa head Jessica is made up of 3,931,000 Vertices, Lelutka head's about 62,000. Yet the ARC for Catwa head is 8,270 and the Lelutka 49,900.

I do get a noticeable difference wearing these heads, the Catwa often takes a few logs to load, friends with that head often look like eye ball and brain monsters. The Lelutka head loads fine, they are both animated heads, they both look smooth.

So what is going on with the ARC? and why does the low value head cause more problems than the high ARC head?

How can a head 70 times more complex than the other have a fifth the ARC?

If people work reducing their ARC to avoid being jelly beans and wear the low ARC head then that will cause more headless people on the grid and more rendering problems.

---

The problems you're seeing with the Catwa head are because all those polygons take a long time to arrive at your viewer and everyone else's. Once they arrive, most of them aren't drawn at all. It's two completely separate things. It's as if you have two classes in school - with one of them your nightly assignment is to read 10 pages out of a 1000 page book, and with the other you read all of a series of 100 page books every night. The book for the first course will always be heavier to carry; the assignments for the second course will always take longer to read.

---

I understand what you are saying, I think, but I still don't see how that can explain those numbers. Both are heads, both will have some tattoo layers, both will have stuff invisible for doing their facial expressions.

The more complex head is a fraction of the ARC of the much lighter head.

When I asked Chalice Yao about this she replied:

"The answer is that Render Weight, for whatever reason, hardly freaks out about insane geometry. Which does not really make sense, especially when it comes to rigged geometry.

 

Heck, Render Weight freaks out at times about things that *don't* slow down your PC;

Flexies are an example. Flexies kick RW up by the 10's of thousands, but while flexies are calculated on the CPU, they also have a tiny, hard limit of time their calculations are allowed to take..you'd need a LOT of flexy to slow anything down.

Yet, it's punished very, very harshly."

Whilst their ARC formula seems so badly flawed, is it really going to be of any use? and if it encourages people to wear "insanely" complicated mesh, as it appears to do, won't the effects be to make peoples experience worse and not better?

[Theresa Tennyson]

---

Aethelwine wrote:

---

Theresa Tennyson wrote:

---

Aethelwine wrote:

---

Theresa Tennyson wrote:

---

Aethelwine wrote:

Chimney, I am curious to know where you got those numbers and if there is a more detailed explanation anywhere for how the ARC Is calculated. The reason I am curious is because I have seen a comparison of mesh bodies and heads where the ARC value is very different from the complexity of the mesh measured by the number of vertices. The relationship between the two figures was the inverse of what you would expect.

---

My understanding is that the rendering cost is how hard it is to render an avatar

in any given frame

. Many of the bodies that have high polygon counts but low ARC's have many additional triangles that aren't normally textured and visible - for example, alternate hand poses, etc. The rendering engine automatically ignores these triangles when it's rendering a frame but that data still needs to be sent to your viewer when that avatar arrives. It will take longer for that avatar to show up the first time because more data is sent, but it won't necessarily be difficult to draw (i.e. reduce your graphics framerate) it when it finally arrives.

---

The Catwa head Jessica is made up of 3,931,000 Vertices, Lelutka head's about 62,000. Yet the ARC for Catwa head is 8,270 and the Lelutka 49,900.

I do get a noticeable difference wearing these heads, the Catwa often takes a few logs to load, friends with that head often look like eye ball and brain monsters. The Lelutka head loads fine, they are both animated heads, they both look smooth.

So what is going on with the ARC? and why does the low value head cause more problems than the high ARC head?

How can a head 70 times more complex than the other have a fifth the ARC?

If people work reducing their ARC to avoid being jelly beans and wear the low ARC head then that will cause more headless people on the grid and more rendering problems.

---

The problems you're seeing with the Catwa head are because all those polygons take a long time to arrive at your viewer and everyone else's. Once they arrive, most of them aren't drawn at all. It's two completely separate things. It's as if you have two classes in school - with one of them your nightly assignment is to read 10 pages out of a 1000 page book, and with the other you read all of a series of 100 page books every night. The book for the first course will always be heavier to carry; the assignments for the second course will always take longer to read.

---

I understand what you are saying, I think, but I still don't see how that can explain those numbers. Both are heads, both will have some tattoo layers, both will have stuff invisible for doing their facial expressions.

The more complex head is a fraction of the ARC of the much lighter head.

When I asked the Chalice Yao about this she replied:

"The answer is that Render Weight, for whatever reason, hardly freaks out about insane geometry. Which does not really make sense, especially when it comes to rigged geometry.

 

Heck, Render Weight freaks out at times about things that *

don't

* slow down your PC;

Flexies are an example. Flexies kick RW up by the 10's of thousands, but while flexies are calculated on the CPU, they also have a tiny, hard limit of time their calculations are allowed to take..you'd need a LOT of flexy to slow anything down.

Yet, it's punished very, very harshly."

Whilst ther ARC formula seems so badly flawed, is it really going to be of any use? and if it encourages people to wear insanely complicated mesh, as it appears to do, won't the effects be to make peoples experience worse and not better?

---

I did a test, standing on a pose stand in a skybox with a low draw distance and kept my camera position stationary. This meant that the figure "KTris per Frame" under the Statistics panel was absolutely solid and identical for every frame. This number is the actual number of triangles the rendering engine draws every frame - the higher the number, the harder it's working.

CONTROL: Avatar with only the required system components, draw weight 1000 = 83.944 Ktris per second.

SAME AVATAR WITH CATWA "ANNIE" MESH HEAD DEMO AND ASSOCIATED ALPHA = 133.916 Ktris per second.

SAME AVATAR WITH LELUTKA "KARIN" MESH HEAD DEMO AND ASSOCIATED ALPHA = 171.680 Ktris per second.

These numbers suggest to me that the higher render weight for the Lelutka head is perfectly accurate for what the render weight is meant to represent, despite the Catwa head having a much higher vertex count.

[ChinRey]

---

Aethelwine wrote:

Whilst their ARC formula seems so badly flawed, is it really going to be of any use?

---

Well, they just have to fix it, and fix it fast. Oz, are you reading this?

One very obvious flaw that has turned up, is that QuickGraphics isn't actually based on the actual ARC at all, it's based on the ARC aproximation built into the viewer. I did some quick tests and found differences as high as 50% between the vierwer's and the sim server's readings. That was quite a shock and of course completely unacceptable. Easy to fix, add the actual ARC formula to the viewer, or alternatviely use the server's data instead. But a bug as basic as that should never ever have survived all the way to an official release anyway and the fact that it did casts serious doubt on the quality of the project as a whole.

[Perrie Juran]

---

polysail wrote:

Yes ~ approximately 45% of all avatars are over 80K.  I did a little measuring test and submitted a JIRA on it in the hopes that they would back off the 80K line.  But they seemed rather intent on keeping it there.  ( Though supposedly it changes based on what your grapics card is? )

He're's the study.

https://jira.secondlife.com/browse/BUG-10967

---

Wow, old JIRA. 

I started talking about this stuff ages ago:  So Linden Lab Wants Us to All Be Naked.

But here we have a case of LL having the cart in front of the horse for a very long time.  They are making an end run on educating people about Avatar Impact.  Educating people about best practices should have been going on for a long time.

Consider this from Performance Improvements.

"All of these Improvements are great but they still will only be of minimal benefit without better building practices in SL.  Because after all those 1024 textures load I'm still going to lag or even crash because I run out of texture memory.

Consider this exchange between Monty & Torley Linden:

"Monty Linden added a comment - 17/Oct/14 11:32 AM - edited

So, in something like game development where one hierarchical team would make resource decisions, a resource target would be set (say 256MB resident textures) and content would be adapted to fit in it. Doesn't work for us where content is designed without foreknowledge of its target environment. Better tools for the content creators is certainly desperately needed. Has been, is now, will be tomorrow.

But it's not enough. That centralized feedback loop within a design team doesn't have a direct analog in SL. Instead, there are many independent possible feedback loops. Estate owners/managers and event/build organizers might want the resource allocation and enforcement role. Renters, visitors, fabricators, etc. are directly and indirectly consuming it. The piece that is missing is the communication/advice/enforcement/review network so that everything can be brought into balance. Prim/rendering cost doesn't quite cover it.

Recent changes are probably going to aggravate it. Mesh and texture behavior just became a whole lot more permissive. I'm expecting overbuilding to become more common.

 

Torley Linden added a comment - 17/Oct/14 4:07 PM - edited

That's a great way to put it, Monty — the "communication/advice/enforcement/review network" is the social-cultural piece of the puzzle. I have always advocated for this in SL and am more than happy to help if we (Linden Lab) are going to raise awareness, especially at a broad level that sets a good example of content creation practices. It's incredibly important to teach our community how to get the most out of any tools and to be aware that resource usage needs to be balanced for optimized experiences."

https://jira.secondlife.com/browse/BUG-2514?

Both Monty and Torley recognise the need to better educate people.

But what has happened is Linden Lab has left this education in the hands of its users.  And it isn't working.  Certainly there is the Knowledge Base and the Wiki but people don't even know to search for this info."

So now what we get are these Jelly Babies, which, if you think about it, destroy the shared user experience.  Hmmmmmmmmmm.

 

[EdmundPendragon]

---

Perrie Juran wrote:

So now what we get are these Jelly Babies, which, if you think about it, destroy the shared user experience.  Hmmmmmmmmmm.

 

---

This is EXACTLY what Linden Lab wants EVENTUALLY. The death of Second Life and people migrating to their special snowflake, Project Sansar. The only argument is the timetable.

[ChinRey]

---

Aethelwine wrote:

Flexies are an example. Flexies kick RW up by the 10's of thousands, but while flexies are calculated on the CPU, they also have a tiny, hard limit of time their calculations are allowed to take..you'd need a LOT of flexy to slow anything down.

Yet, it's punished very, very harshly."

---

Really? Let's find out.

Here is an empty sky platform above the Mirus Sandbox. I'm wearing a full body alpha, SL Viewer, mid res graphics but with draw distance lowered to 64 m. Nobody else in the sim:



Fps is 92.2

 

Fill it up with 128 regular prims:



And surprisingly, the fps drops all the way down to 78.5. I didn't expect just plain prims to be that laggy!

 

Replace the regular prims with flexis of the same size - with a little bit of wind effect:

 

Fps 74.8, not much lower than with regular prims.

This quick-and-dirty informal experiment has two flaws. The effect of flexible polys and vertices depends a lot on hos much they move of course and unfortunately the SL wind remained depressingly stable. Also, it's possible I should have spaced the prims out a bit more - they're so close they're overlapping and you can barely see there are 128 of them and not 64. That shouldn't matter but it's one extra unnecessary complication. Sorry. More tests are required to draw any kind of conclusion but it's an interesting start.

[Polymath Snuggler]

I don't know if you've actually looked at what sansar IS.  Based on your remarks I'm just going to assume that you haven't ~ because it's got almost nothing to do with virtual living in the manner that SL provides.   Sansar is a virtual reality hosting platform.  It's a service to produce virtual environments and share them with other people via the web.  What it's not designed to do is to be a virtual living space and social network.  So unless you're in the habit of creating art installations or doing online education it's really not going to have much appeal to most people already on SL.

 

Sansar is Linden Labs attempt at making a product for everyone else who needs a VR environment but doesn't really like / want or need something like SL.

[wherorangi]

ps. I just add

in the viewer we do get told by a system notification whats happening

when we change/add/remove stuff then we are notified what our now Complexity is

when we are in a scene and there are others present, and our Complexity is high, we can get a notification that others present may not be able to see us fully

[Polymath Snuggler]

If you've worked with the Lindens to try and solve some of the problems of SL ~ it quickly becomes apparent that they are out to do the most amount of good in the least amount of time.  That means putting out a lot of little wild-fires but not always applying the shiniest most comfortable divinely inspired bandaid to the wound that someone can theorize might exist.

 

The ARC calculation may not be perfect, but it does fairly well at representing what causes graphics based viewer lag.

 

The other thing that becomes quickly apparent is that ( and I know this is not a popular idea on these forums )  they actually know what they're doing.  Their ideas may not always be the best and their solutions may not be perfect and utopian and ideal.  The server stability may be questionable at times but if you look back at what SL is~  a 13 year old behemoth cratering under the weight of it's own databases.  ( Just stop and think for a minute how much data must be crammed into the inventory servers after 13 years and millions of users, with 100K-300K + Inventory counts. )  And then look at SL and realize that it still works.  Most of the time it's online, and mostly functional.  That's because~ though the Lindens may be a bit poor with their public relations at times, and they may be overworked and running on razor thin profit margins, their technical expertise is actually pretty impressive.

 

~ just my 2 cents

 Just a quick post-note ~  There's absolutely nothing wrong with wanting them to improve stuff.   It's what i do all the time.  Just commenting on this for awareness that its a weighing game of "results for time & effort spent."

 

[wherorangi]

user and designer education is a difficult problem for sure, in a anybody-can-have-a-go environment

i think the most useful thing for the most number of people to come out of this work is the now ability to create/save/reuse the graphic settings. Thats a pretty good thing to have for a lot of people

i think also that the Complexity thing will be good for designers going forward. The successful for-sale product makers will take notice of it, and it time they will start producing more efficient clothing and accessories

Users probably less so. Less so in the sense that I found these boots. I really like them

each boot adds about 10,000 to my complexity. Relatively high. Thing is tho that I really really really like them. Until I find another pair of boots that I really really even more like then I will continue to wear them

 

 

 

[EdmundPendragon]

You obviously know everything and I know nothing.

 

You wouldn't happen to be my RL ex-wife.

[Bryce Kidd]

---

wherorangi wrote:

Users probably less so. Less so in the sense that I found these boots. I really like them

each boot adds about 10,000 to my complexity. Relatively high. Thing is tho that I really really really like them. Until I find another pair of boots that I really really even more like then I will continue to wear them

 

---

That's the situation most of us will face. Until our parts are redone (assuming the creators are still even in SL; the person who made my ears left in 2007) we will just be another jellybaby.

The render my friends setting needs to be as persistant as derender is. Especially for the changeover period as everyone adjusts, especially those in the Fur and Anime communities who will want to see their friends wach time they log in.

---

Drake1 Nightfire wrote:

99% of those small images are 1024x1024 to "capture the awesome detail." What they don't realize is that image has no more detail than a 512 would.

---

And in 1/4 the video RAM. Not many people enlarge the vendors up to full screen anyway, which sort of defeats the purpase of making a screen sized texture.

And this texture overuse is the biggest failure of Fantasy Faire and many other large events. Year after year Fantasy Faire is full of laggy 1024x1024 ventor images on postage stamp sized vendors where a 256x256 would be more than adequate. 

---

Phil Deakins wrote:

---

polysail wrote:

No no! ~Script count 

still matters

.

---

the time alloed to run scripts in a sim is limited. It's capped. If all the scripts don't get time to run, it's the scripts that will lag, and not avatars.

---

I agree with Phil and the others that mention script count doesn't matter as much as previously. However there is a small residual effect that causes me to still optimise scripts in my regions to be as low as possible.

The main time a script does matter is as people TP in their scripts place a much higher load on the CPU, but that settles down after a few hundred frames in a busy sim so it's pretty moot.

The recent hair show that kicked people for too many scripts was fairly obnoxious, and also redundant. Just showed an uneducated organiser. And that is the biggest reason for render cost never to be added to land settings.

[Aethelwine]

---

Theresa Tennyson wrote:

I did a test, standing on a pose stand in a skybox with a low draw distance and kept my camera position stationary. This meant that the figure "KTris per Frame" under the Statistics panel was absolutely solid and identical for every frame. This number is the actual number of triangles the rendering engine draws every frame - the higher the number, the harder it's working.

CONTROL: Avatar with only the required system components, draw weight 1000 = 83.944 Ktris per second.

SAME AVATAR WITH CATWA "ANNIE" MESH HEAD DEMO AND ASSOCIATED ALPHA = 133.916 Ktris per second.

SAME AVATAR WITH LELUTKA "KARIN" MESH HEAD DEMO AND ASSOCIATED ALPHA = 171.680 Ktris per second.

These numbers suggest to me that the higher render weight for the Lelutka head is perfectly accurate

for what the render weight is meant to represent

, despite the Catwa head having a much higher vertex count.

---

I got slightly different numbers:

Catwa Jessica : 86.5 Ktris per frame

Lelutka Karin : 89.3 Ktris per frame

They aren't different enough to indicate the scale of the difference in the ARC, but it is interesting and illustrates the point that the total Vertices in a mesh object are not that important for lag once the object has loaded.

I am still left feeling the ARC isn't measuring the cause of problems I have when going in to busy clubs, which is more about people slow rezzing or not rezzing at all, than any impact on frame rates. Which I had thought it would sincewhen discussion about it spend so much time talking about texture sizes.

What actually is the relationship between Vertices and Triangles in a mesh object? The ARC measures triangles... if you make your mesh object out of squares instead of triangles can you cheat the ARC? - does that even make sense?

[Polymath Snuggler]

I did a pretty lengthy search of google for release notes on them changing how scripts function~ and I haven't been able to find much.  If anyone can point me to the update ~ I'd be elated.  I have noticed that sims have a much bigger tolerance for exceedingly high script count avatars ( 500-1200 scripts )   But at the same time I've also seen the simulators bog down and even crash with areas that have high script counts. ( From avatars and objects alike )

 

~ Also @ Mr Pendragon, I looked at some of your other posts ~~ If I ever made the mistake of marrying anyone dull witted, cynical and small minded as you in the first place, I'd have no hesitation on rectifying that mistake as soon as I was able.

[arton Rotaru]

---

Aethelwine wrote:

What actually is the relationship between Vertices and Triangles in a mesh object? The ARC measures triangles... if you make your mesh object out of squares instead of triangles can you cheat the ARC? - does that even make sense?

---

 

3 vertices make a triangle. In a connected mesh you need only 1 more vertex position to define another triangle though. Because the other 2 vertices are known already and will be re-used.

There are only triangles, and nothing but triangles in-world. So no, there won't be any cheating with quads. :matte-motes-little-laugh:

[arton Rotaru]

---

polysail wrote:

I did a pretty lengthy search of google for release notes on them changing how scripts function~ and I haven't been able to find much.  If anyone can point me to the update ~ I'd be elated.

---

Lookout for lines of tehKellz (kelly.linden) for what's causing lag, and what doesn't. Especially starting at [09:39].

http://wiki.secondlife.com/wiki/Content_Creation/Scripting_User_Group/Transcripts/2012_01_09

[Polymath Snuggler]

Ahh!! Thank you!!!   Seriously thank you!

That clarifies what people were saying by a lot and contradicts my own personal experiences muuuuuuuch less.   ( I've lagged entire sims with some of my script projects )

 

So ~ just so I make sure I get this straight.  Script count, as long as they're not doing anything don't induce much lag on their own.  But having a enormous mess of scripts does increase the statistical probability that some of the scripts that you are wearing might be taking up serious amounts of server resources? ( by manipulating prims etc )?

 

I've always been taught that leaving listeners open induced tremendous amounts of sim lag.  Hence why the 255 prim jewelry with a resizer script with an open listener in each one are so bad.  I'm guessing that it ~ in some capacity place demands upon the sim?  Or is that an age old myth?  ( The programming wiki stresses turning them off when un-used )

 

[ChinRey]

---

polysail wrote:

The other thing that becomes quickly apparent is that ( and I know this is not a popular idea on these forums )  

they actually know what they're doing.

 

---

They do. The Uber stats I posted here actually proves that. It was intended to show how little scripts contribute to server side lag but it also is a good example of something completely different: a server as overloaded as that should have crashed so badly it would have shown up on seismographs all over the world. The fact that it managed to stay online at all speaks volumes about how good the programmers and technicians at LL are.

However, I think I'll quote Andrew Linden here:

---

Andrew Linden apparently once wrote (according to Prok):

Please, I just write and design code. I think in terms of code. I don't think in terms of group law and anarchy.

---

That's it really. It wouldn't take much work to update the ARC formula to better reflect  SL as it is today rather than as it was a few years ago. It shouldn't be hard to program QuickGraphics to use the actual ARC formula rather than the rough estimate built into the viewer. And it would be dead easy to set a more realistic default cutoff value.

The reason LL didn't do any of those things is that they miss two important points:

Most people don't want to spend time fiddling with the preference settings

and most of all:

We don't want to see any jellybean figures in Second Life at all, we want to see people! If some avatars have to be derendered because of their lagginess, then so be it but please leave everybody else alone! QuickGraphics is not a good thing, it's a necessary evil and as such it needs to be as unobtrusive as it can possibly be.

Aethelwine mentioned the apparent discrepancy between the significance given to path based and skeleton based flexis and that's a good example of what I mean. A few hours of testing, rezzing and wearing items, comparing stats, then change a few variables in the code to reflect the new data and also publish the results for everybody to see. Job done! One less controversy to argue about and a greatly improved QuickGraphics.

Do you really think that's too much to ask for?

Finally, just to make it absolutely clear: I think QuickGraphics has value even in its current crippled state. But it could and should be so much better and it's not too late to fix it.

Time is running out though because as soon as people get the impression that it's just another overhyped LL blunder - and they will the way it works today - they'll just deactivate it and then all the work will have been in vain.

 

[BilliJo Aldrin]

My partner last night told me Firestorm has a setting where u can see everyones avatar complexity, she was 102,000 with mesh hair, i was 110,000 with my 120 prim flexi prim hair.

I think this jelly baby thing is just the latest disaster thrust upon the users of second life. Nothing good will come of it except fostering an elitist attitude among those users that are willing to totally gut their inventories to get the latest and greatest of everything.

I have an adequite video card in a fairly new computer, my frame rate is reasonable, and i run on medium settings. In a crowded club i drop my draw to the minimum and set the number before avatar imposters appear as low as necessary to keep my frame rate adequate. I don't want or need to see jelly dolls.

I'm just waiting for the first im from a low impact elitist saying, you know, you are a jelly doll, u are such a resource hog, you need to update yourself. And they will blame me for destroying their sl experience.

oh well, whatever.