Tag: Content Creation 2026

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

2026 week #31: 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, July 30th, 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

  • While viewer 26.3 is now available as a Release Candidate viewer, it does not include all the hoped-for performance improvements (particularly with some of the texture streaming work.
    • This was because of time constraints in getting the updates tested across as many hardware configurations as possible.
    • As a result, this work will be held over for the Graphics Care Package (GCP) viewer.
  • The GCP viewer is a lot of fixes and improvements around PBR and correcting issues within it as far as possible. It is hoped that this viewer, which has been suffering a lack of resources, will start to move forward once more in the near future.
  • Various pull requests (PRs) are now being looked at and worked on (e.g. semi-transparent media on a prim), but no guarantees as to when these might surface in a viewer.

Lua Updates

  • There is a new versions of the Lua editor viewer, as noted above.
  • This includes a new version of the VSCode plugin.
    • This has a much tighter integration with the viewer.
    • It is possible to select multiple objects in-world and open them for examination in a Visual Studio panel and then manipulate them (e.g. stop scripts, remove scripts or notecards) subject to permissions.
  • These new features do need to be enabled for use in the viewer:
    • Preferences → Advanced → Script Development → Script Development Settings floater → check VS Code Tight Integration.
Enabling tight VS integration on the most recent Lua editor viewer
  • Rider Linden is actively looking for bug reports on both the viewer and the VS Code plugin.
  • Note that the above does not mean that Lua is grid-wide.
    • Server-side support for Lua scripting remain available only in those regions with the required back-end code.
  • Currently, the hope is to:
    • Have the Lua editor got to beta / Release Candidate status after the 26.3 viewer is promoted to release status, with the caveats again being a) viewer priorities may change; b) at the time the viewer reaches beta / RC, Lua code support in the viewer still may still be restricted to those regions running on simulators with the required back-end support.
    • Have the back-end support for Lua deployed grid-wide “some time” during quarter 3 2026 (e.g. between this meeting and the end of September 2026)
  • Official Linux support remains with the Lua editor viewer as its first release.

General Discussion

  • Discussion on mesh improvements are continuing internally at LL. This is something the Lab wants to get done, but it may not be something that surfaces in the near future. Once the internal discussions have led to decisions, then more details will be put to the CCUG for discussion.
  • The game_control code now might not ship with the Lua editor viewer given the additional back-end work Leviathan Linden has agreed needs to be done (see my notes from the previous Leviathan Office Hours meeting).
  • A demonstration of a means to export scripts from a HUD to an external app to assist with HUD creation / positioning / testing was demonstrated (videos here, here, here and here). The end goal for the project – making it available to others and how, was not too clear.
  • The above led to the subject of SVG support in the viewer being again raised.  This is seen by Geenz as being “something that could be interesting at some point”, but the Lab is “a ways off” of having time for the work outside of MOAP.
    • In the meantime, Callum Linden is looking at MOAP + SVG support and what can be done there.
  • Viewer-native (aka “official”) PBR support for Bakes on Mesh (BoM):
    • Geenz noted there is interest at LL in providing this, but there there are various pre-requisites and consideration to be worked through, together with priority.
    • One example of this is: considering how to combine PBR BoM with Blinn-Phong, with a prerequisite being PBR specular support in the viewer (which is due to be a part of the GCP viewer).
    • There is also some need for work on BoM in general, such as improving elements of the UX.
  •  glTF lights:
    • glTF lights are described as “still a ways out”, but SL is getting radiometric units per the glTF specification for the Sun and Moon as a part of the GCP viewer.
    • Point and spotlights are a “much bigger ask” requiring additional wire protocol work and updating object parameters. As such, there is work in advance which needs to be completed in order to make point and spot lighting “doable”.
  • The above touched on shadow casting, which was seen as a combination of being something that might have to wait for the graphics API / Vulkan work, and as requiring sufficient controls and settings so as to allow users to adjust it for performance on their hardware.
  • A pull request (PR) to add the ability to take screen shots with a transparent background only showing avatars, Animesh, particles from the avatar, objects sat on, and selected objects (eliminating green screens) has been put forward and looks like it is going to be accepted.
  • A question was asked if the consensual system at the Adult Welcome Hub (see my review here) will be made available to content creators for use grid-wide. There is apparently a Feature Request asking for this, and it is under review.
  • Geenz requested that if people know of regions  parcels with pre-PBR EEP settings which look “broken” when viewed on a PBR viewer rather than a non-PBR viewer (e.g. things seem to be unnatural dark or objects are unnaturally glowing, etc., when see on a PBR viewer but not on a pre-PBR viewer such as non-PBR versions of Firestorm), to please for LMs to him for investigation. This does not include PBR EEP settings looking differently on pre-PBR viewers, etc.

