SL project updates 45/1: server, viewer

Sol Existence; Inara Pey, October 2017, on FlickrSol Existenceblog post

Server Deployments for Week #45

As always, please refer to the server release thread for updates and the latest news.

On Tuesday, November 7th, the planned Main (SLS) channel deployment was cancelled when the restart system overloaded while trying to restart a few thousand regions around the same time. Some reported that RC regions were also being restarted during the deployment attempt, which may have contributed to the problem – although this has yet to be confirmed as being the case by the Lab.

Once the cause of the problem has been diagnosed, the deployment will be re-tried, although Oz Linden indicated this may not be before the usual Tuesday deployment in week #46.

There is no planned deployment to the RC channels on Wednesday, November 8th, 2017.

SL Viewer

The Wolfpack RC viewer which was functionally identical to the release viewer, but included additional back-end logging, was withdrawn from the Alternate Viewers page at the start of week #45. Otherwise, the viewer pipelines remain as for the end of week #44:

  • Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Alex Ivy 64-bit viewer, version 5.1.0.510354, November 2 (still dated Sept 5 on the wiki page).
    • Maintenance RC viewer, version 5.0.9.329707 October 31.
    • Voice RC viewer, version 5.0.8.328552, October 20 (still dated Sept 1 on the wiki page).
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

New Premium Benefit

On Tuesday, November 7th, 2017, Linden Lab announced their new Premium benefit: a 90-day transaction history – read more here and here.

2017 Viewer release summaries week 44

Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, November 5th

This summary is published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.

Official LL Viewers

  • Current Release version 5.0.8.329115, dated September 22nd, promoted October 13th – formerly the “Moonshine” Maintenance RC – no change.
  • Release channel cohorts (notes on manually installing RC viewer versions):
    • Alex Ivy RC viewer updated to version 5.1.0.510354 on November 2nd (still dated Sept 5th on wiki page).
    • Maintenance RC viewer, version 5.0.9.329707 October 31st.
  • Project viewers:
    • No updates.

LL Viewer Resources

Third-party Viewers

V5-style

V1-style

  • No updates.

Mobile / Other Clients

  • No updates.
  • Lumiya removed from TPV Directory, but still in development.

Additional TPV Resources

Related Links

SL project updates 44/2: TPV Developer meeting

The updated official viewer splash screen for general users (i.e. not first-time log-in)

The following notes are taken from the TPV Developer meeting held on Friday, November 3rd 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.

SL Viewer

The Voice RC viewer has one remaining significant bug, which causes some of those on the Windows version of the viewer to connect to the wrong voice channel, which is preventing this viewer progressing further.

The 64-bit Alex Ivy RC viewer updated to version 5.1.0.510354 on November 2nd, 2017. Overall, this viewer is described as doing “really well”, although there are still crash issues with it. These are most noticeable with people on 32-bit Windows systems (those on 64-bit versions of Windows running the 64-bit version of the viewer are experiencing far fewer crashes).

The latest update should correct issues with the viewer’s updater, and it is likely more users will be added to the RC cohort usage pool before this viewer is promoted to release status.

Work is once again proceeding with the 360-snapshot viewer, with improvements to image quality and processing speed, and a new update should be appearing soon. The Lab is also working on a new means to upload 360 snapshots from the viewer to SL Place pages.

Inventory UDP Messaging

Work has started in deprecating all UDP inventory messaging. This is not progressing “super fast”, as it is being progressed alongside other work, and the projected end date is some time “fairly soon” after the end-of-year holidays, when back-end support for the UDP messaging will be turned off. This means that any active viewers still using the UDP inventory handling routes should be making the move to HTTP.

No Change Windows

With the end-of-year holiday season approaching, the Lab is looking at dates for no change windows – periods when they will not be making and simulator or viewer releases, and would prefer to see TPVs do the same.

