Tag: Content Creation 2026

2026 week #43: SL CCUG meeting summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from my chat log of the Content Creation User Group (CCUG) meeting of Thursday, October 22, 2026.

Please note that this is not a full transcript of the meeting but a summary of key topics.

Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis, in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer 26.4.0.37384746592, October 13:
    • Lua scripting support (on regions with Lua scripting enabled).
    • Improved communication between the Viewer and the newly published Second Life VS Code extension.
    • Offers an experimental Linux viewer build.
    • Includes the latest WebRTC Voice and viewer-maintenance updates.
  • Second Life Chat Modernisation viewer 6.5.0.38448248489, October 16:
    • Seamless integration of IM histories between clients / devices.
    • Camera and Travel improvements.
    • Create an account from within the viewer.
    • LEAP Camera API.
    • Portable viewer storage.
    • And more.

General Viewer Notes

  • Further questions were asked on the new Group Role ability to determine roles able to post links to Group chats. All of this is covered in my week #43 Leviathan Office Hours notes. However, in terms of the questions asked:
    • The server-side support will be part of the upcoming Olive simulator updates (not deployed anywhere on the grid at the time of writing).
    • The ability will require viewer updates and back-end database updates. As such, if these are not available when Olive is deployed, the capability will sit behind a flag and only be available once this work has been completed.
    • It is hoped the viewer work will be included in the 26.5 viewer as it works through RC updates.
  • Graphics Care Package (GCP) viewer: this work is now targeting 2027 Quarter 1 (January-March time), but is still dependent on other priorities.

