Category: SL User Group Meetings

2024 week #51: SL CCUG & TPV meeting summaries

Posted on by Inara Pey
Ashemi, October 2024 – blog post †
The following notes were taken from:

  • My chat log of the Content Creation User Group (CCUG) meeting of Thursday, December 19th, 2024.
  • My chat log  of the Third Party Viewer Developer’s Meeting (TPVD) of Friday, December 20th, 2024.

Please note that this is not a full transcript, but a summary of key topics. .
Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
  • The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
  • Dates and times of both meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.

Official Viewer Status

    • Release viewer: version 7.1.11.12363455226, formerly the ExtraFPS RC (multiple performance fixes, aesthetic improvements and UI optimisations), dated December 17, promoted December 20 – NEW.
    • Release Candidate: none at present.

ExtraFPS Notes and Rendering – Both Meetings

ExtraFPS Notes

  • The majority of legacy (non-PBR) skies should now look “extremely close” (if not “spot on”) to how they looked prior to the initial PBR release:
    • This is in part due to the default for the RenderSkyAutoAdjustLegacy debug setting being changed to False, which means that legacy skies should render close to the “pre-PBR” look, whilst leaving PBR skies unchanged.
      • This change in the default (from True to False) has caused some confusion among those using the Firestorm ExtraFPS beta versions, as they have been mistakenly switching the default back to True. This should not be done.
    • Tone Mapping is no longer applied the legacy skies, which should help eliminate legacy environments looking too bright / dark.
    • There is a chance that some legacy skies may have been missed, so the request is for those on non-PBR viewer to give ExtraFPS a try and check their preferred legacy skies, just in case. Issues should be reported via the feedback portal – including any noted issue with transitions when moving between different EEP settings.
  • Ambient lighting should be generally improved and “much more consistent” with pre-PBR viewers.
  • Exposure has been reset to 1.0.
  • As a part of the performance options for lower-specification machines, there is now an options to disable HDR rendering and emissives (single check box).
    • This should be automatically unchecked for those running on very low-spec systems (e.g. those running with Intel HD graphics), but those on lower-spec machines might want to check.
  • It terms of overall performance on older hardware types, LL believe theta in the “vast majority” of cases, ExtraFPS runs on a par with FPS rates seen on pre-PBR viewers.
  • Absent from ExtraFPS is the updated alpha/linear/exponential (aka alpha/gamma) settings. This is awaiting decisions around matter of permissions to allow people to apply the changes to legacy content they might own but for which they may not have the required permissions. The hope is to have this in an future viewer as an update.

