2025 week #14: SL CCUG meeting summary

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, April 3rd, 2025.

Please note that this is not a full transcript, 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.
  • 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 Status and Updates

Viewer Status

Upcoming Viewers

  • The current version of 2025.03 will remain in soak for the next few days in the hope that it will be ready for promotion to de facto release status “in the very near future”.
  • The April release – 2025.04 – is provisionally targeting:
    • The glTF mesh uploader (based on the current .DAE mesh uploader and doing pretty much the same). Again, please note that this is not the full glTF scene importer which has been discussed at previous CCUG meetings; that work is being broken down into smaller, more easily managed projects.
    • Possibly – and subject to confirmation – re-enabling subfolders within the My Outfits folder.
    • Hover height improvements.

glTF Mesh Upload / Importer

  • The outline of this work can be found in Add Simple (llmesh) GLTF Model Import.
  • In short: it should be taken that whatever can be done within the existing .DAE uploader will remain so for uploading glTF mesh models at the first pass, and enhancements will come later.
    • This means that anything that is compliant with COLLADA which can be currently imported to SL via the uploader will work under glTF.
    • Any “new” capabilities not available to the current uploader will then be duly considered an implemented over time.
    • This is not a replacement for COLLADA format uploads – it is an addition to; uploading of .DAE objects will remain possible unless support for COLLADA becomes untenable.
  • The reason for this approach is to avoid having a large-scale glTF import project (variously referred to has “scene import” or the “Post-Materials Features Project” or PMFP), which would take months / years to develop, enhance and ship, and instead be more spritely in development and improvements.
    • This does not mean that everything that had been targeting the scene import / PMFP work will be abandoned.
    • Rather, it means those aspects which could end-up delaying it due to the amount of research, development and testing required to support them (e.g. custom skeletons / rigged meshes) can be put to one side for future development, rather than preventing the foundations to enable them from being laid.
  • The back-end format for imported mesh objects (“SL mesh”) will not be changing at this time.  One of the reasons for this is the “SL mesh” format allows for easy upload of selected LODs.
    • However, this does not mean the format will not be improved upon in the future (and even a possible hybrid glTF / SL Mesh format implemented).
  • One aspect of the new mesh uploader will be the potential for adding materials-related glTF extensions to the current Khronos glTF specification.
    • These include (but are not limited to) the likes of the glTF specular extension, transmission, IOR, iridescence, emissive strength etc.
    • Geenz Linden is particularly interested in these, as the uploader allows them to be quickly added, and he would like to put together a package of extensions that a) creators can readily use; b) help move things towards being better placed to support other aspects of the PMFP work.
  • There was more discussion on support for uploading complete mesh region surrounds – this again was seen as something for consideration after the initial phases for implementing the glTF upload have been completed, and something possibly requiring the implementation of something like a node hierarchy.

Texture “Stutter” Issues

  • The recently introduced changes to texture use of VRAM have resulted in some users experiencing “viewer stutter” when the viewer is loading / uploading textures in a scene.
  • As a result, the options to define texture VRAM settings have been disabled in the 2025.03 RC.
  • Geenz Linden is anticipating being able to work on this issue later in April with a view to determine the cause and hopefully rectifying it.
    • This work will likely also look at texture streaming in general and make adjustments where textures tend to get loaded at resolutions that “don’t make sense” at the time of loading, and so improve that.
  • It is not anticipated that this work will start to surface much before the 2025.06 viewer development cycle.

Removing Scale From LI Calculations

  • Signal Linden highlighted a Feedback Ticket he has raised, proposing the removal of scale from Land Impact calculations, which has been touched upon at the last couple of SUG meetings.
  • However, there are now a few caveats starting to appear possibly impacting “everything from rendering to physics”, which require further internal discussion at LL.
  • One of these is the LI goes in both directions – so while removing scale from the calculation may be positive for a net reduction in the LI of objects that have been scaled up in size – it could have a net negative for objects scaled down (e.g. you have a group of objects each with 20 LI, and have scaled them down so each only has 10 LI, removing scale would reset them to 20 LI apiece).

