Day: March 14, 2026

2026 week #11: SL CCUG meeting summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from:

  • My chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, March 12th, 2026.
  • Please note that this is not a full transcript of either meeting but a summary of key topics.
Table of Contents

 

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 and is held 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  – Legacy search; WebRTC improvements; QoL improvements – 26.1.0.22641522367 – March 12 – NEW
  • Second Life Project Viewers:
    • Second Life Lua Editor Alpha viewer 26.1.0.21525310258, February 12.
    • Second Life Voice Moderation viewer 26.1.0.20139269477, December 12.
      • Introduces the ability to moderate spatial voice chat in regions configured to use webRTC voice.
    • Second Life One Click Install viewer 26.1.0.21295806042, January 26, 2026 – one-click viewer installation.

Viewer Notes

Viewer 2026.01

  • Promoted to default release ahead of the meeting – see above.

Viewer 2026.01.o1

  • The next viewer targeting promotion to default status.
  • Comprises the one-click installer / updater.
  • It is hoped promotion of this viewer is “weeks away” rather than “months”.

Viewer 2026.02

  • 2026.02 remains on track for the “Flat” UI and font updates + plus a possible refresh of the log-in splash screen.
  • It now also includes the WebRTC voice moderation capabilities (as seen in the project viewer) to help align viewer-side WebRTC updates more with the hoped-for server-side deployment.
Example of the upcoming flat UI. Via: Geenz Linden / Github #4681/2

Viewer 2026.03

  • Some changes on this – originally defined as the SLVP – Second Life Visual Polish viewer, the status has changed such that 2026.03 is liable to one of the following:
    • The SLUA viewer update, or
    • The Visual Polish viewer, including the long awaited SSR improvements. PBR specular for residents who are more familiar with the old Blinn-Phong work flow + HDR controls in EEP so residents can decide how bright or dark things should be, or
    • A new performance improvements viewer option.
  • It is possible that further water improvements might find their way to this SLVP viewer, and also that as some of the updates require sever-side changes, the promotion of SLVP might be subject to delay once available, to allow time for the server changes to be slotted into the simulator release schedule.
  • It is also possible some of the above might be combined into a single viewer release under the 2026.03 banner.
  • The potential for making monthly promotions to get all the current inflight viewers up to release status is also being discussed at the Lab. 

Viewer Performance Discussion

  • Better performance is obviously always a benefit to using SL, and currently there is an internal discussion at the Lab overtrying to make some further performance improvements ahead of any release of the SLVP viewer, to enable the latter to better leverage them (e.g. by “shaving off” some VRAM usage).
  • VRAM is particularly problematic for performance as many SL creates will try to crank the texture resolution for every single material slot to the maximum, whether it is visually beneficial to do so or not. The 2K white emissive texture is an example of this.
  •  Geenz Linden has been making changes to introduce “texture channels”. That is, to more intelligently stream specific maps  – diffuse, normal, emissive,, specular, etc., at different resolutions to more intelligently manage VRAM usage with little reduction by way of a scene’s visual fidelity, particularly in scenes with a lot of high resolution textures for every material / material slot.
  • It has been noted that for this to work, there must be a means for users to make adjustments to suit their visual needs. These might take the form of a texture quality drop-down in the viewer’s Graphics settings.
  • The texture discussion led to musings on how best to identify texture size / resolution, and the complexities involved (e.g. the asset system doesn’t know – or need to know the specific resolution of a texture, it doesn’t entirely make sense for the logical to determine a texture’s resolution and how to manage it o sit within the server, which leaves the viewer – which requires the texture to be downloaded anyway – and such controls can be ignored by specific viewers simply by not adopting the code, so proactively handling texture resolutions is complicated.
  • Other work on performance might see changes to the avatar render cost calculations because, ironically, these appear to impact performance.

General Discussions

  • SLua:
    • There is a “breaking change” coming to SLua “in the next couple of weeks” which is apparently not deemed worthy of a blog post, so notification will be via Discord and social media – because “communications”.
    • It will require every current SLua script to be recompiled and restarted.
  • A discussion on using GPU texture compression to help with performance – something that would require work on LL’s part, but not out of the question for consideration.
  • HDRI support for environments – again, not out of the question. The major question is how are they to be encoded:
    • Creating a new asset type specifically for them is not seen as “super practical”.
    • While the JPEG2000 specification supports HDRI, it is “probably not the most effective application for SL’s specific use for HDRIs.
    • There needs to be a means of encoding them that is GPU memory friendly, as HDRIs are memory heavy (whilst HDRIs are already used in the rendering pipeline,  LL uses them as sparingly as possible for this reason.
    • EEP would also require updates to fully support them.
    • None of the above is seen as particularly impossible to overcome, it does require further discussion among all the relevant stakeholders0.
  • It is hoped that tweaks to the EEP ambient sky settings will help make environments using PBR to “pop” more and will help improve the current Mainland ambient lighting issues.
  • A number of general discussions on WIBNis (“wouldn’t it be nice if….”), none of which are currently in development..

Next Meeting