The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting of Thursday, March 6th, 2025.Please note that this is not a full transcript, but a summary of key topics .
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.
Linden Water improvements – water should now appear much as it did “pre-PBR” (note: this viewer does have known Linden Water issues, for which fixes are already going into to the next viewer update).
Support for 20 Picks in the viewer’s Profile floater (requires simulator release 2025-02-14 or later).
Project viewers:
Second Life Project Lua Editor Alpha, version 7.1.12.13526902562, March 3rd, 2025 – NEW.
Will only work on Aditi, within the following regions: [Luau Yardang], [Luau Tombolo], [Luau Mesa] and [Luau Tideland].
Release Cadence and Numbering Changes
The Lab has been undertaking work to further streamline viewer development and the release cycle.
These changes specifically mean:
Official viewer updates will be moving to a planned monthly release cadence.
The viewer version numbering will be changed to reflect the year / month of release, so 2025.03 (March 2025) will be the next viewer in the pipe, followed by 2025.04 (April 2025).
It is presently unclear if these number system will include additional number to indicate individual updates as a viewer moves through its own update cycle prior to being promoted to de-facto release status.
Within this cadence, individual updates will be incorporated into each upcoming release on an “as needed” basis – so presumably high-priority fixes will be fast-tracked into releases as they occur.
This also means the old Develop Github branch is now archived (archive/develop in the LL viewer Github repo), and updates / changes within it will be pulled across to active viewer repos as decisions are made as to what updates are to be implemented in which viewer in the new release cycle.
A key reason for altering the viewer release cadence is that LL is trying to move away from implementing large-scale projects (involving both the viewer and the simulator / back-end services) which can take months / years to deploy, towards implementing smaller, more manageable projects which can be implemented / integrated more easily and iterated upon faster, in order to deliver improvements to the platform as a whole.
Upcoming Viewers
The 2025.03 release is being looked at as a maintenance release, which will incorporate (among other things):
The Linden Water fixes referenced above.
Improvements for VRAM handling, including a new VRAM divisor specifically for texture usage (by default will try to use half of the available VRAM available to the viewer for textures, with the ability to manually adjust the amount used as needed).
Monty Linden’s improvements to avatar loading.
The large volume of work which had been classified as a “Maintenance B” viewer update prior to releases being overtaken by the need to focus on performance fixes (DeltaFPS, ExtraFPS and ForeverFPS) might be incorporated in to 2025.03 release, but could be held over until the following 2025.04 release.
Linux Support
It is hoped that the new approach to releases, coupled with the number of Linux-focused updates pushed towards the “Maintenance B” stockpile will help with Linux viewer development and support.
This does not mean LL will be guaranteeing a broader, more holistic support of Linux going forward, but rather it will put the Lab in a position to better address the question of on-going Linux support.
The above noted, Linux support is described as becoming “more and more of a forefront priority” in terms of how the Lab might more forward in supporting it, particularly as there are some internal (to the Lab) dependencies on supporting it.
Open Source Programme Revamp
In line with all of the above, Geenz Linden has put forward a proposal for revamping the open source programme and making it more responsive, inviting input from TPV and open source developers.
One aspect of this is the Lab will be clearly flagging areas in which they would specifically benefit from open source developer assistance.
A developing list of areas where such help / code contributions would be welcome can be found here.
Any open source developers who have not seen the proposal are directed to it.
Beta Testing New Features and Capabilities
As has been previously stated, one aspect of feature development and implementation will be adding features and capabilities to the viewer and then guarding them against use via flags controlled on the server-side.
This will allow features and capabilities to the viewer which might be back-end support requirements, and have the viewer completely ignore them until such time as the server-side flag is set so that they can be used.
It is hoped that this will again allow for a faster implementation and deployment of features and capabilities.
Given this, Aditi (the Beta grid) will remain as the place for general new feature testing and bug-hunting.
Water Exclusion Surfaces – Re-cap
Now available in the Forever FPS release, and all third-party viewers merging with that code base are Water Exclusion Surfaces (WES).
These in a similar manner to the old invisiprims:
When seen from above will “hide” Linden Water -thus allowing water to be excluded from inside boat hulls, dry docks, etc.
If looked at from directly below, it will cull the underwater plane but leave the water fogging.
A very(, very) basic example of a Water Exclusion Surface hiding Linden Water
Currently, all invisiprims fitting the above use-case should now work, together the with scripts for converting prims into invisiprims.
A new UI element for more easily creating WES items will be added to the viewer in a future release – possibly 2025.04.
WES will work on any prim or mash face except rigged mesh or with attachments by intent due to performance issues.
Rigged meshes will likely be rendered black.
Attachment will render, but the exclusion surface will be ignored and will not hide Water or rigged mesh (the rigged mesh will likely be rendered black.
Additionally, WES will not work with the system avatar.
Water Exclusion Surfaces will not provide volumetric water exclusion (e.g. “hiding” water from the rooms of underwater buildings).
Mesh Import Formats – glTF Mesh Support
The removal of support for the COLLADA mesh file format from Blender under Linux has raised concerns about the longevity of the format in general in regards to Second Life.
LL are looking to implement glTF mesh imports for Second Life – something which has been promised since work started on moving Second Life towards compliance with the glTF specification.
However, the overall scope of the project has changed. Rather than being the overarching project with scene imports, etc., the work is now being focused on “just glTF mesh”. See this planned implementation feature for details.
The idea is to have the glTF mesh import to work in the same manner as the current COLLADA .DAE import floater, and this work should be surfacing in a viewer in the near future.
This revised approach does not mean the rest of glTF import is “going away”; it is more a re-prioritisation of work and breaking things down into smaller deliverables, in keeping with LL’s desire to implement and iteration projects and work faster than might be achieved through single grand “omnibus” projects.
Along with this, two requests were asked of LL:
The ability to select which part of a mesh model are to be uploaded (e.g. via check box), rather than defaulting to the entire model.
The ability to select at upload which attachment point rigged meshes should attach to, so as to encourage creators to do this, rather than leaving them defaulting to the the right hand position and letting the rigging take care of appearance.
Both of these ideas were seen as beneficial – with the caveat that they would require additional UI design and testing / iteration, adding further complexity to the work, delaying the initial release. As such, they are unlikely to be a part of the initial release of the glTF mesh uploader, but could potentially be looked at as future additions to it.
LL is not currently working on a means for automatic LOD generation on in-world objects.
In Brief
There are continuing reports of people who are on-line reporting as off-line once again. Canny reports if encountered, included where the issue occurred.
There are plans in-hand for LL to hold a Town Hall in which the product development roadmap for Second Life will be discussed. Details are currently TBA.
Alpha gamma work:
In order for PBR lighting to render anywhere close to correctly, alpha blending had to be switched from SRGB to linear colour space.
This caused some older content using Blinn-Phong, to look either more opaque or more transparent than in did pre-PBR.
The fix for this giving people the ability to adjust the alpha/gamma on per texture entry for the object (including no mod items).
However, the work was targeted via the old viewer development branch, and needs to be re-targeted for implementation as a part of the new viewer release cycle, and this has yet to be done.
Puppetry project:
There are currently no plans to re-start the Puppetry project.
There are some significant technical hurdles LL believe need to be understood and addressed (such as a joint transmission between viewers), which the project as a whole needs to be reviewed in terms of requirements and priorities in order for it to be more easily addressed.
Terrain painting (summarised here) remains on hold due to other priorities.
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.
Dates and times of meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.
Official Viewer Status
Default viewer: version 7.1.11.12363455226, formerly the ExtraFPS RC (multiple performance fixes, aesthetic improvements and UI optimisations), dated December 17, 2024, promoted December 20, 2024 – No Change.
Release Candidate: Forever FPS, version 7.1.12.12999043440, February 4, 2025.
The “not so great news”: it is not possible to get Linden Water to look exactly as it did “pre-PBR”.
The “great news” is that LL can get very close in terms of overall look.
Most of the old Fresnel reflection/refraction, together with some of the underwater fogging has been restored.
Some of the fixes for water are currently in the very latest Firestorm Beta (and will presumably be going into the official ForeverFPS RC, if not there already).
Feedback on the changes – with the caveat things cannot (per above) ever be 1:1 with “pre-PBR” water appearance – is regarded as very important in order for the Lab to judge how well the changes are working.
This work is not the end of water tweaks; Geenz is looking at restoring real-time water reflections once the performance impacts of doing so can be assessed.
This will involve the use class of Hero reflection probe (like mirrors), which means the mirror capability as a whole will need additional optimisation work, as any frame rate drops it might incur are currently deemed as “not acceptable” by the team.
In addition, Geenz is looking at improving reflections more generally via the automatic reflection probes, such as reducing the moiré effect of Screen Space Reflections (SSR) on water.
The above will hopefully be released either in a dedicated viewer to follow ForeverFPS, or rolled into the viewer(s) directly following ForeverFPS.
“Hide Water” – Water Exclusion Surfaces
Geenz Linden has been working to provide a means of excluding Linden Water from internal volumes such as boat hulls, and has arrived at a solution with the technical name Water Exclusion Surfaces (WES).
The capability will hopefully be surfacing in an update to the ForeverFPS RC viewer. When it does:
It will likely be an option setting within the Texture tab of the Build / Edit floater, the name of which is still TBD, but is currently being referred to as “Hide Water”, and will work with most prim and mesh shapes to which it is applied (see the limitations notes, below).
When used with boats and similar:
It will cull Linden Water and the associated subsurface fogging when looking down on the hull / surface from above.
If looked at from directly below, it will only cull the underwater plane, the fogging will be intact.
Water exclusion surfaces should work as well as / better than invisiprims (e.g. they won’t clash with worn alphas or cause shader issues, occlusion culling will work correctly, etc.
Limitations:
The capability will not provide volumetric water exclusion (e.g. “hiding” water from the inside of underwater buildings) – This is a “future looking thing”, which might be addressed in the future. It is intended for use in boats and similar.
It is not intended to replace all use cases associated with invisiprims, and should not be taken to be a “replacement” for the latter.
The capability will not work when incorporated in an attachment (the attachment will render, but the exclusion surface will be ignored and will not hide Water) or rigged mesh (the rigged mesh will likely be rendered black). This is by intent, to limit performance impacts. Also do not work on the system avatars.
There are some additional limits to ease performance impact (e.g. fogging will not get really dense when looking up through the water plane).
In Brief
Placing Linden Water on prims or mesh: not a capability currently being developed, but one that is subject to internal discussions at times.
It was again noted that many creators are still awaiting scripted support for PBR (e.g. PBR specific texture offset / UV coordinate manipulation).
This support is described as “still on the roadmap”, but may have had other priorities push it down the list of priorities.
The fact that creators are waiting on them will be taken back from the meeting for internal discussion.
Cosmic Linden’s PBR terrain painting work remains on hold due to her being engaged in other work. Work on glTF mesh import is much the same.
Geenz noted that following ForeverFPS there is a lot of additional render maintenance and similar work required on the viewer as well as additional / in progress feature sets, and all of this work needs to be prioritised.
Maxwell Graf recently posted a request to increase the polygon resolution for terrain – and asked about the potential technical / performance issue this might cause (if any), and whether it is something that might be selectable (e.g. if you want the higher polygon resolution then enable it on your region(s), if you don’t – then don’t!).
The short answer to this, there is no technical reasons as to why not – beyond testing and assessment for unforeseen impacts; although a) the request itself has yet to be officially responded to; b) the above doesn’t necessarily mean it will be acted upon.
However, it did led to LL requesting people with ideas for SL terrain to file feature requests for future consideration.
A further request was made for scenic backdrops to be available for regions (e.g. rendered options that can be rendered in place of the water and taking the form of a range of in-viewer selectable options – cityscape, forest, hills, mountains, etc., – so that actual mesh / sculpty based region surrounds do not have to be used.
This is something Sansar did reasonably well – including custom surrounds.
Feature requests via the feedback portal were asked for on this.
It was noted that SL lighting still needs to be updated – again not on the immediate roadmap, but under consideration; however, the hoped-for punctual lighting has been pushed back.
An issue with updating lighting (and things related, like how shadows function), is that the lighting system was developed at a time (early 2000s) where it had to be constrained. While things have developed to a point where those constraints may no longer be applicable, they are nevertheless heavily baked-in to SL, and will require considerable effect to unpick and replace.
Feedback through the feedback portal on what people would like to see with lighting / shadows was requested, in order to help the Lab further understand expectations, determine options and factor feedback into a more holistic approach to lighting in SL at some point in the future.
Screen Space Reflections (SSR): this is again something Geenz would like to get back to, but (again) would like feedback via the feedback portal on issues people have why they do / do not use SSR – particularly issues they have with SSR that are not related to Linden Water (e.g. on glossy surfaces), what they feel is needed, etc.
The general feedback on this was that SRR on other surfaces works reasonably well (if with random noise in places – which Geenz believes he has a handle on fixing in the future), and possibly increasing the angle at which it can be seen to take effect).
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.
Dates and times of 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, 2024.
Numerous bugs and issues have been reported following the ExtraFPS viewer promotion, and as a result, these seem likely to be developed into a bug-fix viewer (“ForeverFPS”), with an initial cut at an RC version potentially coming in the next week or so.
There are “numerous discussions” occurring at the Lab regarding possible future projects, but nothing at present to announce.
It was announced that Runitai Linden (often referred to as DaveP) is departing Linden Lab to enter public service.
Runitai commented directly on his reasons for departing the Lab and his feelings about doing so, however, rather than drop them here for those who prefer to read rather than listen, I’ve provided a transcript with some additional notes: Runitai Linden hears the call of Public Service.
It is believed the 2K bake updates for the Bake Service are “ready to go”, having cleared QA per my notes from the SUG meeting.
The viewer updates required to allow 2K textures to be used with wearable layers are apparently merged into the Develop branch, but yet to surface within an RC viewer built from that branch.
In theory, the back-end support could be enabled pending the viewer update, because it will not interfere with current rendering, as the viewer should continue to limit wearable textures to the current maximum of 1024×1024 until it is updated to apply 2K bakes. However, discussions on how to proceed pending the viewer update will be taken-up internally by LL.
[Video: 14:48-15:00] here have been multiple requests / discussions over the years about the potential of an Inventory archive to allow people to reduce (some of) their Inventory bulk / bloat by archiving items through a supported system rather than just boxing them. Currently, such a service is not on the roadmap.
[Video: 17:32-22:55] A request to add the type of client (viewer, browser, SL Mobile) some is using to their avatar tag “to help people help others”. Surely the easiest way to find this out, as a mentor / someone giving assistance, etc., is to ask (“Are you using SL on a Mobile or through a browser, or have you installed the client on your computer?”).
Comments from Philip Rosedale
The core CCUG meeting was shortened to 30 minutes due to LL meeting conflicts. However, Philip Rosedale dropped in to provide assorted comments and feedback.
[Video: 24:40-25:35] On AI and Scripted Agents, etc.: thinks the Lab’s policy on AI and bots is going to be “a complex and evolving matter”, and that as AI becomes more powerful, people will need to come together to decide how best to handle it in SL, given the variety of views.
[Video: 27:39-40:14] The above indirectly led to a discussion on being able to identify bots in Group chat sessions and IMs similar, where it may not be obvious that messages are being bot / AI-generated. There are flags which should be used with scripted agents and which should force a message to indicate a messenger is a scripted agent in IMs; however, the issue appears to be that chat and IM can get flooded so quickly with text, the notification can be missed. Suggestions were made to make this text a different colour and possibly pin it to the top of the chat / IM window.
This resulted in a list of categories of bot bad behaviour being drawn up, including begging, phishing, undesired group chat, traffic gaming, data collection (e.g. Bonnie Bots) even overwhelming users with NPC text & failing to account for other interactions.
Overall, this became an extended conversation, and following the video is recommended for full context.
[Video 25:45-26:48] On promoting Second Life as a place to hold work meetings: does not believe the platform has reached that point, because of the lack of nuance within avatar communications – humans really heavily on non-verbal communication cues for further subtext, etc., in exchanges, and SL currently cannot provide these.
[Also, as a sidenote, LL put considerable effort into trying to develop SL as a behind-the-firewall “business application” between 2008-2011 with the Second Life Enterprise (SLE) package (licenses at around US $55,000, but I cannot remember how many avatars came with that license), and that didn’t go so well at the time – potentially because of the shortfalls Philip mentions being among the reasons it didn’t really gain a lot of traction at the time.]
[Video: 40:14-50:10] A discussion on resource allocation through Project Zero to allow fair and balanced access to SL at minimum / no cost through the browser for people without it being abused (e.g. by people creating and running dozens / hundreds of bots through the browser access, thus running up costs to a point where others have to start paying at a higher rate.
As this was a brainstorming session producing multiple ideas (e.g. limiting browser access to subscription accounts – potentially missing the people the service is really geared towards helping, as they may not have subscription accounts; controlling via some form of 2FA; utilising Payment Information on File both as a means to limit access to those who are PIOF and a means to prevent them logging-on more than one account through the streaming service at one time, etc.), please refer to the video.
[Video: 50:11-54:08] When will voice services switch solely to WebRTC? – still waiting for more users to move from Firestorm 6.6.17 to a PBR-enabled version of Firestorm (which will hopefully happen once Firestorm release a version based on the ExtraFPS viewer code, allowing for the issues for poor Linden Water quality – reflections, etc.).
[Video 55:50-1:01:05] Discussion on exclusion volumes for boats under PBR (as re-enabling the forward renderer to allow invisiprims to hide water volumes is not going to happen). Runitai indicated there are potentially alternatives to allow such exclusion volumes to work.
[Video: 1:01:11-1:02:55] Comments on alternative rendering engines and content support segueing into thoughts on why other VW platforms have never achieved the level of adoption by users as witnessed with Second Life (including Sansar, OpenSim and Meta).
† 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.
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.
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.
† 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.
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.
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.
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.
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: 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.
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.
† 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.
My chat log & the live stream video (embedded below) of the Content Creation User Group (CCUG) meeting of Thursday, November 21st, 2024.
My chat log and Pantera’s video (embedded towards the end of this article) of the Third Party Viewer Developer’s Meeting (TPVD) of Friday, November 22nd, 2024.
This is not a full transcript, but a summary of key topics.
“[Video]” time stamps refers to the CCUG meeting livestream recording; “[Pantera]” refers to the TPVD meeting video provided by Pantera.
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.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.11750364439, November 12.
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).
Core focus remains on performance work and will remain so until “everyone is happily on PBR-enabled viewers.”
Hope is still to have ExtraFPS promoted to release status by the end of 2024.
This viewer should see some “significant [performance] improvement” on certain types of hardware – e.g. the Intel HD4000 series (launched May 2012), which is “remarkably popular” among SL users.
This work is focused on developing a “classic” mode (also known as a “potato mode” which will see various rendering options disabled (e.g. HDR, Tone Mapping, Reflection Probes, the Emissive channel) to render SL more in keeping with its pre-PBR appearance when running with ALM enabled (aka Deferred Rendering).
To achieve this and ensure decent frame rates, comparative benchmarking is being carried out:
If an older GPU runs a non-PBR viewer at a higher FPS with ALM enabled than with it disabled – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer. Or;
If an older GPU runs a non-PBR viewer at a higher FPS with ALM disabled (thus using the old Forward Renderer) – – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer, but with ALM-like graphics fidelity.
A major element of this work is to get older harder performance back up without creating a rendering schism through the re-introduction of something like Froward Rendering.
This work is being carried out alongside “various end of year this and kick-off the next year things.”
[We’re] doing our level best to ensure everybody who can use Second Life on Firestorm 6.6.17 can upgrade to some version of 7.x [PBR] without suffering negative consequences. That’s what we’re doing; we’re chasing all the crashes that we can and all the performance issues that we can.
– Runitai Linden.
[Video 33:28-35:10] A reiteration that a lot of the issues impacted older / lower spec systems are not PBR-related per se (they just happen to have been surfaced within PBR-enabled viewers). Rather, they are the result of things like running out of VRAM due to the updates made to the texture streaming system.
Where issues have been due to PBR (e.g. exceptionally heavy PBR in-world builds) there are additional optimisations that are being done.
A point to remember here is that PBR is a part of the glTF 2.0+ specification which LL are adopting – and glTF is designed to support a very wide range of hardware, including mobile ‘phone upwards, and so is not itself particularly resource-intensive.
Until now, issues with the quality of water reflections on PBR viewers has not been seen as a priority to fix, as it is not performance related and has thus been “taking a back seat” in the queue of fixes. However, if it is seen as a significant issue that prevents users from moving to a PBR viewer, this might be reviewed.
In response to comments about texture blurring, Runitai Linden noted that the viewer will start down-scaling textures as it detects a system is running low on available VRAM.
This can result in some scene textures close to the camera remaining blurred until focused / zoomed-in upon.
Runitai believes there is more work that could be done as to how the fall-off curve for this works to reduce the need to zoom “right in” on textures doing this in order for them to render properly.
He further noted that the old behaviour of just using mouseover on a texture to get it to load is no longer applicable, as that actually caused most of the textures in a scene to load at full resolution, causing a performance hit.
In addition, there are still some bugs which can result in the viewer getting the wrong answer as to how much VRAM is available on a system (and start downscaling textures when it may not need to). To check if this might be the case:
Open the viewer’s texture console (Develop(er) → Consoles → Texture Console / CTRL-SHIFT-3).
Check Est. Free (top line of the Console display) and compare the number with something like GPU-Z or Task Manager (via GPU option).
If the two are very different, then there is likely a bug. Please file a bug report with hardware details (Help → About → Copy to Clipboard and paste info into report).
Note that on integrated graphics system, the amount of VRAM usually gets reported as the amount of system RAM, and this is referenced by the Sys Free number in the viewer’s Texture Console. Sys Free also reports based on the fact that the viewer tries to minimise its total memory footprint to under 16 Gb.
There is no set “minimum” or “maximum for VRAM with SL; LL are committed to enabling SL to run on GPUs with as little as 2 Gb of VRAM, and it is felt that systems with a minimum of 4 Gb and a Draw Distance of 128 metres should be able to manage most scenes – but this is a very broad rule of thumb; the viewer will continue to use VRAM until it runs out, if necessary – there is no upper limit, although some TPVs do allow caps to be set.
When downscaling occurs, it should be a) because VRAM has been used; b) commence with textures in the background / off-camera before moving to those in-view.
Note that textures will also be off-loaded from VRAM when SL is minimised / put in the background, to allow other applications access to VRAM. This can also cause blurring as textures are reloaded when SL is brought back to the foreground and resumes using all available VRAM as best it can.
In Brief
[Video: 18:32-21:02] WebRTC: LL are still awaiting more users to move to viewers with WebRTC support prior to disabling Vivox.
[Video: 23:31-24:40] Older EEP (e.g. Windlight, they’re that old – such as CalWL) settings can look blown-out on PBR views.
LL have been attempted to auto-adjust them, but this has proven subjective in terms of results.
Therefore, going forward, work will be limited to trying to make them look like they used to, which is acknowledged as not being great for PBR content, but is the “least bad” in terms of keeping EEP settings people like looking the way people like to see them.
Hopefully, this work will be finished in time to be included in ExtraFPS; however, if it misses ExtraFPS, it may be issued as a viewer hotfix.
[Video: 39:15-40:10] A note of two long-term risks, graphically speaking, that have to be addressed within SL at some point:
COLLADA support: support for COLLADA is waning world-side, and so SL needs an interchange file format that is not dependent on COLLADA. Again, glTF is seen as the best solution here.
Similarly, OpenGL support is waning, so SL requires a rendering engine that does not rely on OpenGL [and this has been an on-going discussion for the last couple of years or so].
[Video: 40:12-45:10] Land Impact: it has long been acknowledged that the Land Impact calculation needs to be revised; there is both a lack of real incentive within it for creators to optimise their builds, and it misses some key adjustments for things like large builds. The question here is more when it will be revised – although doing so may not eliminate all the ways in which some people game the system to produce lower LI items, as this is something of a separate issue.
A general discussion on glTF and mesh imports (incl. scenes) via glTF. In short, no-one working on things at present, given the focus on the performance issues. The local preview remains available in those viewers with the code – by Runitai reminded people that the preview does not use texture streaming; everything gets pulled in at full resolution – and so VRAM can easily be gobbled up.
TPVD Meeting
Much of the TPVD covered ground already walked during the CCUG meeting. Therefore, the following is thus a summary of additional points discussed. Time stamps reference Pantera’s video, below.
Note the meeting formally ended at around 29 minutes, although the video runs through until just shy of 41 minutes, covering a more generic conversation.
A recap of the “classic” / “potato” mode work (get PBR viewers running on lower-spec machines running at the same or better FPS than the hardware can run a non-PBR viewer).
Debunking the PBR myths:
It is not necessary to run the viewer on Ultra quality in order to view PBR content.
LL are not removing support for Blinn-Phong (or “classic” or “legacy”, however you want to call them) materials. PBR is an extension to materials support in SL, not a replacement.
A general conversation on Blinn-Phong and PBR Materials, notably in terms of providing the former as “fallbacks” to the latter to accommodate people on non-PBR viewers and prevent them seeing grey / white / plywood surfaces / features.
[Pantera: 9:42-10:42] Some people may experience issues with PBR not just because of computer hardware limitations, but also because of network / router issues (e.g. instead of a single diffuse map, PBR calls multiple maps, resulting in multiple HTTP requests which can cause some routers to choke).
To counter this, the “classic / potato” mode LL is developing already doesn’t use the emissive map; if this is shown to work and push up performance, then LL will likely go through as see what other maps might be ignored without compromising the overall visual look of “classic” mode, and hopefully further lift performance in these cases.
[Pantera: 15:11-16:45] A reiteration that LL are continuing to work on trying to resolve performance issues, and that anyone experiencing such issues should file a feedback report with as much detail as possible (including hardware information (Viewer Help and use the Copy to Clipboard button and paste info into the report).
Specifics are important, as there is only so much info LL can pull from their stats. This is particularly true when terms such as “performance craters” are used, as these are so broad-ranging as to be meaningless.
[Pantera: 16:50-20:00] SL viewer’s use of CPU cores and threads: thread usage is variable depending on the number of CPU cores.
Those with a specific interest in this, the Steam Hardware Survey is “pretty close” to SL, although SL’s install base tracks “a little closer” to the lower end of hardware, so reduce what is reported in the Steam Hardware Survey 10-20%, and that’s fairly representative of SL.
Overall with SL, the main processing loop is single-threaded; texture rezzing and some audio processing occurs on background threads.
Runitai Linden has been experimenting with adding threads – such as a dedicated idle thread – and these are showing a “lot of promise”, particularly when Vsync is used.
As most GL processes are multi-threaded, hints are sent to things like Nvidia drivers to put themselves into multi-threaded mode.
[Pantera: 20:38-25:35] Frame limiters / Vsync: some TPVs use frame limiters to assist with performance, and LL would be interested in receiving a code contribution for one of these.
However, it is felt that if trying to limit frame rate to screen refresh, then Vsync remains the better option; whilst a frame limiter is more suited to use in other situations. But, and depending on the frame rate, Vsync can cause more screen jitter than a frame limiter.
In this discussion it was noted that a fix from Apple at the OS level means Vsync with work at 100/120 Hz.
It was noted that Firestorm are now defaulting to 60fps with their frame limiter.
† 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.
Inara Pey: Living in a Modemworld 