The Main (SLS) channel was updated on Tuesday, April 3rd to server release 18#18.03.27.513831, containing internal fixes and updates the new off-line IM and Abuse Report capabilities (see below).
On Wednesday, April 4th, the BlueSteel and LeTigre release candidate channels should receive server maintenance package 18#18.03.29.513939, containing internal fixes; the Magnum RC has no planned deployment, and remains on 18#18.03.27.513831.
SL Viewer
There have been no changes to the viewer pipelines at the start of the week, leaving them as:
Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
Release channel cohorts:
Media Update RC viewer, version 5.1.3.513644, March 27.
Ouzo Maintenance RC, version 5.1.3.513630, March 23.
Love Me Render RC viewer, version 5.1.3.513005, March 2.
Project viewers:
Bakes on Mesh project viewer, version 5.1.3.513936, March 30 (note this version of the viewer does not support applying bakes to mesh bodies / heads).
360 snapshot viewer, version 5.1.3.513006, March 6 (this version can have significant rendering issues, see my hand-on update).
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
Region Crossings
As I’ve reported in recent Simulator User Group meetings, Joe Magarac (animats) working on a scripted workaround to improve region crossings (“partial unsits, etc.) – see BUG-214653. The Lab is also working on crossings on the simulator side. While no time frames for the work were given, Oz Linen did observe, “How successful we’ll be remains to be seen, but we’re optimistic that we can make significant improvements.”
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, April 1st
This summary is generally published on 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.1.2.512803, dated February 23rd, promoted March 1st – formerly the Nalewka Maintenance RC – No Change.
Cool VL Viewer updated as follows: the Stable branch to version 1.26.20.49 and the Experimental version to 1.26.21.16, both on March 31st (release notes).
The majority of these notes are taken from the TPV Developer meeting held on Friday, March 30th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.
The meeting was reduced to under 15 minutes,with minor topics of discussion taking up the latter half. Please refer to the video for these.
Server Deployment Update
The Main (SLS) channel was updated on Tuesday, March 27th, to server release 18#18.03.14.513292, containing the new off-line IM and Abuse Report capabilities (see below).
The Magnum and LeTigre RC channels were updated on Wednesday, March 28th with server maintenance package 18#18.03.27.513831, containing internal fixes and the new off-line IM and Abuse Report capabilities (see below).
The BlueSteel RC was updated on Thursday, March 29th with server maintenance package 18#18.03.27.513838, comprising internal fixes.
SL Viewers
Viewer Pipeline
Note: At the time of the meeting, the viewer had just been approved for issue, but it wasn’t clear if it would be released before or after the Easter weekend. However, it was in fact issued after the meeting – see below.
[00:24-3:02] At the time of the meeting, the viewer pipelines were as follows:
Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
Release channel cohorts:
Ouzo Maintenance RC, version 5.1.3.513630, March 23.
Media Update RC viewer, version 5.1.3.513644, March 27.
Love Me Render RC viewer, version 5.1.3.513005, March 2.
360 snapshot viewer, version 5.1.3.513006, March 6 (this version can have significant rendering issues, see my hand-on update).
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Off-Line and Abuse Reports Capabilities
[0:44-1:36] Two new capabilities are now grid-wide:
The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.
However, both require further revision, and they require viewer-side updates as well. These should be appearing in the next Maintenance RC viewer issued by the Lab.
Bakes on Mesh Project Viewer
The Bakes on Mesh project viewer, version 5.1.3.513936, was released on Friday, March 30th after the TPV Developer meeting had concluded.
From the release notes (link above):
Bakes on Mesh is a new feature to allow system avatar baked textures to be shown on mesh attachments. Currently you will need a special project viewer to use it. Bakes on Mesh does not depend on simulator code, so it should work in all regions and all grids.
Basic features
Any face of a mesh object can be textured using one of the server baked textures.
The corresponding region of the system avatar is hidden if an attached mesh is using a baked texture.
Benefits
Avoid the need for appliers -> easier customization workflow
Avoid the need for onion avatars -> fewer meshes, fewer textures at display time
Avoid the need to sell full-perm meshes. You can customize any mesh you have modify permissions for simply by setting the flags and equipping the appropriate wearables.
Avatar wearables are baked into six different textures (BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR) by the baking service. You can now apply these textures to your avatar’s object attachments’ diffuse texture slot. Right click on the attachment, click edit and from the edit face menu select textures. Click the diffuse texture icon to open up the texture picker. The texture picker has an extra radio button mode called ‘bake’ for selecting server bakes. The ‘bake’ radio button mode has a drop-down for selecting BAKE_HEAD, BAKE_UPPER, BAKE_LOWER, BAKE_EYES, BAKE_SKIRT, BAKE_HAIR server bake textures. When an attachment is using a baked texture, the corresponding base mesh region of the system avatar is hidden.
If a mesh face is set to show a baked texture but is not attached to an avatar, you will see a default baked texture. If you are using an older viewer without bakes on mesh support, then faces set to show baked textures will also display as the default baked texture, and base mesh regions will not be hidden.
Known Issues
Detaching a mesh object that’s using BAKED_HAIR, does not make the base hair region visible. You have to log back in or teleport again. This will be fixed in next release.
The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on Thursday, March 29th, 2018 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.
There is no video to accompany this update, notes are taken from my own audio recording of the meeting.
Animesh Project
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.
Current Progress
Vir now has a proposed revised land impact / tri count formula and test plan for Animesh. This will be going to QA, and if all goes well, the new formulas will be deployed on the Aditi Animesh test regions ready for public testing. No end-date for public testing on Aditi has been defined – the Lab want to ensure as many as are interested have to opportunity to test the new formula. Animesh attachment will remain limited to one per avatar, at least for the time being.
It is likely that server-side support for Animesh will reach the Main grid ahead of the project viewer reaching release candidate status – although this still won’t be for a while.
LODs and Streaming Costs
How Animesh Level of Detail (LOD) is handled is still being tweaked. Currently, Animesh objects sit between in-world objects and avatars in terms of the way their LODs are handled / swapped. The Lab is looking to adjust this, so that Animesh LODs are more consistently handled as they would be for in-world objects.
The broad plan is – for Animesh only – that the lower LODs will not affect streaming costs so long as they are not disproportionately large. Providing they get smaller by at least a factor of approximately 2 as they go down to the courser LODS, they will not impact streaming costs.
Note this work is not part of Project Arctan, which may lead to further changes in costs associated with objects at some point in the future – see below for more.
Project ARCTan
This is the code-name for the project to re-evaluate object and avatar rendering costs (e.g. Land Impact and avatar ARC), led by Graham Linden as a part of the overall rendering system work. The aim of is to have the costs assigned to objects and avatar more accurately reflect the impact they have on people’s viewer performance.
The hope is that overall, by making a careful set of adjustments, not only can client-side performance be improved, but creators can be given positive incentives to build more performant content (a problem currently being that providing good LOD models – high, medium, low and very low – for mesh content can actually penalise a creator in terms of upload costs / Land Impact, encouraging them to skip doing so).
This project is still in the early stages, and the Lab is fully aware of the risks and concerns involved in potentially making changes to things like Land Impact (e.g. undesired object returns), and so are approaching the work cautiously. Right now, data is being gathered and internal comparative testing is being tried. There are no plans to make any kind of changes in the immediate future. When changes do start to be made, they will be done so carefully to avoid disruption, and users will be appraised of what is happening and when.
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.
This work does not include normal or specular map support, as these are not part of the existing baking service.
It is important to note that this project is still in its preliminary stages. Any release of a project viewer doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.
Current Progress
The project viewer is still with QA with a couple of outstanding JIRAs awaiting resolution. The hope is that it will be making a public appearance soon.
When issued, this viewer should work anywhere, as it doesn’t require simulator changes. However, only those using the project viewer will see things as intended. Anyone on a viewer without the Bakes on Mesh updates will see placeholder textures, rather than the intended baked textures, on avatars trying the Bakes on Mesh capability.
Bakes on Mesh will essentially use the three avatar elements used by the baking service – head, upper body, lower body, eyes, hair, skirt), and applies clothing bakes for those elements to specific mesh faces, effectively “hiding” the corresponding base mesh region. This means for example, a head bake can be applied to a mesh head, an upper body to the mesh upper body faces, etc. It does not at this point allow for more finely tuned applications – such as an individual jacket layer, or just to the hands.
Rider is still engaged on infrastructure work, which he hopes to complete Soon TM. Once that is done, he’ll complete the work on assets in inventory.
Custom Pivot Points
Work is being carried out to provide custom pivot points for mesh objects (see BUG-37617). This will most likely appear in a Maintenance RC viewer, once ready. The exactly implementation details weren’t clear at the meeting; it’s believed the data for the pivot point is coming from the corresponding data for the highest LOD in the uploaded .DAE file. However, the pivot point must be inside the bounding box of the object, and remains the centre of the object. Steps will also be taken to prevent pivot points placed outside of the bounding box simply causing the bounding box to increase in size (as did happen in a mesh uploader error), as this tends to both increase the objects LI by a factor of at least 2, and break the associated LODs.
Other Items
Texture Caching
Work continues on trying to improve texture caching in the viewer – which has already been an educational process for the Lab. There is nothing on the horizon yet in terms of updates for the viewer, as the work is not seen as a high priority when compared to other projects. However, there is a belief that there is room for “dramatic improvement” in the way textures are managed.
Permissions System
The question was asked if there are any plans to re-work the Second Life permissions system to be more supply chain driven, as is planned for Sansar. Short answer: there are no current plans to overhaul the permissions system simply because it is so complex. Currently the only thing being considered with permissions is extending them to allow scripted permission changes (formerly known as mod keys), which are seen as important for enhancing Animesh capabilities. However, here are current no time frame in when / if these will be implemented.
Some appear confused by the recent RenderVolumeLODFactor behaviour change (see here) and what it is doing, believing it is part of a change to object LODs in Second Life.
Essentially, the Firestorm update is purely a viewer-side change only, intended to encourage users not to use over-the-top settings in their viewer which can affect performance, because changes to this value are globally applied, affecting all objects within the viewer’s field of view, not just a specific wearable or object.
However, this change does not mark any kind of change to the object’s LOD data held on the servers (the content isn’t being “changed” in any way on the back-end); it purely alters the way content is rendered by the viewer in terms of which LOD model of the object it uses.
Date of Next Meeting
There will be a CCUG meeting on Thursday, April 5th, as the normal LL internal meeting has been postponed a week.
Grumpity and Alexa Linden host the Web User Group monthly meetings at Alexa’s barn
The following notes are taken from the Web User Group meeting held on Wednesday, March 28th, 2017.
These meetings are generally held monthly on Wednesdays, and are chaired by Alexa and Grumpity Linden at Alexa’s barn. The focus is the Lab’s web properties, which include the Second Life website (including the blogs, Destination Guide, Maps, Search, the Knowledge base, etc.), Place Pages, Landing Pages (and join flow for sign-ups), the Marketplace, and so on and the Lab’s own website at lindenlab.com.
Meeting Format
A point to remember with the Web User Group meetings is that they are informal discussions on things like the Marketplace.
While the Lab does give information on the work they are carrying out, plans they have in-hand for updates to web properties, etc., equally, a lot of what is discussed is ideas and the taking of feedback from attendees, and should not necessarily be regarded as statements from the Lab as to what will happen, it priority, or anything else.
Within these reports, I try to indicate those plans / actions / projects that are in progress, and offer a differentiation between “firm” plans and ideas under discussion.
Marketplace
Priority item flagging: under discussion at the Lab is the idea – put forward by Merchants at a previous Web User Group meeting – that “certified” Merchants priority in flagging and the Marketplace reports. This “certification” might be through the payment of a fee.
Survey: the Lab is considering a Marketplace survey in which Merchants can indicate their preferences around possible enhancements, etc., to the Marketplace and perhaps submit and idea of their own.
Feature requests: specific, well thought out idea for new features for the Marketplace (and Second Life in general) can / should be submitted via the Second Life JIRA.
It is preferable that only one idea (or a limited set of related ideas) for new features is submitted per Feature Request submission.
Feature Requests are triaged (reviewed) by the Lab on a weekly basis.
The Feature Request form is accessed via your JIRA dashboard – log-in via your Second Life credentials required. Select Create Issue in the top right of your dashboard to open the default Bug Report form. Then click on the Issue Type drop-down and select New Feature Request to replace the Bug Report form with the Feature Request form.
Marketplace search: the Lab is aware that there are issues with the MP search function, and hope to be able to improve it. However, reporting that search “is broken” is sufficiently helpful. If there are specific instances where search fails to work as expected which can be specifically defined, these need to be reported via a JIRA bug report, with detailed steps so that the Lab can see (and reproduce) the problem, then take steps to address the issues.
Destination Guide
The Destination Guide suffers from a large number of locations listed within it which have ceased to exist in one way or another (the region no longer exists, it has changed hands and been re-purposed; the owner has made it private with access control, etc.).
There is curation of Destination Guide entries, but this is described as inefficient as it doesn’t parse all the DG categories “very frequently”.
There is discussion at the Lab about automating the curation process to help with the removal of outdated locations, but nothing so far is on the road map for implementation.
Further development of Place Pages is planned, with one of the first added features, possibly appearing in the near future, is support for land auctions, offering the same functionality as the current auctions. This will be expanded over time to offer resident-to-auctions.
Name Changes – Further Information
“Original / legacy” last names will not be re-opened for use.
New users joining Second Life will still be given the automatic “last name” of “Resident”, but have the option of changing if they wish.
The fee for name changes has not been announced, however, at this point the indication is that the fee will be in fiat currency (i.e. US dollars) not Linden Dollars.
One of the reasons the return of last names will take time to be implemented is that all of the SL web properties – like the Marketplace – have to be updated to recognise users as they change their names (something which applies across almost all of the SL services when you think about it).
Governance and DMCA
Issues around Governance, the Marketplace and the DMCA process continue to be raised.
Governance User Group?
Often at user-group meetings questions are asked around matters of governance or which may be related to legal / financial issues (e.g. fraud or alleged cases of fraud). All of these matters are overseen by teams outside of the technical personnel who attend the in-world meetings, and so – while it may be frustrating for those raising the questions – cannot comment on or address such issues.
There are discussions at the Lab about holding a Support / Governance user group in the future. There is currently no date as to when this may take place, or whether, if it does, it will be a one-off or one of a series. However, once the dates have been established, it will be announced through channels such as the User Groups wiki page.
DMCA Filing
Currently, the Lab’s Infringement Notification Policy requires that DCMA notices are filed with Linden Lab via mail or fax.In December 2017, it was indicated that this would be revised so that DMCA’s can be filed via an on-line form. The provisional date for implementing this change had been around January / February 2018, however, it has been subject to delay.
Oz and Grumpity Linden indicated the reason the form has yet to be deployed is twofold:
The original version of the form was subject to a change in requirements, and so had to be re-worked.
The submission process has to be robust enough to prevent abuse (e.g. repeated multiple filings from an individual on the same issue);has to have checks in place to ensure the submitter’s credentials can be verified; and has to meet the requirements for non-Second Life users to be able to file a meaningful DMCA notice (e.g. in the case of an external company finding copies of their copyrighted material is being sold unlicensed through Second Life).
It is hoped that form will be available in the near future.
The Main (SLS) channel was updated on Tuesday, March 27th, to server release 18#18.03.14.513292, containing the new server capabilities (see below).
At the time of writing, the Release Candidate channels were all TBD regarding potential deployments. This report will be updated if the deployment thread provides further information on the RC channels.
New Capabilities
The new capabilities in 18#18.03.14.513292 for the Main (SLS) channel is the first part of a set of server and viewer updates.
The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.
Updates to the viewer incorporating these changes will be made available by the lab in the near future.
SL Viewer
The Maintenance RC viewer updated to version 5.1.3.513630 on Friday, March 23rd.
The Media Update RC viewer updated to version 5.1.3.513644, on Tuesday, March 27th.
The remainder of the pipeline remains as:
Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
Release channel cohorts:
Love Me Render RC viewer, version 5.1.3.513005, March 2.
360 snapshot viewer, version 5.1.3.513006, March 6 (this version can have significant rendering issues, see my hand-on update).
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
In Brief
First Name / Last Name Changes
This is still a long way off from being implemented, however, Oz Linden confirmed llDetectedName() will return the current name for an avatar, no matter what the change. However, it may take some time for it to change everywhere due to caches.
Simon Linden is looking into the Second Life messaging layer, which may be the problem behind a lot of “lag” issues. “There’s actually a number of small improvements I want to make, but I’m being careful to do them one at a time and have real data showing it gets better,” he said in providing an update on the work.
Friendship Offers Failing
Some are experiencing Friendship offers failing, even when the offer is accepted – see BUG-215977. According to Simon Linden, this might require a server-side update to fully correct.
Part of the issue, a previously noted, is viewer / simulator communications. If these are suffering latency or packet loss, then things can get rough with vehicle region crossing very quickly. This is something Joe has been trying to compensate for by introducing a script that turns off physics and freezes the vehicle when received by a new region until it can confirm the associated avatar data has arrived.
Unfortunately, excising the viewer from region crossing data handling would be difficult, as it has to be involved to move and change its primary connection for an avatar. It would take a major protocol change to remove the viewer from the region crossing loop and separate connection hand-off from crossings. Further, if such a protocol change were to be made, it would require more work to support both new and old until enough viewers get updated.
Mainland Price Restructuring
While the Lab does not issue numbers, Oz Linden indicated at the Simulator User Group meeting that since the Mainland Price Restructuring, “mainland ownership is up quite significantly.”
Inara Pey: Living in a Modemworld 