Tag: TPVD / Open Source Meetings 2026

The following notes were taken from: My chat log of the Open-Source User Group (OSUG) meeting held on Friday, July 24, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Notes The SL Wiki Other Items Next Meeting

Meeting Purpose

• The Open Source User Group (OSUG) meeting is an open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
• This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

• 26.3 is heading towards a beta  / Release Candidate release, but with the texture streaming work removed. The latter will now form a part of the Graphics Care Package (GCP) viewer.
• The next alpha version of the Lua viewer (with Linux support) is seem to appear “soon” – it is just awaiting the OK to be allowed into the wild.
• Overall, the viewer release schedule is “a bit up in the air right now”. The hoped-for plan remains:
  • 26.3 issued as an RC and progressing to release status.
  • Lua/Linux progressing to beta / RC shortly after 26.3 releases release status and then itself moving to release. However, this is not guaranteed as yet.
  • On-going work with GCP so that it can be more fully discussed at the next OSUG.
• Vcpkg (under-the-hood viewer packaging to replace the current Autobuild process used to build the viewer):
  • Currently, LL is trying to figure out where to land this work, but currently it is unlikely to be introduced with the GCP viewer builds.
  • One thought is to try to land it in develop at some point in the coming months.
  • However, feedback was requested from TPV developers relying on the existing autobuild infrastructure as to what they would like as the preferred path towards adoption.
  • Geenz requested TPV Developers should contact him with their views; in lieu of feedback, he’ll also post something on this on Github .

The SL Wiki

From Kyle Linden:

We’re reviving the Wiki. Our goals are improved moderation tools, a theme refresh and it will be the new central repository for Lua documentation, complimenting the LSL Portal in the Wiki. That means we also want to re-open editor access to all SL accounts that have logged in world. Enabling the Wiki to be a Wiki. Along with a more robust moderation toolset we’d also like to have dedicated residents who are interested in helping, be part of the human moderation team. Please IM me if interested.

• Kyle also noted that the Second Life Creation Portal is to take a “new direction” and that the scripting information currently there is to be migrated to the SL Wiki. 

Other Items

• Monty Linden noted that Lua/Luau documentation is sparse at the moment, so LL will be leaning on external materials and contributions to support Lua.
  • In this regard, those interested should refer to Suzanna’s SLua Guide, developed by Suzanna  Linn, which includes documentation and details on in-world Lua scripting classes.
• It has been noted that there is code on the SL Github repositories written around CEF to replace the current plugin model.
  • The advice was given to keep whatever the new plugin architecture might be running in a separate process.
  • Linking directly the CEF library to the viewer was seen as causing issues with memory allocations as CEF/Chromium uses its own allocator; would expose the viewer to all of the vulnerabilities and exploits discovered weekly in Chrome; open the viewer to crashing each time CEF crashes.
  • Additional concerns were raised on this, including the idea that perhaps LL should investigate a means to push CEF updates to all users, regardless of the viewer they are using.
  • Callum Linden indicated that the work in the SL Github referenced is a research project – LL are looking at ways to improve memory and speed + cookie sharing with CEF that would remove some of the issues associated with it. However, the concerns raised were noted.
  • This led to a technical discussion on CEF and how best to approach its use in the viewer- please refer to the video.
• Geenz noted the work to simplify the means by which developers can contribute code to LL (e.g. shifting from a Contributor License Agreement (CLA) to a DCO – Developer Certificate of Origin) has been on hold due to time and availability, but he hopes to be able to get back to it in the near future.

Next Meeting

• 13:00 SLT, Friday, August 7, 2026, at the Hippotropolis Theatre.

The following notes were taken from: My chat log of the Open-Source Developer (OSD) meeting held on Friday, July 10th, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Notes More on Updating from OpenGL Other Items Next Meeting

Meeting Purpose

• The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

• 26.3 is back in development with some additional texture streaming work added. It’s currently awaiting QA testing.
• The Lua viewer (with Linux support) still looks set to be the viewer to proceed to release status after 26.3.
• The Graphics Care Package (GCP) viewer should be getting some attention “soon”.
  • Geenz Linden indicated that he’d to try and get more PBR fixes into GCP, and encouraged anyone with a broken environment to send details his way (+ landmarks to places that are broken vs. non-PBR).
  • The fixes for water (reflections, etc.), are “mostly there” in GCP, but there are still several edge cases that need tracking down.
  • The alpha-gamma work still doesn’t yet have a home in a viewer .

More on Updating from OpenGL