In Brief

  • Allowing larger Linksets: raised at recent SUG meetings as well, this has not been ruled out for the future, but has some inherent issues, notably:
    • Limitations within the current physics engine, which would probably have to be updated.
    • Interest List issues – if a scene has a particularly massive linkset within it, it could simply fail to render in a viewer using a limited Draw Distance, simply because the root prim is outside of the viewer’s DD, even if child elements of the object are within range.
  • PBR Bakes on Mesh: this is seen as having a minimum of two requirements:
    • Providing PBR specular support.
    • Being able to set blend modes for different layers. This has some added complications in how blend modes should work for different types of maps, and this needs to be worked through in terms of implementation.
  • LSL Support for PBR:
  • The viewer / graphics roadmap is being reviewed, and it is hoped that and updates / decisions on direction will be available for discussion at the next CCUG meeting.
  • The is no time frame on the delivery of “water exclusion volumes” (i.e. the ability to hide Linden Water entirely from the inside volume of an underwater room). Again, it is not because this cannot be done, but rather there is other work deemed as having a higher priority LL wish to address.
  • It was found that the water shoreline fade was causing issues with shoreline water effects (e.g. things like mesh shoreline elements using alphas to simulate the ebb and flow of shoreline tide looking broken / patchy / flickering), and so the fading has been disabled until the issue can be corrected.
    • It is possible this might for a wider piece of work to improve water / sky environment assets in general to make the ambient environment rendering less likely to break content.
  • Improving light sources (e.g. punctual lights, better point lighting, etc.) is seen as a future issue to be addressed before of current limitations within the current forward rending. Forward+ is one potential way forward, but this would require proper scoping ahead of any attempt to change the current rendering system.

Next Meeting

2025 week #12: SL CCUG meeting summary: PBR / BOM

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 20th, 2025.Please note that this is not a full transcript, 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.
  • 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 Status and Updates

[Video: 02:07-8:00]

Viewer Status

  • Default viewer: 7.1.12.13550888671, formerly the ForeverFPS, dated March 1, 2025, promoted March 5th – No change.
    • Numerous crash and performance fixes.
    • Water exclusion surfaces.
    • Water improvements.
  • Second Life Release Candidate viewer 2025.03 version 7.1.13.13906285233, March 20th – NEW.
    • New UI element for water exclusion surfaces: Build / Edit floater → Texture Tab → Hide Water checkbox.
    • The maximum amount of Reflection Probes can now be adjusted to better accommodate low VRAM scenarios.
      • Values will be set automatically depending on your chosen graphics quality, OR
      • Use Preferences → Graphics →  Advanced Settings →  Max. Reflection Probes to manually set. Note that lowering the value on this slider can help within environments where a lot of manual Reflection Probes have been placed out.
    • An issue with being unable to see Sky Altitude values in the Region/Estate window has now been resolved.
    • Preferences → Graphics → Max. # of Non-Imposters has been renamed Max. # of Animated Avatars for clarity.
    • Bug and performance fixes and memory optimisations.
Updates to the UI elements in the 2025-03 Release Candidate viewer (click for full size, if required)

Upcoming Viewers

  • The hope is that the 2025.03 RC viewer will progress fairly rapidly through its pre-release iterations and be promoted to de facto viewer status “soon” – most likely early April.
    • Again, this viewer includes many fixes and and work originally scheduled for the 2024 “Maintenance B” RC, which had been held over due to the focus on the performance improvements work.
  • The April release – 2025.04 – is provisionally targeting:
    • The glTF mesh uploader (based on the current .DAE mesh uploader and doing pretty much the same). Again, please note that this is not the full glTF scene importer which has been discussed at previous CCUG meetings; that work is being broken down into smaller, more easily managed projects.
    • Possibly some additional Materials features, although these are currently subject to shifting priorities.
  • Geenz Linden reiterated the idea that the new viewer update process is intended to provide work on a major feature, and also include viewer quality of life improvements – notably requests / fixed file via the Feedback Portal.

Bakes on Mesh Improvements – PBR

