Tag: TPVD meetings 2024

2024 week #51: SL CCUG & TPV meeting summaries

Posted on by Inara Pey
Ashemi, October 2024 – blog post †
The following notes were taken from:

  • My chat log of the Content Creation User Group (CCUG) meeting of Thursday, December 19th, 2024.
  • My chat log  of the Third Party Viewer Developer’s Meeting (TPVD) of Friday, December 20th, 2024.

Please note that this is not a full transcript, but a summary of key topics. .
Table of Contents

Meeting Purpose

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with related viewer development work. This meeting is 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.
  • Dates and times of both meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.

Official Viewer Status

    • Release viewer: version 7.1.11.12363455226, formerly the ExtraFPS RC (multiple performance fixes, aesthetic improvements and UI optimisations), dated December 17, promoted December 20 – NEW.
    • Release Candidate: none at present.

ExtraFPS Notes and Rendering – Both Meetings

ExtraFPS Notes

  • The majority of legacy (non-PBR) skies should now look “extremely close” (if not “spot on”) to how they looked prior to the initial PBR release:
    • This is in part due to the default for the RenderSkyAutoAdjustLegacy debug setting being changed to False, which means that legacy skies should render close to the “pre-PBR” look, whilst leaving PBR skies unchanged.
      • This change in the default (from True to False) has caused some confusion among those using the Firestorm ExtraFPS beta versions, as they have been mistakenly switching the default back to True. This should not be done.
    • Tone Mapping is no longer applied the legacy skies, which should help eliminate legacy environments looking too bright / dark.
    • There is a chance that some legacy skies may have been missed, so the request is for those on non-PBR viewer to give ExtraFPS a try and check their preferred legacy skies, just in case. Issues should be reported via the feedback portal – including any noted issue with transitions when moving between different EEP settings.
  • Ambient lighting should be generally improved and “much more consistent” with pre-PBR viewers.
  • Exposure has been reset to 1.0.
  • As a part of the performance options for lower-specification machines, there is now an options to disable HDR rendering and emissives (single check box).
    • This should be automatically unchecked for those running on very low-spec systems (e.g. those running with Intel HD graphics), but those on lower-spec machines might want to check.
  • It terms of overall performance on older hardware types, LL believe theta in the “vast majority” of cases, ExtraFPS runs on a par with FPS rates seen on pre-PBR viewers.
  • Absent from ExtraFPS is the updated alpha/linear/exponential (aka alpha/gamma) settings. This is awaiting decisions around matter of permissions to allow people to apply the changes to legacy content they might own but for which they may not have the required permissions. The hope is to have this in an future viewer as an update.

