2024 SL SUG meetings week #37 summary

Xanadu, August 2024 – blog post

The following notes were taken from the Tuesday, September 10th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. Pantera’s video is embedded at the end – my thanks to her 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.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, September 10th, the SLS Main channel was restarted without any deployment.
  • On Wednesday, September 11th:
    • There will be a further attempt to deploy the Picnic simulator update to the Ferrari simulator RC channel. A bug was found in llAvatarOnSitTarget() last week, which has now been fixed. The hope is that Picnic will now progress to the rest of the simulator RCs during week commencing September 16th, 2024, and thence to the SLS Main channel the week after.
    • The remain RC channels will be restarted.
  • Monty Linden indicated he is very interested in feedback about avatar region crossings  / TPs, particularly with with Ferrari versus the rest of the grid.

Future Deployments

Currently, and following on from Picnic, upcoming simulator deployments currently have the following order:

  • Doubtfire, which has some internal changes, will follow Picnic.
  • Then will come the WebRTC deployments to make that code grid-wide.
  • After WebRTC will come a new simulator update called BBQ, which is still gathering updates for inclusion.

SL Viewer Updates

No updates at the start of the week, leaving the currently available public versions of official viewers as:

  • Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus RC (object take options; improved MOAP URL handling) promoted August 26.
  • Release channel cohorts:
    • DeltaFPS RC, version 7.1.10.10708851543, updated September 5.
      • Performance boosts. Memory management has been optimized and users will experience a higher FPS across various systems. A comprehensive range of bug fixes are also provided. This includes better PBR material handling and resolving frequent crashes. See the release notes for more.
      • UI for scheduling region restarts now available via a new button located in the Region/Estate floater. (Note: there is currently an issue with scheduled region restarts working correctly and a fix is due to come in the next server release).

In Brief

Please refer to the video below for the following:

  • Issues have been reported with attachment behaviours. for example:
    • Attachments would disappear from everyone’s view except owner, who would be unable to detach, reattach, or interact in any way with the affected attachment, as the server no longer register them as attached.
    • This Canny issue (simulator release specific)).
    • Some of these are currently under investigation, and the subject led to an extended discussion through the first half of the meeting.
  • Pepper Linden noted further updates to the Map service are due to be deployed, and that pruning of ghost regions (those no longer on the grid but still showing on the Map) should commence later in the week.
  • 2K BoM texture bakes: it is possible that code for this may be deployed to Aditi (the Beta grid) some time in the next week or two, bugs allowing. Hopefully an update at the next SUG or CCUG meeting.
    • The rule of thumb is that the bake resolution will match the maximum of any texture. So, if all the textures are 1024×1024, then the bake will 1024×1024. But if one of the textures is 2048×2048, then the bake will be 2048×2048.
    • The exception to the above will be eyes, which are limited to a maximum resolution of 512×512.
    • The deployment of 2K Bakes on Mesh will have an associated official blog post as it becomes available.
  • Add flag to llSetLinkSitFlags, SIT_FLAG_INVISIBLE is now being actively tracked by LL. The hope is to have the request in the simulator release after BBQ.
  • Lua work:
    • There are no plans on LL’s part to provide a translate from LSL user-code to Lua user-code.
    • Luau will likely be in 32-bit mode, until LL get the simulator binary building in 64-bit mode.
    • LL do not intend to define standards on how to write a Lua script for Luau; they are hoping that the community will consolidate and settle on particular design patterns and approaches, and once the dust settles, LL may then standardise the most common approaches
  • A general discussion on on throttling for llRegionSay and llRegionSayTo.
  • Leviathan Linden indicated the a dedidcate Game Control viewer is on hold as he is currently engaged on other work, and the code needs to be tested in relation with the Lab’s updated Linux support.

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

2024 week #36: SL CCUG summary: viewer performance and aesthetics

Goblins Knob, August 2024 – blog post
The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday,  September 5th, 2024.

The meeting was also livesteamed on You Tube by the Lab. The video is embedded at the end of this summary, my thanks to the Lab for providing it.

Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
  • Meeting dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers Status

  • Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus RC (object take options; improved MOAP URL handling) promoted August 26.
  • Release channel cohorts:
    • DeltaFPS RC, version 7.1.10.10708851543, updated September 5.
      • Performance boosts. Memory management has been optimized and users will experience a higher FPS across various systems. A comprehensive range of bug fixes are also provided. This includes better PBR material handling and resolving frequent crashes. See the release notes for more.
      • UI for scheduling region restarts now available via a new button located in the Region/Estate floater. (Note: there is currently an issue with scheduled region restarts working correctly and a fix is due to come in the next server release).

