Category: SL Tech

The following notes are taken from the TPV Developer meeting held on Friday, February 5th, 2021.

These meetings are generally held every other week.  They are recorded by Pantera Północy, and her video of the meeting is embedded at the end of this report – my thanks to her for allowing me to do so – and it is used with a transcript of the chat log from the meeting and my own audio recording to produce these notes.

SL Viewer News

[0:00-4:10]

The Project Jelly viewer updated to version 6.4.13.555567 on Friday, February 5th. This presumably brings it to parity with the current release viewer code base, and moves it closer to potentially being the next viewer to gain promotion to de facto release status, although no decision has been made on this as yet.

• Current release viewer Dawa Maintenance RC Viewer, version 6.4.12.555248, dated January 25, 2021, promoted February 1st, 2021 – NEW.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Custom Key Mappings project viewer, version 6.4.12.553437, January 7, 2021.
• Project viewers:
  • Love Me Render (LMR) 5 project viewer, version 6.4.12.553511, issued on January 7, 2021.
  • Simple Cache project viewer, version 6.4.11.551403, November 12.
  • Legacy Profiles viewer, version 6.4.11.550519, October 26.
  • Copy / Paste viewer, version 6.3.5.533365, December 9, 2019.
  • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, November 22, 2019.
  • 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.

General Viewer Notes

• With Dawa now at release status, the current RC viewers are being bought up to parity with its code base.
• As noted in my most recent CCUG summary, the Love Me Render (LMR) 5 graphics RC viewer is close to being ready for promotion from project to RC status.
• The simple cache viewer (VFS replacement viewer) is in “decent shape” for promotion to RC status once updated to the Dawa code base.
• There may be further UI work for the Legacy Profile project viewer (returns avatar profiles,etc., back into the viewer, a-la Firestorm) which may delay this viewer from progressing.
• For OS X users, a viewer is in the works that will “get Apple’s notarisations working”. This has been something of a long standing issue, and the viewer should be appearing in the near future.

Project Jelly Viewer

[9:06-11:32]

• This viewer essentially improves the rendering of Jelly Doll avatars.
• The idea behind Jelly Dolls (first introduced in 2015, with various improvements since)  was to give users the means to reduce the load of having to render extremely complex avatars on computers with low hardware specifications by:
  • Explicitly selecting a nearby avatar and set its display value to Do Not Render, reducing them to a simplified, “flat” grey avatar form.
  • And / or setting a “complexity value” within the viewer that, if exceeded by any avatar in the field of view, will render it as a Jelly Doll.
  • Both the grey and the Jelly Doll forms are simplified avatar outlines, with the latter rendered as one of a number of solid colours selected by the viewer from a colour map. The term was coined by user Whirly Fizzle after the British Jelly Babies brand of sugared jelly sweets.
• There have always been a number of issues with the manner in which these avatars are rendered. For example:
  • On the visual side, many users have avoided the viewer’s complexity setting (to the detriment of their viewer’s performance) as they do no like seeing solid, brightly coloured avatar forms in their field of view.
  • On the technical side, the code currently attempts to render all of  avatar’s attachments. As these tend to be the most costly to render, this can defeat he object of the code.
  • Also, the baseline formula for jelly doll calculations doesn’t allow for consistent results.
• As a result, the Project Jelly viewer:
  • Does not attempt to render attachments, but instead renders affected avatars as a simplified, easy-to-render humanoid shape.
  • Render all such avatars in grey, no longer using the previous colour map, in the hope this will encourage more people on lower-end systems to use the capability, as the grey avatar forms tend to be less intrusive within a scene.
• [13:38 via chat] In relation to avatar rendering / Jelly Dolls, it was asked if better global controls for rendering could be provided. In reply, Grumpity indicated that in addressing performance as a whole, such global controls might be considered in the future.

Viewer Log-in Changes

[4:41-8:05]

• Oz Linden is working on the viewer log-in process that are designed to prevent people logging-in to Second Life when their inventory is “broken” (and potentially making their situation worse).
• The updates to the log-in process means there will be additional checking on the status of an avatar inventory data on the back-end as a user logs into Second Life.
  • If errors within the data are found, the log-in process suspended, in order to prevent the errors being propagated to the viewer, and then viewer then exacerbating the situation by trying to manipulate the inventory database further on the basis of the invalid data.
  • Should this happen, the user will receive a massage that explicitly states that log-in has failed as a result of inventory issues with the request the user contacts Support. This message will also provide some specific information the user can pass to Support when they contact them.
  • Support will then use the information supplied to initiate the required corrective action to resolve the issue.
• While this may impede users with inventory problems from logging-in, the hope is that these changes will actually make the resolution of inventory-related issues easier to correct at source and thus have less of an overall impact on affected users.
• This is seen as a priority change, and the Lab hopes to be in a position to have the back-end changes tested and the viewer-side updates available by the end of the month.

In  Brief

• [4:17-4:32] The Lab is making some changes to how deployments are managed within the AWS environment. If done correctly, this work should result in no user-visible changes.
• [11:38-14:11] Post-Uplift issues:
  • There remain some issues still to be fully resolved as a result of the transition to AWS, including (but not necessarily limited to):
    • The problem with Map tile not being generated. This is being addressed.
    • The fact that the chat servers currently need to be restarted more frequently than pre-Uplift. This is still being diagnosed.
    • Teleport failures resulting in an “wrong” or “invalid” region message. This is also being diagnosed.
  • However, the Lab caution against assuming any issue that is encountered is a result of the AWS transition. The general rule remains, if you’re seeing a specific (and preferably reproducible) issue, raise a bug report.
• [14:31-15:33] in response to a question on the avatar skeleton (why 159 bones, but capped at 110 on upload?),  vir pointed out the 110 bone cap is per sub-mesh in a character, rather than on a complete character (which can have several sub-mesh components. The reason for the cap is down to older GPUs that can be used in SL being unable to handle the transform matrices.
• [19:54-20:28] Premium Plus: internal discussions have resumed on the deployment of Premium Plus, but there is nothing to share in terms of time frame, etc., at the moment.
• [21:49-24:15] The recent Marketplace issues are seen as a combination of both the continuing work to improve the Marketplace experience and the work to transition it to AWS.
  • As the MP involves multiple back-end services, there are a lot of interdependencies that can be impacted particularly as a result of the AWS transition work, and not all of these can be accurately QA’d, as the sheer volume of transaction, etc., the MP sees hourly cannot be easily or accurately replicated.
  • The current focus is on general MP stability (including its various dependencies) in order to hopefully make future maintenance and update easier / smoother.
  • The most preferable way to deal with the MP would perhaps be to take the service down entirely for a a period of time and overhaul it, and then re-release it. However, given the impact this would have, it is simply not a viable option.
• [24:42-25:45] Generally speaking, LL believe SL to be a lot more stable / robust now than previously, simply because it is running on much more recent hardware and within an infrastructure where they no longer have to worry about things like hardware that is well beyond its operational life failing, whilst any underpinning hardware / infrastructure issues are more-or-less immediately addressed by AWS. This in itself allows LL’s engineering and ops teams to be more focused on running the software side of things.