General Rendering Comments and Feedback

  • The PBR deployment has made LL particularly aware that significant changes which may impact viewer performance need to be monitored far more on a case-by-case basis in terms of older hardware types (graphics cards / types, etc.), rather than looking at across-the-board averages.
    • As has been previously mentioned in CCUG meetings (and elsewhere), this has led to the graphics and viewer teams spending time pulling together older hardware and cards to build what has been unofficially dubbed the Potato Farm, so that changes can be tested against specific older hardware known to be popular among SL users.
  • The Graphics Team acknowledge Linden Water still “doesn’t look anywhere near as good as it should”, and is part of a series of legacy consistency issues they are still addressing.
    • In particular, Geenz Linden noted that Screen Space Reflection (SSR) is “in need of improvement”, but LL just have not had the cycles available to work on it. He has ideas on how things can be improved without having to uproot everything, and hopes that there may be an opportunity to work on them in 2025.
    • One suggestion was to place a glTF transmission texture on Linden Water to help resolve problems. However, this doesn’t appear to be an option due to Linden Water rendering being “kind of incompatible” with the glTF materials specification.
    • Bringing back water reflections to a point where they matched pre-PBR water reflections is seen is expensive in terms of performance, ergo while improvements will be made, they are unlikely to offer the same level of real-time reflections as seen “pre-PBR”.
  • Firestorm ExtraFPS Beta: Firestorm have been iterating on a beta version of their viewer incorporating the ExtraFPS updates. However:
    • Geenz Linden noted that there are some “broken things” in the Firestorm ExtraFPS beta which are leading to some “very noticeable differences” between it and the official ExtraFPS. He is currently working with the Firestorm team to try to correct these issues.
    • The environment doesn’t always change over to the local shared environment on a region crossing (physical or teleport), together with ambient reflection probes getting discarded and rebuilt as a Day Cycle advances to the next preset (keyframe). This is not something the Lab’s graphic’s tam have noted on their viewer; if it can be reproduced on the official ExtraFPS release, bug reports would be appreciated.
  • It has been noted that cube reflection probes do not affect water (although spherical probes do appear to affect water). It’s not clear if this is an unintended breakage as a result of various testing (e.g. with water reflections) or intended (as those in a position to address this question are out of the office on holiday breaks).
  • Tone Mapping:
    • Tone mapping is a highly subjective area – what looks good to one person might not appeal to another.
    • Because of this, and without changing defaults beyond what have been set within the ExtraFPS viewer – the Lab is seeking to provide choice by making options available (e.g. the Khronos Neutral Tone Mapper as well as ACES), and through options to adjust tone mapping (which will eventually be including in the Sky Settings floater), enabling people to make choices for themselves.
  • To assist with manging environment-related settings, Geenz Linden hopes to move things to enable asset versioning for sky / water assets, thus allowing for easier maintaining of legacy code paths when required, which in turn should help with avoiding some of the issues seen with the likes of sky settings in the move to PBR / glTF.
  • Requests:
    • Allow arbitrary meshes to be used as reflection probes. Whilst this could help with fitting probes into difficult spaces (e.g. within cave tunnels), arbitrary mesh shapes as probes are not seen as particularly performant, particularly WRT lower specification systems.
    • Allow blending on reflection probes so that neighbouring / overlapping probes offer smoother transitioning (such as at the entrance to a cave or tunnel or an entrance into a darker interior. In theory this could be done.
    • Provide a new means to “hide” Linden Water from the interior of boats, etc., in a manner similar to using invisiprims under the (now defunct) Forward Renderer. Unfortunately there is no easy means of providing occlusion volumes for Linden Water to replace invisiprims in this use.
  • A lot of questions on PBR Materials which really boiled down to the need for more informative documentation / FAQs / tutorials.

TPVD Meeting

The Lab Using TPVs

  • A long standing policy at the Lab is that staff and contractors have been required to only use the official viewer, and that bugs reported to the Lab need to be reported using the official viewer.
  • In recognition of the widespread use of TPVs – notably, but not exclusively, Firestorm – this policy is now changing.
  • The Lab has already taken steps to implement the ability to build Firestorm internally and with the necessary security options in place to make it “safe” for use by Linden personnel and contractors.
We’re all using Firestorm more … so we can be helpful if need be on integration work and stuff like that with Firestorm. There were security changes in general to allow Lindens to log-in to any third-party viewer, but we’re definitely changing to respect that Firestorm in particular comprises almost all active use of Second Life today and we’ve got to do everything we can to make sure it’s working first, even before our own viewer.

– Philip Rosedale, TPVD Meeting, Friday December 20th, 2024

  • This does not mean that the Lab is adopting Firestorm or taking any form of control over it (or any other TPV); the Firestorm team remains in control of their viewer,  and the roadmap and plans for it. Rather, the aim is to provide assistance for Firestorm and other TPVS where it is needed.
  • Right now for Firestorm, this assistance – as noted above – is focused on evaluating the ExtraFPS code and performance updates for inclusion in Firestorm as quickly as possible.

The Viewer Structure and Open-Source Development

  • The above led to Philip expanding on some of the issues which have arisen due to the way in which the viewer was coded and opened out as a open-source project.
Looking all the way back to 2005, which is when I think we open-sourced the viewer, we didn’t have the team then – nor do we have it now – to properly separate the viewer into into a bunch of modular components that could connect to each other and have plug-ins attached to them in a way that Chrome does. I think that coming back now and being the CTO and looking at what’s going on, one of the elephants in the room is that the structure of the code doesn’t support extensions and plug-ins in the way that would make sense for a properly-run open-source project. I say that without a specific solution in mind, I’m just recognising it. 

– Philip Rosedale, TPVD Meeting, Friday December 20th, 2024

  • Because of the approach taken, the viewer code has become “a plate of spaghetti”, with third-parties developers able to open the code up and make changes then deem necessary at any point in the code.
  • This has been further exacerbated by the lack of overall documentation for the viewer that might be constructively used by developers internally and externally to the to the Lab to understand the viewer code – a point that is again acknowledged.
  • Ideas for trying to make the viewer code more modular are being looked at, but no decisions  – much less a roadmap – for starting to do so have yet been reached.
    • As both Philip Rosedale and Vir Linden noted, the fact that there has been 15-20 years of open-source viewer development, with TPVs (and the Lab) picking their own paths does make doing so “tricky”.
    • One possible avenue being considered here is trying to separate the viewer UI more from the underlying rendering engine, potentially making updates to either less intrusive either way.
  • An additional goal of the work currently being carried out to support Firestorm with ExtraFPS is to try to ensure the code in question can be more easily pulled-in by other TPVs as well.

General Discussion Points

  • Web development:
    • The Marketplace is written on Ruby on Rails, communicating with a SQL running on Redis, an infrastructure which is making it hard to chase down query optimisation problems.
    • As a result, there is a likelihood that some engineering support is going to be pivoted towards SL’s web properties and infrastructure, which may result in work in the viewer / server areas slowing down.
  • Open positions at LL:
    • Time was taken in discussing current (at the time of the meeting) open positions at LL – server developer, Mobile developer and senior product manager.
    • This touched on some of the upcoming features coming to Mobile – such as the Lobby capability due to surface in SL Mobile during Q1 2025 (see: Second Life Blogger Town Hall, December 2024: Mobile, marketing and more).
    • Specifically, there was a request for any Second Life developers / users who have the requisite skills for the posts and who might be looking for a career change (or who know someone who does / is) to considering applying / pointing people to the Lab’s careers page.
    • In addition, Philip noted, in line with the above web development, the Lab is seeking expertise in Ruby on Rails development (preferably with SQL experience as well) – although this is not currently advertised on the LL careers page. Anyone who has / knows of such experience can contact him – preferably via e-mail.

Next Meetings

 

† 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 week #47: SL CCUG & TPV meeting summaries

Posted on by Inara Pey
Silent Melody, September 2024 – blog post †
The following notes were taken from:

  • My chat log & the live stream video (embedded below) of the Content Creation User Group (CCUG) meeting of Thursday, November 21st, 2024.
  • My chat log and Pantera’s video (embedded towards the end of this article) of the Third Party Viewer Developer’s Meeting (TPVD) of Friday, November 22nd, 2024.
Table of Contents

Please note that:

  • This is not a full transcript, but a summary of key topics.
  • “[Video]” time stamps refers to the CCUG meeting livestream recording;  “[Pantera]” refers to the TPVD meeting video provided by Pantera.

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.
  • 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 of both meetings are recorded in the SL Public Calendar, and they are conducted in a mix of Voice and text chat.

Official Viewer Status

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11750364439, November 12.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations.

Mobile Notes – CCUG Meeting

[Video: 45:24-47:42]

  • Adding PBR support to SL Mobile is on the roadmap, with ah hoped-for target of some time in Q1 2025 (Jan-March).
  • SL Mobile voice support is experimental, and utilises WebRTC.

CCUG Meeting

Graphics Team Work – General Recap

[Video 0:28-5:31 and 25:04-32:33]

  • Core focus remains on performance work and will remain so until “everyone is happily on PBR-enabled viewers.”
  • Hope is still to have ExtraFPS promoted to release status by the end of 2024.
    • This viewer should see some “significant [performance] improvement” on certain types of hardware – e.g. the Intel HD4000 series (launched May 2012), which is “remarkably popular” among SL users.
    • This work is focused on developing a “classic” mode (also known as a “potato mode” which will see various rendering options disabled (e.g. HDR, Tone Mapping, Reflection Probes, the Emissive channel) to render SL more in keeping with its pre-PBR appearance when running with ALM enabled (aka Deferred Rendering).
    • To achieve this and ensure decent frame rates, comparative benchmarking is being carried out:
      • If an older GPU runs a non-PBR viewer at a higher FPS with ALM enabled than with it disabled – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer. Or;
      • If an older GPU runs a non-PBR viewer at a higher FPS with ALM disabled (thus using the old Forward Renderer)  – – then the aim is to try to match or better that FPS when the same hardware is running a PBR viewer, but with ALM-like graphics fidelity.
    • A major element of this work is to get older harder performance back up without creating a rendering schism through the re-introduction of something like Froward Rendering.
  • This work is being carried out alongside “various end of year this and kick-off the next year things.”
[We’re] doing our level best to ensure everybody who can use Second Life on Firestorm 6.6.17 can upgrade to some version of 7.x [PBR] without suffering negative consequences. That’s what we’re doing; we’re chasing all the crashes that we can and all the performance issues that we can. 

– Runitai Linden.

  • [Video 33:28-35:10] A reiteration that a lot of the issues impacted older / lower spec systems are not PBR-related per se (they just happen to have been surfaced within PBR-enabled viewers). Rather, they are the result of things like running out of VRAM due to the updates made to the texture streaming system.
    • Where issues have been due to PBR (e.g. exceptionally heavy PBR in-world builds) there are additional optimisations that are being done.
    • A point to remember here is that PBR is a part of the glTF 2.0+ specification which LL are adopting – and glTF is designed to support a very wide range of hardware, including mobile ‘phone upwards, and so is not itself particularly resource-intensive.
  • Until now, issues with the quality of water reflections on PBR viewers has not been seen as a priority to fix, as it is not performance related and has thus been “taking a back seat” in the queue of fixes. However, if it is seen as a significant issue that prevents users from moving to a PBR viewer, this might be reviewed.

Texture Blurring and downscaling

[Video: 6:54-14:25]

  • In response to comments about texture blurring, Runitai Linden noted that the viewer will start down-scaling textures as it detects a system is running low on available VRAM.
  • This can result in some scene textures close to the camera remaining blurred until focused / zoomed-in upon.
  • Runitai believes there is more work that could be done as to how the fall-off curve for this works to reduce the need to zoom “right in” on textures doing this in order for them to render properly.
  • He further noted that the old behaviour of just using mouseover on a texture to get it to load is no longer applicable, as that actually caused most of the textures in a scene to load at full resolution, causing a performance hit.
  • In addition, there are still some bugs which can result in the viewer getting the wrong answer as to how much VRAM is available on a system (and start downscaling textures when it may not need to). To check if this might be the case:
    • Open the viewer’s texture console (Develop(er) → Consoles →  Texture Console / CTRL-SHIFT-3).
    • Check Est. Free (top line of the Console display) and compare the number with something like GPU-Z or Task Manager (via GPU option).
    • If the two are very different, then there is likely a bug. Please file a bug report with hardware details (Help → About → Copy to Clipboard and paste info into report).
    • Note that on integrated graphics system, the amount of VRAM usually gets reported as the amount of system RAM, and this is referenced by the Sys Free number in the viewer’s Texture Console. Sys Free also reports based on the fact that the viewer tries to minimise its total memory footprint to under 16 Gb.
  • There is no set “minimum” or “maximum for VRAM with SL; LL are committed to enabling SL to run on GPUs with as little as 2 Gb of VRAM, and it is felt that systems with a minimum of 4 Gb and a Draw Distance of 128 metres should be able to manage most scenes – but this is a very broad rule of thumb; the viewer will continue to use VRAM until it runs out, if necessary – there is no upper limit, although some TPVs do allow caps to be set.
  • When downscaling occurs, it should be a) because VRAM has been used; b) commence with textures in the background / off-camera before moving to those in-view.
  • Note that textures will also be off-loaded from VRAM when SL is minimised  / put in the background, to allow other applications access to VRAM. This can also cause blurring as textures are reloaded when SL is brought back to the foreground and resumes using all available VRAM as best it can.