The first of these periods will be the US Thanksgiving holiday period, when a no change period is liable to be enforced from Wednesday, November 22nd, with the all-clear on Monday, November 27th (subject to formal confirmation).  The Christmas no change window is still TBD, but will likely be from at least Friday, December 22nd through until shortly after the new year.

Other Items

Resource Usage tools

Chalice Yao has proposed a feature to the Firestorm team to allow users better understand the resources they are using, both through their avatar’s VRAM usage and the VRAM, triangles and vertices for any selected object (see FIRE-21793). As the Lab is currently working on amending how rendering cost calculations, a more detailed discussion on these ideas has been tabled for the next TPV Developer meeting, on Friday, November 17th.

Firestorm Release

The next Firestorm release has been delayed of late, but recently entered beta testing, with the aim of it appearing before the end of the year. When it arrives, I’ll have me usual overview of significant updates, but Beq Janus recently blogged about a couple of updates she has contributed to the release, and the Lab have indicated their own interest in possibly adopting the updates, if contributed.

Second Life Minimum System Requirements

It has been noted that the specified minimum system requirements for Second life may be out-of-date (see BUG-139301), and this may be exacerbated with the Alex Ivy viewer. It’s likely that the specifications will be looked at again.

SL project updates 44/1: server, viewer

Pandora Resort; Inara Pey, October 2017, on FlickrPandora Resortblog post

Server Deployments for Week #44

As always, please refer to the server release thread for updates and the latest news.

  • There was no deployment or restart for the Main (SLS) channel on Tuesday, October 31st
  • leaving it on package #17.10.06.509394.
  • On Wednesday, November 1st, the RC channels should be updated with a new server maintenance package, #17.10.25.510119, comprising internal fixes – notes still to be posted at the time of writing.

SL Viewer

The current Maintenance RC viewer updated to version 5.0.9.329707 on Monday, October 30th. All other viewers in the current pipelines remain as per the end of week #43:

  • Current Release version 5.0.8.329115, dated September 22, promoted October 13 – formerly the “Moonshine” Maintenance RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Wolfpack RC viewer,version 5.0.9.329478, dated October 20 – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”
    • Alex Ivy 64-bit viewer, version 5.1.0.508209, dated September 5.
    • Voice RC viewer, version 5.0.8.329250, dated September 1.
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

 

2017 Viewer release summaries week 43

Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, October 29

This summary is published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.

Official LL Viewers

  • Current Release version 5.0.8.329115, dated September 22nd, promoted October 13th – formerly the “Moonshine” Maintenance RC – no change.
  • Release channel cohorts (notes on manually installing RC viewer versions):
    • No updates.
  • Project viewers:
    • No updates.

LL Viewer Resources

Third-party Viewers

V5-style

V1-style

Mobile / Other Clients

Additional TPV Resources

Related Links

SL project updates 43/2: Content Creation User Group

A rally of (Animesh) raptors on Aditi!

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 26th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts are provided to provide additional content. Note that some of the audio extracts have been gathered from various points in the meeting and presented here as a concatenated whole by subject heading for ease of reference.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.

However Animated objects will not (initially):

  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
  • Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

General Status

  • The project viewer is now available, and testing can be carried out on  5 regions (4 Moderate + 1 Adult) on Aditi: Animesh1, Animesh2, Animesh3, Animesh4 and Animesh Adult.
  • Feedback can be offered through the Animesh forum thread, while specific issues, bugs, and / or feature requests related to the project should be made via JIRA.
  • A filter for raised JIRA reports is available.

Root Prim Object

There have been a number of requests to allow Animesh objects to have a non-rigged mesh (e.g. a prim) as the root object. Vir has been working to make this possible. He’s also looking at the issue of non-rigged mesh links in an Animesh object becoming invisible when the Animesh flag is set.

Limits