[Video: 12:17-24:42]

  • A bump of a feature request to provide the ability to make alphas for AUX BOM layers led Geenz to note that there are internal discussions on Bakes on Mesh and what additional things / features the Lab would like to tackle with regards to it (e.g. blend options, including the ability to blend materials attributes).
  • However, nothing is as yet on the roadmap for implementation.
  • This led to a general request on feedback as to what creators would like to see by way of BOM improvements. Responses included:
    • Full PBR Materials compositing / baking.
    • The mentioned materials blending + Photoshop-like blend modes + the ability to have blends (+ opacity) user-modifiable, even if the assets themselves are not.
    • Provide opacity sliders on the bakes slots, so as to allow things like the creation of a universal tattoo in 100% opacity black, then being able to ‘fade’ it without using more textures with separate opacity settings – see: Introducing Opacity Control for BOM Layers.
    • The ability to drag different BOM layers around when changing layer priorities, rather than having to use the current Up/Down buttons in the appearance floater.
  • Additional requests should be filed via the Feedback Portal.
  • A request for real-time in-viewer painting for alpha layers with a very basic editor was also requested as a part of the above, with Geenz indicating this would be unlikely any time soon.
  • Providing full support for PBR materials within the Bake Service is being actively “thought about” at the Lab, but Geenz noted there are some caveats. For example:
    • There is both a compatibility issue and some degree of “convertibility” between supporting a mix of PBR materials and “legacy” (Blinn-Phong) materials within BOM.
      • The compatibility issue is that both are largely different in how they operate.
      • The “convertibility” aspect lies in the fact that the specularity channel within “legacy” materials was developed with what was at the time (2012) the glTF specularity workflow. This potentially opens the door towards mixing both.
    • However: there are multiple considerations when it comes to possibly supporting both Blinn-Phong and PBR materials in BOM – particularly when it comes to ensuring the end-user understands what is going on, what might happen when editing / combining layers, and the whole question of how the necessary guidelines / caveats / warnings can be meaningfully put before users without causing confusion.
    • These internal discussions are currently on-going.
  • The idea of being able to modify blending when the assets themselves are No Mod was described as “an interesting one”, with Geenz suggesting it is something that should be posted as a request to the Feedback Portal to gain broader feedback from the user / creator community before any specific actions are taken, particularly given changes to the permissions system can lead to debate.
    • This led in part to an additional discussion on the idea of “opening” the permissions system in other areas – such as allowing users the ability to colour tint meshes that are otherwise No Mod, or add glow, if required).
  • During the discussion Geenz noted that in general, PBR is unlikely to be getting displacement mapping “any time soon”.

In Brief

  • [Video: 6:02-7:05 + later in the meeting] glTF mesh uploads:
    • The outline of this work can be found in Add Simple (llmesh) GLTF Model Import.
    • In short: it should be taken that whatever can be done within the existing .DAE uploader will remain so for uploading glTF mesh models at the first pass. Enhancements – including possibly forking the glTF  uploader into its own floater distinct from the .DAE uploader – will come later.
    • Given this, the ability to upload custom skeletons / rigs will not be supported. This does not necessarily mean that custom skeletons / rigs will “never” be supported – rather than it is a more significant project that requires further consideration before a decision can be made.
    • A request was made to be able to select maps / materials for upload in the glTF uploader, e.g. whether it should be a selectable list rather than a drop-down (for materials – which defaults to one or “bulk”) – this also has been included in the Feature Request.
  • [Video: 8:29-11:59] Kyle Linden sought information on why those using vehicles – notably boats / aircraft disable sky rendering (via Advanced → Rendering Types) during normal game play (e.g. not for matters of terraforming, etc.).
    • The majority of feedback within the meeting suggested the core reason to be doing so gives a small FPS boost (and there have been reports filed that sunset / sunrise rendering can impact FPS).
    • Anecdotally, it was suggested that it can improve region crossings, although examples weren’t cited.
    • Some also stated they did it to stop the “frantic” cloud scrolling when moving between different regions with different EPP settings (why not just apply a preferred EEP setting to your avatar to avoid this?). This prompted Geenz Linden to remark that there have been some internal discussions about making the transitions between EEP setting less jarring.
  • [Video: 26:23-27:53] some are reporting increased frequency of texture thrashing on PBR viewers over non-PBR viewers.
    • This is in part why LL has been adding further controls over texture use of VRAM.
    • Manually adjusting VRAM usage may not always resolve all issues of texture blurring (as there can be multiple reasons for it), and tweaking thing like the slider for adjusting the amount of VRAM available for texture loading can make things worse in certain conditions – so keep this in mind.
  • [Video:37:02-38:26] A request was made via chat for the Feedback portal to have a means for people to view all the tickets they have filed. This was seen as something that the Canny developers would need to implement in general, rather than a capability LL could add to the system, and so should perhaps be requested on Canny itself!
  • [Video: 38:51-41:08] It’s been reported that the eye-dropper for tinting PBR surfaces from the colour picker swatch is not working. This extended into comments that copying / pasting materials between surfaces can fail and planar face alignment not working. Fixes for issues such as copying PBR materials are within the 2025.03 RC viewer, together with a fix for PBR materials not always persisting when applied to a mesh face.
  • The last 20 minutes are a general discussion on VR support (not yet, to much work in other areas to complete first); reflection probe fixes (such as better blending) to be looked at; anecdotal comparisons on frame rates being experienced at the meeting (anecdotal as no real indication of overall graphics settings being used, direction people had their camera point & the complexity of their field of view, etc.); general performance and performance tracking.
  • [Video: 58:12-1:00:05] Part of the discussion on frame rates / performance it was noted that turning off the name tag display in the viewer Preferences → General → Name Tags options) can cause an increase in FPS – most likely due to the use of alpha layer in name tags pulling on performance.  This led to request for feedback on whether the default should be left at Name Tags On & left to a person’s individual choice to alter it; or perhaps change it to Show Briefly; or perhaps alter the behaviour so the name tag only renders when the mouse is hovered over an avatar (without necessarily having the hovertips enabled).