In Brief

  • [Video: 18:32-21:02] WebRTC: LL are still awaiting more users to move to viewers with WebRTC support prior to disabling Vivox.
  • [Video: 23:31-24:40] Older EEP (e.g. Windlight, they’re that old – such as CalWL) settings can look blown-out on PBR views.
    • LL have been attempted to auto-adjust them, but this has proven subjective in terms of results.
    • Therefore, going forward, work will be limited to trying to make them look like they used to, which is acknowledged as not being great for PBR content, but is the “least bad” in terms of keeping EEP settings people like looking the way people like to see them.
    • Hopefully, this work will be finished in time to be included in ExtraFPS; however, if it misses ExtraFPS, it may be issued as a viewer hotfix.
  • [Video: 39:15-40:10] A note of two long-term risks, graphically speaking, that have to be addressed within SL at some point:
    • COLLADA support: support for COLLADA is waning world-side, and so SL needs an interchange file format that is not dependent on COLLADA. Again, glTF is seen as the best solution here.
    • Similarly, OpenGL support is waning, so SL requires a rendering engine that does not rely on OpenGL [and this has been an on-going discussion for the last couple of years or so].
  • [Video: 40:12-45:10] Land Impact: it has long been acknowledged that the Land Impact calculation needs to be revised; there is both a lack of real incentive within it for creators to optimise their builds, and  it misses some key adjustments for things like large builds. The question here is more when it will be revised – although doing so may not eliminate all the ways in which some people game the system to produce lower LI items, as this is something of a separate issue.
  • A general discussion on glTF and mesh imports (incl. scenes) via glTF. In short, no-one working on things at present, given the focus on the performance issues. The local preview remains available in those viewers with the code – by Runitai reminded people that the preview does not use texture streaming; everything gets pulled in at full resolution – and so VRAM can easily be gobbled up.

