January 2025 SL Web User Group summary

The Web User Group meeting venue, Denby
The following notes cover the key points from the Web User Group (WUG) meeting, held on Wednesday January 8th, 2025. 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: 0:40-3:40 and 7:36-8:20]

  • Pre-Holiday Marketplace issues:
    • There were some outages and slow delivery times on the Marketplace in the run-up to the holidays.
    • Due to these problems, store holders were unable to see the view count on their Top Selling Products report, as it was not reporting correctly. This has now been corrected, and the view count is once more reporting correctly, and will not be removed from the report.
    • The underlying causes of all of these issues should now be fixed. Anyone experiencing continued problems WRT them should file a ticket.
  • Decimal point values manifesting on L$ amounts: users noted that places such as the Marketplace cashier page started displaying decimal point valves on L$ amounts (e.g. L$50.98). This was not intentional, and should now be corrected. Again, anyone still seeing it should file a ticket.
  • Related Items Display on MP listings: an issue with Related Items not displaying correctly on Marketplace project listings has been fixed and related items should all display correctly, even when resizing the browser window smaller.
  • [Video: 7:36-8:20] Featured News Blog feed:  the Feature News blog widget on the default viewer log-in screen (“Linden News” on Firestorm) is currently broken.
Broken blog feed widget on the default log-in splash screen for the viewer
    • This may also be causing Featured News failing to display on the dashboard (which might display something like Grid Status instead).
    • LL are working to correct this problem.

Web Properties Refresh

[Video: 3:47-6:08]

  • The pages at community.secondlife.com have been refreshed as a part of the overall drive to update the appearance of the various pages / sites.
The refreshed community.secondlife.com pages / portal
    • Four page themes are offered on refreshed pages: Light Classic, Light New, Dark Classic, and Dark New (the default). These can be selected via the Themes drop-down link at the foot of refreshed pages:
Options for switching Second Life refreshed page themes
      • Issues have been reported when displaying Knowledge Base articles in the new layout (not clear if this is in general or specific to the Dark mode(s)), and LL are working to rectify these issues.
      • Again, if anyone notes specific issues with page displays in any of the themes, please file a ticket.
    • Updated, January 9th: Similar work in planned for the dashboard (secondlife.com), although at the time of writing, this has yet to be surfaced – although Sntax Linden indicated it was “very close to being deployed”. The initial Dashboard refresh has been deployed.
The initial dashboard refresh (secondlife.com) was deployed shortly after this summary was published. Currently, there is no option to change themes
  • Within secondlife.com, the What Next? section (top menu bar and https://secondlife.com/my/whatnext/) is also to be significantly updated, as much of it is very dated in content. However, the time frame for this surfacing is still TBD.

Project Zero (Viewer Streamed to a Browser)

[Video: 33:00-48:22]

  • For background (if you need it!) see: Second Life in your browser: a new initiative from Linden Lab).
  • Sntax Linden indicated that this can also be a subject for discussion at WUG meetings (he is on of those leading the work), although it may evolve into having its own user group in the future.
  • Overall response appears positive, although some appear to have pain points – notably with multi-factor authentication causing problems in loading the viewer. This was thought to have been fixed, but still appears to be an issue.
  • The time limit for Project Zero has now been increased to 1 hour per session (from 10 minutes).
The viewer-in-a-browsers website, showing increased time limit (as of January 9th, 2025)
  • Reasons as to why people might not use the services (currently still free) given at the meeting included:
    • Inability to: save viewer Preferences; perform uploads; save chat IM logs, etc.
    • Lack of Firestorm support.
    • No in-built (client-side) AO for avatars.
    • Most of the above are on the roadmap – see my article in the link at the top of this section – although TPV support is dependent on TPVs being willing to engage in the project as it continues to be developed.
  • There have been reports of zero.secondlife.com not working on Brave (Chrome derived browser) which were thought to have been fixed; however Brave still hangs without loading the viewer (the same is true for Gener8, Vivaldi and Epic, all of which, like Brave, are heavy on privacy browsing).
  • Note that from the 48 minute point onwards, this conversation devolves in discussions on food.

In Brief

  • A further discussion on https://maps.secondlife.com/ following that of the December 2024 meeting, this focused on the search function and how it arrives at its results, given they do not appear to be region / parcel based.
    • This segued into a wider discussion of map searches and sources used, accuracy of returns, preferred means of searching for places (e.g. SL search – then use the Map link in the relevant result, or use Maps (in-world or web), etc.
    • As a part of the more general search comments, it was suggested that when users have Maturity ratings set (e.g. only G or only M), search indicated that results are limited due to the set rating.

Next Meeting

  • Wednesday, February 5th, 2025.

2025 week #2: SL SUG meeting summary

Omerta Island, November 2024 – blog post

The following notes were taken from the Tuesday,  January 7th, 2025 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, January 7th, 2025, the simulators on the Main SLS channel were restarted with no update.
  • On Wednesday, January 8th:
    • The BlueSteel RC should be updated with the Apple Cobbler simulator update, which includes: llGetAttachedListFiltered(),llGiveAgentInventory(),llMapBeacon(),llTransferOwnership(), and a modification to llModPow, so it should work faster (however, it does not correctly handle the full range of positive 31-bit integers -and Leviathan Linden is working to define the range for which it supplies correct answers, so check the wiki page for updates).
    • The remaining simulators on the RC channels are to be restarted without any update.

SL Viewer Updates

  • 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 – No Change.
  • Release Candidate: none at present.

In Brief

Please refer to the video below for the following:

  • A discussion on llSetAgentRot and extending it, with Rider Linden noting:
I left the API open to be able to use any rot. Unfortunately there are a lot of assumptions in both the simulator and the viewer about the agent only rotating around Z. Changing that is going to be a much larger project.
  • Questions were asked on improving the quality of Linden Water effects and reflections. Such questions are best dealt with via the Content Creation User Group (summaries here).
  • An intertwined discussion with the above about Linden Water and swimming options.
  • There have been requests for a llSetObjectMass() function. Whilst this doesn’t currently exist, this SL wiki page has been created to provide a (hopefully) equitable capability, with Leviathan Linden noting:
Vehicle developers were asking for an llSetMass() method so they could standardize the mass of the vehicle after the agent had sat down. It turns out that LSL function is not necessary, there is a way to do it with existing LSL functionality, but it is a little tricky for multi-prim objects.
  • A further discussion on improving vehicle interaction with parcel bans – something LL is hoping to address – such as the potential for putting banline information on the mini-map, with other suggestions being put forward.
    • This led to a broad discussion on issues of parcel privacy and access, security and forced teleporting of unwanted visitors.
  • Requests have been made to modify Experience permissions so that creators can set them to “only this time” or “work like phone apps“. This led to a discussion on Experiences  and the format of the permissions dialogue, etc.

 

† 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 #51: SL CCUG & TPV meeting summaries

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

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

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

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.