Next Meeting

2026 week #29: 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, July 16th, 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 Updates

  • Viewer 26.3.0 is undergoing “final” bug fixing and testing.
  • Some of the team have started on some of the SL Mesh improvements which have previously been discussed  with a focus on improving workflows using existing tools (e.g. – mesh uploads, etc., not “SL Mesh 2”).
    • Feedback was requested on mesh uploads. Roxie Linden also indicated that the current work will likely be dropped as a viewer alpha build at some point in order to gain further feedback.
    • As has also been previously noted, all mesh work is to be carried out incrementally, rather than being bundled into a single large project.
    • Blend shapes are something that might be considered for mesh, but not as an initial part of the work; right now everything ins foundational.
  • There are CEF improvements inn hand that should help performance (load time, rendering speed) which will help media-on-a-prim (MOAP).
    • A request was made to incorporate MOAP support for transparent background. This was seen as quite interesting and so added to LL’s list for investigation, although it was noted there is currently no planned work for transparency at the moment.
  • The Graphics Care Package (GCP – including Index of Refraction, PBR specular, significantly improved Screen Space Reflections, HDR EEP settings, etc.) viewer is still awaiting attention.
    • Feedback and screen shots relating to an early version of the GCP viewer (when it was still called the Visual Polish viewer) can be found here.
    • Currently, the Mesh workflow improvements are slightly higher on the focus list right now.

General Discussions

  • A broad request was made for further glTF support, with the reply being LL plan to add further glTF updates that make sense “given various limitations”.
  • A request was made for larger prim sizes – this was viewed in terms of prim sizes and their impact on physics, the potential to overlap simulators, etc., they would have to be considered carefully if anything were to be done.
  • The request for a larger colour picker palette was repeated – this looks like it might find its way into the GCP viewer as that is updated.
  • It was asked if it would ever be possible for region holders to place thumbnails of their region terrain a features like roads, etc, onto the Mini-Map view of their regions.
    • This was seen as “interesting” with a side note that it could result in misleading experiences for people, it would need to be given careful consideration.
    • This sparked a general user-led discussion on the Map and Mini-Map (such as being able to upload textures for personal regions in general, both World and Mini maps; having a Mini-Map layer with detailing people could enable / disable, etc.).
  • The second half of the meeting resolved around WIBNIs (“wouldn’t it be nice ifs”) and wish lists of options and capabilities (e.g. having options available for things other than water surrounding a region without having to revert to off-region meshes – possibly something that could be achieved with additional EEP support). As ever, the Feedback Portal and Feature Requests are the way to get ideas looked at.

Next Meeting

2026 week #27: SL CCUG meeting summary: “updating SL Mesh”

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, July 2nd, 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

Viewer Notes

  • Viewer 26.3.0 is undergoing some fine tuning as it passes through QA, and the hope is this work will complete in the next week or two, allowing it to surface as a beta / RC viewer.
  • The Lua editor viewer should be next in line to progress towards release behind 26.3.
  • The Graphics Care Package (GCP – including Index of Refraction, PBR specular, significantly improved Screen Space Reflections, HDR EEP settings, etc.) viewer is liable to be some time after the Lua viewer.
    • A request was made for displacement maps, but these were referenced as being unlikely any time soon.

Discussion: “Updating SL Mesh”

As introduced by Geenz Linden:

Today I had a topic I’d like people to consider and see what people want here. If we were to do an update to SL Mesh, what would people like? Our current setup is quite old, and we’d need to adopt a new format internally to really push things forward with newer features and such. So today it’s not easy to extend due to viewer compatibility issues. But if we were to revisit this, say having a variant of glTF, that enables extensibility much more easily – what sort of features would people be interested in seeing?

– Geenz Linden

This obviously caused a wide range of feedback with comments including:

  • Increasing the number of available materials faces.
  • glTF mesh hierarchies with proper origins.
  • Implementing Universal Scene Description support.
    • This was seen as “interesting” and that adding SL-specific schema would be “easy”.
  • Allowing partial editing of glTF metadata via the viewer’s Build floater and scripts to allow building more complex scenes with multiple meshes, object hierarchies etc.
  • Basic in-world mesh building tools such as mesh panels, the ability to edit vertices (which would require care!) and / or manipulate vertices and faces.
    • Seen as difficult to implement due to the mechanics of assets in SL.
  • “Fleximesh” for clothing, hair, etc.
    • Seen as difficult to pull off, while a physbones (“physics bones”, basically a defined “chain” of bones with a beginning and end, with the viewer simulating them moving around and such. It’s a technique seen in low-cost games and has the advantage of being low-overhead for the viewer to simulate, if a little basic) approach might be preferable.
  • Better Blender support.
  • More bone control for avatars, notably custom skeletons / avatar rigs.
    • Seen as likely necessitating some sort of in-viewer set-up unless we were to adopt something like VRM and utilise something like the VRM Unity-based rig. This was seen as “not out of the question”.
    • These comments came with a warning that there are a lot of opportunities for depositing bullets in pedal extremities with custom skeletons (mainly around animation compatibility), but these could be navigated were things to move in this direction.
    • A caveat was also given that while there has been thinking about custom skeletons within LL, “It’s not s short path”.
  • The requests for custom skeletons / rigs raised a second question: how would people use them. Responses included:
    • Ropes, plants, chains, snakes, cows.
    • “Everything that needs to move for animation.”
    • Animals like birds or fish.
  • Blendshapes (see this request as well).
    • Geenz noted that some hardware acceleration added for skeletons, but further hardware acceleration would be necessary for something like blendshapes – and noted this also is not off the table.
  • Geenz further noted on the discussion:
The biggest thing that stops us from doing this is really just the whole we can’t touch the original format. It has to stay in amber. But that doesn’t mean we can’t have a new internal format.
    • Exactly how this would work would be a case of TBD – presumably if / when any project has been scoped in terms of content and goals.

Geenz’s final comment on the discussion was:

I just want to close with although these are all good suggestions, I can’t guarantee when/if these will land. Chances are if we do a SLMesh 2, you’re getting feature parity first before we move on to adding shiny stuff to it. Whatever we do here will be iterative, rather than a big all in one release.

General Discussions

  • Kyle Linden indicated a possible change in direction for documentation:
    • The Second life Creation portal (/Getting Started with Scripting) could be refocused more towards helping those new to Second Life.
    • The Second Life Wiki might be re-opened for broader edit access and maintenance of information there (some of which is now badly out-of-date).
    • No further details were forthcoming.
  • As a part of the discussion on SL Mesh, requests were made for enhancements to the prim building capabilities (e.g. adding a bevel capability, more basic prim types, etc.). It was indicated that there are currently no plans to enhance or extend the prim system at present.
  • A hint was given that in terms of graphics API, it appears that LL is leaning back towards Vulkan as a solution, with the promise of more to talk about this in the future.

Next Meeting

2026 week #23: 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, June 4th, 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

