2025 week #29: 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, July 17th, 2025. Please note that this is not a full transcript, but a summary of key topics, and timestamps are to the official video, embedded at the end of this report.
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

  • Official Viewer: 2025.04 – 7.1.14.15192634334, issued May 25, promoted May 28 – No Change.
  • Second Life Project glTF Mesh Import, version 7.1.14.15976006598 July 2 – No Change.
    • This is an early Alpha release with some of the rough edges and already resolved many bugs and crashes, although more are to be found, together with general feedback from the community. Please read the release notes if you intend to test this viewer.
  • Second Life Project Lua Editor Alpha (Aditi only), version 7.1.12.14888088240, May 13 –  No Change.

 glTF Mesh Uploader

[Video: 1:41-3:03 – and as noted below]

  • This project is moving into beta testing, and the updated viewer for beta testing is currently with QA, and should appear on the Alternate Viewers page “pretty soon”.
  • Again, as a reminder this project is providing the overall functionality available for uploading COLLADA .DAE files to the upload of glTF mesh files. As such all current constraints will continue to exist within this work.
  • Enhancements will be coming (and Feature Requests have been received for things like increased tri counts and vertex limits), but are regarded as a separate tranche of work.
  • [Video 4:50-6:00] A request was made for enhancements to the convex physic hull limits (e.g. number and complexity). This would require simulator-side changes, as some of the constraints are enforced server-side, and are “fundamental” to how Second Life works.
    • There is no work currently being planned around this.
    • In general it was considered something that might be better tackled if / when the Lab gets to “re-doing” SL’s internal mesh format.

Lighting Discussion

  • [Video 6:05-7:40] Light and particle exclusion volumes – the question was asked that as SL now has water exclusions “volumes”, how hard would it be to do the same for lighting and particles (e.g. to prevent lighting in one room bleeding into another).
    • In actual fact, SL does not currently support water exclusion volumes – it only supports water exclusion surfaces, which operate more-or-less in 2 dimensions to “hide” water”, rather than excluding it from a volume area.
    • Geenz noted that water exclusion and light / particle exclusions are “very different” in nature, with water exclusions surfaces being handled by a dedicated rendering pipe, and both light and particles requiring their own specific solutions.
    • He further noted that for lighting, other engines typically support linking a light source to a volume, constraining the light to it. SL does not have that capability, and while it would not be impossible to enable it, the work would be non-trivial, and is not something being looked at. His preferred approach would be to get shadows working more efficiently and at a larger scale.
  • [Video: 10:39-11:25] Related to the above, it was noted that non-shadow punctual lighting could help with lighting / darkness / shadow issues. These had been something Runitai Linden had started to look at prior to departing the Lab; in Geenz’s view, a means to determine which lights should / should not cast shadows might offer a partial solution.
  • [Video: 12:17-13:43] Geenz also noted there are been several requests on Canny for lighting improvements, and he would like to get some work on lighting prioritised. However, there is a large amount of work already identified for the viewer, and so prioritising and further work has the be done “carefully”.
    • He also noted issues with point lights were noted (fall-off being incorrect; the light radius tends to exceed the value set; point light penetrate objects far too much, etc), and suggested they could potentially benefit from a revisit at some point.
  • [Video: 24:36-25:30] Would it be possible to create a reflection probe-like if volume and assign an EEP setting to it?
    • There is no means to do this directly, but in theory could be done via LSL.
    • Rider Linden noted that by using an Experience, it is possible to trigger EEP settings for individual agents, which might achieve something similar.
    • A Feature Request on the idea was requested.

Viewer-side Havok Sub-Library and Pathfinding

