2025 week #10: SL CCUG meeting summary: new approaches (viewer / projects)

Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting of Thursday, March 6th, 2025.Please note that this is not a full transcript, but a summary of key topics .

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

Official Viewer Updates and Release Changes

Viewer Status

  • Default viewer: 7.1.12.13550888671, formerly the ForeverFPS, dated March 1, 2025, promoted March 5th – NEW.
    • Numerous crash and performance fixes.
    • Water Exclusion Surfaces (see below).
    • Linden Water improvements – water should now appear much as it did “pre-PBR” (note: this viewer does have known Linden Water issues, for which fixes are already going into to the next viewer update).
    • Support for 20 Picks in the viewer’s Profile floater (requires simulator release 2025-02-14 or later).
  • Project viewers:
    • Second Life Project Lua Editor Alpha, version 7.1.12.13526902562, March 3rd, 2025 – NEW.
      • Will only work on Aditi, within the following regions: [Luau Yardang], [Luau Tombolo], [Luau Mesa] and [Luau Tideland].

Release Cadence and Numbering Changes

  • The Lab has been undertaking work to further streamline viewer development and the release cycle.
  • These changes specifically mean:
    • Official viewer updates will be moving to a planned monthly release cadence.
    • The viewer version numbering will be changed to reflect the year / month of release, so 2025.03 (March 2025) will be the next viewer in the pipe, followed by 2025.04 (April 2025).
      • It is presently unclear if these number system will include additional number to indicate individual updates as a viewer moves through its own update cycle prior to being promoted to de-facto release status.
    • Within this cadence, individual updates will be incorporated into each upcoming release on an “as needed” basis – so presumably high-priority fixes will be fast-tracked into releases as they occur.
  • This also means the old Develop Github branch is now archived (archive/develop in the LL viewer Github repo), and updates / changes within it will be pulled across to active viewer repos as decisions are made as to what updates are to be implemented in which viewer in the new release cycle.
  • A key reason for altering the viewer release cadence is that LL is trying to move away from implementing large-scale projects (involving both the viewer and the simulator / back-end services) which can take months / years to deploy, towards implementing smaller, more manageable projects which can be implemented / integrated more easily and iterated upon faster, in order to deliver improvements to the platform as a whole.

Upcoming Viewers

  • The 2025.03 release is being looked at as a maintenance release, which will incorporate (among other things):
    • The Linden Water fixes referenced above.
    • Improvements for VRAM handling, including a new VRAM divisor specifically for texture usage (by default will try to use half of the available VRAM available to the viewer for textures, with the ability to manually adjust the amount used as needed).
    • Monty Linden’s improvements to avatar loading.
  • The large volume of work which had been classified as a “Maintenance B” viewer update prior to releases being overtaken by the need to focus on performance fixes  (DeltaFPS, ExtraFPS and ForeverFPS) might be incorporated in to 2025.03 release, but could be held over until the following 2025.04 release.

Linux Support

  • It is hoped that the new approach to releases, coupled with the number of Linux-focused updates pushed towards the “Maintenance B” stockpile will help with Linux viewer development and support.
  • This does not mean LL will be guaranteeing a broader, more holistic support of Linux going forward, but rather it will put the Lab in a position to better address the question of on-going Linux support.
  • The above noted, Linux support is described as becoming “more and more of a forefront priority” in terms of how the Lab might more forward in supporting it, particularly as there are some internal (to the Lab) dependencies on supporting it.

Open Source Programme Revamp

  • In line with all of the above, Geenz Linden has put forward a proposal for revamping the open source programme and making it more responsive, inviting input from TPV and open source developers.
  • One aspect of this is the Lab will be clearly flagging areas in which they would specifically benefit from open source developer assistance.
    • A developing list of areas where such help / code contributions would be welcome can be found here.
  • Any open source developers who have not seen the proposal are directed to it.

