Second Life Third Party Dev Meeting 2016 w32


The main viewer has updated to version This was formerly the Maintenance RC Viewer. There are a lot of fixes in this update. Oz Linden points out that work is being done to prevent viewer crashes. This release dropped the crash rate by 4%, which is huge.

One fix in that line is in the image processing. When video memory filled up and there was no way for the viewer to handle the texture… it crashed. Now it will simply skip rendering the texture and color the object gray. 

If, after a time, you start to see lots of grey, it is probably time to relog… clear memory.

There is now an ongoing effort to fix viewer crashes and handle exceptions. Exceptions are those events the programmers didn’t anticipate or didn’t handle. The viewer has no idea what to do in those cases and usually dies.

The current focus is on the image processing pipeline. Other areas are going to be looked at too. Goal is to stop the crashes and give the user and especially the log an idea of what went wrong.

The next viewer likely to be promoted is the QuickTime replacement viewer: RC Second Life VLC Viewer version This version fixes the Windows version. Apple versions will not see this replacement until the 64-bit version of the viewer comes out. Until then Windows and Apple users will have different support for media.

Firestorm is changing to GStreamer rather than VLC. Interesting.

The RC Second Life Visual Outfit Browser Viewer version will update getting the new default viewer changes and appear as a new version in week 33.

Oz says they are going back to work in the 64-bit viewer hopefully in week 33.

A new maintenance version is coming out. With any luck we will see it in week 33 but, may be not until week 34.

Second Life Project Bento Viewer version will update really soon. Bugs are coming in quickly so, it is hard to anticipate when it will go prmote to RC status. Vir Linden is guessing we’ll see Bento go to RC status within the next month… four weeks, but… may be not.

Avatar Complexity

Whirly says the FS Team is finding Avatar Complexity settings, aka JellyDolls, is doing a good job of protecting against worn graphics crashers. Enough so that griefers are abandoning them. Unfortunately they are moving to video memory bloat attachments.

There are attachment they can wear so that even as a JellyDoll they suck up 4GB of memory. That is enough to take down anyone using a 32 bit viewer. Samples of such a crasher have been given to the Lab. They are looking into how to stop that grief.


Voice updates are progressing. Oz is working on debugging the current Vivox build the the Lab has. Oz says they will be where they can release a public version of the changes in a couple of three weeks.

Abuse Reporting

There was an SL Conference, an in-house presentation from the support group. One thing they highlighted was Abuse Report categories. Using categories other than the ones in the Linden viewer confuse the support tools. The Lindens are asking that all viewers use the same report categories to speed Linden support processing.

In the future the category list will be supplied from the SL servers. This will make updating and changing categories MUCH easier and everyone will change at the same time.

Screen capture is going to be a mandatory part of an Abuse Report. The viewer will grab a screen capture and send it with the report, needed or not.

Having the backend supplying the category list is several weeks out.

Firestorm ACI

Firestorm now has JellyDolls, aka Avatar Complexity. So, now the interesting part of the social experiment starts.

The Lab has asked that third party dev’s not change the complexity calculation. There are comments in the code to that effect. Dev’s are asked to send in suggestions for improving the calculation.

We also are not going to see ACI as part of the marketplace, built in at least, for some time. For the time that number varies depending on your graphics card. So, using ACI values in the marketplace would be confusing and possibly misleading.

The problem is for some cards the polygon count is most important, meaning the card works hard to render polygons. Other cards are designed to handle tons of polygons and they have little effect on performance. Some handle transparency easily and for others it is a big challenge. The Lab has tried to create a calculation that works with the users’ individual hardware. So, different people will see different ACI values as the number represent how hard THEIR computer has to work, not some generalized computer.

As more information accumulates the ACI calculation is likely to change. The Lab has made the policy decision to only change the ACI calculation slowly and when the reasons are strong.

They also test the calculation using test objects and various hardware and software, i.e., Windows, Apple, Nvidia, and ATI and various versions and models. This takes time to run the tests, collect the results, and figure out what they mean so, it is a slow process.

But, expect ACI values to be VERY similar in all viewers but, different between users.

If my hair ‘A’ has a greater ACI than my hair ‘B’, we can expect everyone will see ‘A’ with a higher ACI than ‘B’ even if we all have different values.

3 thoughts on “Second Life Third Party Dev Meeting 2016 w32

  1. One thing LL absolutely needs to do is increase the cost of excessive texture use. Right now, reducing the texture memory of an attachment from 16MB to 256kb results in only a difference of 896 ARC. I’ve seen avatars walking around with half a GB of textures, complaining about how poorly SL runs and never understanding that they’d done it to themselves.

    As someone who understands how realtime 3D rendering works, and what habits are drilled into professional 3D artists, I can tell you that LL has always underestimated the impact texture use has on framerates. So much so that they left it out of Land Impact calculations entirely, and we’re all still paying for that mistake.

  2. Pingback: Second Life News 2016 w33 | Nalates' Things & StuffNalates’ Things & Stuff

Leave a Reply

Your email address will not be published.