Category: SL User Group Meetings

2026 week #30: SUG meeting summary

Posted on by Inara Pey
The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, July 21, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from the video recording by Pantera, embedded at the end of this summary – my thanks to Pantera for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • As recorded in my notes from the the previous Simulator User Group, there has been a bug which has been causing some regions to fail to grant capabilities.
    • A hot fix for this was deployed on July 14 and July 15 across all simhost channels. This is described as “not a complete fix, but at least now we aren’t taking out an entire simhost at a time”.
  • Tuesday, July 21 saw the SLS Main channel server restarted without a deployment.
  • Wednesday July 22 should see the Mango update deployed to the simulator RC channels.
  • The next simulator release after Mango is Nectarine.

In Brief

  • Rider Linden has as been finishing up a first pass on the VS code integration and is looking forward to getting it out, although it will need to be coordinated with the next Lua release
  • Leviathan Linden:
    • Has cut a new pre-release of the game_control viewer, and acknowledged the assistance of user Wolfgang Senizen for submitting changes to help in mapping actions to buttons, and Horny nuzzle for the suggestion to use PromptFont for the game_control preferences UI (see my Leviathan Office Hours notes).
    • What’s new with the updated viewer:
      • You can map buttons to avatar movement actions.
      • The DPad is mapped by default to fwd/back and strafe left/right.
      • You can run if you tilt the sticks far enough.
      • The UI mapping is revamped, mapping actions to inputs rather than the other way around.
      • There is an improvements to show the raw inputs/outputs in the per-device axes options (offset, invert, dead_zone), another sub-tab that shows raw data being sent to the server.
    • There are some further server-side aspects to game_control Leviathan wishes to complete, but these will be as his schedule allows.
    • Following discussion of an issue he introduced into UDP messaging at his last Office Hours meeting, he now has a fix for the problem (which is related to avatars that stay cloudy on log-in).
  • Roxie Linden noted that:
    • Has been working on the WebRTC p2p IM bug where sessions fail to start, and is making progress. There is now a potential fix for at least some of the failures, and which should be going out “soon”.
  • Pepper Linden:
    • Has been “hacking away on a new test harness” which creates a “fake grid” with multiple real simulators and viewers, and which can be used to reproduce some of the more tricky scenarios that are hard to pin-down – in this case, region crossing issues.
    • As a result of this, Pepper has managed to put together some fixes which – all things being equal – should help out with vehicle region crossings.
      • These fixes include changes to hold a vehicle in a region until all passengers are “ready” before it is allowed to enter another region, with an extension to what it means for a viewer to be “ready”.
      • This means the hand-off will only be performed after each passenger/viewer has polled their new neighbour’s event queue and it’s been able to verify there’s a real circuit/session in place.
      • Pepper is willing to have these updates deployed to the Blake Sea region on Aditi (the Beta grid) for user testing.
    • Pepper also noted that there is still an open question of how to handle region hand-offs when an avatar is crossing into parcel to which they do not have access to, such as perhaps fining the nearest open parcel and deliver the avatar there , or simply “tunnel through” the blocking parcel.
    • Another issue area Pepper hopes to be able to look in to is getting caught in TP limbo.
  • Harold Linden (Lua):
    • Is currently trying to catch-up on a backlog of word after being caught up with a house move an all that has involved.
    • Given the majority of changes LL wanted to implement are now in the SLua 0.710 branch and are relatively stable, he plans to merge-in the updates from upstream Luau in the next day or so.
      • This was not going to include the Luau integer implementation, however, as discussion in the meeting which indicated that integers are enabled by default, classes are not, in the most recent Luau updates may have given Harold pause to consider swapping LL’s integer implementation over to the upstream Luau implementation first.
      • He also noted he’s very much like for classes to be stabilized before general release but will “see how that goes”.
      • Once merged, the updates will take a little time to reach release as he catches up on the pending definition changes.

General Discussion

Please refer to the video below for  more on the following.

  • Pepper’s work on vehicle region  crossing led the a discussion on banlines and providing better means for those driving / sailing / boating / flying to identify parcels they are not able to access before then come up against the banlines and encounter problems (being unseated, becoming stuck and having to relog, etc., losing their vehicle, etc) – such as by highlighting parcels where access is block on the Mini-Map.
    • This led to a discussion on security orb, warning, marking parcels with orbs in operation, etc.
  • A further general discussion on Lua ran through the latter 2/3s of the meeting, interpolated with the above discussion for part of the time.
  • The slight drop on crossing regions when free-flying was discussed among region attendees.
  • Assorted commentary and one or two gripes and some viewer-side requests with the suggestion they are referred to the viewer (open-source) meetings.

Date of Next Meetings

  • Leviathan Linden: Tuesday, July 28, 2026.
  • Formal SUG meeting: Tuesday, August 4, 2026.

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 #29: SUG Leviathan Hour