Viewer Performance – Priorities

[Video 1:15-3:03]

  • The performance setbacks between the original PBR viewer release (7.1.6) and the Graphics Featurettes viewer (7.1.8), and which particularly negatively hit the Firestorm PBR release were again covered (for additional content, see my August 30th TPVD meeting summary).
  • This has resulted in a “significant portion” of the viewer development work being focused on recovering performance and rectifying the underpinning bugs and issues – some of which are not specific to the PBR implementation itself. Some of this work has been surfaced in the DeltaFPS viewer, but more is to come.
  • The above work also folds into it various fixes for crashes and bugs and a number of Visual Aesthetics (as in how SL looks – see below).
  • This work will impact other areas of viewer work, so glTF projects like the PBR Terrain Painting and Transmission / IOR work are going to be pushed back somewhat, as is work on the viewer-side implementation of Laua scripting support. However, all of these work is still on the roadmap, just delayed.
  • [Video: 8:24-8:56] Cosmic Linden has been working on an improvement to avatar loading to assist with performance improvements, and this has been pushed to the DeltaFPS RC viewer, together with working on bug fixes.
  • [Video: 9:00-9:54] Runitai re-iterated that the Graphics Featurette viewer introduced the major performance hits (some of which are related to bounding box management and memory management, the the TPVD notes linked-to above), and DeltaFPS sees a good improvement in performance over Graphics Featurettes, and the viewer in development (“ExtraFPS) that will follow DeltaFPS should see performance return to levels seen with the initial PBR release.
  • [Video: 45:46-46:36] Which is not to say there are not additional PBR-related performance problems – such as those tied to specific GPU such as the Nividia GT1030 2Gb. These are also the subject of fixes being implemented in either the DeltaFPS viewer or the upcoming ExtraFPS viewer that will follow it.

Viewer Aesthetic Updates

[Video: 4:54-8:10]

  • Linear alpha blending: in order for PBR lighting to render anywhere close to correctly, alpha blending has to be switched from SRGB to linear colour space. This can cause some older content using Blinn-Phong to look either more opaque or more transparent than in did pre-PBR.
    • The fix for this will likely be to add the ability for people to set and alpha/gamma ramp on an item, which can be modified per texture entry, adjusting how transparent the item is on a curve.
      • This should help with a range of issues – particularly those associated with pre-PBR hair, as has been noted by an number of users.
      • To help with this, the new alpha/gamma ramp value will still be adjustable even if the content is No Mod, so as to allow users to adjust legacy content affected by the issue, rather than having to wait for  fixes from content creators.
    • This fix will hopefully follow in the ExtraFPS viewer after DeltaFPS, but in the meantime will be made available in a viewer build available through the Content Creation Discord group‡ for those wishing to test it once the initial work has been completed.
    • Runitai Linden also indicated that as an extension to this work, LL might be able to find a way to apply the adjustment automatically, rather than people having to manually set it, but also noted any automatic solution would be “hard”.
  • Auto-exposure: LL is looking to add controls for dynamic exposure (speed of transition, range, ability to turn off / on). These options will be made available via the Advanced Graphics floater, and maybe / someday via the the sky settings floaters.
  • [Video: 10:03 -10:50] Anti-aliasing: there has been negative feedback from those who used to run the viewer with Advanced Graphics Model (ALM) disabled and who are forced to have it enabled all the time as a part of the PBR rendering, don’t like the look of Fast Approximate Anti-Aliasing (FXAA) as used in the viewer, so LL are adding support for Subpixel Morphological Anti-Aliasing (SMAA).
    • In addition, Rye Cogtail from the Alchemy team did a pass on the FXAA code and found it was not working as well as it should be.
    • Updates to FXAA and the addition to SMAA will be appearing in the viewer to follow DeltaFPS.
    • Those requiring more insight into anti-aliasing and the various types of AA, including FXAA and SMAA, can find out more in What Is Anti-Aliasing? TAA, FXAA, DLAA And More Explained, via Digitaltrends.
  • Work is also being put into smoothing the problems created by switching from 8-bit colour precision to 16-bit float colour precision (which can be the cause of bugs wherein you go somewhere in SL and everything glitches to black or solid white). This work should surface through DeltaFPS.
  • [Video: 11:05-11:45] The Sun is unrealistically dim. LL are considering adding a specific Sun intensity multiplier to Sky settings.
    • As a temporary fix, and whilst not specifically addressing the sun issue, the overall brightness in a scene can be adjusted via very small tweaks to the HDR slider in the Personal Lighting floater.
  • [Video: 49:16-56:05] Tone mapping: Rye Cogtail from the Alchemy team has contributed the Khronos Neutral tone mapper for inclusion into the viewer.
    • This is not as dark as the current default in the viewer, and initially will use debugs to select which tone mapper is used (as the existing mapper will remain).
    • LL are looking to make this the default for tone mapping (subject to the outcome of testing), and the mapper is currently in the viewer Develop branch for TPV / viewer builders to take a look at.
    • When implemented the controls will likely be in the Advanced Graphics settings as a combo box and a slider. The control may also in the future be added to the sky settings.
    • In addition, there will be a new control – Tone Mapping Strength – to alter the linear alpha colour.
    • A key point to content creators on this is: you should not put the tone mapper in your textures (e.g. via the options available in PhotoShop when exporting textures) by bumping saturation, etc., and baking the tone mapper into the texture (as well and not baking things like reflections into textures).
    • WYSIWYG will still be possible providing creators select a tone mapper in SL that matches the mapper in their tool of choice or by using no post and working in linear + using the HDRI Preview option (Develop(er) > Render Tests) and use the same HDRI in SL as your content creation tool.