Viewer Notes

  • Viewer 26.3.0 (performance improvements) remains the priority for issue and later promotion. This viewer will include async inventory loading, which should further help with loading very large inventories; together with new texture streaming updates which should help those on SL minimum specification computers with constrained VRAM.
  • Beyond this, there are on-going discussions within the Lab as to priorities for the viewer train going forward.
    • This might see the Lua Editor and the Linux updates for the viewer get merged into the Develop branch. However, if this does happen, it should not be taken to mean Lua is on the cusp of being formally released; rather it will will mean that the viewer side gets released within a viewer ahead of the back-0end support going grid wide (the latter loosely seen as being in the late summer at the earliest).
    • Setting feature flags within the viewer to gatekeep upcoming features and functionality until such time as it is generally available (as would be with the Lua code mentioned above) is also being discussed.
  • The Graphics Care Package Viewer (GCP) is effectively “on hold” for the present. However, it might see some additions made to it, such as the glTF transmission work (which will depend on the overall performance impact).
  • Maintenance releases are also in development. As has been indicated in past CCUG and Open Source meetings, these will be much smaller updates to the viewer, aimed at offering a more limited number of fixes  (e.g. the top 5 or 10 issues / viewer crashers) than has been the case with past maintenance viewer updates. The first of these is probably going to be viewer 26.3.1 (i.e. following 26.3).

General Discussions

  • Kyle Linden confirmed the Second life Creation portal (/Getting Started with Scripting) has seen a lack of outward communications from LL, but the Lab definitely wants to proceed with building it out and does want to receive contributions. To this end he will be contacting those known to have produced documentation on things like Lua, and this work will be progressing in the near future.
  • It was requested that the upcoming rendering updates within the GCP viewer all have options to disable them if people do not wish to use them.
    • Geenz pointed out that rather than options to disable, all of the items with could impact performance (such as glTF transmission) will have drop-down options within Preferences, allowing their quality, to be lowered, limiting any performance impact. However, some capabilities (e.g. glTF metallic) will remain enabled at all times, as they are viewed as essential to content.
  • A general conversation about possibly reintroducing texture sampling / supporting glTF texture filtering, plus looking beyond OpenGL together with upscaling resolution via the likes of AMD’s FSR, Nvidia’s DLSS, Intel’s XeSS, etc. See here for more), with Geenz noting the with the deprecation of OpenGL, LL is getting increasingly constrained as to what they can do, although FSR is a “maybe”, as there has been some backporting of support to OpenGL.
    • The above being said, LL is currently still looking at API options (e.g. Vulkan / Metal /  WGPU (the latter being seen as  suiting a wider mixed of older hardware can address multiple APIs)), although the focus at the moment is on finding a good inflection point to determine the direction which should be taken (such as Apple finally finally ending their support of OpenGL, rather than deprecating it but still supporting in through Mac Os 14 Sonoma).
  • Conversations not directly related to content creation included Nvidia’s new CPU/GPU ARM chips and how they may affect hardware (and Windows support) in the future; availability of Second Life OpenSpace regions; whether Second Life can have regions larger than 256×256 sq m (not on the horizon).

Next Meeting

2026 week #21: 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, May 21st, 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

Viewer Notes

  • 26.2.0 is now release, per the above. The code has also been merged into all viewers currently in development (such as the Lua Editor) with the exception of the Graphics Care Package (GCP) viewer.
  • Viewer 26.3.0 is the performance improvements viewer, intended to be the next release viewer and which is currently awaiting being issued as an alpha or RC viewer. This viewer:
    • Includes async inventory loading, which should further help with loading very large inventories; together with new texture streaming updates which should help those on SL minimum specification computers with constrained VRAM.
    • Is viewer is reported as providing good performance across a range of systems and scenarios.
  • As a part of the texture streaming updates mentioned above:
    • The viewer will not have: “a proper” texture quality setting (Low to Ultra) or the current LOD resolution drop-down.
    • The viewer will have a new texture resolution drop-down, which is more aggressive on its Low setting to optimise the use of VRAM on low-specification client systems; a Medium setting also doing more lower-resolution loading for textures at a distance from the camera (but high resolutions for those close-up); a High setting with resolutions slightly below their current levels; and an “Ultra” option that pretty much matches the current setting.
    • The viewer will also have a new (around 5 metre) “camera bubble” that follows the camera round and tries to load high resolution textures as best the client computer can manage
  • Lua Editor viewer:
    • There are “a lot of asterisks around” this viewer, both in terms of client-side work and server-side work.
    • This viewer may end up with numerous flags within it which can be toggled on / off depending on the status of server-side Lua support.
    • The availability of an official Linux remains tied to this viewer.
  • The Graphics Care Package Viewer (GCP) is effectively “on hold” as work continues on other viewers. However, when it does surface, it will likely include (but not necessarily be limited to) the following:
    • EEP post-processing settings, easing the work of setting-up EEP environments.
    • PBR specular support.
    • Updated and more performant Screen Space Reflections (SSR), including the ability to adjust SSR rendering to better suit the capabilities of the client computer (e.g. cranked right up on a very capable modern computer & GPU, or dialled down so it doesn’t choke older hardware).