General Rendering Comments and Feedback

  • The PBR deployment has made LL particularly aware that significant changes which may impact viewer performance need to be monitored far more on a case-by-case basis in terms of older hardware types (graphics cards / types, etc.), rather than looking at across-the-board averages.
    • As has been previously mentioned in CCUG meetings (and elsewhere), this has led to the graphics and viewer teams spending time pulling together older hardware and cards to build what has been unofficially dubbed the Potato Farm, so that changes can be tested against specific older hardware known to be popular among SL users.
  • The Graphics Team acknowledge Linden Water still “doesn’t look anywhere near as good as it should”, and is part of a series of legacy consistency issues they are still addressing.
    • In particular, Geenz Linden noted that Screen Space Reflection (SSR) is “in need of improvement”, but LL just have not had the cycles available to work on it. He has ideas on how things can be improved without having to uproot everything, and hopes that there may be an opportunity to work on them in 2025.
    • One suggestion was to place a glTF transmission texture on Linden Water to help resolve problems. However, this doesn’t appear to be an option due to Linden Water rendering being “kind of incompatible” with the glTF materials specification.
    • Bringing back water reflections to a point where they matched pre-PBR water reflections is seen is expensive in terms of performance, ergo while improvements will be made, they are unlikely to offer the same level of real-time reflections as seen “pre-PBR”.
  • Firestorm ExtraFPS Beta: Firestorm have been iterating on a beta version of their viewer incorporating the ExtraFPS updates. However:
    • Geenz Linden noted that there are some “broken things” in the Firestorm ExtraFPS beta which are leading to some “very noticeable differences” between it and the official ExtraFPS. He is currently working with the Firestorm team to try to correct these issues.
    • The environment doesn’t always change over to the local shared environment on a region crossing (physical or teleport), together with ambient reflection probes getting discarded and rebuilt as a Day Cycle advances to the next preset (keyframe). This is not something the Lab’s graphic’s tam have noted on their viewer; if it can be reproduced on the official ExtraFPS release, bug reports would be appreciated.
  • It has been noted that cube reflection probes do not affect water (although spherical probes do appear to affect water). It’s not clear if this is an unintended breakage as a result of various testing (e.g. with water reflections) or intended (as those in a position to address this question are out of the office on holiday breaks).
  • Tone Mapping:
    • Tone mapping is a highly subjective area – what looks good to one person might not appeal to another.
    • Because of this, and without changing defaults beyond what have been set within the ExtraFPS viewer – the Lab is seeking to provide choice by making options available (e.g. the Khronos Neutral Tone Mapper as well as ACES), and through options to adjust tone mapping (which will eventually be including in the Sky Settings floater), enabling people to make choices for themselves.
  • To assist with manging environment-related settings, Geenz Linden hopes to move things to enable asset versioning for sky / water assets, thus allowing for easier maintaining of legacy code paths when required, which in turn should help with avoiding some of the issues seen with the likes of sky settings in the move to PBR / glTF.
  • Requests:
    • Allow arbitrary meshes to be used as reflection probes. Whilst this could help with fitting probes into difficult spaces (e.g. within cave tunnels), arbitrary mesh shapes as probes are not seen as particularly performant, particularly WRT lower specification systems.
    • Allow blending on reflection probes so that neighbouring / overlapping probes offer smoother transitioning (such as at the entrance to a cave or tunnel or an entrance into a darker interior. In theory this could be done.
    • Provide a new means to “hide” Linden Water from the interior of boats, etc., in a manner similar to using invisiprims under the (now defunct) Forward Renderer. Unfortunately there is no easy means of providing occlusion volumes for Linden Water to replace invisiprims in this use.
  • A lot of questions on PBR Materials which really boiled down to the need for more informative documentation / FAQs / tutorials.

TPVD Meeting

The Lab Using TPVs

  • A long standing policy at the Lab is that staff and contractors have been required to only use the official viewer, and that bugs reported to the Lab need to be reported using the official viewer.
  • In recognition of the widespread use of TPVs – notably, but not exclusively, Firestorm – this policy is now changing.
  • The Lab has already taken steps to implement the ability to build Firestorm internally and with the necessary security options in place to make it “safe” for use by Linden personnel and contractors.
We’re all using Firestorm more … so we can be helpful if need be on integration work and stuff like that with Firestorm. There were security changes in general to allow Lindens to log-in to any third-party viewer, but we’re definitely changing to respect that Firestorm in particular comprises almost all active use of Second Life today and we’ve got to do everything we can to make sure it’s working first, even before our own viewer.

– Philip Rosedale, TPVD Meeting, Friday December 20th, 2024

  • This does not mean that the Lab is adopting Firestorm or taking any form of control over it (or any other TPV); the Firestorm team remains in control of their viewer,  and the roadmap and plans for it. Rather, the aim is to provide assistance for Firestorm and other TPVS where it is needed.
  • Right now for Firestorm, this assistance – as noted above – is focused on evaluating the ExtraFPS code and performance updates for inclusion in Firestorm as quickly as possible.

The Viewer Structure and Open-Source Development

  • The above led to Philip expanding on some of the issues which have arisen due to the way in which the viewer was coded and opened out as a open-source project.
Looking all the way back to 2005, which is when I think we open-sourced the viewer, we didn’t have the team then – nor do we have it now – to properly separate the viewer into into a bunch of modular components that could connect to each other and have plug-ins attached to them in a way that Chrome does. I think that coming back now and being the CTO and looking at what’s going on, one of the elephants in the room is that the structure of the code doesn’t support extensions and plug-ins in the way that would make sense for a properly-run open-source project. I say that without a specific solution in mind, I’m just recognising it. 

– Philip Rosedale, TPVD Meeting, Friday December 20th, 2024

  • Because of the approach taken, the viewer code has become “a plate of spaghetti”, with third-parties developers able to open the code up and make changes then deem necessary at any point in the code.
  • This has been further exacerbated by the lack of overall documentation for the viewer that might be constructively used by developers internally and externally to the to the Lab to understand the viewer code – a point that is again acknowledged.
  • Ideas for trying to make the viewer code more modular are being looked at, but no decisions  – much less a roadmap – for starting to do so have yet been reached.
    • As both Philip Rosedale and Vir Linden noted, the fact that there has been 15-20 years of open-source viewer development, with TPVs (and the Lab) picking their own paths does make doing so “tricky”.
    • One possible avenue being considered here is trying to separate the viewer UI more from the underlying rendering engine, potentially making updates to either less intrusive either way.
  • An additional goal of the work currently being carried out to support Firestorm with ExtraFPS is to try to ensure the code in question can be more easily pulled-in by other TPVs as well.

General Discussion Points

  • Web development:
    • The Marketplace is written on Ruby on Rails, communicating with a SQL running on Redis, an infrastructure which is making it hard to chase down query optimisation problems.
    • As a result, there is a likelihood that some engineering support is going to be pivoted towards SL’s web properties and infrastructure, which may result in work in the viewer / server areas slowing down.
  • Open positions at LL:
    • Time was taken in discussing current (at the time of the meeting) open positions at LL – server developer, Mobile developer and senior product manager.
    • This touched on some of the upcoming features coming to Mobile – such as the Lobby capability due to surface in SL Mobile during Q1 2025 (see: Second Life Blogger Town Hall, December 2024: Mobile, marketing and more).
    • Specifically, there was a request for any Second Life developers / users who have the requisite skills for the posts and who might be looking for a career change (or who know someone who does / is) to considering applying / pointing people to the Lab’s careers page.
    • In addition, Philip noted, in line with the above web development, the Lab is seeking expertise in Ruby on Rails development (preferably with SQL experience as well) – although this is not currently advertised on the LL careers page. Anyone who has / knows of such experience can contact him – preferably via e-mail.

Next Meetings

 

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2024 SL SUG meetings week #51 summary

Posted on by Inara Pey
Dominae Templum Doloris, October 2024 – blog post

The following notes were taken from the Tuesday, December 17th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from Pantera’s video of the meeting, which is embedded at the end – my thanks to her for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, December 17th, 2024, the simulators on the Main SLS channel were restarted with no update.
  • On Wednesday, December 18th, the servers on the RC channels should be restarted without any deployments being made.

With the holiday period starting in a week, the engineering team will be making a call in the next day or so on whether to run re-starts over the holiday period or not.

SL Viewer Updates

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.12363455226, December 17.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

In Brief

Please refer to the video below for the following:

  • A discussion on llGetObjectDetails, together with llGOD() or using a rezzer to check for an object’s presence, and potential confusion which can potentially arise, and the potential benefit in using llGetOwnerKey.
    • This sparked ideas for additional functions / parameter for check on objects with regions / parcels – e.g.: llDoesExist() with parameters IN_REGION, IN_PARCEL and IN_OWNERS_PARCEL.
  • A request was made for an update on the server-side lua implementation project, and information on challenges encountered. This prompted Rider Linden to respond:
The project is moving forward, but it is a pretty complex undertaking and we need to move forward cautiously. Remember, we’re trying to swap the VM out from under 20 years worth of scripts… in place and on the fly.

– Rider Linden

  • The above led to a further discussion on Lua some of which can be addressed via the Lua FAQ, although one of the the easiest to answer (“Why replace Mono”?) is perhaps best answered by the observation that the Mono version SL is running is old, and Mono itself is becoming seemingly frozen in time.  This discussion wound through the rest of the meeting.
  • The Lua / Mono exchange segued into a discussion on region performance slowing as avatars enter, together with anecdotal reports of an increase in region crossings timing-out and people being logged-out as a result.
    • Monty Linden again noted the issue of avatars entering regions is being looked at, and requested that reports be filed (including locations and times) when these issues are noted.
    • To help, he has opened a report to which people can append their information via comments.
    • In terms of avatars entering regions and slowing things, he added: “Note that the recent avatar work makes entering *worse* for the offending avatar, better for those already in-region.”
  • Testing llTransferOwnership has shown the function generates two confirmatory message: after opting to Accept whatever is being offered by the in-world object, recipients are hit with the messages similar to “an object owned by somebody gave you a thing”, followed by “you are now the owner of a thing. [ OK ] “.
    • The duplication of messages is in known issue, and due in part to the viewer automatically generating the first message as soon as the Accept button is pressed, whereas the second message comes from the server.
    • The implication appears to be that the viewer message will be addressed, as it can be misleading.
  • An issue has been reported (and reproduced) relating to llGetEnvironment (+ related functions) returning inaccurate unit vectors for Sun / Moon position. There is some potential disagreement as to what is being seen / where the issue might reside, but it is being looked into.

Date of Next Meeting

  • Tuesday, January 7th, 2025.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2024 SL SUG meetings week #50 summary

Posted on by Inara Pey
Burrow Coffee Co,, October 2024 – blog post

The following notes were taken from the Tuesday, December 10th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from Pantera’s video of the meeting, which is embedded at the end – my thanks to her for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, December 10th, 2024, the simulators on the Main SLS channel were restarted with no update.
  • On Wednesday, December 11th,the RC channels will also be restarted. The planned deployment of the Apple Cobbler update to BlueSteel has been postponed for a week to allow further QA testing.

SL Viewer Updates

No updates to start the week with the current official viewers:

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.12150664210, December 5.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

In Brief

Please refer to the video below for the following:

  • A forum thread concerning “elephants in the room” in terms of SL’s “immersion breakers”. As is pointed out in the thread, what may be a “elephant” to some might not be so much so to others. Nevertheless, as Soft Linden also points out, there are lots of issues long-term users of SL have learned to “eat around,” but using the thread to highlight issues which could impact matters of retention, etc., could be useful.
  • A discussion on an LSL function for text rendering based around this feature request (or should that be “feature suggestion”, given Signal Linden filed it?! The discussion also touches on the possible use of markdown and other alternatives and the use of Media on a Prim.
  • A discussion on the upcoming llTransferOwnership function and possible issues.
  • This spun out to a wider discussion on LSL functions, including an idea for a function called he calls “llTempWearFromInventory”:
[It] would allow you to put on a wearable from an object’s inventory, but I’ve never gotten a lot of traction to get it done. The idea was to get rid of alpha cuts on bodies by allowing mesh clothing to have it’s own alpha layer that gets applied when it is worn. On the attach from inventory, I might take the approach of it rezzes the item and attaches it as a single LSL function.

– Rider Linden

Again, this is an idea, not a function actually being worked upon. However, it sparked a conversation on the subject of alpha masking / alpha cuts, etc., with clothing.

  • Rider Linden also offered a FYI – there is an LSL call coming that will allow a script to set terrain textures at the estate level.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.

2024 week #49: SL CCUG summary

Posted on by Inara Pey
DREAMS, October 2024 – blog post †
The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, December 5th, 2024.
Table of Contents

The session was livestreamed by Strawberry Linden, and her video is embedded at the end of this article. Timestamps are provided to the relevant points in the video for ease of reference.

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
  • Meeting dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewer Status

[Video: 1:49-4:03]

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.12150664210, December 5. This focuses on performance improvements for lower-specification / old viewer hardware and includes:
    • Enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • [Video 4:12-6:23]:
      • A new checkbox to disable HDR-  this will improve performance for lower-spec machines but will see some of the “banding” previously seen in things like skies – and PBR emissive. These may be split into two separate checkboxes to allow one or the other to be disabled / kept.
      • A pass on “legacy” skies (e.g. those in the Library and / or which have no been converted from PBR skies) will look much as they did on pre-PBR viewer. This is described as the “least bad” option to address issues.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.
  • It is hoped that the December 5th RC version of ExtraFPS will be the version that will be promoted to de facto release status soon.

Near-Term Viewer Release Roadmap

  • There is additional work going on around performance that isn’t seen as urgently enough to delay the release of ExtraFPS, so there may be a “hotfix” viewer release to handle some of these, if required. Some of this additional work could take the form of:
    • Improvements to avatar loading, work which it was noted at the SUG meeting that Monty Linden had recently been tasked with looking at.
    • [Video: 6:38-6:55] Further texture streaming improvements (if these do not make it into ExtraFPS prior to promotion), which prevent the viewer repeatedly loading redundant textures.
  • The work in combining the “pre-performance work” Maintenance B and  Maintenance C RC viewer codes into a single RC update is continuing.  However, exactly what will be in it and when it is likely to appear as an RC viewer is still TBD.

General Discussion

  • [Text only] It was noted that some are seeing the texture bias tends to get stuck at high values in ExtraFPS, and failing to unstick until the viewer is restarted. This has been acknowledged by LL, but so far  they have been unable to consistently repro it. SLurls of regions where it frequently occurs have been request (feedback portal).
  • [Video: 12:08-14:45] a request to have settings in the viewer to allow users to set their own loading / rendering priorities depending on what they are doing, such as “near avatar”, or “near camera”, “avatars”, “rezzed items” , etc.
    • For example, while most use cases might be biased towards “near camera”, there might be situations where such as landing in very busy environments where “avatars” might be a preferable priority, so as to avoid shoving other avatars around when trying to move because they cannot be seen. Conversely, when cam-shopping, the priority is liable to be camera+ objects, with loading other avatars a much lower priority.
    • This was seen as having potential (allowing for the viewer and simulator carrying out different roles in scene loading: – the simulator sends the basic data of where things are and whatever meshes and textures are associated with them, but the viewer decides for itself what it is actually going to fetch (from the CDN) and when), but the current focus of work, per above, is on simply getting avatars + their attachments to simply load faster.
  • [Video: 16:19-18:43] Texture repeats / offsets reset on an object if the PBR material is changed: a bug report was requested on this. It was also noted that editing an alpha to opaque not holding has also been reported.
  • [Video: 17:38-18:31] Linux viewer status: the Linux work is defined as being in the “big bundle of stuff” which originally formed the Maint B and Maint C viewer code branches, which is in the process of being combined into a a single viewer under the Github Develop branch. As such, its progress and disposition is tied to this work, and while their are builds within the Github Actions, they are not in a condition for general release.
  • [Video: 18:47-21:33] A request to be able to crate new folders in Inventory from the Recent tab (or have newly-created empty folders at least appear on the Recent tab).
    • This was seen as a reasonable feature request submission.
    • A request was also made to be able to purge Trash from the Recent tab – however, given the Trash only shows items added in the current log-in session; purging all of Trash from Recent could have unintended consequences (e.g. an item previously and unintentionally dropped in to Trash gets mistakenly purged on account of it not showing in Trash under Recent).
    • It was also pointed out that opening an additional Inventory floater (CTRL-SHIFT-I) can help with issues of moving items around, rather than solely relying on one floater and its tabs.
  • [Video: 22:00-24:32] Add a checkbox to the Build / Edit floater – Select Only My Objects, rather than having to go through the Build → Options menu to set it:
    •  A problem here is the Edit / Build floater is already overcrowded, and the Build menu can be torn-off when editing / creating (although this can obviously impact screen real estate when open with the Edit / Build floater).
    • Simply enlarging the Edit / Build floater to accommodate additional options is also seen as a problem, again due to the added screen real estate taken up, particularly for those using lower-resolution screens.
  • [Video: 24:38-31:03] Ability to designate folders on upload on-the-fly:
    • Rather than having a single set of folders defined for uploads of specific types (e.g. a set folder for images, a set folder for sounds, a set folder for objects, etc), allow users to define which folder they wish to use for a specific upload  / number of uploads via  a drop-down, which can then become the default until next changed.
    • This is seen as advantageous to content creators, etc., as it would allow them to upload different asset types by “project” (so all mesh items, animations, sounds , etc., for “Project X” go to the “Project X” folder, for example).
    • A feature request was requested for this, with the added not that the current work on the viewer is not focused on adding to the UI, so it may be a while before such requests are reviewed & potentially actioned.
    • [Whilst not precisely the same, a similar request has been made regarding the upcoming llGiveInventory function, so that rather than having receiving  folders simply defined by the object giving them, recipients can select the folder into which they can receive the incoming items].
  • [Video 26:57-48:14] & intertwined with the above bullet point] Various discussions on hiding the current outfit folder, avatar customisation, etc., which were more general in nature and of a more historic / subjective nature than covering potential changes / improvements.  This also touched on avatar creation in Sansar, the use of devkits / applications (such as Marvelous Designer) etc.  This also bled into a re-hash of oft-raised issues around the new user experience, the use of Senra vs. the continuance of the Creator Avatar option in the viewer (which references the older starter avatars), which has no connection to Senra, etc. Please refer to the video.
  • [Video 51:18-53:47] The above led to a question (from LL) about the provision of a “private changing room” for people to be able to change their appearance anywhere in SL without being seen.
    • A similar capability was provided in Sansar, where altering the avatar’s appearance happened in a editor “outside” of the current scene, with the avatar returned to the scene post-update.
    • The idea has been the subject of requests for Second Life as well, being tied to the Appearance Editor; as such it is on the Lab’s radar for possible future implementation.
    • [Video: 55:45-End] In terms of implementation, one option under consideration is the re-cloud the avatar to other viewers whilst the avatar is having its appearance edited. An alternative would be to impostor the avatar to others.
  • [Video: 53:48-54:50] A reiteration that LL do plan on integrating RLV/a into the official viewer (code contributions from kitty Barnett for RLVa have been received, together (I believe) with input from Marine Kelley on RLV).
    • However, it was emphasised that this is a large project requiring significant code contributions / integration, so the work in regarded as in progress.
    • Because of the stigma associated with RLV/a (e.g. the “restrained” element of the title), it was suggested a rebranding might be in order.

Next Meeting

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.

December 2024 SL Web User Group summary

Posted on by Inara Pey
The Web User Group meeting venue, Denby
The following notes cover the key points from the Web User Group (WUG) meeting, held on Wednesday December 4th, 2024. They form a summary of the items discussed and is not intended to be a full transcript. A video of the meeting, recorded by Pantera Północy, is embedded at the end of this summary – my thanks as always to Pantera for recording it and making it available. Table of Contents

Meeting Overview

  • The Web User Group exists to provide an opportunity for discussion on Second Life web properties and their related functionalities / features. This includes, but is not limited to: the Marketplace, pages surfaced through the secondlife.com dashboard; the available portals (land, support, etc), the forums.
  • As a rule, these meetings are conducted:
    • On the first Wednesday of the month and 14:00 SLT.
    • In both Voice and text.
    • At this location.
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

General Update

[Video: 1:59-3:59 and 6:18-8:45]

  • Marketplace UI: work on updating the marketplace with a new user interface is described as being in the final stages of internal testing and thus “very close”.
  • Second Life Dashboard (secondlife.com): this is also being updated to a new design, and there is a chance it may be deployed in the next month / during January 2025.
  • Web Log-in and Multi-Factor Authentication (MFA): this is ongoing work to update the Second Life web log-in splash screen to a new design which will will work better on all devices, and will support MFA.
  • Marketplace MFA: work is continuing on adding MFA to the Marketplace.
  • Also in the works:
    • Changes to Linden Home store, adding some UI updates.
    • Updating the Second Life web maps – described as “still in early design”. Some of this work was mentioned in the November meeting – also see below.

Single Sign-On

  • [Video: 5:28-5:58] The subject of single sign-on (SSO) – allowing a user to log-in with a single ID to several related but independent services (e.g. SL dashboard, the Marketplace, (possibly) the viewer, etc.), just once (and possibly with unified authentication factors) Has often bee requested  – and looked at – by the Lab. In response to SSO being raised at this meeting, Sntax Linden responded:
SO and Federated login is something we have been looking at doing in the future. The MFA on web login and marketplace will just be reusing the existing MFA we have on viewer and mobile.

Gifting Marketplace Items

[Video: 7:09-8:45 and 11:44-24:06]

  • This has been discussed at past meetings. Gifting is seen as confusing for some (having the Add to Cart as Gift and Buy Now buttons so close together suggests Buy Now must be clicked when gifting); plus the Shopping Cart is often used as a means of storing things people might be interested in purchasing, but as gifting is tied to it, carts must be cleared of anything stored therein.
  • As such, requests have been made for a direct means of gifting items in a manner similar to the Buy Now button (e.g. an “Gift Now”) button.
  • Commenting on this,  Juniper Linden said:
We do have some updates to the gift UI coming out soon-ish; minor changes to that flow that might be better but nothing like “gift now”
  • Sntax indicated the MP team will get to gifting as soon as they can.
  • The basic requirement for this was seen as a simple button within listings, per above.
    • However, maintaining the ability to still add gifts to the cart as an option was also seen as useful – so having the “Gift Now” button present the current steps for gifting (enter recipient’s name + an optional message) followed by options to send the gift directly or add it to the Shopping Cart was seen as the optimal solution.
  • The main pressure from the meeting was to have some form of “band-aid” solution for direct gifting, and then refine things after-the-fact. This was seen as the preferable course of action.
  • This conversation also spiralled into use of legacy (user) names over Display Names and mis-gifting people.

Second Life Web Maps

[Video: 28:09-54:59]

  • As noted above, LL are looking at updating the Second Life web maps (https://maps.secondlife.com/), and to this end, a series of questions were asked on the functionality they provide:
    • Do people use the web maps or just the in-viewer World Map. Probably fair to say the if a broad audience were asking, there would be a reasonable split between “viewer” and “both”.
    • Is the Create Your Own SLurl option in the viewer World Map a useful option?
    • Do people use the Destination Guide element of the web maps to find places?
    • Do people use the Search option on web maps?
A Second Life web map (https://maps.secondlife.com/) showing: 1. the Create Your Own Map Link option (opens a dialogue box), 2. search bar option and 3. the  Picks Destination Guide 
  • That those at the meeting assumed that these questions were focused on the viewer’s World Map (with ensuing confusion as to the Search and Destination Guide questions) is possibly indicative as to how often the web maps are directly used (although eight people at a meeting is far too small a sample from which to draw meaningful conclusions).
  • Web Maps are frequently used, however – and possibly without people realising they are a map system – when clicking on SLurls included in things like blog posts, etc., in order to locate and teleport to the region / location in question.
  • The above spread to a discussion on sharing SLurls and how people go about it (including the misconception that the viewer World Map does not allow for the copying / creation of SLurl, despite the large button at the bottom of the Map legend).
  • A request was made for possible information to be added to the SL maps. Replies focused on the viewer World Map and included:
    • A “show rez zones” option.
    • A “show Set Home locations” option to help new users to find regions where they can set their home position.
    • Ability to find out more about  location via the map. Fore example, clicking on a location on map.scondlife.com gives a default dialogue (which LL have stated will be updated to actually reflect the region information) – having this available for regions / parcels on the viewer World Map was suggested (on a mouse-over hover?).
    • Whether or not a location is open to public teleporting  / a user’s ability to teleport (e.g.  whether there is a minimum age set for access, or access is controlled by having Payment Information on File).

General Discussion

  • The last 10 minutes of the meeting focused on issues around links to outdated videos on web properties such as Where Next? the Support portal, etc., and the potential negative impact they have on new users / incoming new users.

Next Meeting

  • Wednesday, January 8th, 2025.

2024 SL SUG meetings week #49 summary

Posted on by Inara Pey
Soulstone, October 2024 – blog post

The following notes were taken from the Tuesday, December 3rd, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from Pantera’s video of the meeting, which is embedded at the end – my thanks to her for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, December 3rd, 2024, the simulators on the Main SLS channel were updated to release 2024-11-25.12013542687.
  • On Wednesday, December 4th:
    • The BlueSteel RC is due to be restarted with no deployment.
    • The remaining RC channels will see a “small” update to the Barbeque (BBQ) updates, presumably bringing them to parity with the version of BBQ currently on BlueSteel.

Upcoming Simulator Releases

Apple Cobbler currently remains in testing on Aditi (regions of Mauve and Jigglypuff for those wishing to test), but is now due to start an initial deployment to the BlueSteel RC in week #50 (commencing Monday, December 9thm, 2024). Apple Cobbler includes:

  • llTransferOwnership which enables a prim give itself to a new user (subject to owner permissions already set). The version on Aditi has been updated. To quote Rider Linden:
The prototype for llTransferOwnership has changed slightly. There is a new list parameter tacked to end. It does nothing at the moment, but I’ve got plans to add a few things there early in the New Year. The wiki has been updates with the new data. You will need to recompile any test scripts you might have had. [Also]  For llTransferOwnership, I’d like to add an exclusion list (transfer the item and all its contents EXCEPT for these items).  
  • An extended llGiveInventory to allow for a destination folder (system folders + RLV/a) to be specified as well (+ the use of a parameter list, so further options can be added in the future).
  • llMapBeacon – like llMapDestination, but a) does not necessarily open the map window; b) can optionally open the map, with or without focus. This will also require a viewer update.
  • A new function for detecting attachments. If it is running with an experience it will be able to detect HUDs that also have scripts with the same experience (e.g. to ensure the correct HUDs are being used – this will not allow anyone to script to find out all the HUDs someone is using).

Following Apple Cobbler, the next simulator update is code-named Banana Bread, but its contents have yet to be defined. However Rider Linden conducted a quick poll on what those at the meeting might like to see included. – please refer to the video (29:48-35:32).

SL Viewer Updates

No updates to start the week with the current official viewers:

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.12041172537, November 27.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

2K Bakes On Mesh (BOM)

Pepper Linden provided this update:

We were hoping to get 2K BOM out by the end of November [as] its been stuck in QA a while now. Unfortunately, an issue came up recently where the viewer wasn’t properly showing the lower resolutions for avatars that weren’t close up (e.g. far away). So a fix had to be made on the viewer for that (we were seeing VRMA use double for highly complex avatars with dozens upon dozens of wearables). 
There’s a few other minor things that came up, but they should all be addressed very soon [but] unfortunately I have no idea when 2K BOM will make its way here at this time, though as soon as I know, I’ll be sure to let everyone know.

In Brief

Please refer to the video below for the following:

  • Leviathan Linden implemented a fix to llModPow(), noting the older implementation was inefficient and that with the update, it should now run faster under the hood.
    • It was noted the one second sleep requirement made the function fairly unusable, and Leviathan noted it could now be relaxed, and will aim to do that as a part of the Banana Bread simulator update.
  • Further discussion on  llTransferOwnership().
  • A general discussion on Combat 2.0 updates.
  • A note that Monty Linden has been put on to poking at why avatars take time to load / de-cloud.
  • A discussion on media support and Media on a Prim (MOAP) / CEF.

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.