WebRTC

[Video 3:05-4:26]

Summary

  • A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
  • Key benefits:
    • WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
    • Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
    • Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.

Status

  • WebRTC is now fully supported in the official viewer.
  • The back-end deployment on the simulator servers is progressing (2 release candidate channels for simulator servers – BlueSteel and Ferrari – should now have WebRTC support), but this is not yet universal across the entire grid, and will take at least another 2 weeks to be grid-wide.
  • Throwing the switch from running Vivox on the back-end to running WebRTC only will be dependent upon third-party viewers implementing and releasing the viewer-side WebRTC library.
  • In the meantime, peer-to-peer and ad-hoc WebRTC can be tested on the WebRTC regions of WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4. However, there is no bridging between WebRTC peer-to-peer  / ad-hoc and Vivox.

In Brief

  • [Video 17:06-25:06] A discussion on Marvelous Designer (MD) cloth simulation within Second Life. This was done with Sansar, allowing clothing to be properly draped over an avatar body, and allowed for adjustments to be made prior to the finished results being baked-out (with automatic hidden surface removal).
    • Second Life utilises a different data modern to Sansar which introduces a range of complexities that would require significant re-working of how clothing  / mesh data is management, a potential re-writing of the entire Bake Service and other factors, all of which make MD integration a challenge.
    • Further complexities are added by the fact that unlike Sansar, which utilised a single avatar body type, SL has a plethora of bodies, and so using the cloth simulation against different body types (whether by creators or users) gets considerably more complicated, as do the requirements for data handling / storage and the costs involved.
    • As such, whilst these issues are not necessarily complete barriers to integration, they do mean that there are significant considerations involved, as well as significant changes to SL that would have to be made. Thus, it is not currently on the roadmap or under current consideration.
    • Please refer to the video for further details.
  • [Video: 25:16-26:12] 2K texture support for Bakes on Mesh – while there was no precisely update available:
    •  It is believed the majority of the work in enabling 2K Bakes on Mesh is now done in terms of getting an early prototype put together on one of the Lab’s own development grids.
    • However, there is currently no public availability for the capability, not is there any release schedule. The work remaining “on-going”.
  • [Video: 26:31-28:50] A brief discussion on creating content with both Blinn-Phong and PBR materials and some of the issues that can occur + some of the slight eccentricities (e.g. objects with both appearing to turn metallic when edited).
    • It was noted that as Blinn-Phong is still supported, creators can continue to use that in preference to PBR materials, although as time goes on the underpinning tools (like Blender) might move more and more into the glTF support arena and make it easier to produce glTF compliant content which can be used in SL.
  • [Video: 29:14-30:57] Transmission and IoR: these are being implemented against the glTF extensions approved by Khronos. This work is focused on implementing them against the prototype glTF implementation, then it they pass that, the focus will move to integration with SL and how they work with glTF materials assets and how to apply them to mesh and prim faces.
    • However, as noted above, this work is currently paused pending completion of the performance improvements work, and is unlikely to resume until after the viewer following Delta FPS has surfaced.
    • It was also noted that it will still be a while before LL are confident enough with both Transmission and IoR to allow either to be added to content be users, even on a test basis.
  • [Video: 40:22-41:48] The question was asked that, when SL gets glTF morph targets, if it would be possible to swap out vertex maps as well to change vertex weights so that it might be possible to deform clothing using the morph targets via script, then change the rigging, so an to allow one-size-fits-all clothing.
    • Runitai Linden noted that LL are aiming to hit all of the “musts” and “shoulds” in the glTF  specification. For morph targets, this means effectively having three channels per mesh that can be modified with the morph slider, thus limiting what could be done.
  • [Video: 42:10-44:55] llSetAlpha / llSetColor, etc: LL is planning on making these functions implicitly access the PBR equivalents when a PBR material is present. However, this is hampered by the fact a good proportion of users are still on non-PBR viewers, so “there’s not good answer to which channel it should modify.” This means that currently, the easiest thing it to leave the functions “as is” until sufficient enough users are on viewer with PBR support.
    • This does not mean non-PBR content will no longer be a thing; just that creators should not have to make a non-PBR version of their content because there are people still using a non-PBR capable viewer.
  • The last few minutes of the meeting are spent discussing what additional elements of the glTF specification have yet to be worked on.