Next Meetings

  • Subject to confirmation: Saturday CCUG, Saturday, March 29th, time TBA.
  • 13:00 SLT, Thursday, April 3rd, 2025, at the Hippotropolis Campsite.

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

2025 week #6: SL CCUG meeting summary: Linden Water news

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, February 6th, 2025.

Please note that this is not a full transcript, 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 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 Status

  • Default viewer: version 7.1.11.12363455226, formerly the ExtraFPS RC (multiple performance fixes, aesthetic improvements and UI optimisations), dated December 17, 2024, promoted December 20, 2024 – No Change.
  • Release Candidate: Forever FPS, version 7.1.12.12999043440, February 4, 2025.
    • Numerous crash and performance fixes.

2K Bakes on Mesh

Linden Water Updates – Geenz Linden

  • The “not so great news”: it is not possible to get Linden Water to look exactly as it did “pre-PBR”.
  • The “great news” is that LL can get very close in terms of overall look.
    • Most of the old Fresnel reflection/refraction, together with some of the underwater fogging has been restored.
    • Some of the fixes for water are currently in the very latest Firestorm Beta (and will presumably be going into the official ForeverFPS RC, if not there already).
    • Feedback on the changes  – with the caveat things cannot (per above) ever be 1:1 with “pre-PBR” water appearance – is regarded as very important in order for the Lab to judge how well the changes are working.
  •  This work is not the end of water tweaks; Geenz is looking at restoring real-time water reflections once the performance impacts of doing so can be assessed.
    • This will involve the use class of Hero reflection probe (like mirrors), which means the mirror capability as a whole will need additional optimisation work, as any frame rate drops it might incur are currently deemed as “not acceptable” by the team.
    • In addition, Geenz is looking at improving reflections more generally via the automatic reflection probes, such as reducing the moiré effect of Screen Space Reflections (SSR) on water.
    • The above will hopefully be released either in a dedicated viewer to follow ForeverFPS, or rolled into the viewer(s) directly following ForeverFPS.