TPVD Meeting

Much of the TPVD covered ground already walked during the CCUG meeting. Therefore, the following is thus a summary of additional points discussed. Time stamps reference Pantera’s video, below.

Note the meeting formally ended at around 29 minutes, although the video runs through until just shy of 41 minutes, covering a more generic conversation.

  • A recap of the “classic”  / “potato” mode work (get PBR viewers running on lower-spec machines running at the same or better FPS than the hardware can run a non-PBR viewer).
  • Debunking the PBR myths:
    • It is not necessary to run the viewer on Ultra quality in order to view PBR content.
    • LL are not removing support for Blinn-Phong (or “classic” or “legacy”, however you want to call them) materials. PBR is an extension to materials support in SL, not a replacement.
  • A general conversation on Blinn-Phong and PBR Materials, notably in terms of providing the former as “fallbacks” to the latter to accommodate people on non-PBR viewers and prevent them seeing grey / white / plywood surfaces  / features.
  • [Pantera: 9:42-10:42] Some people may experience issues with PBR not just because of computer hardware limitations, but also because of network / router issues (e.g. instead of a single diffuse map, PBR calls multiple maps, resulting in multiple HTTP requests which can cause some routers to choke).
    • To counter this, the “classic / potato” mode LL is developing already doesn’t use the emissive map; if this is shown to work and push up performance, then LL will likely go through as see what other maps might be ignored without compromising the overall visual look of “classic” mode, and hopefully further lift performance in these cases.
  • [Pantera: 15:11-16:45] A reiteration that LL are continuing to work on trying to resolve performance issues, and that anyone experiencing such issues should file a feedback report with as much detail as possible (including hardware information (Viewer Help and use the Copy to Clipboard button and paste info into the report).
    • Specifics are important, as there is only so much info LL can pull from their stats. This is particularly true when terms such as “performance craters” are used, as these are so broad-ranging as to be meaningless.
  • [Pantera: 16:50-20:00] SL viewer’s use of CPU cores and threads: thread usage is variable depending on the number of CPU cores.
    • Those with a specific interest in this, the Steam Hardware Survey is “pretty close” to SL, although SL’s install base tracks “a little closer” to the lower end of hardware, so reduce what is reported in the Steam Hardware Survey 10-20%, and that’s fairly representative of SL.
    • Overall with SL, the main processing loop is single-threaded; texture rezzing and some audio processing occurs on background threads.
    • Runitai Linden has been experimenting with adding threads – such as a dedicated idle thread – and these are showing a “lot of promise”, particularly when Vsync is used.
    • As most GL processes are multi-threaded, hints are sent to things like Nvidia drivers to put themselves into multi-threaded mode.
  • [Pantera: 20:38-25:35] Frame limiters / Vsync: some TPVs use frame limiters to assist with performance, and LL would be interested in receiving a code contribution for one of these.
    • However, it is felt that if trying to limit frame rate to screen refresh, then Vsync remains the better option; whilst a frame limiter is more suited to use in other situations. But, and  depending on the frame rate, Vsync can cause more screen jitter than a frame limiter.
    • In this discussion it was noted that a fix from Apple at the OS level means Vsync with work at 100/120 Hz.
    • It was noted that Firestorm are now defaulting to 60fps with their frame limiter.

Next Meetings

 

† 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 week #43: SL TPVD meeting summary

Posted on by Inara Pey
Grauland / Primary Colors, September 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, October 25th, 2024. My thanks to Pantera as always for providing it.

Meeting 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: 0:00-2:30]

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11, promoted September 17 – No change.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11296522354, October 18.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain;  additional code to improve texture streaming on rigged attachments (e.g. if an earring is made with 2K textures, the viewer will correctly calculate the required resolution for the textures and download them, rather than downloading the full 2K textures), etc.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).
    • UI Optimisations: lessening the impact of UI rendering on frame rates / performance (discussed more fully at 16:52-18:04].