Next Meeting

Footnotes

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

‡ Due to an express request from Linden Lab, I am unable to publish information on how to join the Content Creation Discord group. If you are a creator and are not a member, please contact Vir Linden via notecard or IM.

Linden Lab promotes updated SL Combat System 2.0 with video

Combat 2.0, courtesy of Linden Lab

As regulars to these pages are probably aware, I covered the Combat User Group meetings from February 2024 through until late July, 2024, during which Rider Linden worked with members of SL’s widespread community of combat enthusiasts on an initial overhaul of Second Life’s combat system (SLCS). The aim was not to develop a new combat game or combat system, but to provide combat enthusiasts with a much improved box of tools (scripted capabilities) for better, more immersive combat experiences within Second Life.

Details of what many hope will be the first phase of the Combat 2.0 project can be found in my Combat User Group summaries.  However, two spin-offs (so to speak) of this work have been the Combat Partnership, and the return of three much-loved combat regions (which were originally part of the Teen grid): Concord, Lexington and between them, No Mans Land, with the promise that the latter would undergo a facelift and act as a new nucleus to help encourage combat enthusiasts – both within Second Life and those who may have departed the platform – to give the new and updated capabilities a go.

An inaugural (and informal) meet-up within the regions was initially held on July 25th, mainly featuring those combat enthusiasts who had participated in the user group, the session being to mark a wrap on the first phase of work and to put the Combat User Group on hiatus for a time.

Combat 2.0: Concord (with personal EEP setting)

Now the facelift work on the three regions has been completed, and on September 5th, 2024, Linden Lab launched a new promotion for Combat 2.0 utilising a video produced by Vrutega‬, expressly aimed at encouraging people to come back into Second Life and give things a go. And going on preliminary responses, it has been well-received. 

Concord and Lexington act as the base locations for two teams for those wishing to engaged in team-based combat, but the regions are also open to more general player versus player (PvP) or player versus environment (PvE) combat. They each have  dedicated landing point:

No Mans Land is the epicentre for combat. It includes a network of WW1 style trenches, open land, for PvP and cover for PvE against the roaming armed aerial drones. For team-based combat, Red and Blue flags are also located in the region, ready to be attacked / defended. Nor do those wishing to join in have to equip themselves before joining in – those who are new to Combat in SL or are making a return out of curiosity, can obtain various free weapons, generously provided by creators with the Second Life combat community. These can be found within the hangers at Concord and Lexington, and some might be floating around elsewhere.

As well as the showcase regions at Concord et al, the updated Combat 2.0 capabilities are available to all combat regions holders in Second Life to leverage. As a very, very small thumbnail of the updates, the following are now available with Combat 2.0:

  •  Damage events (llDamage) and healing (incl. objects having health).
  • Better control over what happens on death.
  • Spawn points.
  • A new and dedicated combat log – “Brigadier Linden” combat region owners can leverage in administrating combat in their regions.
  • region-wide settings available to combat region owners.
  • new LSL functions and events.