[Video: 25:39-32:38]

  • Pathfinding’s future is still up in the air, with no final decision taken as yet. Currently all that is being looked at is the removal of the Havok sub-library from the viewer, which impacts Pathfinding.
  • This sub-library is used for two purposes:
    • For convex decomposition in mesh uploads.
    • Visualising / managing the Pathfinding Navmesh.
  • In terms of mesh uploads, there are alternative open-source libraries which could be used in place of Havok. Some of these alternatives are already being used by TPVs in preference to having to obtain a Havok sub-library licence from LL, and Geenz noted that a Pull Request from any viewer using such an alternative would be “welcome”.
  • Using Havok in the viewer purely for visualising the Navmesh is seen as overkill, again considering there are potential alternatives which could be used.
  • Philip Linden noted the need to reduce the amount of technical debt in the codebase, and removing Havok from the viewer would assist in this.
  • As far as Pathfinding as a whole is concerned, Geenz reiterated that currently, the Lab is not looking to completely deprecate it (both within the viewer and on the server-side); all that is being discussed at present is the need to remove Havok from the viewer.
  • An ancillary question asked by Rider linden was how many people at the meeting actually used Pathfinding characters, as opposed to NPCs using llGetStaticPath (which appears more popular, given the 15LI penalty and overall complexity of build Pathfinding characters).

In Brief