Upcoming Viewers

  • ExtraFPS is described as having some “high priority” bug which require fixing before it progresses to release status.
  • The next RC viewer to follow ExtraFPS is likely to be the Maintenance B build, which includes work put on hold while the focus was on PBR and non-PBR related performance fixes.
  • Performance improvement will continue to be part of the on-going work with the viewer, but once ExtraFPS is promoted to release status, it is unlikely that the Lab will produce viewers dedicated only to performance fixed for a while.
  • From the comments made, it appears as if LL are going to try to pull work from what had been the Maintenance C RC viewer (also put on hold whilst the performance work was going on) into the next viewer build as well.
    • It was acknowledged that this approach may need toa delay in getting the updated Maint B viewer out and to release status, but it is hoped that in the long run, it will mean a faster release cycle with the viewer builds which eventually follow behind Maint B.
  • [Video 21:09-22:27] Vir reiterates that as the Maint B(/C) viewer appears, it should mark the return  of Linux to the list of official viewer builds.
    • However, the Linux flavour will be based on code contributions rather than dedicated support from with in the Lab.
    • If things break with it, the Lab will attempt to fix them, but will not hold back viewer releases as a result of Linux-specific breakages / bugs.

WebRTC

[Video 2:31-4:20]

Summary

  • The replacement of the Vivox Voice service and plug-in, with 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

  • There is now a “pretty significant fraction” of users still using a non-WebRTC capable viewer.
  • LL would like this number to be further reduced before they completely pull the back-end support for Vivox. As such, the exact time frame on when the switch might be thrown is still TBA.
  • [Via chat throughout the 10-25 min point in the meeting, and with some Voice from approx 18 mins] It was noted that Voice roll-off under WebRTC should work the same as for Vivox, BUT the range at which is rolls-off completely is greater (60m).
    • Some have reported that this does not appear to be the case, with roll-off potentially not working at all (also reported at the last TPVD meeting).
    • LL to investigate further.

