2020 SL project updates week #16: TPVD summary

Little World, February 2020 – blog post

The following notes are taken from the TPV Developer meeting held on Friday, April 17th, 2020. These meetings are generally held every other week, unless otherwise noted in any given summary. The embedded video is provided to Pantera – my thanks to her for recording and providing it. Time stamps are included with the notes will open the video at the point(s) where a specific topic is discussed.

The latter part of this meeting as largely general text chat related to group chat issues – please refer to the video, if required.

SL Viewer News


  • As per my week #16 CCUG meeting notes, the EEP RC viewer updated to version on Wednesday, April 15th.
  • If no issues are found with this version of the viewer, it will likely be promoted to de facto release status in week #17 (commencing Monday, April 20th).

The remainder of the official views currently in progress remained unchanged through the week as:

  • Current Release version  version, dated March 12, promoted March 18th. Formerly the Premium RC viewer – No change.
  • Release channel cohorts:
    • Camera Presets RC viewer, version March 25.
    • Love Me Render (LMR) RC viewer, version, March 25.
    • Zirbenz Maintenance RC viewer, version, issued March 19.
  • Project viewers:
    • Copy / Paste viewer, version, December 9, 2019.
    • Project Muscadine (Animesh follow-on) project viewer, version, November 22, 2019.
    • Legacy Profiles viewer, version, September 17, 2019. Covers the re-integration of Viewer Profiles.
    • 360 Snapshot project viewer, version, July 16, 2019.

General Viewer Notes

  • EEP is expected to be promoted “early” in week #17. By close of business Friday, the viewer had around 1/3 of the preferred number of users hours LL look to have before determining on a viewer’s promotion.
    • This viewer should allow personal environment settings applied to an avatar to persist across log-ins. However, if this is used with custom settings, there is a risk the viewer will crash on logging-in; a fix for this will follow the viewer’s release.
  • The order of promotion for the remaining RC viewers still TBD.
    • It had been indicated that the LMR RC would not follow behind EEP in the order of promotions, as the Lab did not want to have two sets of rendering updates going out almost back-to-back to one another (allowing for the 2-week gap between release promotions). However, from comments made at the CCUG and the TPVD meetings, LMR may be the next to be promoted after EEP.
    • However, all of the current RC viewers appear to be in good shape and ready for promotion over the next 1-2 months.
  • The Camera Presets RC viewer is currently suffering from around an issue a week cropping up that is preventing it being declared as fit for promotion.
  • The mesh upload updates viewer is expected to appear in project viewer form soon, but could rapidly move to RC status once available.
  • Another viewer due to appear is the build tools viewer (using the updated tool chain with VS 2017  / a more recent version of Xcode). This currently has a couple of significant crash issues that are to be resolved, but once available might also go through a short cycle to achieve release status.
  • Once the build tools viewer is out, there are plans to upload the viewer’s Chrome Embedded Framework (CEF) for media handling, that should result in improvements to handling more (and more recent) video codecs.

In Brief

  • [11:18-16:10] Names Changes
    • Currently causes a breakage in the viewer’s ability to handle chat logs and settings (e.g. if you have a log of “user XY” who changes their name to “user XZ”, the viewer cannot reconcile the two names and give you the complete chat history using both names). There is currently no viewer-side change being implemented to auto-update chat logs should someone change their user name. But if this becomes an issues, LL will consider doing so – although a contributed patch would be most welcome.
    • Despite the US $40 fee, name changes have proven popular, as has been noted by the Lab and by Firestorm (who have received a lot of support calls over it). Oz noted in particularly that the initial demand has gone higher than the more optimistic forecasts by LL.
    • Scripted support for finding and listing the past names of and avatar will not be supported.
    • It was suggested by user Anastasia Horngold that Premium members should be able to pay the fee to change the name of the alt accounts without having to upgrade said accounts to Premium as well – and it has been suggested that the idea be submitted as a feature request.
  • [18:23-20:03] Could the viewer have a separate rendering distance for shadows (e.g. so a user can have draw distance set to 200m, but can set the maximum distance for rendering shadows to (say) 20m), to reduce the processing load on their system?
    • Would need to be tested for potential performance boost, but could be worth considering. Again, a feature request has been requested.
    • An ancillary suggestion to this would be to tie shadow rendering to an object’s LOD settings so shadows are only rendered on the high and medium models.
    • It was also suggested a simple general cap on the distance from the camera at which shadows are rendered might also help with performance.
  • [30:50-33:05] Could terrain drawing be decoupled from object drawing, so aviators, etc., have a “long” terrain draw set so they can see the land ahead, but without the load of object data transmission / rendering? LL is not well-disposed to setting relatively “long” drawing ranges (e.g. 512m or greater), as this ends up putting extra update load on all the simulators on which an avatar could have a child agent.
  • [36:57-39:24 + beyond in text chat] Chat lag: the increase in user concurrency has resulted in some strain on the group chat services, particularly those handling very large groups – however, the issue is not a common across-the-board issue with all groups.
    • It is believed the issues of failing group chat message delivery is down to an issue with a single group chat server that has a couple of “spectacularly large” groups running on it, which at present cannot be relocated (efforts focused on cloud uplift). LL is investigating to see if something else can be done to alleviate the problem.
    • It is hoped that transitioning group chat services to the cloud will help improve general performance, but it is likely that specific issues such as group loads will require algorithmic changes to the code itself.