Please refer to the video as well.

  • [Video: 3:14-4:10] There is some work going into “beefing up some frame time metrics” – this will mean the viewer’s Statistics Floater (CTRL-SHIFT-1) will be updated with “a lot more” statistics going forward.
    • Some of this work will be surfaced in the next update to the glTF Mesh Upload RC viewer.
    • How many of the new stats are to be tracked in real-time is still TBD within the Lab.
  • [Video: 8:05-8:40] In terms of water exclusion volumes, this work has not yet bee prioritised and would required co-ordination between the simulator and viewer teams as it would require the passing of new object flags in order to work properly.
  • [Video: 20:41-24:08] General Linden Water update:
    • Improvements to Screen Space Reflections (SSR) on water are currently on hold pending the work on gathering better frame time metrics to be sent to the logs (how often is a user’s frame rate significantly dipping, for example), rather than just logging a user’s frame rate at the time they log-off.
    • The work that has been done on water SSR also still needs some further polish.
    • Overall the aim is to offer real-time reflections on any surface without it being a “gigantic frame rate killer”.
    • Other things that Geenz would like to bring back include shoreline fading, which had to be disabled due to alpha rendering issues – but this kind of work may have to wait for expanded EEP settings for water.
  • [Video: 33:40-36:02] PBR texture stretches when “stretch textures” is unchecked was raised over a year ago, and is marked as “complete”. It is not clear if a fix was actually deployed (and it does keep occurring), so Geenz and Atlas linden are going to take this back for a further review.
  • [Video: 37:04-48:24] A discussion on “lag”, and the (still common) assumption that most of it is simulator-side, and thus LL’s problem, rather than the viewer becoming overloaded thanks to people’s proclivity to jam-pack their avatar with complex meshes, multiple attachments, high-resolution textures, etc., thus impacting their own system’s performance (and potentially that of the people around them).
    • Geenz acknowledged that there is more LL could do to allow people to better quantify the impact they are having on themselves and others, vis à vis their avatar outside of the (inaccurate) avatar complexity system.
    • A problem here is that whether provided via options in the viewer, documentation, etc., people will ignore recommendations, warnings, reminders, etc.
    • Potential approaches to helping people understand the impact of the avatar include: indicating how much of their VRAM their Avatar is absorbing; having a meter display over their avatar’s head indicating the level of impact on general performance their avatar is having (both of which would only be visible to the user viewing them – and not to everyone else).
    • Technical solutions which might also help and under potential consideration for future implementation include texture streaming.
    • This discussion also encompassed the deficiencies with the ARC (Avatar Render Cost calculations & figures, and regulating the tension between people dressing their avatars so that they are resource-intensive to render, then going to a club or social venue and then dragging down the performance experienced by other users vs. allowing the venue owners to have the ability to set an “upper limit” on how resource-intensive avatars entering their club can be in order to preserve an experience that can be enjoyed by everyone.
  • The first 10 minutes of the meeting included a largely text-based discussion on the physics engine and viewer freezes. In short, there are no planes to change the physics engine, and the kind of viewer freezes experienced by SL as physics calculations are carried out are not uncommon within platforms using user-generated content (UGC), so trying to replace the current Havok engine (or even updating it) would not necessarily solve these issues.
  • A discussion between a user and Geenz concerning an EEP setting setting and use of an RGB cloud map, and whether this is supported. No definitive answer, other than Geenz would need to investigate.
  • The end of the meeting touched on SL Mobile issues and Project Zero – these are covered in other user group meetings.

Next Meeting

2025 week #20: 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, May 15th, 2025. Please note that this is not a full transcript, but a summary of key topics, and timestamps are to the official video, embedded at the end of this report. .
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

2025.04 and Upcoming 2025.25 RC Viewers

[Video: 5:55-7:01]

  • The feature set for the 2024.04 RC viewer remains as per the currently available version:
    • Chat Mentions (Early Support): Type @ then pick a name. To follow: audible alerts and highlight colour pickers.  This does not support generic mentions such as @everyone or @here.
    • My Outfits subfolders: now supports the use of subfolders.
    • Hover height: the minimum/maximum is now +/- 3 meters.
    • UI Quality of life improvements.
    • Use the release notes link, above, for full details.
  • The upcoming 2025.05 RC looks set to include:
    • A “catch-up merge” of fixes and updates from the old Develop / Maintenance C branches.
    • Inventory Favourites (described at the meeting as “a little bit buggy”). As per [Video: 11:41-13:30], this is  a capability originally designed in 2024, and will see the addition of an Inventory tab where selected favourite items can be listed.

 glTF Mesh Uploader

[Video: 3:51-5:54 + as noted below]

  • The decision has been made to move this out of the upcoming 2025.05 RC viewer.
  • This decision also means that the Lab is evaluating what will be required to get PBR material imports working as part of the mesh upload process at the same time (rather than just having only the Base Colour uploaded).
    • Under previous plans, it had been stated that direct import of a full set of glTF materials as a part of a glTF mesh requires an large refactoring of code; so the initial release of the uploader would only support Base Colour, with other maps to be added in the future.
    • It also marks a switching away from discussions at the last CCUG, where creators expressed a preference to upload meshes with all materials and just have blank faces to which they could they apply their materials post upload. This is because the Lab would rather provide a complete drag-and drop solution, if this can be done.
    • The unspoken element of this update suggests that if direct upload of materials with meshes does prove to be complex, providing uploads with blank faces will likely be the fallback approach.
    • Either way, the ability for people to apply their own materials to objects that are Modify will remain unchanged.
  • [Video: 7:02-8:31] As to when an in which viewer the mesh uploader will surface is TBA, and subject to further internal discussions at the Lab.
    • There is currently a issue in getting rigged meshes (full avatars, as provided for testing by content creators, rather than individual items) to upload correctly.
    • LL is not opposed to shipping the uploader as a Project viewer once suitable for testing. This is liable to occur “sooner rather than later”, subject to the above mentioned issue.
  • [Video: 8:55-9:55] Will the glTF uploader support large meshes / those with more than 8 faces, rather than breaking them up?
    • The 8-face constraint a current system constraint and requires potentially significant simulator codes changes. As such, it is liable to remain “for now”
  • Implementation of a glTF mesh uploader will not mean the end of COLLADA (.DAE) upload support for SL – this will remain available. However, as modelling tools, etc., are deprecating COLLADA support, there is a recommendation that if creators wish to continue supporting their old mesh content, then they convert it to glTF .

In Brief

  • [Video: 13:32-15:00] Feature Request Add Custom Tags to Inventory Items – was raised at the end of 2024, and is currently marked as Tracked.  It was raised again at this meeting. Kyle Linden confirmed that a design for such tagging in on the viewer roadmap.
  • Terrain:
    • [Video: 15:15-16:12] Potential for better terraforming tools: Described as something LL would like to get to, including higher resolution texture support; the (currently on-hold) Terrain Painting work, etc. However, nothing is currently being worked on, and suggestions for terrain improvements request through the Feedback Portal.
    • [18:04-20:26] New terrain textures for Mainland: seen as a “nice to have”. However, given issues around enabling HDR skies to make PBR look good on Mainland (and the resultant “dim/dark” look to the skies) + the number of people still not using PBR-capable viewers (although this number is falling), LL is cautious about making widespread changes to Mainland. Nevertheless, updating terrain textures is something (per the above) LL “would like to do” in time.
    • [Video 44:41-46:26] WRT terrain and texturing a question was asked on whether it would be possible to have a “grass” functionality at so point, allowing land holder spawn grass on their land, rather than just having a texture. This does (to a point) exist in the viewer through the Build floater → plant rez option, although this is admittedly old and can be LI intensive, so likely needs revisiting in the future to update. Canny requests on what people would like to see with this were requested.
  • [Video: 17:10-17:45] It was asked if there was any further news on feature request: Make Appearances Height = Prim Height, noted at the last meeting as “something that could be looked at”.
    • Short answer: no.
    • The discrepancies in height are something LL would like to address, but involves where they are and what needs to be done (even different viewers can report different heights for the same avatar). But is it not something currently in progress.
  • [Video: 20:33-24:39] A discussion on being able to “share” attachments (e.g. one person being able to have a pizza box attached to them, and others being able to “take” a slice of pizza from the box a) without any complex means of taking an attachment to inventory and adding it (or similar) and b) having the corresponding slice of the pizza “vanish” from the box.
    • Rider Linden confirmed two approaches (to meet different use-cases) are “on the drawing board” to address this. One involves the use of Experience capabilities; the other enabling attachments to be made directly from an object’s inventory. However, neither option is currently being worked on.
  • [Video: 24:51-29:21] A request was made for further attachment points.
    • Providing additional attachment points is seen as sub-optimal, simply because of the additional rendering load / script processing requirements doing so will bring.
    • Rather, and while not currently on the roadmap, LL might look towards allowing customs skeletons (when supported) to have their own attachment structures, with a proxy system to offer back compatibility with the existing attachment point system.
    • This discussion touched on the Permissions system (e.g. allowing no modify items to be linked to others), which is really a no-no among many (although subject to debate within and without LL), as so unlikely to change in the foreseeable future, if at all.
  • [Video: 29:50-31:20] The above flowed into a discussion on the proposed permissions “bypass” that had been put forward by Geenz Linden for resolving issues of alpha/gamma issues causing some hairstyles to look “wrong” under PBR lighting.
    • This would have enabled uses to make a change through the viewer to enable “legacy” blending on the hair, even if it was No Modify. However, this was not seen as an optimal route to take by some at LL.
    • As such, the fix remains on hold until either those at LL can be persuaded that allowing such a bypass of permissions is not so bad, or an alternative solution can be determined, which could be used to detect all instances where legacy alpha blending is required.
  • [Video 33:22-34:55] Imposters and mesh proxies:
    • It is acknowledged that the current avatar imposter system is looking increasingly outdated.
    • The idea of providing some form of proxies (e.g. “visible triangle only” when seen from a distance) has been discussed internally at LL, however, this is not something being actively worked upon, nor is it part of any scheduled future work.
  • There were also general discussions around Gacha (more policy than content creation) and this Canny report; new user on-boarding; content being ripped from SL (or other platforms) and (re)uploaded to SL for sale (file a DMCA Take-Down request); LL addressing quality of life issues (usability) – being addressed, file Cannys!; items awaiting better prioritisation (e.g. dynamic Landmarks). Please refer to the last 20 minutes of the video for more on these.