Posted on by Inara Pey
The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, July 14th, 2026 Simulator User Group (SUG) off-week meeting (the “SUG Leviathan Hour”). These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from my chat log of the meeting, and Pantera’s video is embedded at the end of this article – my thanks to her, as always, for recording and providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Update

  • As recorded in my notes from the the previous Simulator User Group, there has been a bug which has been causing some regions to fail to grant capabilities.
  • Rider Linden has been investigating the issue, and a hot fix should have been / will be deployed during the July 14th SLS Main channel restarts and the restarts of the RC channels on July 15th.

Game_Control

  • Whilst not directly linked to Lua, Leviathan hopes to get his work on game_control complete and into the Lua editor viewer so it can be shipped with the Linux viewer support.
  • It has been suggested that PromptFont could be used for the game_control preferences UI, and Leviathan is investigating this.
  • He will also be providing some viewer-side actions that can be mapped to, and triggered by, pressing buttons on the game controller (e.g. fly, run, toggle Voice on/off) in addition to the existing ability to move the avatar around (walk, crouch-walk, jump, strafe).
  • Another area of work he is investigating is to add a limited interaction capability so avatars can walk up to in-world, unseated object and transmit an action event to it (such as display any dialogue menu it has associated with it).
  • Leviathan has previously mentioned the idea of adding “semantic” meanings to the game-control data, and had been considering adding a new event to provide that info.
    • However, Monty Linden has suggested using a new function call (e.g. “llGetSemanticGameControl()” or similar) which could be used in the regular event to get the same data but resorted according to how the viewer has mapped it.
  • Leviathan noted he also needs to add new data to the GameControlInput message.
  • These updates led to a further discussion on possibilities for game_control together with possible additional avatar movement option – please refer to the video for more.
  • Alongside of game_control, Leviathan has been working on enhancement for the viewer’s flycam capabilities (e.g. for use with a 3D mouse system), such as Roll. More work is required on this, which might see the enhancements ported to game-control.

In Brief

  • Leviathan noted he has been working on a fix for an issue he actually caused, in which attachment scripts sometimes cease working correctly according to parcel permissions. He tracked this to his changes in making the simulator process idle scripts faster.
  • Lua:
    • Following an internal meeting, it appears there is a “hopeful tentative plan” to release Lua in the “O” simulator update.
    • If time frames stand, this could be sometime in late August or September, given that the next simulator release will be Mango, which will be followed by Nectarine, which is targeting late July or August.
    • This would see the Lua editor viewer (with resumed official support for Linux) released around the same time, if not a little earlier.
  • Work on this has not as yet been merged into the simulator development code.
    • Leviathan believes the work is almost done, he just needs consensus for the rest of the team that the fix as he’s implemented it is the right thing to do.
    • Once consensus has been reached, the fix will likely be merged into the simulator development code for a future release.
  • It has been reported that there is an issue with events being dropped causing scripts to stop working as intended.
    • One report is that  scripted object stop working correctly when they change owner change owner, or message_linked or linksetdataRead randomly stop working.
    • The issue of scripts dropping is known to LL and Monty Linden is apparently investigating it.
  • A report has been made about the new dual-queue UDP messages processing code (currently in viewer-development but not released) in the viewer in that it causes out-of-order messages processing.
    • In particular, the first ObjectUpdate message creating an avatar can be processed too late and after the AvatarAppearance message to rez that avatar: since the avatar object is not yet created (not in object list), the AvatarAppearance is ignored and the avatar does not rez.
    • This may be due to there being assumptions in the dual queue design (both server and viewer side), which could be inappropriate, on the order in which some messages must be sent and processed for things to work properly.
    • Leviathan has indicated this will be looked into.
  • The above prompted Leviathan to note that he has a follow-up project to his UDP work and related to viewer networking he still hopes to get to.
    • This will be to tighten up the back-pressure info from viewer to server when it starts to get overloaded by network traffic, the problem being that when the viewer gets into this state, it will inform the server, but the process to send the messages takes too long and the viewer might only inform the primary simulator to which it is connected, not all the simulators it is currently talking to.
    • This led to a brief discussion on bandwidth throttling and use of an ACK UDP message to inform the server that its UDP queue is getting full, reducing the volume of messages until the flag is cleared by the viewer.
    • This was seen by Leviathan as a good idea.
    • See the last 15 minutes for the video for more on this.

Date of Next Meetings

  • Formal SUG meeting: Tuesday, July 21, 2026.
  • Leviathan Linden: Tuesday, July 28, 2026.

2026 week #28: SL Open Source meeting: OpenGL