Graphics Work

[Video: 5:28-end]

  • The first part of this update referenced rigged attachment texture streaming as noted in the ExtraFPS summary, above.
  • Also as noted above, the work on improving performance has reached a point of diminishing returns for dedicated viewer updates, so future performance improvements will be folded in ither other viewer updates making it to the Develop branch.
  • The above noted, LL is still digging into specific hardware types where the viewer does not perform well (e.g. some AMD graphics chips) in order to determine what might be done to improve things.
    • If people running a viewer with the DeltaFPS code included are still fining they have very poor performance (e.g. single-digit FPS; an already low FPS cut in half, etc.), they are asked to file a Canny report and included information on their hardware (e.g. copy-paste their hardware information as displayed in Help → About, in the viewer).
  • [Video: 7:57-9:07] A change was introduced with the Delta FPS code such that if the viewer is running in the background on a system for more than 10 seconds, it will down-rez textures to prevent over-use of VRAM when it is not the application in focus.
    • This has received completely mixed feedback: some feel 10 seconds is too long a period to wait; others feel it is too short; those running multi-screen systems with SL on one monitor dislike the fact that when they focus away from SL to work on their other screen, SL “goes blurry”, etc.
    • As a result, LL is considering making this a switchable option, so users can decide whether they want to utilise it or not.
  • [Video 9:20-11:13] A discussion on using Vsync in the viewer vs. limiting frame rates (e.g. through the viewer or via something like the Nvidia control panel).
  • [Video 27:29-33:33] A discussion on brightness and  gamma / PBR vs non-PBR / use of HDR rendering + tone mapping.
    • In terms of tone mapping, the decision is to move back o ACES as the default in light of feedback, but people will remain able to select Khronos Neutral or ACES through Preferences.
    • The long-term plan is to have tone mapping and colour correction per sky setting, allowing region holders / designs to choose which ones they want.
    • As such, content creators are reminded no to bake tone mapping in their base colour / diffuse map but let the viewer’s post-processing handle the tone mapping.
  • [Video: 33:25-38:33] Alpha / gamma work:
    • As per previous meetings: in order for PBR lighting to render anywhere close to correctly, alpha blending had 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 giving people the ability to adjust the alpha/gamma on per texture entry for the object (including no mod items)
    • A link was provided to an installer for a viewer with the code at the meeting, but this later generated a 404 error.