Next Meeting

2025 week #18: 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, May 1st, 2025. Please note that this is not a full transcript, but a summary of key topics, and timestamps are to the official video, embedded at the end of this report. .
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

  •  Default viewer: 2025.03 7.1.13.14343205944, issued April 9th and promoted April 15th.
    • 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.
    • 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.
  • Release Candidate: 2025.04 – 7.1.14.14742193597, Issued May 2nd 2025.
    • Includes the following new features:
      • Chat Mentions (Early Support): Type @ then pick a name. To follow: audible alerts and highlight colour pickers.
      • My Outfits subfolders: now supports the use of subfolders.
    • Key updates:
      • Build Floater improvements: increase to scale boundaries; Physics Material Type now updates when selecting linked objects; Repeats per Meter value no longer incorrect for non-uniform sized objects.
      • Hover height: the minimum/maximum is now +/- 3 meters – requires a simulator-side update, currently in the process of being deployed.
      • Snapshot floater: L$ balances can be hidden independently of the rest of the UI.
      • Preference Search bar: general usability and readability improvements.
    • Refer to the release notes for full updates and fixes.
  • Second Life Project Lua Editor Alpha, version 7.1.12.14175675593, April 2nd.

Upcoming Viewers

[Video: 2:22-5:16]

2025.04
  • See above.