All of these are covered in much greater detail via the dedicated Combat 2.0 SL Wiki page, which also includes links to specific information on things like the Combat log and updated / new LSL functions.

Combat 2.0: No Man’s Land (with personal EEP setting)

Combat Partnership

With Combat 2.0 becoming available, Linden Lab has announced the Combat 2.0 Promotion Partnership Programme has been launched.

  • The intention behind the Promotion Partnership Programme this is to give those actively involved in combat activities in Second Life the “opportunity to help us spread the word across the grid about Combat 2.0 in Second Life”.
  • Participants will have their regions / communities included in a Combat section of the Destination Guide. There may be other benefits for participants as well.
  • Those interested can sign-up via this Google form.
Combat 2.0: Lexington

So, if you’re curious about combat in Second Life, why not hop over to Concord or Lexington and have a look around.

SLurl Details

The showcase combat regions are rated Moderate

2024 SL SUG meetings week #36 summary

NeverendingSL: Souru Sosaeti, August 2024 – blog post

The following notes were taken from the Tuesday, September 3rd, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. Pantera’s video is embedded at the end – my thanks to her 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.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, September 3rd, the SLS Main channel was restarted without any deployment.
  • On Wednesday, September 4th:
    • The BlueSteel and Ferrari simulator RC channels will receive the Picnic simulator update (which includes: llFindNotecardTextSync, llDerezObject, for the viewer side, group member lists can now be retrieved in a paginated manner).
      • The existing WebRTC regions of WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4 might also be updated with Picnic.
      • Picnic also include the first of the region crossing improvements Monty Linden has been working on. These should see a) avatars already in a destination region getting better frame rates as others arrive in the region; b) crossing avatars with too many scripts will experience slower but smoother crossings.
    • The remaining simulator RC channels will be restarted without any new deployment / update.

SL Viewer Updates

No updates at the start of the week, leaving the currently available public versions of official viewers as:

  • Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus RC (object take options; improved MOAP URL handling) promoted August 26.
  • Release channel cohort: DeltaFPS RC, version 7.1.10.10622905308, issued August 30.
    • Performance boosts. Memory management has been optimized and users will experience a higher FPS across various systems. A comprehensive range of bug fixes are also provided. This includes better PBR material handling and resolving frequent crashes. See the release notes for more.
    • UI for scheduling region restarts now available via a new button located in the Region/Estate floater. (Note: there is currently an issue with scheduled region restarts working correctly and a fix is due to come in the next server release).

In Brief

  • The recent updates to the SL Map system appears to have been generally well received, with those providing feeding at the meeting noting the Map does appear to load a lot quicker and that changes to regions are more timely in being reflected on the Map.
    • The ability to see ground-level details of regions using regions surrounds where the scale is > 256*1.33 on either the x or y axis (rather than them appearing a flat grey) has been particularly appreciated.
    • The next element of this work will include improvements to pruning “ghost” regions from the Map (i.e. regions that appear on the Map but are no longer a part of the grid).
    • This sparked a general discussion on the Map and its capabilities and possible updates.
  • Github issue: [PBR] PBR Material resets to legacy material after teleport. #853 – while there is no fix for this at present, it sparked a discussion on issues related to broken meshes, which appear to result from the simulator and viewer not agreeing on how many faces a mesh has. Some of this may have been fixed in the Altasaurus release viewer, and Brad Linden noted, there are more coming in the 7.1.10 (DetlaFPS) RC and the viewer to follow it.
  • A reminder that if people have issues where log files might help LL with investigations, this article provides information on where to locate said logs for attaching to a bug report.
  • Need a function for easy PBR alpha switching: Brad Linden indicated he had started working on this, but he’s had to shift over to doing some viewer-related work, so things are currently on hold.
  • A discussion on a means for scripted Group join invites, rather than requiring a bot – please refer to the last third of the video.

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

2024 week #35: SL TPVD meeting summary; performance issues

Petite Provence d’Annisss, July 2024 – blog post

The following notes were taken from my audio recording + the video recording by Pantera (embedded at the end of this summary) of the Third-Party Developer meeting (TPVD) held on Friday, August 30th, 2024. My thanks to Pantera as always for providing it.