So, as everyone knows we’ve been on OpenGL for a very long time. And we’ve kicked the can on this for a while – mostly because although things aren’t moving most of the time in OpenGL land, it’s not really – moving. However, deprecation is still landing in various ways across various drivers and the like whether we like it or not, and we’re forever stuck on GL 4.1 because thanks Apple. That limits our options as far as further optimisations. But we can’t just up and move everything over night. There’s a good bit of tech debt that needs clean-up, API calls that are using a lot of older ways to do things, etc., and things that just don’t really make sense even in a “modern” OpenGL context.

– Geenz Linden, discussing plans for “after OpenGL”

• Geenz went on to note:
  • The “first big chunk” of work – already underway and will hopefully ship with the Graphic Care Package (GCP) viewer – is cleaning up a lot of how OpenGL is used. There are still a lot of “exposed” OpenGL calls. A separate fork of the viewer cleans this up, and should be landing in GCP in the near future.
  • There needs to be work to update and modernise a lot of elements of the viewer that assume a surprising amount of old fixed function pipeline-style GL usage. This is also being worked on, and the hope is it will land in the GCP viewer.
  • There then needs to be some significant work on LLPipeline separation.
    • At its core, this means getting the rendering engine into its own library and making it so the viewer can more directly function in a headless state.
    • Whilst the viewer has had a headless mode for a while, it’ is currently under utilised, and more-or-less banks on LLRender being compiled with some flags that disable OpenGL.
    • The new library-based approach would make it so the rendering pipe is entirely its own library and optional; it just won’t have any render output on its own (it will require a render interface).
• The current thinking at the Lab is to build a new renderer interface to replace LLRender, which can then be used to:
  • Either port the current rendering engine to Vulkan through, maybe something like an LLPipelineVulkan/ LLPipelineMetal/LLPipelineD3D12(?) + something called LLGPUDriver (which is pretty much where OpenGL/Vulkan/Metal lives).
  • Or TPVs can port in some other third party rendering engine without any coupling with LLRender.
  • Thus, the point of the renderer interface is to further decouple the viewer from the concept of rendering in the first place. Basically, there’ll like be LLRenderEngine which is probably going to be a (mostly) pure interface that LLPipeline gets to be the first consumer of.
  • He noted that this second option is still going through internal decision-making processes, and that both it and the first option are very much “a bit of a large lift”.
• The reasons for this approach is about having an offramp from the OpenGL pipe without being super disruptive (as might be the case if the new pipeline ships prematurely, forcing people onto it similarly prematurely in a similar manner to PBR). So what is likely is that:
  • There will be an OpenGL pipeline that lingers for a while (aka “years”) as the legacy renderer.
  • Whatever lands as the “new” renderer (whether that’s a direct port to Vulkan or something else)
  • A debug setting to select which one is to be used.
• A lot of what happens vis OpenGL overall is going depend on overall confidence in a new pipeline reaching a maturity across across a broad enough range of machines used to access SL so as to consider retiring OpenGL.
  • As such, the main thing LL will be tracking once  a project is initiated, is how well adoption is holding up on the low-end for this thing by the way. Some of those machines might be stuck on OpenGL forever, and might not get all of the shiny Vulkan stuff eventually.
• Geenz further indicated at:
  • He’s been working on a rendering engine of his own for some time, and that is a potential option.
  • Using slang-rhi is very much an option asl well, so multiple APIs can be targeted APIs at once, and then just tweak depending on what is required to support a specific platform.
• In terms of the up-front clean-up, etc., mentioned in Geenz’s opening statement on the subject, this was noted as being not that far away.
• A request was made for the new renderer to support more than one pipe at a time with different camera angles, so that a single account could make use of them for shooting machinima, etc.
  • Geenz noted that this is unlikely to be officially supported.

Other Items