2025.05
  • Internal discussions on what form this should take remain in progress.
  • As a result of delays with 2025.03 and 2025.04, coupled with a need to consider how to better offer viewers with features / capabilities user will find valuable, rather than simply lobbing buckets of changes and updates into each release, the viewer team is backing off of the idea of a monthly release cadence for the immediate future.

More on the glTF Mesh Uploader

[Video: 7:41-12:22]

  • Overall, the focus remains on getting the flow of model uploads working smoothly and in providing the same capabilities when uploading glTF models as is currently the case for COLLADA models.
  • However, there will be some constraints on capabilities:
    • Higher vertex limits on uploads will not be supported for glTF, as it is described as requiring a “whole mesh format upgrade”, which requires further thought before moving in that direction. As such the current 65K vertices per face limit will apply to glTF model uploads.
    • Due to the complexity, and until things can be re-thought, glTF materials cannot be imported as a part of a glTF mesh (outside of the Base Colour map); they must be imported separately and then applied.  Direct import of glTF materials as a part of a glTF mesh requires an large refactoring of code which is not possible in the immediate future.
    • The above point prompted the question from Geenz on whether people would prefer the Base Colour to be uploaded, or simply just have a blank face provided until such time as full glTF materials can be imported with the mesh. Opinion at the meeting leaned towards the blank surface.

In Brief

  • [Video: 6:02-7:10] Feature request: Make Appearances Height = Prim Height – responded to as “something that could be looked at”.
  • [Video: 15:25-20:21] Are there plans to support Unreal Engine? – No, and defined as “probably never happening”.
    • This led to a question about supporting Unreal Engine plug-ins and perhaps getting plug-in support for Marvelous Designer, often used as an adjunct to making and rigging SL clothing (in fact, Linden Lab struck a deal with MD so a plug-in could be provided for the Sansar platform and its avatars).
    • While not averse to the idea of plug-in support, it was noted that in respect of rigging to the avatar skeleton, the latter would need additional work to make it offerable to third-parties to support.
    • This led to a general acknowledgement and discussion on the need for better pipelining to support popular tools, what those tools might in fact be, beyond Blender, how widespread is their use, availability of SDKs, convergence in trends (e.g. towards OpenUSD) – although how this might all be achieved is a head-scratcher.
    • Overall, such work is seen as “worth discussing” but well beyond the current roadmap.
  • [Video: 20:24-25:52] In terms of the SL skeleton, it was stated that “everyone” uses Avastar – including the Lab -(although the MayaStar plugin by Cathy Foil also gets good usage), due to the SL skeleton having issues.
    • Geenz suggested the way to offer easier compatibility between the SL skeleton and commercial tools like MD would be to get the skeleton files updated and offer them as glTF and / or OpenUSD downloads.
    • This grew into a general discussion on the skeleton, its complexity compared to other games / platforms, etc.
  • [Video: 25:52-33:30] A general discussion on the Avatar Welcome Pack, specifically some of the shortfalls in how it has been put together.
    • Some of the issues are known, and have been raised by the creators who provided the content for LL to bring together, others may not have been identified.
    • The request is for any issues identified by experienced users opting to try / test the avatar, etc., to be filed as a bug report.
    • It was also noted that clearer instructions were not provided with the Avatar Welcome Pack – such as *copying* a body folder / outfit from the Library to Inventory, rather than adding / wearing an avatar or outfit directly from the Library (and thus spawning multiple copies in Inventory.
    • In relation to the above, Kyle Linden suggested the Lab offer the pack’s contents on a Lab-driven Marketplace store to help with discoverability, and this was positively received.
  • [Video: 33:35-38:24] A discussion on lighting  – “block” (aka volume) lighting, improving the flexibility of lighting in SL, implementing physically based lighting capabilities, etc.
  • [Video: 41:20-46:29] A discussion on filling the “voids” between continents and regions with water / air open space to allow free passage to boats and aircraft, and why this currently in not feasible on technical or financial grounds.
The system complexity of doing is so enormous … to do that, we’d have to either run a single server in each one of the void spaces, which would obviously put us out of business overnight [fees to Amazon] or… to build mega regions. But the trick to those mega regions need to sit on top of existing regions, or something. Because otherwise, you have the protocol for cross-region communications at the boundaries, and you no longer have cardinal boundaries. Every programmer here can imagine the horror of going from having one neighbour to your left to having between 1 and 600 neighbours to your left, or something. We just didn’t code Second Life that way, so that we could have regions of different size adjacent to each other. I don’t know how to solve that … I don’t have an easy answer off the top of my head.

Philip Rosedale

  • [Video 48:13-54:30] General comments on providing VR support – options, issues, technical hurdles.

Next Meeting

2025 week #16: 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 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 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

  •  Default viewer: 2025.03 7.1.13.14343205944, issued April 9th and promoted April 15th – 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.
    • 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.
  • Second Life Project Lua Editor Alpha, version 7.1.12.14175675593, April 2nd.

Upcoming Viewers

2025.04
  • The 2025.04 viewer is “still progressing”.
  • There is an issue described as “not all of the glTF meshes not coming in”, including those with less than 65K vertices. The cause for this is still under investigation and is currently preventing the viewer progressing to an RC release.
  • This viewer 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.
  • The glTF issue coupled with an elevated crash rate issues discovered in 2025.03 and affecting 2024.04 means that this viewer will be running behind the planned schedule for releases.
2025.05
  • Internal discussions on what form this should take are in progress.
  • One option is to have this release comprise entirely of updates originally planned for inclusion in the 2024 Maintenance C release prior to that being put on hold when the focus shifted to addressing performance issues, etc., in the wake of the initial PBR release.
  • One of the updates for this viewer is likely to be Inventory Favourites (presumably somewhat similar to the Firestorm Favourite Wearables).

Removing Scale From LI Calculations (Recap/Update)

  • 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).
  • Further, the Lab needs to re-evaluate LI as a whole and where there could be potentially “bad” impacts on LI changes as a result of scaling – such as with streaming calculations, which are entirely based on scale.
  • As such, this work is now in the column of “something we want to do, but we need to do it responsibly”.