Meetings Purpose

  • The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
  • Dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers Status

[Video: 1:25-4:45]

  • Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus RC (object take options; improved MOAP URL handling) promoted August 26.
  • Release channel cohorts:
    • DeltaFPS RC, version 7.1.10.10622905308, issued August 30th.
      • Performance boosts. Memory management has been optimized and users will experience a higher FPS across various systems. A comprehensive range of bug fixes are also provided. This includes better PBR material handling and resolving frequent crashes. See the release notes for more.
      • UI for scheduling region restarts now available via a new button located in the Region/Estate floater. (Note: there is currently an issue with scheduled region restarts working correctly and a fix is due to come in the next server release).
  • The next viewer to surface after DeltaFPS will have further bug fixes and improvements.

Graphics / PBR

Performance Issues Update

On Thursday, August 29th, Linden Lab issued the following via the Grid Status report mechanism:

We have seen an increase in crashes for some Residents on Windows with older Intel HD-based graphics (GPUs) after the latest release of Second Life Viewer 7.1.9.

If you are experiencing such issues, be sure to download and try the DeltaFPS RC given above. This has a lot of changes and fixes to things like bugs, and to texture loading, memory management (including running the viewer in the background), etc, and those testing it who encounter issues are asked to file reports.

Work Status

[Video: 4:58-7:00]

From Runitai Linden:

We’ve been going over statistics trying to figure out what went wrong and in our stats, 7.1.6 [quoted as 7.1.7] was running quite well, and 7.1.8 [the Graphics Features viewer release] was running quite badly. Atlasaurus [the current release at the time of writing – 7.1.9.10515727195] gets us back up close to where were with 7.1.6, but not quite to where we want to be, so we’ll see where DeltaFPS lands and will get some statistics on that over the weekend. 
We do know some low-end systems are having problems with the PBR update, so we’re still looking at that. for example, we’ve noticed that on Nvidia GT1030s [[GPU released in 2017] we’re had a large drop-off of users from users on those cards. Now we have some of those in-house, and we’ll be making sure … they run well on those. 
Most of the issues for low-ends seem to be coming from running out or memory, and there was a bug that went out  with Featurettes that caused the viewer to think that you had system memory available, and it would continue to allocate textures and then run out of memory and your performance would go to crap and you’d crash. So that’s been fixed in Delta FPS, it was not fixed in Atlasaurus, so were hoping to see the trend continue to improve with the release of DeltaFPS. 

– Runitai Linden, video: 4:58-6:47

  • Runitai further indicated that DeltaFPS is running SL a lot better than has been the case for some time, and that the graphics team are continuing to work on things.
  • [Video 35:49-38:17] Whilst PBR  / mirrors have been blamed for the performance impacts people are experiencing, outside of issues with the likes of GT1030 GPUs mentioned above, LL’s investigations have show that the performance issues evident in the Graphics Featurettes viewer are not related directly to PBR or mirror rendering (although the latter will naturally impact FPS – just not to the degree people have witnessed).
    • Rather, the issues are related to bugs with elements such and bounding box management and memory management which had been previously missed, but particularly came to the fore with Firestorm’s PBR release.
    • Retrospectively, Runitai acknowledges that LL should have picked up on the issues before the Graphics Featurettes code was released, as they had all the data to hand. As a result, the release process has been adjusted to try to account for these circumstances to try to prevent a similar occurrence in the future.
  • [Video: 16:59 in text] Everything Looks Black and White should be fixed in either the current Altasaurus release viewer or in the DeltaFPS RC.

Improved Controls for Visual Aesthetics

[Video: 7:39-13:30]

This is currently work in progress and includes:

  • Linear alpha blending: in order for PBR lighting to render anywhere close to correctly, alpha blending has to be switched from SRGB to linear colour space. This can cause some older content using Blinn-Phong, causing it to look either more opaque or more transparent than in did pre-PBR.
    • The fix for this will likely be to add the ability for people to set and alpha/gamma ramp on an item, which can be modified per texture entry, adjusting how transparent the item is on a curve.
      • This should help with a range of issues – particularly those associated with pre-PBR hair, as has been noted by an number of users.
      • To help with this, the new alpha/gamma ramp value will still be adjustable even if the content is No Mod, so as to allow users to adjust legacy content affected by the issue, rather than having to wait for  fixes from content creators.
    • This fix will hopefully follow in the viewer after DeltaFPS.
  • Tone mapping is another aesthetic being looked at.
    • Rye Cogtail from the Alchemy team has contributed a neutral tone mapper which is not as dark as the current default in the viewer, and LL are looking to make these the default for tone mapping (subject to the outcome of testing).
    • In addition, LL are looking to re-add tone mapping controls to the Advanced Graphics floater.
    • These were available as debugs early in the PBR beta, but creators found it confusing as to which tone mapper they should target.  However, it is hoped that creators now understand that tone mapping is something that should be done by the renderer and not something dome to the diffuse map in PhotoShop (or equivalents).
  • Auto-exposure: LL is looking to add controls for dynamic exposure (speed of transition, range, ability to turn off / on). These options will be made available via the Advanced Graphics floater, and maybe / someday via the the sky settings floaters.
  • The overall hope is that by adding additional functionality and options like this, LL will be in a better position to identify defaults that don’t cause users angst by making things look too different all at once, and will provide users with all the tools they need to adjust their visuals to their liking when changes are made.

WebRTC

[Video 15:00-15:36]

Summary

  • A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
  • Key benefits:
    • WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
    • Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
    • Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.

Status

  • Once the viewer-side updates for WebRTC is widely adopted, the switch for the back-end switch over from Vivox to WebRTC will be thrown.
    • The hope is that this could happen in September, depending on how fast TPVs adopt and release the viewer code.
    • [Video 17:39-18:12] In order to minimise the impact of running both Vivox and WebRTC side-by side, it is hoped that switching to WebRTC can be completed in two step: throwing the switch for all simulators on the RC channels one week,  and a week later switching all simulators on the SLS Main channel.
  • In the meantime, peer-to-peer and ad-hoc WebRTC can be tested on the WebRTC regions of WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4. However, there is no bridging between WebRTC peer-to-peer  / ad-hoc and Vivox.

In Brief

Please refer to the video, below.

  • [Video: 19:16-21:52] Will PBR will replace the “old clothing system” one day?
    • Short answer: on a technical level, probably not, given the longevity of content of all kinds in SL. However, whether creators continue use older system / methodologies are newer ones emerge is  down to choice / what drives their market.
    • That said, PBR will impact system layer clothing in as much as LL are actively working on 2K Bakes on Mesh, after which they will be looking at adding PBR to system layers.
    • In respect of legacy content / capabilities, this is why things like Blinn-Phong materials continue to be supported, etc.
  • [Video: 22:32-26:10] Exclusion volumes / invisiprim replacements:
    • There have been a number of requests for exclusion volumes to keep water out of boat hulls and particle weather like rain and dusty wind outside of buildings. etc. These are seen as being something for the longer-term roadmap.
    • In terms of providing an invisiprim style capability outside of this type of use, specific Canny feature requests on why and how such a capability (or options) are required / would be used were requested.
  • [Video: 28:06-32:08] SSR causes moiré-like patterns on the water (formerly BUG-233647): this has been a particular issue for those who enjoy pursuits like sailing and boating, or who simply like to look out over Linden Water.
    • The issue is rooted in the implementation of reflection probes, which required a simplification of the water shader so it did not dominate frame rendering.
    • Screen Space Reflections (SSR) was an attempt to redress this and get SL back to high-quality water rendering, but has not worked as hoped.
    • Geenz Linden is now looking to use some of the work on planar mirrors to possibly allow high-quality water reflections once more. However, this will impact viewer FPS when enabled, and if implemented.
    • It was also noted that there were performance issues with the release of mirrors and hero probes in the Graphics Featurettes viewer, but some of these have been fixed & mirrors are now defaulted to “off”, no matter what the graphics quality default is.
  • [Video 31:41-35:48] The above led to a broader discussion as to the perception of what PBR is for, how the changes were communicated, the need for creators to fully understand the differences in how they might have used PBR (e.g. baking reflections into the diffuse map) when producing textures and materials prior to the introduction of PBR support, and how they should be doing things now when using PBR, etc.
  • [Video: 42:00-46:16] a discussion on a  texture loading issue, potentially fixed using the the multithreaded texture debug option, on Mac systems running Apple Silicon. This appears to be a test on a bug fix that had been implemented to try to eliminate issues of texture loading on Silcon, and might offer an alternative solution, but needs investigation.
  • Firestorm Notes:
    • [Video: 46:26-51:50] 2K textures in Group Profiles: it has been noted that the use of 2K textures for Group Profile images will crash Firestorm 6.6.17 (pre-PBR release) for any user using that viewer who opens the Group Profile or tries to join the Group. So the request is (for now) for people not to use 2K textures as Profile images.
    • It was noted that Firestorm’s 3-version viewer policy stems from an old LL policy (introduced under Oz Linden’s tenure as VP of Engineering) which LL no longer adhere to (and by extension, TPVs are not obliged to adhere to if they do not wish to).

Next Meeting

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

2024 SL SUG meetings week #35 summary: Combat 2.0; Kindriod AI

Ai-mura, July 2024 – blog post

The following notes were taken from the Tuesday, August 27th, 2024 Simulator User Group (SUG) meeting. They form a summary of the items discussed, and are not intended to be a full transcript, and were taken from my chat log. Pantera’s video is embedded at the end – my thanks to her 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.
  • These meetings are conducted (as a rule):
  • Meetings are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
  • Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.

Simulator Deployments

  • On Tuesday, August 27th, the SLS Main channel was restarted without any deployment.
  • On Wednesday, August 28th:
    • Simulators on the BlueSteel RC channel should receive the Picnic simulator update (which includes: llFindNotecardTextSync, llDerezObject, for the viewer side, group member lists can now be retrieved in a paginated manner).
      • Picnic also include the first of the region crossing improvements Monty Linden has been working on. These should see a) avatars already in a destination region getting better frame rates as others arrive in the region; b) crossing avatars with too many scripts will experience slower but smoother crossings.
      • Monty reminded people that region crossings involving vehicles are a more complicated issue and not part of this work.
    • The remaining simulator RC channels will be restarted without any new deployment / update.

