Category: SL Tech

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 generally held on alternate Thursdays at Hippotropolis, in a mix of Voice and text chat.
• Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

• Default viewer  26.3 – 26.3.0.31203661088, August 10, promoted August 17 – quality of life improvements; performance improvements; bug fixes – No Change.
• Second Life Lua Editor RC / Beta viewer with Linux support 26.4.0.35914774337, September 24 – NEW.
  • Lua scripting support (on regions with Lua scripting enabled).
  • Improved communication between the Viewer and the newly published Second Life VS Code extension.
  • Offers an experimental Linux viewer build.
  • Includes the latest WebRTC Voice and viewer-maintenance updates.
• Second Life Chat Modernisation viewer 26.3.0.35248298254, September 22 – NEW.
  • Recent conversations follow you seamlessly: a direct message you receive on SL Mobile can also be available when you return to desktop, and vice versa; Recent direct message history will be available on logging-in; existing desktop chat logs are preserved – previously saved local history isn’t being replaced or removed; conversation history feels continuous: on desktop, your existing local history and newer message history are brought together into a single conversation.

General Viewer Notes

• There will be at least one more RC update to the 26.4 Lua Editor / Linux viewer 26.4 before that is ready for promotion to de facto release status.
• As the 26.4 viewer will see the return of official support for Linux, the Viewer Download / Alternative Viewers pages are to be updates so that Linux is “easier to find” as 26.4 reaches release status.
• The next major viewer release – 26.5 – is currently in initial development. This will not be the Graphics Care Package, but – and subject to final confirmation – is liable to comprise in part:
  • The game_control updates to allow things like X-Box controllers and similar to be used with the viewer.
  • The Chat Modernisation work currently in the project/alpha viewer listed above.
  • Further anti-phishing protection work.
• The Graphics Care Package (GCP) viewer is progressing, but the focus currently is on getting the server-side support for the additional glTF and EEP (Environment Enhancement Project) parameters (e.g. in the case of the latter, more tone mapping and HDR controls) into place before that can once again start moving towards a project/alpha version.
  • This work also includes looking into issues such as reflection probes in a region resetting themselves for no apparent reason, causing a brief white-out of the scene in the viewer whilst they do so.

General Discussions

“Water” and Linden Water

• No update on glTF Transmission work (which will give the surface appearance of water on a prim, but not the attributes of Linden Water (and so is not “water on a prim” as people have been referencing it).
• Being able to replicate the attributes of Linden Water on a prim / mesh object volume or surface has been a long-time ask within SL.
• So, rather than try to achieve this, given that Linden Water is essentially a specialised and somewhat “legacy” solution for rendering “water”, Geenz would rather:
  • Enable the use of  glTF capabilities such as transmission within in-world objects to give them the appearance of “water”, but without all the additional complexities of replicating Linden Water.
    • This would require scripted support to give an object the full set of “water” attributes – fogging/haze, etc.).
  • Extend these capabilities, together with things like glTF volume to Linden Water, and so essentially just have a more general “water system” within SL which is more in keeping with how “water” is handled by other platforms/games.
• This would:
  • Be a longer term goal (so not happening in the immediate future), and does have a number of caveats associated with it which have to be addressed.
  • Avoid the complexities of developing a highly-specialised solution to allow the current Linden Water system/attributes to be replicated within prims, etc.
• However, if an interim solution is required to bridge the gap between what is available and what might be available in the future, it was suggested that the simulator engineering team is approached to see if something can be done with the platform’s physics system so that it might be used to simulate some Linden Water characteristics (buoyancy? swimming?) on collision with in-world objects identified as “water”.

In Brief

• Weather effects – physically-based atmospherics have come up for some internal discussion, but there is not official work planned in this areahave come up for discussion.
• PBR particles; are currently more of an “if” than a “when”.
• Terrain “exclusion surfaces”:
  • This came as a request for something akin to the water exclusion surfaces, but which would visually hide the region terrain surface.
  • These would have to be a form of exclusion volume, rather than a surface (due to the visual limitations of exclusion surfaces), and so whilst not “hard” to do, Geenz would rather defer any thought on such an item until after water exclusion volumes are a thing.
  • Doing so could enable a single object to be able to mask Linden Water or terrain – or both – depending on the switch set.
  • Please note:
    • “Excluding” terrain does not mean the ability to build tunnels, etc., “through” the existing SL terrain. This would require significant updates / changes to how the terrain mesh works / is rendered, which is not a project anywhere close to being on the road map.
    • So, any terrain exclusion would be purely visual, as noted.
• The above led to a general discussion on the differences between Linden Water and terrain (for example, whilst both are “planes”, water is “flat” (e.g. “two-dimensional”) whilst terrain is deformable (e.g. “three dimensional”), etc.).
• Geenz reiterated the current plans for mesh improvements:
  • Adding support for custom skeletons and blend shapes for avatars – but not (at least initially and subject to future decisions – physics bones).
  • LOD (level of detail) improvements – particularly for clothing, where the preference is often not to optimise with LODs, but simply provide a notecard aimed at defeating the rendering system (by advising users to massively increase the RenderVolumeLODFactor debug setting, despite the fact this can severely impact their entire SL experience or the sake of a single attachment).
    • As has been previously mentioned, one option for LODs is to have a automated generation system which will either create LOD models of content without any associated LOD models at upload, or which with replace poorly optimised LODs which do not meet specified parameters at upload.
    • The tl;dr of this work, once implemented, will effectively be: “if you don’t want auto-generated LODs, then include your own optimised LODs at upload”.

• • • Geenz further noted that this work will also mandate auto-LODs if mesh imports are updated to allow mesh objects with more than 65K vertices.
    • This conversation rolled into a more general discussion on Land Impact, the need for a better convex hull decomposer, removing Havok from the viewer, etc. However, the key point at the moment is that options / approaches / ideas are still being looked at / investigated, rather than any solution moving towards implementation at the moment. As such, more information will be made available as LL start to move is a specific direction.
• The above ran over into the development of region imposters (essentially a low-impact means of rendering surrounding regions “on the horizon” from the camera position), viewer-side work being done within the Sharpview viewer on this.
  • This looped back to how the necessary data can be obtained
  • Short version of the latter: at least a portion of the data would have to come from LL, so potentially the best solution would be the provision of some form of API). However, even for this, there are Terms of Service and other policy aspects which would have to be addressed by the Lab for this to happen, and these fall outside the purview of most User Group meetings.
• Linden Lab factoid: LL have been running analytics on client systems connecting to Second Life, and in terms of computers / laptops, it appears than systems able to handle PBR rendering decently are in the majority, with the majority of very old hardware which cannot management PBR at all being in the minority.
  • This does not mean LL is going to stop optimising for performance wherever possible, it was offered purely as a general observation.

Next Meeting

• 13:00 SLT, Thursday, October 8, 2026, at the Hippotropolis Campsite.