Second Life: April Fools on Who?

April Fool’s Day is definitely an American tradition. Even big corporations like Sony get in on it. This year Sony released a Proton Pack ala Ghost Busters fame. It isn’t surprising that Linden Lab’s Second Life crew got in on the spoofing too. But, it was a bit of a disaster. They did their best to make the best of it.

The video here is what happened to me when I logged in to go check out the spoof. They announced it here: Exclusive Message for Second Life Residents Available Inworld Today! The tease was this was something about Project Sansar. Also that it was exclusively for Second Life™ residents, so you gotta login to see it. They gave a link to SL Town Hall.

The video is 10+ minutes long. I don’t expect you to watch it, at least not all of it.

You can see I made it about 10 minutes before the viewer completely locked up… pretty much the entire computer. My avatar never actually puller herself together. Nor did many of the other avatars in the region… about 28 of them. You will see me open the World Map about time-mark 4:40 to get a population count. The mini map is showing way more than 28. But, the area is divided up into 4 regions with the common corners in the center of the stage. So, the region I first rez in had more than 28, but 6+ minutes of the time I was in the region with 28 other avatars and not rezzing. Continue reading

The truth about events…

Over on Mesh Body Addicts Lildaria has written an article with that title, Truth About Events (NSFW±). She touches on a pet peeve of mine, but her prime point is the problem we are starting to have… having… with events.

Menage A Trios

Menage A Trios

It seems that people are staying longer at events because they have a hard time getting in. If you leave, it may be a day or two before you can get in again. So, demos are downloaded and tried on while people are at the event. This puts a load on the region server and lags it more than their just being there.  Continue reading

Second Life’s Jelly Babies – BUG?

The coming Quick Graphics Viewer now in RC has some odd behaviors. Well, it is an RC version, so no surprise. One of the ideas with this viewer is to reduce render lag by telling the viewer to avoid rendering complex avatars. These are avatars with lots of high polygon count attachments and large textures that require lots of computer power to render.

The Candy Princess - by  Bewitched Difference @ Flickr

The Candy Princess – by
Bewitched Difference @ Flickr

There is a setting in Preferences* that lets you set a personal limit for what you want your viewer to render. Any avatar over that limit will render as a jelly baby. But, if you change the setting to NO LIMIT you’ll find there are still avatars that render as jelly babies. What’s up with that?  Continue reading

Flickr Problems

I thought it may just be me, but Flickr is NOT working well this morning. It is behaving like I imagine it would if it were inside SL…

Ping to LA is 13ms, download 59mbps, and up 6.7mbps. The Flickr servers are in Lockport, NY, USA. According to Flickr they use Content Delivery Networks (CDN) (Reference), according to a book titled Photography Applications for Cloud Computing. So, testing to New York: 108ms, 29,5mbps down, 6.5mbps up. So, not a network issue.

You can report problems with web sites and see when they are having problems. For Flickr use: Flickr Down? According to them problems started about 10:20 AM EDT 9/24.

 

Avatar Complexity Update Week 37

Second Life™ is getting a new tool to hopefully induce people to reduce avatar generated lag; the Avatar Complexity Rating. I’ve written about it before and I am trying to play with the Project Quick Graphics Viewer version 3.8.4.304761, which adds avatar complexity settings and notices.

Complexity KB Value

Complexity KB Value

The notice that appears in the upper right of the screen just after login tells you your avatar complexity number. I suggested that it be colored, green good and red bad, just as the Show Avatar Render Complexity Information (ARC) display does.

Instead, they added a link in the notice to this SL Wiki page: Avatar Rendering Complexity.

They note the other factors that can cause avatars to be rendered a Jelly Babies;

  • total attachment surface area
  • total attachment byte size

You can change the values of these settings in Debug Settings. See:

  • RenderAvatarMaxNonImposters – The maximum number of avatars closest to your camera who may be fully rendered. Avatars beyond those will be rendered as ‘imposters’, which means that the rendering will be a little simpler and they will be updated less frequently. Increasing this value can cost you in performance if you’re in a crowd. This does not cause them to render as Jelly Babies.
  • RenderAvatarMaxComplexity – Any avatars over this complexity will be drawn as solid color outlines. Changing this value directly may cause problems; use the slider in the advanced graphics preferences floater.
  • RenderAutoMuteSurfaceAreaLimit –The limit for the total surface area of attachments before switching to solid color rendering. The default (10 million square meters) is intended to protect against deliberate abuse and should rarely be encountered.
  • RenderAutoMuteByteLimit – The limit for the total number of bytes of attachments before switching to solid color rendering. The default (10 million bytes) is intended to protect against deliberate abuse and should rarely be encountered.

As you may have guessed, the last two are mostly to stop some griefing issues. But, those settings can be used to improve viewer performance.

Changing RenderAvatarMaxComplexity in the Debug Settings doesn’t seem to be a problem. Whether I change it in the Preferences panel as the Lindens recommend or in Debug Settings the change is reflected in the other. But, getting to the Preferences setting is much easier. Whether changing the setting there affects other settings not affected by using the Debug Setting, I have no information. It is a possibility, but I have not seen anything that leads me to think that happens. But, this is a Project Viewer and it will change.

Link to more pages below…

Avatar Render Cost 2015-07

Penny Patton writes about reducing her avatar’s render cost. (See: Draw Weight.) Kay Jiersen picked up on the article and wrote an article too. (See: Render weight best practices for Second Life.) Some time ago I wrote: Second Life Performance: Render Muting, which is about the same subject.

Penny Paton's Example of Dense High ARC Mesh

Penny Patton’s Example of Dense High ARC Mesh

Penny is pointing out there is a bit we can do to change our render cost with only a minimal change in appearance. Kay suspects few people are even aware of the Avatar Render Cost (ARC) feature in the viewer and have no clue they need to do anything. I agree with Kay. But, she goes on to recommend changes to Second Life, which is where I disagree.

Kay made field trips to various places in Second Life where she recorded the ARC values of avatars in the regions. Kay points out that only 81 of 190 (42.6%) avatars would render using a setting of 80,000 for Render Muting. That means 109 or 57.3% of the avatars would not render .

The horrible frame rates (FPS) I am getting have me looking at a new computer and a better video card. But, I actually have little hope that will help FPS in regions populated with 30+ avatars.

On an empirical basis Kay found that jewelry is a major culprit in high ARC.  Continue reading