Second Life Viewer Updates from the TPD Meeting

Project Azumarill Viewer version 3.8.4.304871Release notes describe the version as:

This viewer release is a complete replacement of the under the hood HTTP infrastructure. It provides improved performance and stability by replacing the self deleting responders with coroutine implementations. These coroutines also provide a finer grained concurrency allowing the Viewer greater control over the numbers and types of HTTP requests that can be simultaneously outstanding. This release also removes a considerable amount of deprecated and unused code from the viewer.

These changes impact all areas of the viewer that use Sim Capabilities. A nonexhaustive list includes:

  • Asset upload (Images, Meshes, Animations)
  • AISv3 inventory manipulation
  • Viewer Managed Marketplace
  • Simhost event polling
  • LSL script compilation
  • Experience management (blocking, allowing, creating)

We will hopefully see our biggest performance improvement in some time with this viewer. Improvement in performance and stability. I personally think stability and performance have been declining for months. I think that is just a byproduct of a smaller staff and a focus in new features. I think this version is a pass at catching up on performance issues.

Presumably there is considerable performance work going on for Project Sansar. Its demands are far higher than those of Second Life. For SL the Lab believes 10 FPS is adequate. To avoid simulator sickness and provide the duel image render needed for VR Headsets Sansar’s FPS will have to much higher. The frame rate for Oculus is targeted at 90 FPS and since two images are needed the actual rate is 180 FPS.

I suspect some of the technology that is helping the Lab get Project Sansar to that goal can be used with Second Life and is making its way in. I doubt we will see the render engine in SL change much as that would be a huge project requiring specialized people. Plus the legacy compatibility problems would limit how much could be improved. Those limits are a significant part of the reason Sansar is being built. But, lots of supporting tech will likely be the same or similar in both systems.

Project Notice Viewer version 3.8.4.305083 – The release notes say:

New Notifications floater separates incoming notifications into System, Transactions, Invitations, and Group. It provides a better way to view, interact with, prioritize and manage incoming notices for busy residents. This Viewer is in Project stage, which means now is the best time for your feedback on it in jira.

A special thank you to Aki Shichiroji for initial feature design.

Project Quick Graphics Viewer version 3.8.4.305063 – Release Notes:

Graphics Presets

You can now create different saved “presets” for your graphics preferences, and quickly switch between them using a new top bar pulldown. Create one with a short draw distance and support for lots of detail to use when going to a dance club, another with long views for exploring, and any others that you find yourself using frequently.

Avatar Rendering Complexity Controls

For many users, the most expensive part of rendering a Second Life scene is rendering the avatars around you. For some time, the viewer has had a measurement of how much each avatar around you is affecting your performance; this viewer introduces some control and feedback based on that measure. A new *Avatar Maximum Complexity* control lets you prevent expensive avatars from lagging you; any avatar over the limit is displayed as a solid color rather than rendering full detail. A default limit is set based on the rendering performance of your system (we may change these defaults based on feedback with this Project Viewer). You’ll also get a notice when your own rendering complexity changes, and an indication when you’re over the limit of too many of the avatars around you.

Links for additional pages below…

3 thoughts on “Second Life Viewer Updates from the TPD Meeting

  1. Oh dear. I took my eye off the ball on this one. Of the problems I reported in BUG-9015, the worst effect (splitting object unpredictably across a single material) seems to be corrected, at least in the test case. The problem where a material with >21844 tris in only the high LOD causes a cryptic material to be generated, which isn’t matched in the lower LODs, still causes upload failure despite all LOD files being correct. So everyone should still be advised just to avoid materials with >21844 tris. Why they don’t simply make that an explicit error, I don’t know.

    Personally I don’t like what they did here at all, and I don’t understand the motivation. If you allow the uploader to decide how to split your mesh into separate objects, you lose control over the sizes of the split objects and therefore of their LOD switching. There is nothing difficult in splitting up a mesh (and/or materials) youself, retaining complete control. The only people who can possibly benefit from this change are those who are uploading other peoples’ meshes not specifically made for SL, with excessive geometry and/or textures, who don’t know how to optimise them for SL. Facilitating that can only make things worse than they already are. Can anyone suggest a more sensible reason?

  2. Pingback: Second Life’s Limits | Nalates' Things & StuffNalates' Things & Stuff

Leave a Reply

Your email address will not be published.