2024 week #51: SL CCUG & TPV meeting summaries

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 Official Viewer Status ExtraFPS Notes and Rendering – Both Meetings ExtraFPS Notes General Rendering TPVD Meeting The Lab Using TPVs The Viewer Structure and Open-Source General Discussion Points Next Meetings

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

• CCUG: 13:00 SLT, Thursday, January 16th, 2025, at the Hippotropolis Campsite.
• TPVD: 13:00 SLT Friday, January 17th, 2025 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.