2026 week #26: SL Open Source 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.