In Brief

  • Blue tint on reflective surfaces: this is largely the result of one of two things:
    • Outdoors, the fact that automatic  / void probes will be reflecting the ambient lighting and when outdoors there is rather a lot of sky, and so they is going to give reflections a blue tint.
    • Indoors: no internal reflection probe has been placed to override the automatic / void probes, so the sky reflections will be used via the automatic probes. Solution (not always ideal / possible): install a reflection probe indoors.
  • PBR metallic “vs.” PBR specular: it was acknowledged that general control of reflectiveness in surface could be – to a degree – better managed through the support of PBR specular rather than relying solely on PBR metallic (as is currently supported), and adding PBR specular is being considered.
  • Terrain:
    • Significant updates to SL terrain (e.g.  terrain painting (summarised here), increasing the terrain geometry, potentially implementing better terrain LODs, etc), all all either on-hold (terrain painting) or seen as a much larger undertaking that needs to be focused solely on terrain improvements.
    • As such, they are currently viewed as “down the road projects” while the focus remains on providing content creators with more immediately benefits (such as the taking mesh models, etc., directly from their preferred workflows and dropping them into SL without additional faffing).
  • Lighting:
    • Geenz Linden has broken down what he refers to a “super Canny” feature request on lighting into a number of smaller requests. All are tracked – but this does not mean they are currently being worked upon, but rather are things Geenz would like to get to as time allows:
    • Path Traced Global Illumination (PTGI) described as “not any time soon”.
    • Environment versioning: to help track chances to the environment rendering, versioning of assets has been introduced. whereby if the parameter ranges of an asset are changed by LL, then the “old” version of the asset becomes locked and the revised parameters only apply to  new asse version (which requires a new viewer version).
    • Light sources on water (outside of the Sun and Moon: not going to be “coming back” any time soon.
  • Some confusion around glow and emissive mask on PBR. The best place for information on PBR, Blinn-Phong (“legacy”) materials + capabilities) is Kirsty Aurelias’ handy (invaluable) guide.
  • Changes to Blinn-Phong alpha-gamma (as has been discussed in previous meetings) is currently on hold and subject to on-going discussions within the Lab on how to best proceed.

Next Meetings

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.