Beta Testing New Features and Capabilities

  • As has been previously stated, one aspect of feature development and implementation will be adding features and capabilities to the viewer and then guarding them against use via flags controlled on the server-side.
    • This will allow features and capabilities to the viewer which might be back-end support requirements, and have the viewer completely ignore them until such time as the server-side flag is set so that they can be used.
    • It is hoped that this will again allow for a faster implementation and deployment of features and capabilities.
  • Given this, Aditi (the Beta grid) will remain as the place for general new feature testing and bug-hunting.

Water Exclusion Surfaces – Re-cap

  • Now available in the Forever FPS release, and all third-party viewers merging with that code base are Water Exclusion Surfaces (WES).
  • These in a similar manner to the old invisiprims:
    • When seen from above will “hide” Linden Water -thus allowing water to be excluded from inside boat hulls, dry docks, etc.
    • If looked at from directly below, it will cull the underwater plane but leave the water fogging.
A very(, very) basic example of a Water Exclusion Surface hiding Linden Water
  • Currently, all  invisiprims fitting the above use-case should now work, together the with scripts for converting prims into invisiprims.
  • A new UI element for more easily creating WES items will be added to the viewer in a future release – possibly 2025.04.
  • WES will work on any prim or mash face except rigged mesh or with attachments by intent due to performance issues.
    • Rigged meshes will likely be rendered black.
    • Attachment will render, but the exclusion surface will be ignored and will not hide Water  or rigged mesh (the rigged mesh will likely be rendered black.
    • Additionally, WES will not work with the system avatar.
  • Water Exclusion Surfaces will not provide volumetric water exclusion (e.g. “hiding” water from the rooms of underwater buildings).

Mesh Import Formats – glTF Mesh Support

  • The removal of support for the COLLADA mesh file format from Blender under Linux has raised  concerns about the longevity of the format in general in regards to Second Life.
  • LL are looking to implement glTF mesh imports for Second Life – something which has been promised since work started on moving Second Life towards compliance with the glTF specification.
  • However, the overall scope of the project has changed. Rather than being the overarching project with scene imports, etc., the work is now being focused on “just glTF mesh”.  See this planned implementation feature for details.
    • The idea is to have the glTF mesh import to work in the same manner as the current COLLADA .DAE import floater, and this work should be surfacing in a viewer in the near future.
  • This revised approach does not mean the rest of glTF import is “going away”; it is more a re-prioritisation of work and breaking things down into smaller deliverables, in keeping with LL’s desire to implement and iteration projects and work faster than might be achieved through single grand “omnibus” projects.
  • Along with this, two requests were asked of LL:
    • The ability to select which part of a mesh model are to be uploaded (e.g. via check box), rather than defaulting to the entire model.
    • The ability to select at upload which attachment point rigged meshes should attach to, so as to encourage creators to do this, rather than leaving them defaulting to the the right hand position and letting the rigging take care of appearance.
    • Both of these ideas were seen as beneficial – with the caveat that they would require additional UI design and testing / iteration, adding further complexity to the work, delaying the initial release. As such, they are unlikely to be a part of the initial release of the glTF mesh uploader, but could potentially be looked at as future additions to it.
  • LL is not currently working on a means for automatic LOD generation on in-world objects.

In Brief

  • There are continuing reports of people who are on-line reporting as off-line once again. Canny reports if encountered, included where the issue occurred.
  • There are plans in-hand for LL to hold a Town Hall in which the product development roadmap for Second Life will be discussed.  Details are currently TBA.
  • Alpha gamma work:
    • In order for PBR lighting to render anywhere close to correctly, alpha blending had to be switched from SRGB to linear colour space.
    • This caused some older content using Blinn-Phong, to look either more opaque or more transparent than in did pre-PBR.
    • The fix for this giving people the ability to adjust the alpha/gamma on per texture entry for the object (including no mod items).
    • However, the work was targeted via the old viewer development branch, and needs to be re-targeted for implementation as a part of the new viewer release cycle, and this has yet to be done.
  • Puppetry project:
    • There are currently no plans to re-start the Puppetry project.
    • There are some significant technical hurdles LL believe need to be understood and addressed (such as a joint transmission between viewers), which the project as a whole needs to be reviewed in terms of requirements and priorities in order for it to be more easily addressed.
  • Terrain painting (summarised here) remains on hold due to other priorities.

Next Meeting