“Hide Water” – Water Exclusion Surfaces

  • Geenz Linden has been working to provide a means of excluding Linden Water from internal volumes such as boat hulls, and has arrived at a solution with the technical name Water Exclusion Surfaces (WES).
  • The capability will hopefully be surfacing in an update to the ForeverFPS RC viewer. When it does:
    • It will likely be an option setting within the Texture tab of the Build / Edit floater, the name of which is still TBD, but is currently being referred to as “Hide Water”, and will work with most prim and mesh shapes to which it is applied (see the limitations notes, below).
  • When used with boats and similar:
    • It will cull Linden Water and the associated subsurface fogging when looking down on the hull / surface from above.
    • If looked at from directly below, it will only cull the underwater plane, the fogging will be intact.
  • Water exclusion surfaces should work as well as / better than invisiprims (e.g. they won’t clash with worn alphas or cause shader issues, occlusion culling will work correctly, etc.
  • Limitations:
    • The capability will not provide volumetric water exclusion (e.g. “hiding” water from the inside of underwater buildings) –  This is a “future looking thing”, which might be addressed in the future. It is intended for use in boats and similar.
    • It is not intended to replace all use cases associated with invisiprims, and should not be taken to be a “replacement” for the latter.
    • The capability will not work when incorporated in an attachment (the 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). This is by intent, to limit performance impacts. Also do not work on the system avatars.
    • There are some additional limits to ease performance impact (e.g. fogging will not get really dense when looking up through the water plane).

In Brief

  • Placing Linden Water on prims or mesh: not a capability currently being developed, but one that is subject to internal discussions at times.
  • It was again noted that many creators are still awaiting scripted support for PBR (e.g. PBR specific texture offset / UV coordinate manipulation).
    • This support is described as “still on the roadmap”, but may have had other priorities push it down the list of priorities.
    • The fact that creators are waiting on them will be taken back from the meeting for internal discussion.
  • Cosmic Linden’s PBR terrain painting work remains on hold due to her being engaged in other work.  Work on glTF  mesh import is much the same.
  • Geenz noted that following ForeverFPS there is a lot of additional render maintenance and similar work required on the viewer as well as additional  / in progress feature sets, and all of this work needs to be prioritised.
  • Maxwell Graf recently posted a request to increase the polygon resolution for terrain  – and asked about the potential technical / performance issue this might cause (if any), and whether it is something that might be selectable (e.g. if you want the higher polygon resolution then enable it on your region(s), if you don’t – then don’t!).
    • The short answer to this, there is no technical reasons as to why not – beyond testing and assessment for unforeseen impacts; although a) the request itself has yet to be officially responded to; b) the above doesn’t necessarily mean it will be acted upon.
    • However, it did led to LL requesting people with ideas for SL terrain to file feature requests for future consideration.
  • A further request was made for scenic backdrops to be available for regions (e.g. rendered options that can be rendered in place of the water and taking the form of a range of in-viewer selectable options – cityscape, forest, hills, mountains, etc., – so that actual mesh / sculpty based region surrounds do not have to be used.
    • This is something Sansar did reasonably well – including custom surrounds.
    • Feature requests via the feedback portal were asked for on this.
  • It was noted that SL lighting still needs to be updated – again not on the immediate roadmap, but under consideration; however, the hoped-for punctual lighting has been pushed back.
    • An issue with updating lighting (and things related, like how shadows function), is that the lighting system was developed at a time (early 2000s) where it had to be constrained. While things have developed to a point where those constraints may no longer be applicable, they are nevertheless heavily baked-in to SL, and will require considerable effect to unpick and replace.
    • Feedback through the feedback portal on what people would like to see with lighting / shadows was requested, in order to help the Lab further understand expectations, determine options and factor feedback into a more holistic approach to lighting in SL at some point in the future.
  • Screen Space Reflections (SSR): this is again something Geenz would like to get back to, but (again) would like feedback via the feedback portal on issues people have why they do / do not use SSR  –  particularly issues they have with SSR that are not related to Linden Water (e.g. on glossy surfaces), what they feel is needed, etc.
    • The general feedback on this was that SRR on other surfaces works reasonably well (if with random noise in places – which Geenz believes he has a handle on fixing in the future), and possibly increasing the angle at which it can be seen to take effect).

Next Meeting

2025 week #3: SL CCUG meeting summary

Lights in White Satin, November 2024 – blog post
The following notes were taken from:

  • The livestream and my chat log of the Content Creation User Group (CCUG) meeting of Thursday, January 17th, 2025.

Please note that this is not a full transcript, 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 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 Status

  • Release viewer: version 7.1.11.12363455226, formerly the ExtraFPS RC (multiple performance fixes, aesthetic improvements and UI optimisations), dated December 17, promoted December 20, 2024.
  • Release Candidate: none at present.

General Update & Runitai Linden’s Departure

[Video: 2:11-7:20]

  • Numerous bugs and issues have been reported following the ExtraFPS viewer promotion, and as a result, these seem likely to be developed into a bug-fix viewer (“ForeverFPS”), with an initial cut at an RC version potentially coming in the next week or so.
  • There are “numerous discussions” occurring at the Lab regarding possible future projects, but nothing at present to announce.

Runitai Linden Departing LL

[Video: 3:52-7:20]

  • It was announced that Runitai Linden (often referred to as DaveP) is departing Linden Lab to enter public service.
  • Runitai commented directly on his reasons for departing the Lab and his feelings about doing so, however, rather than drop them here for those who prefer to read rather than listen, I’ve provided a transcript with some additional notes: Runitai Linden hears the call of Public Service.

2K Bakes on Mesh

[Video: 12:52-14:47 and 15:10-17:03]

  • It is believed the 2K bake updates for the Bake Service are “ready to go”, having cleared QA per my notes from the SUG meeting.
  • The viewer updates required to allow 2K textures to be used with wearable layers are apparently merged into the Develop branch, but yet to surface within an RC viewer built from that branch.
  • In theory, the back-end support could be enabled pending the viewer update, because it will not interfere with current rendering, as the viewer should continue to limit wearable textures to the current maximum of 1024×1024 until it is updated to apply 2K bakes. However, discussions on how to proceed pending the viewer update will be taken-up internally by LL.