• Some discussion circled the topic of “SLMesh2” (see my week #27 CCUG Summary), with Geenz noting:
  • His work on the project is liable to be more high-level, with Product Engine developers doing the coding work.
  • It will be an iterative project, with the first major element being more getting off of the current SLMesh format.
• An update on the status of work in porting RLVa to the official viewer was requested. This was a project started a few years ago and then appeared to be moved to the sidings. No response was given, possibly because the question was missed in the OpenGL / renderer discussions.
• A discussion on water and reflections towards the end of the meeting.

Next Meeting

• 13:00 SLT, Friday, July 24th, 2026, at the Hippotropolis Theatre.

The following notes were taken from: My chat log of the Open-Source Developer (OSD) meeting held on Friday, June 26th, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Notes OpenGL, Vulkan Next Meeting

Meeting Purpose

• The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

• 26.3 is still slated to be the next viewer to be issues, but when is currently TBD.
• Lua (with Linux support) will be the next viewer after 26.3.
• The next major update after Lua is likely to be vcpkg (under-the-hood viewer packaging), but this is probably going to be late summer before this surfaces.
• Some upcoming viewer-side WebRTC updates:
  • libwebrtc is to be updated to m144
  • The issue with p2p/adhoc/conference calls dropping when opening Voice Preferences is getting a fix.
  • (Also, on the back-end, the WebRTC Voice-to-text experimentation is continuing.).
• Geenz Linden is working on a pipeline split in the background that should make getting off of OpenGL generally easier. This won’t move the needle over night, and thus far is mostly code clean-up.

OpenGL, Vulkan

• The majority of the meeting was a discussion on succeeding OpenGL, with a focus on Vulkan.
• Geenz noted:
  • There are “a few plans brewing for Vulkan/Metal/D3D12 support”. For MacOS a rendering hardware interface (RHI) to target Metal.
  • Broadly speaking, there does not appear to be anything “super high risk under Vulkan”, but the Lab still needs to approach things with care.
  • Based on available stats, the number of people using “pre-Vulkan” hardware is no longer extensive & the viewer also logs the number of people using systems capable of Vulkan support.
  • However, the problem is not so much who can / is using Vulkan, but rather how up-to-date are people’s drivers and, “are there any landmines lurking in that specific driver/hardware combo” because SL still has to support hardware that doesn’t get driver updates, etc.
  • The work he did for masked water in things like boat hulls should be relatively easy to port.
• One of the major questions with Vulkan support will be can users’ hardware support modern Vulkan extension (such as bindless, which is liable to be a major optimisation for SL if it goes the Vulkan route).
• In terms of the general plan for switching APIs away from OpenGL, Geenz noted:

Right now the plan is vaguely shaped as: split out LLPipeline and related components (including the draw pools), setup a general interface for the viewer “core” to talk to “a renderer”, amber the OpenGL renderer beyond minor development as our “classic” renderer, and have a separate renderer that at first will be off by default until we’re confident we’ve taken care of everyone’s bugs sufficiently. The devil is in the details of course, but generally we want to avoid another PBR-shaped release where we’re having to speed towards shoving everyone onto something that needed more feedback before it released. So, people get a choice for a while with the target for the new stuff being “similar+”

• So short term at least people with be able to switch between renderers, where “short term” is likely measured in years.
• The chances are as LL gain confidence in different set-ups they will start enabling it by default for certain detected hardware.
• Concern was raised that a switch-over could result in a “ALM moment” (ALM=Advanced Lighting Model) where peopl didn’t use the renderer because of the way it changed the appearance of scenes. However, the changing of APIs / providing different rendering APIs shouldn’t be such as issue, as scenes should look pretty much the same either way.

Other Items

• The question of gathering region data for the purposes of producing things like 3D terrain maps was again raised. This has been passed around the majority of User Group meetings in a attempt to understand any limitations on the use of bots for this purpose. Ideally, the data would come directly from LL; however Geenz noted that LL cannot provide the data in its raw form, but it might be possible to get height / elevation data into the Map service.

Next Meeting

• 13:00 SLT, Friday, July 10th, 2026, at the Hippotropolis Theatre.

The following notes were taken from: My chat log of the Open-Source Developer (OSD) meeting held on Friday, June 12th, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Notes Other Items Next Meeting

Meeting Purpose

• The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

• 26.3 is still slated to be the upcoming performance viewer, but people are currently spread out on some other priorities such as the new compositor work which will hopefully pave the way for XUI moving onto its own thread.
• Currently, the Lua editor is getting reworked into a “sooner rather than later release”, which means a Linux flavour of the official viewer will finally get released.
• The next major update (after Lua?) is probably going to be vcpkg (under-the-hood viewer packaging), but this is probably going to be late summer before this surfaces.
• The Graphics Care Package (GCP) viewer is now anticipated as not happening “for the next few months”.
• Overall, LL is working on refining the release train and figuring out what is to move forward, with Geenz Linden noting:

We’re trying to be a bit more flexible with our releases, and we’re having a ton of internal discussions about how we want to move forward with things like feature releases. So we might have something split those up along the way, we’ll see.

Other Items

• Roxie Linden noted:
  • That there are some WebRTC Voice fixes on the current simulator RC version.
  • There are some potential CEF/Dullahan improvements in the wings.
  • There are some server-side solutions for Voice-to-text transcription being evaluated.
• There are reports that changes to MapBlockRequest blocks limit (so it only accepts requests for up to 64 blocks on the current simulator RC release, when it used to accept up to 256 block requests) has broken the World Map in some viewers.
  • This is currently being discussed internally, and there may be more news on this by the time of the next Server Group Meeting (if not before then).
• There was a general discussion on which Linux distro will be used for the official Linux viewer, the favoured approach currently being “something Arch based”.
• A general discussion on scripting, notably around the availability of Lua scripting in viewers + back-end compilation, and which bumped into Mono and LSL scripting, ran through the second half of the meeting – please refer to the video.
• A concern was raised over Firestorm’s introduction of an option to disable the masking of URLs in the viewer, and how it could break some content. The general feedback from the Lab is that the feature exists as a toggle and does not break the shared experience, ergo, they have no problem with it. However, Geenz is happy to raise concerns (both for and against) internally.

Next Meeting

• 13:00 SLT, Friday, June 26th, 2026, at the Hippotropolis Theatre.

The following notes were taken from: My chat log of the Open-Source Developer (OSD) meeting held on Friday, May 29th, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Notes Chat Modernisation – IM Conversation Histories Other Items Next Meeting

Meeting Purpose

• The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29..

Viewer Notes

• Per the above, 26.2 remains the release viewer.
• 26.3.0 – performance improvements – work continues on this, but it is not ready to be issued as yet.
• The order of progress for all other viewers currently available (Lua Editor) or in development (Graphics Care Package; maintenance release) remains fluid.

Chat Modernisation – IM Conversation Histories

We’ve been working on improving text chat, especially as we have moved from a desktop-only to a multi-platform product. We’re making important improvements to how text chat works behind the scenes. One of the biggest changes: We’re improving how conversations are maintained across devices.

– Grumpity Linden, May 29th, 2026

• The Lab is working to make person-to-person IM chat histories persistent regardless as to how they are accessed – whether switching from one viewer to another or from a viewer to SL Mobile and vice-versa – so that up to the full history of a conversation can remain available, making it easier to pick up conversations wherever you log-in.
• For clarity:
  • Nearby Chat history is not a part of the work, nor (for the foreseeable future) is Group chat (although this may change at some point).
  • The core functionality of messaging will remain unchanged: how live IMs are sent and received via UDP pathways is not changing.
  • Nearby chat logs will remain available just as they are at present.
  • It is only how (and how much of) IM histories are served to the viewer that is changing.
  • This work is in its early stages, and some of it might change in view of on-going feedback, etc.
• Under this changes:
  • IM histories will be served encrypted over HTTPs, and the data store will have encryption at rest — allowing your data to stay completely private and secure.
  • For security reasons:
    • Only users opting-in to the Lab’s Multi-factor Authentication (MFA) will be able to access their complete IM histories.
    • Those who remain opted-out of MFA will only be able to see the last few days of chat histories.
    • This is to reduce risks of privacy breaches if a non-MFA account is hacked. Additionally, the number of days back and history fetch will go, will be determined by the server.
• Partially because of the MFA dependence, LL is intending to expand options for using MFA (e.g. e-mail, SMS, etc.). However, these new options may not be available prior to the new chat history capability going live.
• During the meeting there were numerous security concerns raised – particularly around store IM histories as Personal Identifying Information under regulatory requirements such as the EU’s GDPR, the degree of access LL might have to IM histories, even if encrypted.
  • Some of these were addressed to a degree (e.g. yes, histories would be deleted along with other PII data in response to a request under GDPR).
  • Some questions passed unanswered, potentially because they may require further internal discussion at LL.
• As a semi-side note, it was indicated that one potential outcome of the overall Chat Modernisation work is that a some point in the future, it should become possible to have simultaneous log-ins from different devices.
  • So, for example, someone could be logged-in viewer their desktop but need to go AFK from their computer. They could then open SL Mobile on their mobile device and continue to follow a conversation without going through a log-out / log-in situation. They could then switch back from their mobile device to the desktop on their return.

Other Items

• The legitimate use of bots for grid data gathering was again raised, together with what data may or may not be deemed acceptable for gathering, and guidelines on how such bots should be used in order to avoid sudden bans.
  • Geenz Linden noted that in terms of making aspects of region data available more readily to assist with things like 3D terrain (region) map creation, etc., there is interest in trying to implement an engineering-based ability. However, this is not something actively being developed at this point.
• A brief discussion towards the end of the meeting on EEP bugs (which are likely to be addressed in viewer 26.3), with a note that PBR Sun / Moon will be part of the GCP viewer.

Next Meeting

• 13:00 SLT, Friday, June 12th, 2026, at the Hippotropolis Theatre.

The following notes were taken from: My chat log of the Open-Source Developer (OSD) meeting held on Friday, May 15th, 2026, together with my chat log of that meeting. Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.

Table of Contents Meeting Purpose Official Viewer Status 26.2.0 – Flat UI 26.3.0 – Performance Improvements + 26.3.1 – Maintenance Update Graphics Care Package Viewer Linux Support WebRTC Updates General Discussion Next Meeting

Meeting Purpose

• The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
  • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer  – One-Click Installer – 26.1.1.23806384790 – April 10 – No change.
• Second Life Release Candidate (RC) viewer: Flat UI – 26.2.0.25386466510, May 15 -“flat” UI and font update – NEW.
• Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29..

26.2.0 – “Flat UI”

• A new beta RC was issued on May 14th – see the list above for details.
• Unless a significant blocker arises, this viewer is likely to be promoted in week #21 (commencing Monday, May 18th, 2026).

26.3.0 – Performance Improvements +

• 26.3 is still in progress. The new texture streaming updates should be merged already.
• Work is continuing on getting the async inventory updates included.
• Geenz Linden is working to get the new material and texture batching work in a good state for it as well.
• A beta /RC viewer should be appearing on the Alternate Viewers page “soon”.

26.3.1 Maintenance Update

• The second of the maintenance viewer updates – bug fixes, etc., – is now in preparation.
• Expect to see this appearing on the Alternate Viewers page “soon” as well.

Graphics Care Package Viewer

• This is somewhat “on hold” at present, but work will hopefully resume in the near future, as there are a number of bug reports stacking up.
• There is a reported mirror breakage within the GCP viewer.

Linux Support

• Linux support in the official viewer is to return with the Lua viewer.
• LL is targeting the more common Linux systems for support.
• There is a noted issue with Linux systems without PulseAudio crashing WebRTC versions of the viewer. It has been requested that the WebRTC SDK is fixed to correct this issue, or to provide fallback code PulseAudio to ALSA.
• It was noted that is a patch or PR was supplied to address this issue, LL would consider it, but LL currently doesn’t have the internal resources to implement a fix themselves.

WebRTC Update

• As noted in recent user group meeting summaries, WebRTC is now grid-wide and Vivox is effectively retired for Voice. So those using voice on a Vivox-only viewer will now need to update to a WebRTC-capable viewer.
• WebRTC updates will continue as required, and deployments are carried out separa6tely to the week grind simulator deployment / restarts.
  • Viewers running the latest client-end of WebRTC should not be affected by this, as they they will disconnect from one voice server in the cluster ahead of it going down for update, and automatically reconnect to an operating server in the cluster.
• In terms of updates, currently the WebRTC team is updating the 3p-webrtc-build branch, and is hoping to look at a code contribution that will enable them to support more recent versions of WebRTC.
• A patch has also been forwarded to the team to deal with a Linux viewer freeze at shutdown in WebRTC. This also has yet to be looked at.
• No decision has been taken as to any new capabilities will be added to WebRTC going forward, although voce-to-text transcription (with the potential for multi-language support) remains on the list.
  • There is a lot to be decided on the transcription front: addressing privacy-related concerns, how it is enabled/disabled for people, UX elements, etc.

General Discussion

• LL is retiring the use of the Opire bounty platform for viewer development code bounties.
  • The major reason for this is that it has led to a spate of bot-generated submissions, many of which are not related to any of bounties, causing headaches in trying to identify valid bounty code submissions.
  • The bounty programme is being re-thought rather than discontinued, and further updates on changes to the bounty programme will be made public once they have been agreed and are available.
• A discussion on an approach to mirrors for Linden Water, including:
  • A suggestion that 512×512 mirrors could be used to achieve the required results with less VRAM usage.
  • Geenz Linden’s view that mirror probes are currently exposed as a texture array, which needs to be of uniform size, unless bindless, which doesn’t work for Mac OS (until LL moves to a more modern API such as Metal Vulkan). However, he is considering making an exception to the need for the uniform size requirement for a special Water probe type, with its own sampler – although a problem here is the viewer is close to the limit of samplers for Mac OS.
• Requests have been made to update the official support for CEF to a more recent version. There is an internal project to update CEF / Dullahan within the official viewer.

Next Meeting

• 13:00 SLT, Friday, May 29th, 2026, at the Hippotropolis Theatre.