Posted on by Inara Pey
Hippotropolis Theatre: home of the OSD/TPVD meeting
The following notes were taken from:

  • My chat log of the Open-Source Developer (OSD) meeting held on Friday, July 10th, 2026, together with my chat log of that meeting.
  • Pantera’s video of the meeting (embedded at the end of this article) – my thanks to her for providing it.
Table of Contents

Meeting Purpose

  • The OSD meeting is a combining of the former Third Party Viewer Developer meeting and the Open Source Development meeting. It is open discussion of Second Life development, including but not limited to open source contributions, third-party viewer development and policy, and current open source programs.
    • This meeting is generally held twice a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre and is generally text chat only.
  • Dates and times of meetings are recorded in the SL Public Calendar.

Official Viewer Status

  • Default viewer: Flat UI – 26.2.0.25386466510,  -“flat” UI and font update, dated May.
  • Second Life Project Viewers – Lua Editor Alpha viewer 6.1.0.23768336784, April 29.

Viewer Notes

  • 26.3 is back in development with some additional texture streaming work added. It’s currently awaiting QA testing.
  • The Lua viewer (with Linux support) still looks set to be the viewer to proceed to release status after 26.3.
  • The Graphics Care Package (GCP) viewer should be getting some attention “soon”.
    • Geenz Linden indicated that he’d to try and get more PBR fixes into GCP, and encouraged anyone with a broken environment to send details his way (+ landmarks to places that are broken vs. non-PBR).
    • The fixes for water (reflections, etc.), are “mostly there” in GCP, but there are still several edge cases that need tracking down.
    • The alpha-gamma work still doesn’t yet have a home in a viewer .

More on Updating from OpenGL

So, as everyone knows we’ve been on OpenGL for a very long time. And we’ve kicked the can on this for a while – mostly because although things aren’t moving most of the time in OpenGL land, it’s not really – moving. However, deprecation is still landing in various ways across various drivers and the like whether we like it or not, and we’re forever stuck on GL 4.1 because thanks Apple. That limits our options as far as further optimisations. But we can’t just up and move everything over night. There’s a good bit of tech debt that needs clean-up, API calls that are using a lot of older ways to do things, etc., and things that just don’t really make sense even in a “modern” OpenGL context.

– Geenz Linden, discussing plans for “after OpenGL”

  • Geenz went on to note:
    • The “first big chunk” of work – already underway and will hopefully ship with the Graphic Care Package (GCP) viewer – is cleaning up a lot of how OpenGL is used. There are still a lot of “exposed” OpenGL calls. A separate fork of the viewer cleans this up, and should be landing in GCP in the near future.
    • There needs to be work to update and modernise a lot of elements of the viewer that assume a surprising amount of old fixed function pipeline-style GL usage. This is also being worked on, and the hope is it will land in the GCP viewer.
    • There then needs to be some significant work on LLPipeline separation.
      • At its core, this means getting the rendering engine into its own library and making it so the viewer can more directly function in a headless state.
      • Whilst the viewer has had a headless mode for a while, it’ is currently under utilised, and more-or-less banks on LLRender being compiled with some flags that disable OpenGL.
      • The new library-based approach would make it so the rendering pipe is entirely its own library and optional; it just won’t have any render output on its own (it will require a render interface).
  • The current thinking at the Lab is to build a new renderer interface to replace LLRender, which can then be used to:
    • Either port the current rendering engine to Vulkan through, maybe something like an LLPipelineVulkan/ LLPipelineMetal/LLPipelineD3D12(?) + something called LLGPUDriver (which is pretty much where OpenGL/Vulkan/Metal lives).
    • Or TPVs can port in some other third party rendering engine without any coupling with LLRender.
    • Thus, the point of the renderer interface is to further decouple the viewer from the concept of rendering in the first place. Basically, there’ll like be LLRenderEngine which is probably going to be a (mostly) pure interface that LLPipeline gets to be the first consumer of.
    • He noted that this second option is still going through internal decision-making processes, and that both it and the first option are very much “a bit of a large lift”.
  • The reasons for this approach is about having an offramp from the OpenGL pipe without being super disruptive (as might be the case if the new pipeline ships prematurely, forcing people onto it similarly prematurely in a similar manner to PBR). So what is likely is that:
    • There will be an OpenGL pipeline that lingers for a while (aka “years”) as the legacy renderer.
    • Whatever lands as the “new” renderer (whether that’s a direct port to Vulkan or something else)
    • A debug setting to select which one is to be used.
  • A lot of what happens vis OpenGL overall is going depend on overall confidence in a new pipeline reaching a maturity across across a broad enough range of machines used to access SL so as to consider retiring OpenGL.
    • As such, the main thing LL will be tracking once  a project is initiated, is how well adoption is holding up on the low-end for this thing by the way. Some of those machines might be stuck on OpenGL forever, and might not get all of the shiny Vulkan stuff eventually.
  • Geenz further indicated at:
    • He’s been working on a rendering engine of his own for some time, and that is a potential option.
    • Using slang-rhi is very much an option asl well, so multiple APIs can be targeted APIs at once, and then just tweak depending on what is required to support a specific platform.
  • In terms of the up-front clean-up, etc., mentioned in Geenz’s opening statement on the subject, this was noted as being not that far away.
  • A request was made for the new renderer to support more than one pipe at a time with different camera angles, so that a single account could make use of them for shooting machinima, etc.
    • Geenz noted that this is unlikely to be officially supported.

