Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates from the week through to Sunday, November 6th, 2022
This summary is generally 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.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Official LL Viewers
Release viewer: version 6.6.7.576223 – MFA and TOS hotfix viewer – November 1 – NEW.
Release channel cohorts::
VS 2022 release candidate (uses Visual Studio in the Windows build tool chain), version 6.6.8.576310, issued November 4.
Maintenance P (Preferences, Position and Paste) RC viewer updated to version 6.6.8.576321, November 3rd.
Project viewers:
glTF / PBR Materials project viewer, version 7.0.0.576331, issued November 3rd.
This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
Are usually chaired by Reed Linden, who is the Lab’s Product Manager for the Second Life front-end web properties (Marketplace, secondlife.com, the sign-up pages, the Lab’s corporate pages, etc.).
A video of the meeting, courtesy of Pantera, can be found embedded at the end of this article (my thanks to her as always!), and subject timestamps to the relevant points in the video are provided. Again, the following is a summary of key topics / discussions, not a full transcript of everything mentioned.
All of the currently planned updates are complete and are awaiting the opportunity to “turn them all on”. This will likely happen (with an announcement) ahead of US Thanksgiving, 2022.
Some of the noted updates include:
Merchant and store names will no long be searched in product searches.
Searches for exact matches (using quotation marks around search descriptors) has been added.
Wildcard (e.g. using *) will be possible.
The back-end supports fuzzy matching to better handle typos when inputting searches.
There should be a noticeable increase in speed of search results being returned.
Once running, these updates will allow LL to add-in the relevance engine AI to the Marketplace search (as a separate API entity to the relevance engine already running on the web search).
Work will resume on Marketplace Styles (allowing multiple colours, etc., for an item to appear within a single listing rather than each requiring its own listing) as soon as the MP Search updates are officially enabled.
It is hoped this capability will be available towards year-end.
It will obviously be up to merchants as to whether they use it to group variances in a product within a single listing or continue to list them separately – single listings for multiple versions of an item will not be mandatory.
A complete re-write of every route by which users can obtain and hold land, from Premium (+Plus) Linden Homes, obtaining Mainland (incl. Abandoned Land), and private island regions, and renting from private estates.
The first element of the land work to be user-facing will be the new Land Portal, a central hub from which to get to all aspects of land “ownership”.
Overall, this work is not liable to be surfaced much before the end of 2022.
When it does, it should be looked upon as a template / proof of concept for overhauling the rest of the Second Life web properties to give them a coherent appearance; make it easier to maintain existing web portals and pages and to add new ones; make SL’s web presence more performant overall and ensure it works on mobile devices as well as desktops / laptops.
The new subscription option is to be called simply (if possibly confusingly) “Plus”.
This is designed to sit between Basic and Premium.
Its core intent is to unlock the ability to hold land on the Mainland, although it will have a modest stipend associated with it + a small bump in the number of allowed Groups.
Pricing is subject to the formal announcement that Plus is available, which is anticipated as being by the end of November.
It is hoped that once available and given time to determine how it performs / users respond to Plus, that further subscription levels – which may possibly include an “a-la carte” option – can be defined and added to the selection.
Premium Plus (and Premium) to be Renamed in the future?
It was suggested that the new subscription level would be better named “Basic Plus” – something that was not dismissed by Reed as an informal means of referencing it.
However, the Lab is apparently considering single-word names for all current and future subscription offerings, and Reed indicated that if this is the case, then Premium Plus is likely to be renamed at some point in the future, and this renaming might extend to Premium as well.
In Brief
It is hoped that a future Marketplace update will allow store owners to have access to search metrics for their items (e.g. which items are being popularly searched / purchased, etc.). However, this is not part of the Search updates described above.
The web properties updates will likely include improvements to the web version of the World Map. However, what these changes may be & which they might be implemented is very much still TBD.
Web profiles will not be entirely shut down for as long as the profile Feed remains popular with users – this is the one element of Web Profiles that has not been moved back into the viewer (and appears unlikely to do so).
It has been noted that if a user has the Profile Feed set to Private, the new Legacy Profile viewer code shows a broken version of their web profile in the Web tab.
For all other discussion points, please refer to the video below.
Next Meeting
Wednesday, December 7th, 2022. Venue and time per top of this summary.
Clair View Ruins and caves, The Realm of Rosehaven, September 2022 – blog post
The following notes were taken from the Tuesday, November 1st, 2022 Simulator User Group (SUG) meeting. They form a summary of the items discussed and is not intended to be a full transcript. A video of the entire meeting is embedded at the end of the article for those wishing to review the meeting in full – my thanks to Pantera for recording it.
On Tuesday, November 1st, the Main SLS and Events channels were restarted without any simulator update being deployed leaving them on simulator version 575585.
On Wednesday, November 2nd. simhosts on the RC channels will be updated with simulator release 576126, comprising the new Linkset Data capability (see below for more).
Available Official Viewers
No changes to the current set of official viewers at the start o the week, leaving the list as:
Release viewer: version 6.6.5.575749 – formerly the Maintenance M RC viewer – promoted October 26.
Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
Project viewers:
Puppetry project viewer, version 6.6.3.575529, issued on October 12.
Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.
Linkset Data (LSD)
Linkset Data is a new collection of script functions and one optional event that reads and writes key-value-pairs to a small 64kb table of data that is part of a root object.
It works similarly to Experience Key-Value store, but:
It does not require an underpinning experience – the data lives with the object that sends and receives the data.
Only scripts in the same linkset will be able to read the data written with this feature.
Important Note for the initial deployment:
Like all scripts containing new LSL functions, scripts running LinksetData* calls will only run on regions running version 2022-10-27.576126 or newer (so only the RC channels to start with).
However unlike some other functions if you move an object containing Linkset Data (or teleport wearing an object containing Linkset Data) from a region that supports the capability to a region that does not support it, all Linkset Data stored with the object will be lost, even if you go back to a region that supports the feature.
This limitation will no longer exist once the back-end support for the capability has been deployed to all regions on the Main grid.
llLinkPlaySound and Associated Functions
llLinkPlaySound together with llLinkStopSound llLinkAdjustSoundVolume and llLinkSoundRange are new LSL functions that are described as “coming soon”, and which allow sounds in child prims of a linkset to be played without the need for a supporting script.
Additional related functions might be considered if subject to a Jira feature request.
This is something that has been requested by content creators (particular vehicle creators) for a good number of years.
Flags included will be SOUND_LOOP, SOUND_PLAY, SOUND_SYNCH and SOUND_TRIGGER, and will be used to replace the llPlay/Loop functions.
Other sound restrictions within linkset remain unchanged.
The announcement spurred an extended discussion on the SL sound system as a whole (including pre-loading sounds), as well as options for the new functions, through the first two-thirds of the meeting – please refer to the video.
I’ll have more on the link sounds functions as and when LL have documentation on them and are ready to start deploying them.
In Brief
For a full (and maintained!) list of LSL functions, please refer to the official wiki page LSL_Functions.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates from the week through to Sunday, October 30th, 2022
This summary is generally 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.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Official LL Viewers
Release viewer: version 6.6.5.575749 – formerly the Maintenance M RC viewer – promoted October 26.
The following notes were taken from Pantera’s video recording of the Third-Party Viewer Developer (TPVD) meeting held on Friday, Third-Party Viewer Development meeting held on Friday, October 28th, 2022 at 13:00 SLT. My thanks to her for recording it, and it can be found at the end of this article. Times stamps to the video are included where relevant in the following notes. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.
This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.
The Maintenance (N)omayo Hotfix viewer was promoted to de facto release viewer on Wednesday, October 26th, 2022.
This is an urgent fix for transparency “alpha” blending issues. In cases of many layers of textures that included transparencies, this would cause some of the lower layers to not render at all. There are no other functional changes.
The rest of the current crop of official viewers remains as:
Release channel cohorts:
Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
Project viewers:
Puppetry project viewer, version 6.6.3.575529, issued on October 12.
Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.
General Viewer Notes
The Performance Floater project viewer (which includes UI updates and the Lab’s new Auto-FPS feature) has been undergoing a lot of work to reconcile the Lab’s auto-FPS work with that of Firestorm is still expected to appear as a RC viewer Soon.
The Windows viewer built using Visual Stood 2022 is now awaiting its debut as a RC viewer, also expected Soon.
Github Changeover and Streamlining the Code Contributions Process
As previously announced, there is an initiative to improve continuous update integration in the viewer and improve the viewer deployment process.
For TPVs and developers, the most visible aspect of this is moving the viewer repositories from BitBucket to Github. This includes the viewer code base and the other public code bases currently in BitBucket (Autobuild, LLCA, etc.).
There is still no firm date as to when the actual switch-over to using the new repositories will occur, but the viewer development team is working steadily towards it, and the plan remains to provide plenty of advanced warning to TPVs on when LL plan to cut over to the new repositories before making a clean cut-over.
Code Contributions Process
Alongside of this work, Linden Lab would like to streamline the current open-source code contribution process for the viewer. Under consideration for this are:
Simplifying the language within the contributor licence agreement (CLA) from the current version to something very much like this Github preview (top level here) – which has the backing of the Lab’s legal department.
Automating the acceptance / signing process, potentially by implementing a new pull process for contributions such that:
If the contributor has not signed the CLA, the request will be flagged as requiring a CLA and the contributor will receive a request to review and sign the new CLA using a bot process (possibly this one).
Once the CLA has been signed, the flag is cleared, the pull request is accepted, and the contributor’s details are securely recorded as having signed the agreement so there is no further need for them to review / sign the agreement on subsequent pull requests.
Note: as this will be a new CLA process with revised wording in the agreement, anyone who has previously signed a CLA with the Lab will also be required to sign via the new process the first time they submit a pull request.
The work is being led by Signal Linden, who has requested that anyone who contributes code to LL for the viewer contact him with any questions / concerns they may have with the proposed approach / language in the revised CLA.
Documentation on the new approach will be provided once the process has been finalised and is ready to be introduced.
At the time of the TPVD meeting, the deployment – the simhost RC channels – looks set to go ahead in week #44.
Additional notes:
A JIRA feature request has already been submitted asking for Linkset Data to be viewable through the viewer, and this will likely be added at some point in the future.
There will be an article on the significance of this change appearing in this blog following the RC deployment.
Issues have emerged in messaging between the viewer in which materials are being manipulated and the simulator, and between the simulator and other viewers (so everyone is seeing the same thing), together with colour matching issues. These are currently being looked at by Runitai Linden.
The hope is that once these issues have been cleared, the viewer code should be in “pretty good order” for a formal project viewer to be made available for “open alpha testing” by all who wish to test the capability and offer feedback.
As with the “closed alpha” versions of the viewer, this will only work on the simulators on Aditi (the Beta grid) which have been updated with the PBR back-end support.
During the entire “alpha test” period on Aditi, LL reserves the right to completely wipe the test regions & desynchronise any viewers using them (to force viewer updates as bug are fixed / changes are made), so it is important the regions are only used for testing.
Once LL is confident with the back-end support and the stability of the viewer, then the simulator code will be extended to all of Aditi.
Once there is high confidence that the asset format will not have to change, the permissions system is being respected and there are no security issues, then deployment on Agni (the Main grid) will commence.
As per my week #42 CCUG meeting summary, there are concerns about reflection probes being used incorrectly / causing issues, particularly in the case of objects using their own reflection probes being sold as No Modify.
In summary:
Because the use of reflection probes is arcane and there is no guarantee those trying to employ them will do so “properly” – that is, creators will start adding them to all of their in-world products because they “look good”.
The issue here is, when all such products are put in one setting – such as a room – they effectively “compete” with one another, demanding viewer resources (whereas a single reflection probe within the room would do the same without being resource-heavy).
The above isn’t a problem where goods are sold with Modify permissions (allowing the user to make adjustments), but has been seen as potential problematic in the case of No Modify items sold with a reflection probe.
Therefore, the suggestion has been made to have reflection probes (and also lighting sources, which suffer a similar problem) mutable via check boxes within the build floater’s Features tab, so that users can disable what they see as unnecessary object-related probes and lighting within their scenes, even for No Modify items.
The general feedback during the week #42 CCUG meeting leaned towards this being viewed positively – although no conclusion was drawn; the idea was also looked upon with favour at this meeting.
In terms of disabling lighting, Runitai noted that disabling Full Bright would not be a part of making reflection probes / lighting sources mutable, as Full Bright has its own complexities.
This lead to a discussion on the pitfalls of Full Bright objects within scenes, breaking the visual fidelity of a setting (in the eyes of the observer) and the need to offer those viewing them a degree of control to eliminate them from their world-view, issues of how to control at the parcel level & the additional problem of dealing with avatar-attached Full Bright objects (although muting the avatar wearing the objects should eliminate this issue). Please refer to the video for specifics.
Removal of Forward Rendering and Possible Project Impact
As per past CCUG meeting summaries, LL had planned to disable all forward (non-ALM) rendering from the viewer with the release of the PBR Materials viewer.
Due to feedback voicing concern of this move, LL now plan:
To use November for further viewer rendering optimisation in order to try to ensure deferred (i.e. ALM enabled) rendering offers decent frame rates on as broad a selection of client hardware using SL as can be reasonably accounted.
At the end of this period of optimisation, a final decision will be made on whether or not to push ahead with disabling forward rendering or to maintain it.
If the decision is in favour of keeping forward rendering, then:
This will “almost certainly delay the release of the PBR Materials viewer”.
Should forward rendering be maintained, it will not have any PBR support going forward, and the Forward renderer itself would likely be changed so it is more like Forward+, and less like OpenGL Fixed Function.
In Brief
[Video 15:33-20:16 – via text] with the promotion of the official Legacy Profiles viewer, LL removed the means for uses to update their Profile pictures via the web feeds. This led to some upset among TPV users as the latter merged and released the code, as no forewarning of the change was given by LL for TPVs to pass on to their users. LL has noted the issue & will attempt to ensure clarification of such changes is given in advance in future.
[Video 28:04-37:37] a discussion on the merits (or otherwise) of trying to decrease the number of deltas between LL’s core viewer code and TPVs code bases in order to make merges and general code modification easier, particularly with core functionality.
This included a somewhat lengthy discussion on trying to standardise the use of things likes spaces and tabs in code headers, etc. (LL tend towards spaces and will likely continue to do so, at least some TPVs use tabs), and how best to achieve this – a discussion to be carried forward via the open source developers mailing list for discussion.
It was also noted that some of the deltas are the result of LL tending towards trying to keep the viewer “simple” to make it easier for newer users, and some TPVs trying to fulfil the needs of more established users by offering functions and capabilities LL have tended to retain as debug settings or turn down (if contributed), which can give rise to additional divergences in code, complicating merges – no definitive decisions were reached, and I refer readers to the video for the full context of the discussions.
[Video: 39:59-40:40] LL’s offices will be closed for the Christmas / holiday period from Friday, December 23rd through to start of business on January 2nd, 2023. This means week #52 of 2022 will be designated a No Change period without simulator official viewer releases, and a request the TPVs avoid releases that week. The US Thanksgiving No Change window is still TBA.
The last part of the meeting formed a general discussion on rendering, graphics, LL’s commitment to older hardware in common use as far as possible. Please refer to the video for the discussion; however key points might be:
LL are not looking to “raise” the minimum specifications for minimum hardware required to run SL.
Rather, that are looking to revise the specifications to indicate what APIs are required in order to run SL (e.g.: Graphics: OpenGL 3.x (minimum); OpenGL 4.x (recommended).
The PBR Materials viewer will see OpenGL 2.x deprecated. However, it is estimated that less that 0.5% of Windows systems which use OpenGL 2 (OpenGL 4 has been available for more than a decade), and this is likely to be the result of a failure to update or the fact the hardware is being used by a bot service, rather than in any inability for it to support OpenGL 3 or later.
A reminder that Window 8.1 officially reaches end-of-life with Microsoft on January 10th, 2023, as so after that date will be regarded as no longer supported by LL.
Puppetry demonstration via Linden Lab – see below. Demos video with the LL comment “We have some basic things working with a webcam and Second Life but there’s more to do before it’s as animated as we want.”
The following notes have been taken from chat logs and audio recording of the Thursday, October 27th Puppetry Project meetings held at the Castelet Puppetry Theatre on Aditi. These meetings are generally held on alternate weeks to the Content Creation User Group (CCUG), on same day / time (Thursdays at 13:00 SLT).
Notes in these summaries are not intended to be a full transcript of every meeting, but to highlight project progress / major topics of discussion.
Project Summary
Previously referred to as “avatar expressiveness”, Puppetry is intended to provide a means by which avatars can mimic physical world actions by their owners (e.g. head, hand, arm movements) through tools such as a webcam and using technologies like inverse kinematics (IK) and the LLSD Event API Plug-in (LEAP) system.
Note that facial expressions and finger movements are not currently enabled.
Most movement is in the 2D plain (e.g., hand movements from side-to-side but not forward / back), due to limitations with things like depth of field tracking through a webcam, which has yet to be addressed.
The back-end support for the capability is only available on Aditi (the Beta grid) and within the following regions: Bunraku, Marionette, and Castelet.
Puppetry requires the use of a dedicated viewer, the Project Puppetry viewer, available through the official Second Life Alternate Viewers page.
No other special needs beyond the project viewer are required to “see” Puppetry animations. However, to use the capability to animate your own avatar and broadcast the results, requires additional work – refer to the links below.
There is now a Puppetry Discord channel – those wishing to join it should contact members of LL’s puppetry team, e.g. Aura Linden, Simon Linden, Rider Linden, Leviathan Linden (not a full list of names at this time – my apologies to those involved whom I have missed).
Bugs, Feature Requests and Code Submissions
For those experimenting with Puppetry, Jiras (bug reports / fixes or feature requests) should be filed with “[Puppetry]” at the start of the Jira title.
All of this work will include the ability to move the pelvis and the new Puppetry LEAP API, but will not include the ability to clear a Puppetry joint setting.
OpenXR Support
Leviathan Linden asked for feedback on what the requested “OpenXR support” mean to those requesting it – e.g.: Is it to run an OpenXR app and have a VR experience in SL, or is it to run an OpenXR app as a plug-in to provide measurement input to Puppetry?
The general response was a mix of both:
To generally provide the means for “proper” hardware support for motion capture such that puppetry isn’t just a “best guess” response via a webcam
To allow for more accurate interactions between avatars and objects; eventually moving to provide full support for VR headsets and controllers (requiring the ability to intact with scripted devices, operating levers, controls, etc., which could be correctly interpreted and acted upon by said scripts).
Currently, LL are more willing to consider OpenXR support as a part of the Puppetry work whilst regarding it as a potential step towards wider VR support in SL in the future.
Avatar Constraints / Interactions
The above question led to a broader discussion on avatar-to-avatar and avatar-to-object interactions starting with the avatar constraints / collision system.
As they are right now, avatar constraints and collisions within SL have been adequate for the platform, but lacking (collisions, for example have no concept of the avatars arms / legs, limiting interactions with them and other objects).
OPEN-368 “[Puppetry] [LEAP]: Location Constraints” is a feature request outlining the benefits of overhauling the SL avatar constraints system to allow better interactions with objects, etc. This is currently open to those wishing to add further comments and feedback.
The question was raised as to how “fast” / reliable the required communications (including all the required bone interactions) could be made in order to ensure adequate / accurate response times with actions (e.g..so when shaking hands, he hands of each avatar arrive at the same point at the seem time to be seen as shaking in both viewers).
Also discussed was determining how “reactions” might best be defined – could it be as “simple” a pre-set animation?
One issue with this – interactions, OPEN-368, etc., – is that direct hooks from Puppetry to LSL had been seen as outside the scope of the project, simply because puppetry and the LEAP API are entirely viewer-side, and LSL simulator-side. However, the discussion opened a debate on whether some means for this interaction should be provided, with two options being put forward:
Broadening the LEAP protocol, essentially using it to make the viewer scriptable with plug-ins that run on their own threads.
Providing a specific LSL function that would enable LSL to be able to communicate / interact with the LEAP protocol / JSON (as is the case with the RLV / RLVa APIs used by some third-party viewers).
Both of these approaches were seen as potentially “doable”, if beyond the intended scope of the puppetry project.
A further issue with interactions and bone tracking (which would be required for accurate avatar-based interactions) as that bone tracking via LSL is as best limited to non-existent; this raised the subject of possibly using attachment points as a proxy.
An additional problem here is whether or not is possible to track the location of the attachment points in 3D space relative to any animation the avatar is playing (e.g. if an animation causes the avatar to raise their arm, is it possible to check the position of the wrist point)? This is currently something of an unknown, as it would either:
Require the simulator to inject a lot of additional calculations for joint and attach positions;
Or require a new (optional) protocol where the viewer would just supply its in-world positions at some frame rate – which would require some calculation overhead on the part of the viewer;
Or – given work is in-hand to add the in world camera position relative the viewer, and also the avatar’s world orientation and look at target – provide a straight dump of the animation mixdown together with the skeleton data, enabling the processing to be carried out in a module rather than the viewer.
As a result of these discussions, time has been requested to investigate the various options (which will likely include a determination of what, if anything is to be included in the current project in terms of these additional capabilities).
Inara Pey: Living in a Modemworld 