As has been mentioned numerous times in these updates, Animesh will have some constraints / limits placed upon it in the interests of the capability not unduly impacting performance. For the purposes of test, these have been set at 200LI and a maximum of 20K tri maximum per Animesh object, and only one Animesh can be attached to an avatar at a time. As data is gathered on performance, etc., it is hoped these can be relaxed; however, some creators are requesting limits such as the tri count be raised sooner rather than later. Vir, understandably, would rather wait until more data has been gathered, rather than randomly changing constraints.

There has been a proposal for an alternative method of account put forward with regards to Animesh – BUG-139203.  Vir also reiterated the likelihood that the Animesh limits, once finalised, will have a smaller emphasis on constants such as land impact or the cost of having one attached, and a greater emphasis on the complexity of the Animesh itself (tri count).

Linksets / Permissions Issues

See also Piscine Mackenzie’s forum post on this.

As currently defined, Animesh does not allow for any avatar-like attachment  / detachment of objects (e.g., allowing a pet cat to wear a hat sometimes); the approach is more along the lines that everything that is intended to form the Animesh is attached as the time to object (/linkset) is flagged as Animesh.

This is because adding an avatar-like means of supporting attaching / detaching objects was seen as too high an overhead in terms of development time frames and complexity – although it is not entirely ruled out as a possible future capability.

In the meantime, scripted means to attach / detach items from an Animesh object is possible, but this requires the base Animesh to be modifiable. As detailed in Piscine’s post, and highlighted in the following post from Medhue Simoni, this opens the door to potential exploits / threat vectors (e.g. compromising a supporting ecosystem for pets / breedables to the potential for launching DDOS attacks against the external servers managing pets and breedables).

Vir recognises the issue, and has stated he’ll look into the in more detail. One possible solution has been suggested via feature request BUG-139168, and a possible scripted workaround has also been suggested – although it potentially has its own problems.

An offshoot of this is that it could lead to people including multiple accessories within the Animesh linkset. The problems here being a) doing so would immediately require much higher tri counts per object even after the current 20K limit is raised; b) it will require alpha swapping to hide / reveal different accessories, creating performance hits; c) it will limit the ability for new accessories to be easily added to creations.

Sitting Animesh Objects

Will it be easy to have Animesh sit on other objects (e.g. to have Animesh “mannequins” which could be used with demos of furniture so couples poses could be checked by just one person, etc)? Short answer: not easily. Sitting on objects is avatar-specific, which, among other things, involves re-parenting the avatar to the object it is sitting on, and there is no means to replicate this when trying to “sit” an Animesh (which the server sees and just another in-world object) on another object.

In Brief

  • Lack of Shadows with Animesh objects: this is a know bug, thought to reside within the rendering pipeline, which has yet to be tracked down.
  • Dropping mesh: as noted in my previous CCUG update, by default, mesh attachments cannot be dropped in-world. This means that the only way to currently “pick up” and “put down” an Animesh pet which can roam in-world / be held, is via inventory. Vir has been looking at this, and it is not any easy fix, requiring server-side work (including with physics handling to ensure things land correctly – such as pet on its feet rather than on its side / head) which may preclude it being dealt within the immediate future.


Medhue examines Animesh. Via Medhue Simoni

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

Load testing with the updated server using 1024×1024 textures is in progress. The next phase is liable to be comparing the load test data with that of an existing baking server using 512×512 textures.

Bakes on Mesh and Animesh

Because of the complexities involved with Bakes on Mesh, it is not seen as a dependency for Animesh, as doing so would greatly extended the time frame for delivering Animesh. The Lab would rather implement both incrementally, rather than try to run everything into one huge project.

Environment Enhancement Project (EEP)

Project Summary

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

Current Status

No major change from my previous work. Rider has been working on a simhost issue unrelated to EEP for much of the time.

Final Notes

  • Those requiring access to the JIRA to comment on files issues / request, can send an e-mail request to LetMeIn-at-LindenLab.com.
  • There is no CCUG meeting on Thursday, November 2nd, 2017. The next meeting will be Thursday, November 9th.