Category: TPVD / Open Source User Group

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

• Friday, September 27th, 2024 at the Hippotropolis Theatre.

† 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.

The following notes were taken from: My audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, August 1st, 2024. 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 2nd, 2024. My thanks to Pantera as always for providing it.

Table of Contents Meeting Purpose Official viewer Status Upcoming Releases CCUG – Graphics / glTF PBR Terrain Painting – Cosmic Linden Punctual Lights and Transmission / IOR – Geenz Linden General Discussion TPVD – WebRTC Voice Update In Brief (Both Meetings) Combat 2.0 2K Texture and PBR Materials Support and Bakes on Mesh Additional Items Next Meetings

Note that this is not intended as a full transcript of either meeting, but rather a summary of those topics discussed in terms of project LL have in progress feedback given to ideas / questions comments.

Meetings 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.
• 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.
• For both meetings: 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.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • WebRTC Voice RC, version 7.1.9.10084807842, July 26.
  • Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9981869229, July 22.
  • Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
  • Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.

Upcoming Releases

• The WebRTC RC viewer remains first in line for promotion to de facto release status.
• It will most likely be followed by the Atlasaurus RC, although this currently has a higher then expected crash rate at present.

CCUG – Graphics / glTF

PBR Terrain Painting – Cosmic Linden

Summary