In Brief

  • [Video: 10:05-10:39] A request was made for Darcy Linden to attend at least some CCUG meetings to discuss the Lab’s AI character generation project (see: Introducing the Character Designer (Alpha) and this follow-up forum thread). Vir Linden indicated he will check with Darcy on plans to join / hold meetings.
  • [Video: 14:48-15:00] here have been multiple requests / discussions over the years about the potential of an Inventory archive to allow people to reduce (some of) their Inventory bulk / bloat by archiving items through a supported system rather than just boxing them. Currently, such a service is not on the roadmap.
  • [Video: 17:32-22:55] A request to add the type of client (viewer, browser, SL Mobile) some is using to their avatar tag “to help people help others”. Surely the easiest way to find this out, as a mentor / someone giving assistance, etc., is to ask (“Are you using SL on a Mobile or through a browser, or have you installed the client on your computer?”).

Comments from Philip Rosedale

The core CCUG meeting was shortened to 30 minutes due to LL meeting conflicts. However, Philip Rosedale dropped in to provide assorted comments and feedback.

  • [Video: 24:40-25:35] On AI and Scripted Agents, etc.: thinks the Lab’s policy on AI and bots is going to be “a complex and evolving matter”, and that as AI becomes more powerful, people will need to come together to decide how best to handle it in SL, given the variety of views.
  • [Video: 27:39-40:14] The above indirectly led to a discussion on being able to identify bots in Group chat sessions and IMs similar, where it may not be obvious that messages are being bot / AI-generated.  There are flags which should be used with scripted agents and which should force a message to indicate a messenger is a scripted agent in IMs; however, the issue appears to be that chat and IM can get flooded so quickly with text, the notification can be missed. Suggestions were made to make this text a different colour and possibly pin it to the top of the chat / IM window.
    • This resulted in a list of categories of bot bad behaviour being drawn up, including begging,  phishing, undesired group chat, traffic gaming, data collection (e.g. Bonnie Bots) even overwhelming users with NPC text & failing to account for other interactions.
    • Overall, this became an extended conversation, and following the video is recommended for full context.
  • [Video 25:45-26:48] On promoting Second Life as a place to hold work meetings: does not believe the platform has reached that point, because of the lack of nuance within avatar communications – humans really heavily on non-verbal communication cues for further subtext, etc., in exchanges, and SL currently cannot provide these.
    • [Also, as a sidenote, LL put considerable effort into trying to develop SL as a behind-the-firewall “business application” between 2008-2011 with the Second Life Enterprise (SLE) package (licenses at around US $55,000, but I cannot remember how many avatars came with that license), and that didn’t go so well at the time – potentially because of the shortfalls Philip mentions being among the reasons it didn’t really gain a lot of traction at the time.]
  • [Video: 40:14-50:10] A discussion on resource allocation through Project Zero to allow fair and balanced access to SL at minimum / no cost through the browser for people without it being abused (e.g. by people creating and running dozens / hundreds of bots through the browser access, thus running up costs to a point where others have to start paying at a higher rate.
    • As this was a brainstorming session producing multiple ideas (e.g. limiting browser access to subscription accounts  – potentially missing the people the service is really geared towards helping, as they may not have subscription accounts; controlling via some form of 2FA; utilising Payment Information on File both as a means to limit access to those who are PIOF and a means to prevent them logging-on more than one account through the streaming service at one time, etc.), please refer to the video.
  • [Video: 50:11-54:08] When will voice services switch solely to WebRTC? – still waiting for more users to move from Firestorm 6.6.17 to a PBR-enabled version of Firestorm (which will hopefully happen once Firestorm release a version based on the ExtraFPS viewer code, allowing for the issues for poor Linden Water quality – reflections, etc.).
  • [Video 55:50-1:01:05] Discussion on exclusion volumes for boats under PBR (as re-enabling the forward renderer to allow invisiprims to hide water volumes is not going to happen). Runitai indicated there are potentially alternatives to allow such exclusion volumes to work.
  • [Video: 1:01:11-1:02:55] Comments on alternative rendering engines and content support segueing into thoughts on why other VW platforms have never achieved the level of adoption by users as witnessed with Second Life (including Sansar, OpenSim and Meta).

Next Meeting

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.