General Discussions

  • It was asked if PBR (glTF) lighting is coming soon. Geenz noted that this requires server-side work, notably around the messaging service between the simulator and the viewer. Such work would need to be implemented before LL can fully commit to having largely glTF-compliant lighting. So, not in the immediate future.
  • A question was asked about artefacts occurring in varying levels when a gradient (slope) is applied in the construction of metallic materials, and whether anything was being done to correct this.
    • The question was related to gradients in normal maps, but was not total clear (i.e. was the gradient part of the normal map, or something added latter?). As such a canny report was requested on it.
    • There is a known issue with gradients on the diffuse map, and this is being addressed with the GCP viewer.
  • A request was made for PBR emissive map textures to load as the colour #000000 (up the receipt of the first discard level), as the current value – colour #808080 -, which  causes objects that use emissive to glow while they load – see this issue / Github).
    • Geenz Linden noted this could be so modified, but it would then cut across some of the texture loading work that has been going into the upcoming performance improvements viewer (26.3)
    • As such any change is unlikely to be implemented as a part of that viewer.
  • With the BonnieBots data collection system now banned from SL, a request was made for clarity on what is / is not permissible in gathering data from the grid, as there are a number of valid projects that require the use of specific data gathered from the grid via bots (e.g. in obtaining terrain heightmap data for use in producing 3D terrain maps). Geenz indicated:
    • He would try to get some clarity on this from senior management.
    • That including things like heightmap data into the map system is something the Lab is looking at, so as to make requesting this kind of data easier for those using it.
    • That additionally, LL is considering the use of things like object imposters and mesh proxies where applicable – but there is nothing solid to report on any of this at the moment.
  • It was asked if there are any further updates being planned for the avatar skeleton / avatar bones / blend shapes. Short answer: no; any work on the avatar / avatar skeleton would need to be relatively in-depth due to the risks of content breakage, etc., and so is something LL do not want to take on at present.
  • A question was asked about LL’s strategy for on-boarding and retaining new users. As previously noted in these summaries (and others), LL is not pursuing any single goal for this; there are several inter-related strategies (such as the one-click install on the viewer – making it easier to obtain; & the upcoming graphics improvements – which should make running SL a smoother, more predictable experience).
  • The subject of VR support was raised. The feedback from Geenz was that VR poses significant issues for SL, particularly in the area of being compelling enough to people already using VR headsets. For example:
    • Implementing a means by which people can simply put on a VR headset and look around SL or even move around with their avatar is not technically that complex. However, neither of these approaches would necessarily be compelling to people coming into SL who are familiar with using VR on other platforms.
    • By contrast, making SL interactive in a manner that is compelling to existing users of VR – e.g. being able to engage with, move, etc., in-world objects through hand  arm / body movements and to have things like full facial tracking and representation and having all of that packaged and streamed to everyone else in a region – is a considerably more complex task, potentially touching on multiple areas of the platform. As such it is not actually something LL is directly focused on.
  • The above led to a broader discussion at the end of the meeting on the Lab’s discontinued Puppetry project, its application in a possible VR project, together with alternate approaches, matters of IK, etc., all of which came down (again) to the view that providing a “good” and scalable VR solution in SL requires working on multiple moving parts / would have lengthy lead-times, and so is not something LL  wishes to commit to in the near-term  .

Next Meeting