SL Viewer Updates

  • Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus-WebRTC RC (object take options; improved MOAP URL handling, WebRTC) promoted August 26.
  • Release channel cohorts:
    • None.

Combat 2 Updates

Rider Linden is proposing the following for respawn:

When death occurs, if a respawn location has been set the agent will be teleported to the specified location. If no respawn location is set, the region’s default death behaviour applies (for instance teleport home, or teleport to telehub). The agent’s respawn point survives region crossing and death teleports, but is cleared when the agent makes an inter-region teleport or logs out of Second Life. The following new functions have been added to LSL: llSetRespawnLocation(vector position, rotation facing); llSetRespawnLandmark(string inventory_name); llClearRespawn() and llHasRespawnSet(key agent_id)

He further indicated that he had looked at the above as not necessarily having to be tied to an Experience, they could be granted via a HUD, a regular permission request or an Experience, however questions were raised about managing unwanted scripted respawn being created by users and other potential complexities that may move these functions back towards being Experience based.

This led to a discussion on options and Combat, which ran through the majority of the meeting – please refer to the video below.

Kindroid AI NPCs & Companions

On Monday, August 26th, Linden Lab announced “the integration” of AI companions and NPCs using Kindroid (with the announcement causing some confusing in using both “experience” in generic terms and in reference to SL Experiences).

With Kindroid, you can create engaging and lively characters with lifelike memory, intelligence, and personalities that interact and engage in emotionally-deep and meaningful ways – and then bring them to life within our virtual world. Imagine crafting characters that add fun and engaging new narratives into your roleplaying adventures – or maybe you’ll create a companion that can serve as a language tutor or mentor – the possibilities are endless!
With its API, you can integrate Kindroid characters into your Second Life experience using LSL and scripting, just like other objects. Whether you’re looking to enhance social interactions or explore new storytelling possibilities, Kindroid offers an exciting new dimension for any Second Life adventure.

– From the LL announcement

The announcement provides detailed instructions on using LSL to link an Kindroid AI “chatbot” with objects in-world, with LL recommending the use of Animesh, and, for security purposes, the use of the Experience Key Value Pairs (KVP) database to ensure security of API keys.

I’m honestly not au fait enough with Kindroid or AI chat system (generative or otherwise) to pass considered opinion. However, given it is reported at after the initial free avatar, Kindroid requires a subscription (from USD $13.99) after the 3-day free trial and offers limited assurances on user data protection, then its hard not to raise an eyebrow. Anyway, the topic itself came up for discussion towards the end of the meeting. Please refer to the link to the announcement above and the the video below for more.

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