• An in-development project. Current intent:
  • Provide a means to support the four PBR materials currently used in SL for “terrain painting”.
  • Will allow materials to be defined in their X,Y co-ordinates within a region by using a paint map, rather than having them defined by elevation defined in a height map. This will allow where grass or rock or stones or dirt, etc., appear within the region. providing much more flexibility in how terrain appears / changes.
  • Terrain painting will use the same permissions as terrain texturing (so if you have terraforming permissions, then tertian paining is possible; if you have the appropriate region permissions, you can define the PBR materials for the region.
• Other points of note:
  • LL prefer to limit terrain painting to the four available slots at region revel, rather than allowing fully customisable swatches / slots at parcel level, as the latter presents “non-trivial issues” for terrain texture handling /loading.
  • Terrain painting will require a new entity to be introduced. Exactly what form this will take is still being discussed internally; it is unlikely to be a new asset type.
• Much longer term options being considered for this capability might be to:
  • Allow prims to act as part of the terrain, inheriting the materials of the terrain, whilst still allowing the prim to be sized and shaped.
  • Perhaps allow the terrain within a region to be replaced by “something” else created externally to SL and then imported.
  • Neither of these ideas are currently being pursued beyond possible ideas / options.

Status

• Cosmic has been carrying out some early internal testing on how terrain painting looks using the paint map and how it works in practice in terms of bandwidth and performance.
• The initial results of these tests is described as “promising”.

Punctual Lights and Transmission / IOR – Geenz Linden

• Punctual lights:
  • This a glTF extension that has recently been folded into the main specification, defining the use of lighting sources (house light, table lamps, street lights, etc.), including the potential for shadow casting from such light sources.
  • Geenz is working to implement punctual lights, but they will be tied to the node hierarchy for glTF scene imports.
  • The first iteration of the work will not include shadow casting, and will focus on point and spot lighting as defined in the glTF specification.
• Transmission and Index of Reflection (IOR)  will provide:
  • Both refraction and “blurry” refraction suitable for things like frosted glass surfaces.
  • Dispersion, allowing chromatic aberration, allowing the RGB channels to “separate out” based on a certain factor.
  • Volume, allowing an object surface to be tinted at different surface thicknesses .
  • Geenz believes there is one significant bug left to resolve, relating to the scaling of the effect.

General Discussion

• A request has been made for a “glTF FAQ” to be put together, based on the Lua FAQ that has been made available, and which is seen as extremely useful.
  • The request was specifically made for a glTF Scene Import FAQ, as this capability has the potential to have the biggest impact on SL in terms of content creation, as glTF scenes have the potential to cover multiple areas (e.g. object import, sounds, animations, node hierarchies, lighting, etc.).
  • However, such a FAQ / series of FAQs could allow creators to more fully understand what is being proposed / has been considered / might be excluded, etc.,  thus offering them the opportunity to make more informed suggestions / requests to hep move glTF projects forward.
  • This was seen by LL as something which should “definitely” be on the road map, but may take time to surface as much of what might be covered is still only being discussed / prototyped internally to see what is feasible, and so subject to change.
  • In the interim a set of questions posted to the Content Creation discord channel was suggested as a means to get the ball rolling in providing ideas as to what a FAQ / FAQs might address.
• PBR individual material UUIDs accessible via llGetPrimitiveParams on non-full permission objects has been raised and is subject to being tracked and investigated.

TPVD – WebRTC Voice Update

Summary

• Replacing the use of Vivox for Voice in SL with WebRTC communications protocol (RTC=”real-time communication”).
• Benefits:
  • Move to a “defacto standard” for voice services, with features such as automatic echo cancellation, better noise cancellation and automatic gain control, etc., and offers much improved audio sampling rates for improved audio quality
  • WebRTC can be supplied within the viewer using a library and wrapper, ending the need for any additional third-party plug-in for Voice like SLvoice.exe, as supplied by Vivox.
  • Opens the door to adding new features and capabilities to SL Voice, some of which have been long-requested.
• Care is being taking to address potential security issues (e.g. preventing eavesdropping, exposing users’ IP address (by using an internal proxy server), etc.).
• Feature requests for WebRTC made via the WebRTC board on the SL Feedback Portal are being evaluated and some are being actioned, together with issues being investigated.
• LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers.

Status

• The plan remains to try to promote the WebRTC RC viewer to release status ASAP, with the aim of having as many TPVs adopt it as possible prior to the back-end switch being thrown to move all simulators to only using WebRTC.
• The work is at a point where there is just a “handful” of issues, with fixes most of them actually being tested by QA.  Some of these are transition issues related to moving between regions using Vivox and regions using WebRTC (or vice-versa).
• LL hope to release the back-end support for WebRTC peer-to-peer and Group calls, which should remove some of the limitations with testing WebRTC.
• Roxie Linden also noted some third party viewer users using Linux viewers have been having device/audio subsystem issues with WebRTC, and has offered to provide some assistance with these problems – with the caveat that she’ll need TPV developers to diagnose their issues and on the fixes.

In Brief (Both Meetings)

Combat 2.0

• The updates to the SL Combat system (SLCS), otherwise known as “Combat 2.0” are now in a deployment phase.
  • After to prior attempt, the updates are now deployed to the BlueSteel simulator RC channel.
  • Providing no further issues are found, the updates (as part of the Summer Fun simulator update) will be deployed to he remaining RC channels on Wednesday, August 7th; and then to the SLS Main channel on on Tuesday August 13th.
  • In the meantime, those involved in Combat in SL and who wish to have their regions able to leverage the new capabilities can file a support ticket to have their region moved to a channel supporting Combat 2.0.
• 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”.
  • In particular, this will see some of the LL combat regions (e.g. Concord and Lexington) a facelift and use them to showcase Combat 2.0, with participants in the Programme asked to donate free-to-use combat items for use in the regions.
  • In addition, 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.

2K Texture and PBR Materials Support and Bakes on Mesh

• This is now an active project. However (and as previously indicated in these summaries), the work is more than just updating the Bake Service.
• In particular, it will mean bringing the code for the appearance service back into the viewer codebase.  However, this will will yield two benefits:
  • It will make the code is easier to update in future.
  • Could potentially make it easier possible to add PBR materials support to Bakes on Mesh in the future (although some design work on what compositing PBR materials layers means).
• It was noted that the priority is to get “PBR BOM” in place prior to any release of glTF scene import.

Additional Items

• It has been reported that some auto-replies to Canny tickets do not always include any linked ticket.
  • For example: Beta grid: water “sandboxes” was raised in Canny, but closed as already tracked, but fails to publicly list the tracked issue – in this case Github archive issue #9258 (originally Jira BUG-231883).
  • It was broadly agreed that it would be useful for these replied to at least reference archived / accepted tickets from Jira – even if the tickets themselves cannot be views (e.g. as they relate to a security issue).
• Viewer release process:
  • Brad Linden has been working on the new viewer Gitflow process and release branches.
  • As previously noted, the focus is on moving away from having multiple release candidate cohorts based on different codebases in flight, as has been the case since around 2012, and instead focus on a core Develop branch of the viewer, from which RC versions can be built – so each RC viewer is essentially a “snapshot” of the Develop Branch code, rather than being an entirely separate viewer to anything else in flight.
  • It is hoped the formal switch-over to this approach will commence with the Atlasaurus RC.
• The Lab’s Linux viewer work currently resides within the Maintenance B RC viewer branch.
  • This is awaiting merging into the the main Development branch, and has encountered some issues with merging.
  • Once the merge has happened, and remaining issues dealt with, then packaging Linux builds for the viewer “could start happening some time after that” (so some time after the Atlasaurus viewer release).
• The TPVD meeting included a general discussion on the future of LODs (Level of Detail):
  • As a part of glTF adoption, Linden Lab is looking at adopting the Microsoft LOD extension for glTF 2.0, one outcome of which could be the removal of the RenderVolumeLODFactor (RVLF) setting from the viewer’s Debugs.
  • It was noted that as manually setting RVLF has long been the means by which creators can hide issues with LODs (i.e. raise LOD and force the viewer into rendering the higher LOD instances of an object), removing the debug is going to the lead to a lot of poorly-made content being exposed, potentially leading to a lot of upset.
  • However, it was also noted a more standardised approach to LOD instances of objects is required, and adoption of the Microsoft glTF  extension is the means to achieve this, allowing content creators to better leverage LOD generation within tools like Blender.

Next Meetings

• CCUG: 13:00 SLT, Thursday, August 15th, 2024, at the Hippotropolis Campsite.
• TPVD: 13;00 SLT, Friday, August 30th, 2024 at the Hippotropolis Theatre.

† 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.

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, July 5th, 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.
• For both meetings: 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.8.9375512768, formerly the Graphics Featurettes RC viewer dated June 5 and promoted June 10th.
• Release channel cohorts:
  • WebRTC Voice RC, version 7.1.9.9688089989, July 1.
  • Atlasaurus RC (object take options; improved MOAP URL handling), version 7.1.9.9620320242, June 27.
  • Maintenance B RC (usability updates / imposter changes) 7.1.9.9555137545, June 21.
  • Maintenance C RC (reset skeleton in all viewers), version 7.1.9.9469671545, June 14.
• Project viewers:
  • None.

General Viewer Notes (Both Meetings)

• The switch to working from multiple viewer RC branches to a single development branch is continuing.
  • This will mean in future there are likely to be fewer RCs in the pipeline than has bee the case for roughly the last decade (and sees the visible aspect of viewer development and release process swing back towards how it appeared prior to the switch to using RC channels).
  • Parallel tracking of viewer development will continue for a while, given the fact there are currently four RC viewers in flight.
• The above change-over will not prevent contributions being accepted.

WebRTC

[Video; 5:00-7:28]

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.
• In addition:
  • LL are are of some of the security concerns around WebRTC voice (e.g. risk of eavesdropping, exposure of users’ IP addresses, etc), and is actively working to block these through the use of an internal proxy service.
  • LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers
• Feature requests for WebRTC should be made via the WebRTC board on the SL Feedback Portal.

Status

• Work has been on stabilising WebRTC and getting the viewer to RC status so that TPVs can look at it.
• Overall, development work is in a “wrapping-up” phase.
• Currently, LL is looking at August for a potential deployment across all of SL on the server-side.
  • This will follow the usual approach of roll-out to the simulator RC channels first, then to the SLS Main channel.
  • As a result, there will be some short-term issues around peer-to-peer, Group and ad-hoc voice connections between those on regions running the two different voice services (Vivox and WebRTC).
  • Depending on how the deployment goes (e.g. first to a single RC, then multiple RCs, then the SLS Main channel), it is hoped that any such issues will only be for around 2 weeks.
• Viewers adopting the WebRTC code prior to or during this deployment period will be able to process both WebRTC and Vivox voice.

glTF Update

[Video: 7:42-13:23]

• As a result of the Firestorm PBR release, Runitai Linden has been revisiting the issue of memory use in the PBR-enabled viewer code on lower-specification computers.
• Geenz Linden is continuing to work on various glTF extensions, including glTF index of refraction (IOR) and transmission – with the work on the latter potentially being wrapped up.
• Cosmic Linden has been tweaking the PBR terrain work for PBR transforms on terrain (one transform per material).
• [Video 39:44-41:14] requests have been made for reflection probes in shapes other than cubes and spheres (e.g. cylinders, triangles, hemispheres) to account for more awkward interior space shapes (e.g. in roof areas). This is viewed as “highly unlikely” at the Lab.
  • However, the mirror capability may be extended to include sphere reflection probes at some point “if all goes well”.

PBR Terrain Painting

• This is the next planned project for Cosmic Linden, and is in the very early stages of planning, so things are subject to potential change.
• Currently, the thinking is:
  • The four PBR materials currently used for PBR terrain would remain available for use / painting.
  • The painting element would allow a user to define how these materials are mixed, rather than having to rely purely on the the height map.
    • E.g. if you have a paint map for a region, you’ll be able to blend the materials based on that, rather than having to use the height map, and define where areas of grass or rock or dirt, etc., appears on the ground.
  • The paint map is likely to initially be on the basis of one blended texture at region level (not parcel), although the resolution of the texture is still TBA at the time of writing.
  • The permissions for terrain painting will be based on ability to edit the height map (if you can alter the latter through the Region settings, then you’ll be able to use the terrain painting capability).
• Terrain painting will be a significant departure in how terrain texturing has been managed, requiring a new entity to be introduced. This is also still being thought through, but it is unlikely it will be a new asset type stored on the asset servers.
• [Video: 16:15-16:29] No decision has been made on making terrain painting open to scripted control.
  • Cosmic is open to feedback on how this might be used, if enabled (e.g. a scripted explosion leaving a detonation mark on the ground for a period of time).

In Brief

• Reflections turn black when zooming in close is an issue which appears to be related to the use of mirror probes as well as “normal” reflection probes. If you are impacted by this, add your vote.
• Auto-exposure under PBR (adjusting the general scene brightness when looking at one or more very bright objects in the scene), with people interpreting it as a bug, particularly with the release of Firestorm PBR.
  • It’s been suggested that a wiki page on how auto-exposure  works should be produced, to which people can be pointed to help them understand what it is and how it works. Or potentially a debug setting or similar to disable (with a warning things may not display correctly as a result).
  • Canny feedback has been requested on issues being encountered / suggestions for related features (such as the setting noted above).
  • This led to an extending general discussion on lighting and rendering – please refer to the video.
• RLV/RLVa adoption by the Lab is still in discussion and described as something the Lab wants to do, but it does represent an extensive change to their viewer.
  • As such, it is likely that as contributions are made, they will be pulled into the official viewer incrementally (presumably with some going behind debug flags until such time as they can be properly enabled).
  • Overall, it now appears the Lab does want to support the full RLV/RLVa feature set, rather than just a sub-set thereof as had been previously indicated as a possible route.
• Opening the PBR terrain painting to scripted control led to a conversation on scripted weather systems – such as being able to change the ground appearance to match the season; having the ground appear to be covered by snow when it snows, etc. There have been requests for this, but it is not something the Lab is currently working on.

 

Next Meeting

• Friday, August 2nd, 2024 at the Hippotropolis Theatre.

† 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.

The following notes were taken from the video recording of the Third-Party Viewer Developer (TPVD) meeting held on Friday, May 10th, 2024. My thanks as always to Pantera for recording the TPVD meeting and providing the video, which is embedded at the end of this article.

• 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.
• In regards to meetings:
  • Dates and times are recorded in the SL Public Calendar.
  • Commence at 13:00 SLT on their respective dates.
  • Are conducted in a mix of Voice and text chat.
  • Are open to all with an interest in either content creation or viewer development.
• The notes herein are a summary of topics discussed and are not intended to be a full transcript of either meeting.

Official Viewers Status

[Video: 01:24-2:28]

• The Maintenance X RC (usability improvements) updated to version 7.1.7.8974243247, May 8.
• The WebRTC Voice work was released as a project viewer, version 7.1.4.8947030231, May 8.
• The Puppetry project viewer has been withdrawn.

The rest of the current crop of official viewers stands as:

• Release viewer: 7.1.6.8745209917, formerly the Maintenance Y/Z RC ( My Outfits folder improvements; ability to remove entries from landmark history), dated April 19 and promoted April 23 – No Change
• Release channel cohorts:
  • Maintenance C RC (reset skeleton in all viewers), version 7.1.7.8820704257, May 6.
  • Materials Featurettes RC viewer, version 7.1.7.8883017948, May 2.
  • Maintenance B RC (usability updates / imposter changes), version 7.1.7.8820696922, April 29.

General Viewer Notes

• Maintenance X looks to be the next viewer in line for promotion – most likely in week #20.
• Following the promotion of Maintenance X, the focus will be on getting the Materials  Featurettes viewer promoted, as the simulator-side support for this is already available across the Main grid ( although see below).

Viewer Code White Space

[Video: 24:58-29:00]

• White spacing in viewer code has long been an issue in that it can be a mix of both tabs and spaces.
• A move to standardise on either tabs or spaces has been mooted but never formalised because of the concerns that any bulk change would produce conflicts in things like code merges.
• Signal Linden has been investigating this, and found that providing an appropriate command line option is given, such conflicts between white space using tabs and white space using spaces can be avoided.
• As a result, the current Maintenance X viewer does standardise white space.
• To avoid potential conflicts when merging to this code base after Maintenance X goes to de facto release status, Signal has produced documentation on how to make such a merge.
• Those involved in viewer development (TPVs and self-compilers) are encouraged to read this documentation prior to merging with Maintenance X.

Graphics / Materials Featurette Update

[Video: 2:36-6:12]

• The is the viewer with the new PBR terrain code, support for 2K texture uploads, and PBR mirrors.
• The Graphics team believes all issues considered to be showstoppers for this viewer have now been fixed, and the viewer is going through what is hoped will be a final QA pass.
  • However, there is one remaining issue which can crash the viewer, but this might be down to running the viewer on unsupported hardware as much as requiring a fix.
• Remaining issues / updates will be handled through the main glTF development branch of the viewer.
  • As the server team has switched to the Git Flow  Git branching strategy, and there are conversations about moving to this for the viewer as well.
  • As such, the glTF development branch is a step towards the use of Git Flow.
  • If the approach works for the glTF work, it will likely be adopted for all viewer development work.
• There was a brief debate as to whether the Featurettes viewer will be available for promotion sooner rather than later, with Dan Linden indicating that there is still “quite a bit of testing” still to be done.

glTF Scene Import

[Video: 40:40-48:15]

• More generally covered in my CCUG meeting summaries.
• This is a glTF project to allow glTF scenes (objects, materials, animations, etc) can be imported to SL as assets and brought in-world as a series of nodes rooted in a prim, with the nodes updated with both tools in the viewer and / or using LSL, and ensuring they stay in synch with all viewers looking at them.
• Overall, the idea is a “one touch” import to get a scene from Blender to SL, where it should appear exactly as it is in Blender, modify it as required in SL via the build tools  / LSL or – subject to permissions – export it back to Blender for update.
• Currently at the prototyping stage, with test viewers and test regions on Aditi able to preview a scene (that is, see it within the viewer without the scene being physically imported into SL) for reference purposes, .
• Work is “almost” at a point where a scene can actually be uploaded to SL and stored as an inventory asset and then downloaded and rendered by the viewer – although more back-end work (such as with the CDN pipes) needs to be carried out.
• There are multiple questions still to be addressed concerning the overall data model (LOD generation, LI, linking etc., scene export (for updating) and working with the SL permission system, physics / collision shapes, etc.), so definitive answers to question on these topics cannot be properly addressed at present.
• A video demonstrating how this works can be seen at 44:43.
• This moved into a general discussion on the glTF work – please refer to the video below and my CCUG updates, as linked to above.

WebRTC Voice Update

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.
• WebRTC is something of a “defacto standard”, being built-in to most web browsers and supporting  wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications.
• In terms of audio / voice (the primary focus here), WebRTC has a number of standard features expected of audio communications services (such as automatic echo cancellation, better noise cancellation and automatic gain control, etc.) and offers much improved audio sampling rates for improved audio quality.
• WebRTC will be supplied within the viewer using a library and wrapper. This will mean no requirement to run a third-party voice plugin (SLvoice.exe, as supplied by Vivox) going forward.
  • Care is being taking to address potential security issues (e.g. preventing eavesdropping, exposing users’ IP address (by using an internal proxy server), etc.).
• The switch to WebRTC also opens the door to adding new features and capabilities to SL Voice, some of which have been long-requested.
• Feature requests for WebRTC made via the WebRTC board on the SL Feedback Portal are being evaluated and some are being actioned, together with issues being investigated.
• LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers.

[Video: 6:29-17:35]

Status

• As noted above, a WebRTC project viewer is now available via the Alternate Viewers page.
• Viewer work is currently focused on bug fixing, and the hope is the viewer will move from project status to RC status “pretty shortly”.
• The overall hope is that as WebRTC is a library + wrapper, changes will be fairly localised within the viewer, speeding the implementation process.
• The schedule for WebRTC is described as “pretty aggressive” and TPV developers are encouraged to look at the code repository.
• Work is in progress / has been completed on getting a simulator Snack RC channel set-up with the required back-end support for WebRTC voice – but this will be spatial voice only, not peer-to-peer / Group or ad-hoc Voice communications for the time being.
  • Region names for this channel were not given at the meeting.
  • In line with the aggressive viewer development cycle, the team is looking to have WebRTC support available across at least one full RC channel by the end of June (simulator update schedules permitting) and potentially have the back-end support live across the Main grid by the end of July 2024.
  • Those wishing to test peer-to-peer, Group and ad-hoc Voice via WebRTC can do so via the Aditi (Beta grid) webRTC1 test region.
• There will be further updates to the WebRTC library during the development cycle, as the Lab updates to the latest releases from the WebRTC open-source development website.
• As the work progresses, there will be a blog post to provide and overall update on the work, including the proposes schedule for deployment and explanations of any caveats / potential roughness during the transition (see below as well).

WebRTC and Vivox Voice Support

• The initial versions of the viewer (project and RC) will support both WebRTC and Vivox for Voice.
• As peer-to-peer / Group or ad-hoc Voice support for WebRTC is added to the back-end, things might “get a little weird” as the viewer swaps between WebRTC and Vivox, but Roxie Linden is trying to ensure things are correctly negotiated (e.g. if there is a Group chat going on with everyone using WebRTC, and someone joins from a region still using the Vivox back-end, the viewer will negotiate everyone to using Vivox.
  • This means that for purely testing WebRTC for Group, peer-to-peer and ad-hoc Voice (as support for these are added to the simulator code), it is important for all testers to be on regions with WebRTC support only.
• Voice will not travel across region boundaries between regions using WebRTC and Vivox (and vice-versa)
  • This should not be an immediate issue, but might become noticeable during the transitional period when WebRTC support is being deployed across the main simulator RC channels and before it is grid-wide.
  • Voice will obviously work across regions using the same voice service (e.g. between regions which are both running WebRTC).
• Given the aggressive schedule for the work, it is hoped that support for both WebRTC and Vivox within the viewer will be for a limited duration.

SL21B – glTF and Blinn-Phong

[Video: 18:19-24:38]

• To ease the workload for creators building for SL21B (opening on Friday, June 21st, 2024), Linden Lab has stipulated they do not have to include Blinn-Phong (aka “SL legacy materials”) fallbacks in their build if they opt to use glTF PBR materials.
• This means viewers, in keeping with the expected behaviour, should only display the glTF materials, and should not under any circumstance attempt to display any fallback (as doing so will result in content rendering as grey or white objects).
• This is likely to impact any viewers that do not support PBR materials (and content will not look “right”).
• However, the above should not be taken to mean that LL are looking to “get rid of” Blinn-Phong (e.g. objects have been created using Blinn-Phong only, they will continue to display using Blinn-Phong reflections, etc.).
• Runitai Linden also noted:

Sometime between now and then, we’ll likely start making the LSL scripts that modify Blinn-Phong parameters modify their PBR equivalents, or do nothing when a PBR material is applied. So llSetColor, for example, would set the base colour, not the diffuse colour. That should make life a lot simpler for scripters going forward, as scripters have been giving us feedback that trying to do something simple like that with existing scripts is impossible as they have to do a check to see if a glTF material is applied, and if there is then use llSetPrimParams and if there isn’t, use llSetColor.

• It was unclear if this will require a conversion to linear colour (as glTF uses SRGB), given the LSL for GLTF_BASE_COLOR requests linear colour – or whether there is a conversion from linear colour to SRGB when using GLTF_BASE_COLOR. This is to be looked into.

In Brief

• [Video: 30:10-37:47] 2K textures:
  • There have been concerns raised over “abuse” of 2K textures (e.g. people being “forced” to use them because “everyone else is”).
  • Runitai Linden is of the opinion that with functional texture streaming, use of 2K textures is not as big a problem as is being presented in some cases, because the full 2K texture is not necessarily downloaded rendered by the viewer until the viewer zooms right in on the object face using it; otherwise the texture should be displayed at the pixel resolution (e.g. if the face is only taking up 64×64 pixels, then the 64×64 version of the texture is selected and used.
• Bakes on Mesh support for 2K textures: this is currently not a project under consideration, but the Lab acknowledged that this might need to be re-thought in terms of what is required and scheduling priority.
  • It was noted that updating the Bake Service would not be sufficient for 2K texture use, as the service also composites wearable textures, so the allowed texture resolution for all wearable layers will have to be updated in order for BoM to effectively support 2K textures.
  • That said, updating BoM to support 2K textures is seen by the Lab as a matter of “when” and not “if”. In this, it was further noted that support for the work being shown through the Feedback Portal from users will help LL determine / re-evaluate the priority of the work compared to other projects.

Next Meeting

• 13:00 SLT, Friday June 7th, 2024, at the Hippotropolis Theatre.

† 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.

The following notes were taken from my audio recording and chat log transcript of the Third-Party Viewer Developer (TPVD) meeting held on Friday, April 12th, 2024. My thanks as always to Pantera for recording the TPVD meeting and providing the video, which is embedded at the end of this article.

• 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  the third or fourth Friday, at 13:00 SLT at the Hippotropolis Theatre.
• In regards to meetings:
  • Dates and times are recorded in the SL Public Calendar.
  • Commence at 13:00 SLT on their respective dates.
  • Are conducted in a mix of Voice and text chat.
  • Are open to all with an interest in either content creation or viewer development.

• The notes herein are a summary of topics discussed and are not intended to be a full transcript of either meeting.

Official Viewers Status

[Video: 00:29-1:19]

• Release viewer: version7.1.5.8443591509, formerly the Maintenance-W RC (bug and crash fixes), version and issued March 29th, promoted April 9th.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Maintenance YZ RC ( My Outfits folder improvements; ability to remove entries from landmark history, version 7.1.6.8632452945, April 12.
  • Materials Featurettes RC viewer, version 7.1.5.8472515256, April 3.
  • Maintenance X RC (usability improvements), version 7.1.5.8443777128, April 2.
• Project viewers:
  • Puppetry project viewer, version 6.6.12.579958, May 11.

General Viewer Notes

• Maintenance X looks to be the next viewer in line for promotion.
• The Graphics Featurettes viewer (PBR terrain and mirrors) is expected “soon”.
• LUAU integration (client-side scripting API): still in the early stages, and not a lot available for testing via a test viewer or similar.

Graphics Update

[Video: 4:25-6:17]

• A new glTF mesh importer has been made available via the content Creation Discord channel (which LL have requested I do not link to here – contact Vir Linden if you have a need to be on that channel) purely for the purposes of testing by content creators.
  • This allows for the importing and viewing of static glTF-compliant mesh models and seeing how the look in Second Life.
  • This is the first element within the “glTF Phase II” project.
• Cosmic Linden is working on bug fixes for the PBR terrain support, and Geenz Linden is putting the finishing touches to mirrors, both in the expectation of a public-facing viewer being made available.
• 2K textures is still subject to discussions on pricing, and may or may not surface in the Featurettes viewer’s initial release.
• Simulator support for the upcoming Graphics featurettes is due to go the the Preflight channel in week #16. This will include 2K texture support, which will most likely be disabled pending a final decision on pricing, etc.

WebRTC Voice Update

[Video: 29:17-33:19]

• See here for background.
• A Project viewer is being put together, and this should be available viewer soon, and the code should be fairly stable.
• Some testing has been carried out with WebRTC on Linux with good results.
• Feature requests for WebRTC made via the WebRTC board on the SL Feedback Portal are being evaluated and some are being actioned, together with issues being investigated.
• The test region webRTC1 (Aditi) now has an echo capability for testing WebRTC once the Project viewer is available (or for those on a test viewer).
• There may well be a pile-on test at the WebRTC test regions as things progress to test the new voice capability – although this might be better suited to having a test region available on Agni.

In Brief

• There have been requests to have meeting times across several of the User Group meetings altered to be more accessible to Europeans or for those elsewhere in the US, etc. These requests are under consideration within the various user groups where they have been raised.
  • It was also noted that it would be useful if the Agenda sections of the wiki pages for User Groups were actually maintained, so that people can at least see what is up for discussion from LL’s side ahead of meetings, to help in making informed opinions on whether or not to attend.
• [Video: 18:48-23:22] Featurettes flags:
  • It was noted that the plan for viewer projects going forward is to utilise the idea of featurette flags (as with the Graphics Featurette viewer) and have capabilities / functions new to the viewer placed behind flags (debug settings) managed via the simulator.
  • This is a reversal of the “old” mechanism for viewer features, which was led by the view making specific UDP message requests to the simulator for specific feature capabilities / function, and the simulator then respond on a request-by-request basis.
  • The advantage of this is that it potentially allows for faster viewer development iteration: features can be added to project / RC viewers and placed behind flags potentially allowing for testing on Aditi, rather than having to wait for months (/years) for a project-related viewer to surface with everything in pace and then only get actual user testing.
  • The disadvantage is communicating what in the viewer code might be tested and what is awaiting the setting of a flag from the simulator.
  • As such, LL are aware of the need for clear communications with TPVs on projects, code, and flags.
• A general discussion on UDP message formats.

Next Meeting

• 13:00 SLT, Friday May 10th, 2024, at the Hippotropolis Theatre.

† 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.