In Brief

  • The latter part of the meeting included a discussion on documentation + communication (e.g. communicating more fully the reasoning behind PBR – the move towards better and more consistent content using glTF).

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 week #39: SL TPVD meeting summary: WebRTC

Posted on by Inara Pey
New Deer Isle, August 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, September 27th, 2024. My thanks to Pantera as always for providing it.

Meeting 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: 0:00-2:11]

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11th, promoted September 17th.
  • Release Candidate(s):
    • None at present.

Upcoming Viewers

  • The next RC viewer due to appear is the ExtraFPS viewer. There are some bugs still to be resolved before this viewer can see the light of day on the Alternate Viewers page; like DeltaFPS, it is primarily focused on performance improvements.
  • Further performance improvements will be made to the viewer following ExtraFPS, but work will also be transitioning to other viewer work. This next viewer after ExtraFPS will likely be the Maintenance B viewer. Details on it contents are still TBC, but it will hopefully include some of the work being put into getting Linux builds back up and running.
  • After this, maintenance viewer updates will follow in the usual alphabetical patten (C, D, E, etc.), with viewer being given a suitable name in accordance with the current dinosaurs naming convention.

WebRTC

[Video 2:31-7:55]

Summary

  • The replacement of the Vivox Voice service and plug-in, with 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

  • Under the latest schedule, simulator deployment of WebRTC support is now set to commence during the week commencing Monday, October 7th. This means if all goes well, it could be fully deployed across the grid during the week commencing October 21st.
  • The delay has been to allow LL to make further adjustments to the service.
  • 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.
  • During the transitional period when there will be a split between regions running Vivox and region running WebRTC, so:
    • General spatial audio should work through the viewer, regardless as to whether a region is running WebRTC or Vivox.
    • However, peer-to-peer, conference calls and group chat sessions might be subject to various disruptions (e.g. if you attempt to make a peer-to-peer call from a WebRTC region to some on a Vivox region (or vice-versa), the call will not go through; if you commence a call with both parties on a WebRTC region and one subsequently moves to the Vivox region during the chat, the call will be dropped, etc.).
  • [12:42-14:00 and 24:04-27:45 – chat only] It was noted that Voice roll-off on WebRTC regions does not appear to be as effective as with Vivox, with people much further away still being heard.
    • This was apparently an intentional decision, but can be further adjusted.
    • It was noted that perhaps the roll-off for WebRTC should be adjusted, as it was felt the distance over which voice conversations can now be heard could discourage active conversations in Voice regions, due to potential problems of conversations overlapping one another.

