2026 week #28: SL Open Source meeting: OpenGL

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.