Other Items

  • Some discussion circled the topic of “SLMesh2” (see my week #27 CCUG Summary), with Geenz noting:
    • His work on the project is liable to be more high-level, with Product Engine developers doing the coding work.
    • It will be an iterative project, with the first major element being more getting off of the current SLMesh format.
  • An update on the status of work in porting RLVa to the official viewer was requested. This was a project started a few years ago and then appeared to be moved to the sidings. No response was given, possibly because the question was missed in the OpenGL / renderer discussions.
  • A discussion on water and reflections towards the end of the meeting.

Next Meeting

2026 week #28: SUG meeting summary

Posted on by Inara Pey
The Simulator User Group meeting place at Longfellow

The following notes were taken from the Tuesday, July 7, 2026 Simulator User Group (SUG) meeting. These notes form a summary of the items discussed, and are not intended to be a full transcript. They were taken from the video recording by Pantera, embedded at the end of this summary – my thanks to Pantera for providing it.

Meeting Overview

  • The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas is held every other Tuesday at 12:00 noon, SLT (holidays, etc., allowing), per the Second Life Public Calendar.
  • The “SUG Leviathan Hour” meetings are held on the Tuesdays which do not have a formal SUG meeting, and are chaired by Leviathan Linden. They are more brainstorming / general discussion sessions.
  • Meetings are held in text in-world, at this location.

Simulator Deployments

  • No deployments for the week, just restarts
  • The next simulator update will be called Mango.

In Brief

  • Rider Linden:
    • Has merged in the rulebuilder code for Lua, so that’s ready to go. He noted that if any one wants to volunteer to fill out the tables for some functions it would be much appreciated.
    • This week he is on-call and hopes to hunt down an issue that’s causing some regions to fail to grant capabilities. He has ideas on the cause, and so is hopeful he can fix it.
    • Is also working on object publishing (prims as virtual filesystem that can be interacted with directly from VSCode, so it is possible to access and create scripts and notecards in a prim directly from VSCode rather than to have to keep switching focus between prims in world).
  • Leviathan Linden:
    • Is back working on game_control, currently doing an overhaul of the preferences UI and how the settings get formatted.
    • Notes the goal is to make it possible to map buttons to avatar movement actions (i.e. DPAD buttons to MOVE_FWD and MOVE_BACK)
    • Currently, the game_control viewer code is distinct from the Lua viewer code, but Leviathan plans on using that viewer in code merges with the game_control code.
  • Roxie Linden noted that:
    • Has been working on the WebRTC p2p IM bug where sessions fail to start, and is making progress. The issue seems to be a race condition in the back-end chat handling code; however, given the exact cause is hard to reproduce, there is no guarantee the fix in progress will correct all instances of session start failure, but Roxie optimistic.
    • On the viewer-side, has been working on changes to pull in a more recent libwebrtc + reduce some audio hiss.
  • Harold Linden (LUA):
    •  Has been busy with personal matters, but is now hoping to get back on top of  Lua PRs and resuming work on bringing the SL Lua back in-line with Luau upstream. This is seen as important as many things added to Luau upstream which would be useful for the Lua project (e.g. 64-bit integers and classes).
    • Commenting on the general state of the project, Harold added:
[the work is] Mainly polish at this point. I’d like our integer implementation to be based on Luau’s even if it’s not entirely the same under the hood so LSL can perform well, and I’d to have all scripts share a GC so that we don’t have separate memory allocators for each and every script as we do currently.
  • Monty Linden noted that lsl-definitions have been updated recently but not baked into a release and cycled around yet – this will happen “soonish”.

General Discussion

Please refer to the video below for  more on the following.

  • One of the issues with Lua on the simulator side has been the simulator crash rates. Rider described these as now being “encouraging”, many of the issues are “known and on the list to address”.
  • Harold’s comments on adopting upstream updates from Luau led to a discussion on 64-bit and 32-bit Lua support.
  • This in turn led to a discussion on Lua and llhttp.request.
  • A discussion on documentation.

Date of Next Meetings

  • Leviathan Linden: Tuesday, July 14, 2026.
  • Formal SUG meeting: Tuesday, July 21, 2026.

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