Additional Changes

  • There have been issues with the overhead Voice visualiser (the white do that displays “sound waves” when someone is speaking) always being red on viewers with WebRTC, and in muting and unmuting – both of these issues should be fixed in the upcoming ExtraFPS viewer.
  • ExtraFPS also introduces a new Preference option for users to turn off the overhead Voice visualiser in their view if they wish.
    • The switch is located within Preference → Sound & Media.
    • The inference is that the option will likely be OFF by default (i.e. no visualiser shown), as the introduction of the toggle option is to “reduce screen clutter” – although this may be revised, subject to feedback.
    • A further inference is that having the option off will not alter the Voice visualisers in the Conversation / People floaters.

In Brief

Please refer to the video below.

  • [Video:  9:31-10:25] Graphics work:
    • The focus remains on performance fixes.
    • As per my previous TPVD Meeting summary and my week #38 CCUG summary, Geenz Linden is working with Rye Cogtail on the visual improvements  (improved tone mapping, alpha blending, etc.) , with work also continuing on the anti-aliasing improvements.
  • [Video: 10:26-11:39] The above led to a reminder  updates to improve linear alpha blending for objects using Blinn-Phong materials; again, please refer to my week #38 CCUG summary for specifics.
    • This work is being targeted at the Maint B viewer, and are said to be pending some simulator-side work (which itself should be in the Barbecue / BBQ simulator code update that will follow behind the WebRTC deployment.
  • [Video: 16:51-18:33] A question was asked on the state of the pose tool developed by NiranV Dean.
    • This was originally developed for Black Dragon and has been ported to Alchemy. It was also contributed to LL several years ago.
    • It give the ability to pose an avatar (in your local view), such as for photography.
    • The code has never been integrated into the SL viewer, and part of the reason seems to be the old chestnut of “shared experience”.
    • However, LL are interested in developing it, and in receiving code contributions which may help overcome their reservations.
  • [Video 29:14-32:46] There have been a number attachment issues making themselves felt (e.g. attachments vanishing on teleport arrival; attachments adding and then seeming to remove “after a few seconds”, etc.).
    • LL are aware of a number of such issues and are investigating them.
    • The fix for the attachments being lost following a TP will be deployed as a part of the WebRTC simulator update (which, as noted, is now due to start deployment during the week commencing Monday, October 7th).
    • Those encountering attachment issues should check the feedback portal, and if they have a specific issue that does not appear to have been reported, file a report.
  • [Video: 40:03-44:09 with extended chat discussion through to near the end of the meeting] Future viewer work:
    • Brad Linden has been looking at native Apple / ARM support for the viewer, and considered this more of a “next year” project as the number of ARM users increases as opposed to those on Intel-based Apple systems.
    • He also noted that he has been working on some of the 3rd party libraries required to build the viewer to make them more “universal” for use in different OS versions of the viewer. This should ease the viewer build process when working on multiple platforms, and he noted that contributions from TPVs who may have done similar would be welcome.
    • It was reiterated that where Mac systems are concerned, LL is unlikely to implement Metal as n OpenGL replacement, but could look to a middleware layer to implement Metal compatibility for the viewer via Vulkan (or whatever is finally chosen to replace OpenGL for Windows).
    • In terms of performance improvements beyond the current work, the Lab is looking to better profile hardware and then seek targets of opportunity where improvements might be made to general viewer performance.
  • [Video: 50:03-50:28] RLVa contributions from Kitty Barnett: one pull request has been taken and is expected to make its way into the viewer Develop branch soon (if it is not there already), with more to follow.
  • [Video: 50-29-End]  A discussion on have the avatar selection process within the viewer point to the Senra avatars rather than the older “classic” basic avatars to help new users (there is currently a strong disconnect with the on-boarding process which utilises Senra with no real pointers for new users to understand the different avatar selection processes, Senra being entirely inventory-based).

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 week #35: SL TPVD meeting summary; performance issues

Posted on by Inara Pey
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 week #31: SL CCUG + TPVD summaries

Posted on by Inara Pey
Angel of Pain, July 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, 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

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

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