General Discussions

  • Questions were asked on the recent CVE vulnerabilities and the PHP2Shell vulnerabilities affecting Second Life. No response was offered for discussion other than LL are well aware of the situations and doing what needs to be done.
  • A suggestion to enable folders to have a text pop-up (similar to the thumbnail image capability) allowing creators (and users) to add notes to product delivered by folder (and to their own inventory folders). This also touched on the ability to tag inventory items, etc. These ideas were seen as useful – without an commitment to implement (at least for the foreseeable future).
  • The above broadened into a wider discussion on mesh clothing getting its own inventory icons in a similar manner to those for system layer clothing, providing support for folders within the Contents of prims.
  • A discussion on the feasibility to be able to set a face to use nearest neighbour for a texture, texture sampling, which included the glTF specification covering texture filtering.
  • No work is currently being done for materials bulk uploads, as requested in a previous meeting.
    •  This is outside of the ongoing work related to anti-phishing / scam protect/prevention, as summarised in the viewer notes, above.
  • Requests were made for more prim types / more shaping capabilities for prims (bevels, curves, etc., together with a lamentation for few newer people engaging with in-world building. LL indicated there are no current plans to expand prims in terms of shapes or shaping capabilities, and the lamentations were somewhat countered by the admission that those teaching in-world building techniques finding it hard to interest newer users in building.
  • Geenz Linden left a question for people to consider for a future meeting: given the bar for content creation in SL has got higher, but is it higher or lower when compared to platforms such as VRChat or Unity more generally?

Next Meeting

2026 week #41: SL CCUG meeting summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from my chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, October 8, 2026.

Please note that this is not a full transcript of the meeting but a summary of key topics.

Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis, in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

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

General Viewer Notes

  • The 26.4 Lua Editor / Linux viewer 26.4 is now in what is hoped to be its final RC/Beta version ahead of promotion to de facto release status – although it had previously been hoped to promote this viewer during week #41.
  • The next major viewer release – 26.5 – is currently in initial development. Headline updates for this are:
    • Chat Modernisation (currently still on the 26.4 codebase, per the notes above).
    • A new Group capability to allow Group owners / moderators define which Roles in a group are allowed to post links to the Group chat (outside of a defined list of “whitelisted” LL domains like the Marketplace, etc.). This update will also require sever-side updates which are to be included in the next simulator update after Nectarine.
  • The Graphics Care Package (GCP) viewer is progressing, but has been slowed by a need to focus on “admin work” related to the viewer deployment process at LL.
    • The hope is to have the server-side support for the additional glTF and EEP (Environment Enhancement Project) parameters (e.g. in the case of the latter, more tone mapping and HDR controls) in place “soon” to allow this project to resume moving forward in a timely manner.

Game_Control Update

  • It is currently unclear if the game_control updates will now be a part of the 26.5 viewer as had been planned; they may initially surface in their own viewer. Discussions on this are still in progress.
  • However, some of the hesitation around game_control being included in 26.5 appears to be related to the server-side updates to message handling, which should be a part of the Nectarine simulator updates which (at the time of this meeting) is running across all simhost RC channels and should be deployed to the SLS Main simhost channel on Tuesday, October  13, making it grid-wide.
  • If game_control is pushed from 26.5, then it will be “in the next viewer” that will be made available.
  • Pre-Alpha versions of game_control viewer remain available on Github. However, please remember that currently, if this viewer is used to log-in to or connect to a region without the necessary message support (at the time of writing, any region on the SLS Main channel – so a 2 in 3 chance), the viewer will be disconnected and the the hardware running it temporarily banned from connecting to that region for a period of time.

General Discussions

Side Note on Region Crossings

As per the update to my week #41: SUG Leviathan Hour notes:

  • The Breeze mini-RC channel with pepper Linden’s region crossing updates is now live on Agni (the Main grid) with “almost all” of the Blake Sea regions running on it.
  • Testing – particularly vehicles carrying multiple avatars on corner-to-corner crossings – is encouraged.

In Brief

  • A general – largely text – discussion on Inventory:  LL providing more in the way of top-level system folders for ease of ordering; complaints over Inventory links causing “bloat” (that is, adding additional elements to again given folder, thus increasing overall inventory element count, rather than physical inventory file size / load time – but if links are not visually annotated, how will you know they are there?); Inventory hierarchies; ability to tag mesh clothing in the same manner as system layers; etc.
    • Most of this fell outside of content creation per se, but did result in a general discussion of what might be possible with Inventory (e.g. making links visible in a different manner, adding the ability to have “smart” folders – folders with built-in queries which simply list things), additional inventory search options, etc.
  • A further request for a materials bulk upload option (as available for textures).  Somewhat sidetracked by complaints that upload fees for higher resolution textures are “too damned high” (where, oh where have we heard that complaint before?), with it being pointed out that the fees have been set to try to discourage people from unnecessarily uploading view high resolution textures (e.g. a 2K textures for buttons on a shirt kind of thing).
  • Kyle linden noted that while there are currently no projects in the pipeline, he is tracking requests for Group related updates / capabilities (e.g. improved moderation tools, ability to rename a Group, etc.), so that information is available when LL turn their attention to Group features.
    •  This is outside of the ongoing work related to anti-phishing / scam protect/prevention, as summarised in the viewer notes, above.
  • A general request for identifying AI content (e.g. on the marketplace, enforced tagging at upload (not sure how that would work), etc.

Next Meeting

2026 week #39: SL CCUG meeting summary

Posted on by Inara Pey
Hippotropolis Campsite: venue for CCUG meetings
The following notes were taken from my chat log and audio recording  of the Content Creation User Group (CCUG) meeting of Thursday, September 24, 2026.

Please note that this is not a full transcript of the meeting but a summary of key topics.

Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis, in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

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

General Viewer Notes

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

General Discussions

“Water” and Linden Water

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

In Brief

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

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

Next Meeting

2026 week #37: SL CCUG meeting summary

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

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

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer  26.3 – 26.3.0.31203661088, August 10, promoted August 17 – quality of life improvements; performance improvements; bug fixes – No Change.
  • Second Life Lua Editor RC / beta viewer 26.4.0.34502396632, September 11 – NEW.
    • Lua scripting support (on regions with Lua scripting enabled).
    • Improved communication between the Viewer and the newly published Second Life VS Code extension.
    • Offers an experimental Linux viewer build.
    • Includes the latest WebRTC Voice and viewer-maintenance updates.
  • Second Life Chat Modernization viewer 26.3.0.33643480083, September 4 – NEW.
    • Improved chat (IM) history retention, including integration between the viewer and SL Mobile; on desktop, any existing local history and newer message history are brought together into a single conversation..

General Viewer Notes

  • 26.4 was initially released on September 9, but suffered a high crash rate, with one crasher in particular needing a hotfix, resulting in the release of the September 11 update as listed above.
  • Graphics Care Package (GCP) viewer:
    • Work continues with bug fixing within the viewer.
    • Additionally, server-side work is underway to provide support for the new glTF parameters (e.g. IoR, Specular, and possibly, depending on further internal testing against viewer performance, some of the glTF Transmission capabilities).
      • If included, the latter will enable pseudo water prims – that is prims that have the appearance of Linden Water, but not the native attributes such as buoyancy, underwater haze, etc.
    • Once this server-side work is completed, the plan is to put up a region on Aditi (the Beta grid) so that the GCP (when available) and the new glTF parameters can be tested.
    • GCP includes the ability to have more than two shadow-casting light projectors in a scene (although the default remains at 2).
      • Initially (at least) this will be a Debug setting, not a Preferences option, as setting the value too high can result in murdering the viewer’s frame rate.
      • This update includes a fix to the long-standing bug that the number of projectors casting shadows is not correctly calculated.
  • Confirmation that game_control is now entering the queue for inclusion into a viewer update, but no confirmations as to when this is likely to occur or which viewer update will see it surface.

General Discussions

  • Raise the maximum lighting radius beyond 20 meters was raised, together with the positives and negatives to it (the latter being one parcel with extended lighting overpowering neighbouring parcels + the idea of making lighting (like sounds and avatar visibility) so it can be limited to the parcel boundaries.
    • It was also suggested that better static shadow mapping could eliminate many of the problems such an extension might cause.
    • This led to a brief description of the issues of adding capabilities such as point lighting shadows and static shadow mapping to SL (in short: adding the required parameters to the existing protocol “is a little bit painful right now”, and requires the cleaning-up of some technical debt).
    • As such, improvements to lighting without it being a nuisance to other users is not impossible, it’s just not a current focus.
  • Introducing Opacity Control for BoM Layers was raised, and Geenz indicated that there are numerous improvements which could be made to Bakes on Mesh (BoM), such that it is fast becoming a project or group of projects in its own right.
    • One of the first could be a clean-up of the UI/UX around BoM in order to make it less cryptic and easier for lay users to understand / use.
    • This led to a more general discussion on how capabilities and features in Second Life have often evolved and options for improving aspects of BoM and avatar attachments (e.g. making creators define the default attach point at upload, rather than simply leaving it undefined and the right hand being selected as the default). This took up much of the latter half of the meeting.
  • A request was made for the ability to bulk upload glTF materials. This is not something currently under consideration, but could be explored in the future.
  • Work is continuing on improving texture streaming – although LL are anticipating “some noise” to be made about some of the behavioural changes involved with this work once it surfaces (which is one of the reasons a quality drop-down selector for textures is being included in the viewer).
    • This led to comments that textures should perhaps show an “average” colour when loading, rather than just being grey.
    • Geenz also suggested it would be nice to have some form of mechanism which could better sample / size textures on upload as well.
  • A request was made to make the options to rescale the viewer UI more obvious – particularly for incoming new users with vision impairments – was made. This will be looked into (no pun intended), and might possibly be done through something like a further “Accessibility drop-down” in the two right of the viewer (where the Graphics and Camera presets, etc, are already located), or even via auto-detection (as is already done for MacOS under high definition mode).
  • Whilst not content creation related, it was indicated that the simulator Snack RC to contain Pepper Linden’s region crossing improvements (see my recent Leviathan Office Hours update for further information) will be deployed in the next week or two, and will likely include regions on Blake Sea.

Next Meeting

2026 week #35: SL CCUG meeting summary

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

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

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

General Viewer Notes

  • 26.3, as the default viewer has a  “pretty good” low crash rate.
  • It is hoped that the 26.4 Lua Editor viewer with Linux support will be moving to beta/RC status “pretty soon” – a beta/RC version is currently with QA for testing.
    • The idea being to have this available as server-side Lua support is made available on the Main (Agni) grid.
    • LL is actively building Linux versions of all viewer (alpha/project and beta/RC) moving forward.
    • There is still some back-end work to complete for Linux support (e.g. updating the viewer download pages (main and Alternative, etc.), to reflect the availability of Linux and to have the relevant URLs, etc.).
  • Work has resumed on the Graphics Care Package (GCP) viewer, with the focus on bug fixes and cleaning-up regressions. This latter work includes clean-up issues around mirrors, with some long-standing mirror-related bugs also to be worked on.
    • There is further clean-up work to be done in general before a alpha/Project version of the GCP viewer appears with an official version number.
    • An alpha version of GCP will not mean it is feature complete; further updates, etc., will be made whilst it is soaking as a alpha/Project viewer, the release being to allow those who wish to to try the viewer and provide feedback.
  • One element under review with regards to inclusions in GCP (and Second Life as a whole) is materials Transmission.
    • One potential use for this would be to give any in-world surface the cosmetic appearance of water which could be “seen” as such through the appropriate scripting support  – e.g. volume detect, or this Feature Request to get the face details of an in-world object.
      • Note this is not about giving surfaces / prims the same properties as Linden Water – that is a far more complex ask.
    • Transmission had been promised in the past, but there are concerns over impact performance, so its inclusion in SL is still under internal review and testing. If the impact is too greater for many systems, it is unlikely to be implemented; if its impact can be moderated through the use of a toggle in the viewer, then it might be considered.

General Discussions

  • With regards to Linden Water:
    • We currently have water exclusions surfaces (objects which can “hide” areas of Linden Water when looking on it from above. This is useful for things like keeping Linden Water out of the hulls of boats, etc., when viewed from above, but if the camera moves below the surface, the visual effects of Linden Water (hazing, etc.) will still be apparent.
    • Given this, there has been a long-standing request for water exclusion volumes which would completely hide Linden Water howsoever the volume is viewed from within (above, below, etc.).
    • Whilst LL is aware of this, the development of water exclusion volumes is not currently being targeted.
  • The PBR “terrain painting” project Cosmic Linden was once working on, circa 2023/24 remains “on the shelf” for now.
    • This led to a general discussion as to what form this project would take if it were to be re-started (e.g. supporting permissions, limits to use (e.g. supported at parcel level, or limited to region level), etc.
    • However, as these discussion were mostly theoretical at this point, and it is unclear if current priorities, etc., would allow for the project to be dusted-off and restarted. As such, all such discussions were largely academic at this point.
  • There was a question on improving sound quality in SL (e.g. higher bitrate sampling, etc.). Currently, there is not work in the pipeline for this due to other priorities.
    • This led to a general discussion on sounds and Voice in SL – matters of attenuation, roll-off (or lack thereof), as well as general sound quality, all of which was user-led with little linden input / feedback.
  • Maxwell Graf demonstrated a viewer-side project he has been working on for functional water caustics using EEP lighting / settings together with a projector with a frame-based animation with a negative cut-out to shine the light through it (+ objects to create volume).
    • He noted that scaling the idea beyond anything like fish tank or pond could be problematic, although the process does not require any scripted update mechanism, it is purely based on the animation playback and interaction with the appropriate EEP lighting.

Next Meeting

2026 week #33: SL CCUG meeting summary

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

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

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work.
    • This meeting is generally held on alternate Thursdays at Hippotropolis and is held in a mix of Voice and text chat.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

General Viewer Notes

    • The 26.3 RC/ Beta was updated at the start of the week, and looks set for promotion to release status in week #34 (commencing Monday, August 1, 2026). As a maintenance / bug fix update, this includes a number of WebRTC fixes.
    • Linux support: LL is currently merging Linux “across the board”, and this should see Linux support in the Develop branch, so that it is a part of all future viewer builds.
    • This has meant the the resumption of work on the Graphics Care Package (GCP) viewer with the fixes and improvements around PBR and correcting issues within it as far as possible was slightly delayed – but it will now include a Linux build.
      • There are still a number of bugs to be addressed prior to GCP reaching a project / Alpha release, and once it is listed on the Alternate Viewer page as such, it will remain in soak for an extended period to allow feedback to be gathered.
      • The issuing of the GCP viewer will mark the first step in the graphics pipeline modernisation work which has been raised at both CCUG and Open Source Development meetings, but as a first step, the changes should be transparent to most people.
    • There will be a further project / Alpha update to the Lua Editor viewer, prior to that progressing to RC / Beta, most likely as viewer 26.4.

Mesh and LODs

  • Level of detail (LOD) is a technique used in computer graphics to optimize rendering by reducing the complexity of 3D models as they move further away from the camera so as to improve overall performance while maintaining visual quality. As a very basic description, this is achieved by “swapping” highly detailed (high polygon) models for models with a lower level of detail (fewer polygons) as the viewing position (camera) moves away.
  • For various reasons (cost, complexity, land impact, ease of defeat, etc.), LOD optimisation within Second Life has been something of a contentious issue – with a core part of this being the automatic LOD generation capability within the viewer can easily be defeated / even when used, produces generally bad results.
  • With a focus now turning towards improving the use of mesh in Second Life, Geenz noted that the issues of LODs is one that could perhaps be addressed. He suggested one of three particular approaches:
    • A drag-and-drop capability that allows a model sans LODs to be dropped into it, and without further prompting, the LODs are automatically generated.
    • A similar capability, but where the model and its associated LODs are dropped into it – but if the LODs do not achieve certain metrics, new LODs are automatically generated in place of them; or
    • The current approach is continued, with all of its issues (including creators including n/cards telling users to ramp-up rendering in their viewer to “see a product at its best” because no LODs are supplied / to defeat camera distance decimation (and hurt viewer performance).
  • Given the emergence of greatly improved LOD generation tools such as Mesh Optimiser, Geenz is currently leaning towards the middle of these three options, as it a) allows creators to generate their own LODs; b) ensures that everything is metrics based: if the generated LODs meet the required metric, they are used;  if not auto LODs are generated to meet the criteria and are used instead.
  •  IF such an approach were to be taken, it was acknowledged that consideration would have to be given to potential impact, including whether or not the new LOD system would retroactively apply to content already uploaded or not; the risk of new LODs causing higher Land Impact, resulting in objects being returned, etc.
  • The use of an auto LOD generation tool did receive some positive feedback.
  • This is however, just an initial discussion, not a statement of intent – feedback is being sought and content creators are encouraged to offer such through the usual channels (e.g. Discord) and via future CCUG meetings.

General Discussions

  • Script toggle for Animesh:
    • A request was made for a scripted capability for toggling the state of an Animesh object “on/off” automatically or manually.
    • A number of reasons for this were put forward from simplifying the update process for Animesh objects through to reducing simulator resource use.
    • The request appears similar to this one: New LSL llAnimeshEnabled(integer enabled); Toggle Animesh Property on/off, and it was suggested the requestor review that Canny for applicability & also raise the subject at the Simulator User Group meetings.
  • The above re-opened the topic of enabling wearables / attachments on Animesh objects; this had been something that might be developed under “Animesh 2.0”, after the original release of Animesh in Second Life.
    • However, that project largely got put on hold due to other priorities taking precedent – such as the announced, then much delayed and ultimately stalled and shelved project(s) to re-visit land impact costs, avatar rendering costs, etc.
    • Geenz has suggested he’ll look internally for information on “Animesh 2.0” and the reasons why it was held over and then then left.
    • Also suggested was the idea that rather than trying to address specific Animesh updates, it might be better to pursue a more structured approach to attachment hierarchies and the support of custom skeletons, as doing so would allow for a more broader set of use-cases to be met – although achieve a full system of hierarchal support on the server-side would not be straightforward.
  • A general discussion on the reasons behind working towards custom skeletons / rigs, attachment hierarchies etc., and the potential benefits of supporting custom skeletons / rigs and the complexities of maintaining a given level of continued support for older capabilities under the expectation that any changes made will not prevent older approaches (in this case the current avatar skeletal rig) from working.
  • In terms of mesh improvements, Geenz broke down what is being considered into three project areas:
    • Building-out the foundations in terms of glTF 2.0 specification support – with controls to ensure a consistent approach to data, etc.
    • Support for blend shapes, building off of the current under-the-hood blend shape support. Feedback was requested on what content creators would like to see with blend shape support (e.g. having blend shapes addressable via LSL / Lua).  Again, feedback welcomed via meetings and channels such as Discord.
    • Support for custom rigs.
  • Note: at this point, my recording software decided to disconnect from SL, as as I was AFK, I failed to notice it had, and so have no contextual audio for the last 20 minutes of the meeting, hence ending this summary here.

Next Meeting