Tag: Content Creation 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 #49: SL CCUG summary

Posted on by Inara Pey
DREAMS, October 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, December 5th, 2024.
Table of Contents

The session was livestreamed by Strawberry Linden, and her video is embedded at the end of this article. Timestamps are provided to the relevant points in the video for ease of reference.

Meeting Purpose

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

Official Viewer Status

[Video: 1:49-4:03]

  • 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.12150664210, December 5. This focuses on performance improvements for lower-specification / old viewer hardware and includes:
    • 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.
    • [Video 4:12-6:23]:
      • A new checkbox to disable HDR-  this will improve performance for lower-spec machines but will see some of the “banding” previously seen in things like skies – and PBR emissive. These may be split into two separate checkboxes to allow one or the other to be disabled / kept.
      • A pass on “legacy” skies (e.g. those in the Library and / or which have no been converted from PBR skies) will look much as they did on pre-PBR viewer. This is described as the “least bad” option to address issues.
    • 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.
  • It is hoped that the December 5th RC version of ExtraFPS will be the version that will be promoted to de facto release status soon.

Near-Term Viewer Release Roadmap

  • There is additional work going on around performance that isn’t seen as urgently enough to delay the release of ExtraFPS, so there may be a “hotfix” viewer release to handle some of these, if required. Some of this additional work could take the form of:
    • Improvements to avatar loading, work which it was noted at the SUG meeting that Monty Linden had recently been tasked with looking at.
    • [Video: 6:38-6:55] Further texture streaming improvements (if these do not make it into ExtraFPS prior to promotion), which prevent the viewer repeatedly loading redundant textures.
  • The work in combining the “pre-performance work” Maintenance B and  Maintenance C RC viewer codes into a single RC update is continuing.  However, exactly what will be in it and when it is likely to appear as an RC viewer is still TBD.

General Discussion

  • [Text only] It was noted that some are seeing the texture bias tends to get stuck at high values in ExtraFPS, and failing to unstick until the viewer is restarted. This has been acknowledged by LL, but so far  they have been unable to consistently repro it. SLurls of regions where it frequently occurs have been request (feedback portal).
  • [Video: 12:08-14:45] a request to have settings in the viewer to allow users to set their own loading / rendering priorities depending on what they are doing, such as “near avatar”, or “near camera”, “avatars”, “rezzed items” , etc.
    • For example, while most use cases might be biased towards “near camera”, there might be situations where such as landing in very busy environments where “avatars” might be a preferable priority, so as to avoid shoving other avatars around when trying to move because they cannot be seen. Conversely, when cam-shopping, the priority is liable to be camera+ objects, with loading other avatars a much lower priority.
    • This was seen as having potential (allowing for the viewer and simulator carrying out different roles in scene loading: – the simulator sends the basic data of where things are and whatever meshes and textures are associated with them, but the viewer decides for itself what it is actually going to fetch (from the CDN) and when), but the current focus of work, per above, is on simply getting avatars + their attachments to simply load faster.
  • [Video: 16:19-18:43] Texture repeats / offsets reset on an object if the PBR material is changed: a bug report was requested on this. It was also noted that editing an alpha to opaque not holding has also been reported.
  • [Video: 17:38-18:31] Linux viewer status: the Linux work is defined as being in the “big bundle of stuff” which originally formed the Maint B and Maint C viewer code branches, which is in the process of being combined into a a single viewer under the Github Develop branch. As such, its progress and disposition is tied to this work, and while their are builds within the Github Actions, they are not in a condition for general release.
  • [Video: 18:47-21:33] A request to be able to crate new folders in Inventory from the Recent tab (or have newly-created empty folders at least appear on the Recent tab).
    • This was seen as a reasonable feature request submission.
    • A request was also made to be able to purge Trash from the Recent tab – however, given the Trash only shows items added in the current log-in session; purging all of Trash from Recent could have unintended consequences (e.g. an item previously and unintentionally dropped in to Trash gets mistakenly purged on account of it not showing in Trash under Recent).
    • It was also pointed out that opening an additional Inventory floater (CTRL-SHIFT-I) can help with issues of moving items around, rather than solely relying on one floater and its tabs.
  • [Video: 22:00-24:32] Add a checkbox to the Build / Edit floater – Select Only My Objects, rather than having to go through the Build → Options menu to set it:
    •  A problem here is the Edit / Build floater is already overcrowded, and the Build menu can be torn-off when editing / creating (although this can obviously impact screen real estate when open with the Edit / Build floater).
    • Simply enlarging the Edit / Build floater to accommodate additional options is also seen as a problem, again due to the added screen real estate taken up, particularly for those using lower-resolution screens.
  • [Video: 24:38-31:03] Ability to designate folders on upload on-the-fly:
    • Rather than having a single set of folders defined for uploads of specific types (e.g. a set folder for images, a set folder for sounds, a set folder for objects, etc), allow users to define which folder they wish to use for a specific upload  / number of uploads via  a drop-down, which can then become the default until next changed.
    • This is seen as advantageous to content creators, etc., as it would allow them to upload different asset types by “project” (so all mesh items, animations, sounds , etc., for “Project X” go to the “Project X” folder, for example).
    • A feature request was requested for this, with the added not that the current work on the viewer is not focused on adding to the UI, so it may be a while before such requests are reviewed & potentially actioned.
    • [Whilst not precisely the same, a similar request has been made regarding the upcoming llGiveInventory function, so that rather than having receiving  folders simply defined by the object giving them, recipients can select the folder into which they can receive the incoming items].
  • [Video 26:57-48:14] & intertwined with the above bullet point] Various discussions on hiding the current outfit folder, avatar customisation, etc., which were more general in nature and of a more historic / subjective nature than covering potential changes / improvements.  This also touched on avatar creation in Sansar, the use of devkits / applications (such as Marvelous Designer) etc.  This also bled into a re-hash of oft-raised issues around the new user experience, the use of Senra vs. the continuance of the Creator Avatar option in the viewer (which references the older starter avatars), which has no connection to Senra, etc. Please refer to the video.
  • [Video 51:18-53:47] The above led to a question (from LL) about the provision of a “private changing room” for people to be able to change their appearance anywhere in SL without being seen.
    • A similar capability was provided in Sansar, where altering the avatar’s appearance happened in a editor “outside” of the current scene, with the avatar returned to the scene post-update.
    • The idea has been the subject of requests for Second Life as well, being tied to the Appearance Editor; as such it is on the Lab’s radar for possible future implementation.
    • [Video: 55:45-End] In terms of implementation, one option under consideration is the re-cloud the avatar to other viewers whilst the avatar is having its appearance edited. An alternative would be to impostor the avatar to others.
  • [Video: 53:48-54:50] A reiteration that LL do plan on integrating RLV/a into the official viewer (code contributions from kitty Barnett for RLVa have been received, together (I believe) with input from Marine Kelley on RLV).
    • However, it was emphasised that this is a large project requiring significant code contributions / integration, so the work in regarded as in progress.
    • Because of the stigma associated with RLV/a (e.g. the “restrained” element of the title), it was suggested a rebranding might be in order.

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 #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 #45: SL CCUG summary (with Philip Rosedale discussion)

Posted on by Inara Pey
Evermore the Folklore, September 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, November 7th, 2024. This meeting lasted some 1 hour 50 minutes, due to the presence of Philip Rosedale, who address feedback from the audience as well as discussing SL in general.

The majority of the session was livestreamed by Strawberry Linden, and her video is embedded at the end of this article. However, as the meeting extended beyond the recording session, I’ve summarised the rest based on my chat log and audio recording.

Table of Contents

Meeting Purpose

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

Official Viewer Status

[Video: 1:28-2:19 and 3:43-4:32]

  • 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.11565212741, October 30.
    • 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.

Near-Term Viewer Release Roadmap

  • ExtraFPS work remains focused on bug fixes.
  • The first maintenance RC to follow ExtraFPS will be a viewer bringing together the updates originally planned for the  Maint B and Maint C viewers which were side-lined with the focus on viewer performance (Atlasaurus, DeltaFPS, ExtraFPS).
    • Some issues have crept into the merge process for this work, so the focus on this will be stabilising it after ExtraFPS is promoted to release status.
    • This likely means there will be a longer than usual pause between ExtraFPS being promoted and the new Maintenance viewer RC appearing.

WebRTC Update

[Video: 4:42-5:50]

WebRTC communications protocol (RTC=”real-time communication”) is the new Voice communications protocol for Second Life, replacing Vivox Voice.

  • Situation remains that Linden Lab are waiting for more users to switch to a WebRTC enabled viewer prior to switching over to using WebRTC only, and disabling Vivox.
  • A core sticking point here appears to be Firestorm users remaining on a pre-PBR (Vivox-only) release of that viewer, and they are being strongly encouraged to try swapping to the latest Firestorm release (7.1.1) or if performance with that doesn’t suit them to temporarily consider moving to an alternate viewer to help LL with enabling WebRTC (which is a superior Voice option to Vivox) / avoid losing Voice altogether should it reach a point where the switch is thrown for WebRTC.

Graphics Team Work

Viewer Performance

[Video 6:06-6:44]

  • Core focus remains on performance work , and will remain so until “everyone is happily on PBR-enabled viewers”.
  • Average viewer performance for most users is believed to be “pretty good” for PBR, but the Lab remains aware of the fact that their are cohorts of users who, due to hardware, etc., are “suffering some pretty significant performance loss”.
  • “Hunting down” and trying to fix these issues is now the priority, but will take some time.

Pre-PBR / PBR A/B Testing

[Video: 4421-49:19]

  • LL is carrying out A/B testing with Firestorm 6.6.7 (pre PBR) and SL Viewer’s ExtraFPS (RC viewer at the time of writing) to try to better understand performance differences and which lower-end hardware is being particularly hit under PBR (e.g. lower-spec Intel systems (integrated graphics?), some AMD GPUs).
  • In terms of Nvidia, Runitai believes performance on PBR viewers is “pretty close” to levels enjoyed pre-PBR, although there are still issues to be ironed out with some older GPUs / cards with low VRAM (such as those with only 2GB).  Some of this is likely to be a case of “turning down” some internal settings in the viewer so it its friendlier towards lower-end GPUs with limited VRAM.
  • One thing that has been identified is behaviour on launch / entering a scene (location):
    • Pre-PBR viewers like Firestorm 6.6.7 tend to launch with high frame rates which then decreases as the scene loads and memory is used, before stabilising.
    • PBR viewers tend to front-load textures, resulting in a low frame rate from the get-go, which improves as the scene loads the the viewer rationalises the textures it needs to display. This gives a false impression that performance is “bad” from the outset and only liable to get worse, potentially causing people to quit using a PBR viewer before they witness the increase in frame rates.
  • Part of the work in testing involves automation: the Lab has established a “potato farm” of laptop with limited resources and which are used with SL in order to carry out automated tests to determine where performance issues might reside

Tone Mapping

[Video: 6:56-8:07]

  • Originally slated as being a part of the viewer to follow ExtraFPS, the Khronos Neutral tone mapper, intended to improve overall ambient lighting in SL, making things somewhat brighter and more vibrant.
  • Khronos Neutral was to have been the default, with the option to switch back to ACES via Preferences → Graphics. However, following feedback, the decision has been made to leave the default as ACES and make Khronos Neutral the option, together with the ability to disable Tone Mapping.
  • Setting Tone Mapping will eventually be a Sky setting within EEP.
  • The recommendation to content creators remains don’t bake the Tone Mapping into your textures, allow the post-processing the the viewer handle it – in other words, Tone Mapping belongs to the camera, not the object.
  • The above rule also applies to thigs like lighting under PBR as well.

Auto-Exposure Work

[Video: 8:09-9:18]

  • Geenz Linden is now working on both the Tone Mapper and on auto-exposure.
  • Work has already been done within the auto-exposure process to make transitions “softer / easier on the eye”, and Geenz is now extending this work to make it more configurable (e.g. a “maximum”, a “minimum” and and “offset” for auto-exposure that users can set to their personal preference).
  • The intent is to have these new auto-exposure controls within the EEP Sky settings.
  • This work should help with issues such as the environment looking “dim” over water, snow, and similar.

In Brief

  • [17:36-25:40] Mina PBR Hair issue: Mina Nakamura indicated a possible alpha issue she is experiencing when using the specific PBR versions of some of her hair styles, which has only become apparent with the release of DeltaFPS. This may be a result of multi-layering of alpha blends, but copies of the hair have been passed to LL for testing.
  • [27:48-28:49] It was noted that there have been problems in get various content artists (hair makers, skin makers, etc) engaged in the Content Creation Discord channel, which has impeded some of the work relating to Baking, alpha/gamma, etc.
    • As LL – via Derrick Linden – has requested I do not publish information on how to join the Content Creation Discord channel, if you are a content creator not involved on the channel, please contact the likes of Vir Linden, Runitai Linden and Geenz Linden to request information on how to access it.

2K Bakes on Mesh

[Video: 9:43-13:37]

  • 2K Bakes on Mesh remains in general QA on Aditi (the Beta grid), and content creators are asked to test content there and provide feedback.
    •  Specific feedback being sought includes: bakes coming out at the correct resolution (e.g. if all layers at 1024×1024, that the Bake is also 1K); everything appears visually correct without any compression artefacts or similar; that the general experience with Bakes is the same as on the Main grid.
  • As a part of this work, the Bake Service as a whole has received some performance improvements. However, this aspect of the work has yet to be deployed to Aditi, plus once deployed, they may not result in a visually faster bake, depending on the complexity and resolution of the layers being baked.
  • If all goes according to plan, it is hoped there will be some form of 2K Bakes on Mesh support to the Main grid (Agni) by the end of November – although this is subject to confirmation; and they the Lab will provide a date when 2K skins, etc., can start to be listed on the MP, etc.
  • There was a reminder that account syncing with Aditi should now be automatic at the time of log-in (no need to raise a support ticket). However, anyone encountering issue still with Aditi access should contact support.

Viewer Discussion

This was a wide-ranging discussion commencing at the 29:14 point of the video. The following attempts to summarise that discussion, however, to try and keep a general sense of context, the bullet points may not reflect the order in which comments were made.

[Video : 29:14-55:00]

  • LL are looking to encourage greater engagement in testing new capabilities and features for SL, rather than having to wait for Firestorm to ship a viewer with support for the new feature / capability, in order to avoid a similar situation as occurred with PBR.
  • The SL viewer (SLV) has a good cross-section of hardware running it, but the overall pool of users is much smaller than that of Firestorm, and of those that do use it tend not to be so engaged in the platform so as to test and try things / report issues, which can result in problems such as those seen with the deployment of PBR: the Lab doesn’t have a sufficient deep pool of engaged users to report issues as they are encountered as new features / capabilities are being developed.
  • The question was asked as to what makes Firestorm attractive to users. This boiled down to four major areas:
    • The additional UI elements Firestorm have built to expose functions native to the viewer, but otherwise hidden within Debug settings.
    • Dedicated additional features created for Firestorm (e.g. Contact Sets), our specific new UI elements which pull together options and setting from assorted elements of the viewer and present them as a cohesive whole in their own right (such as the Phototools code contribution; the Graphics Improvement floater, etc.).
    • Very basic quality-of-life improvements, e.g. the ability to de-render / block the rendering of in-world objects (see below for more on this); the additional options to position tollbar buttons in the window (e.g. make them left or right ranged along the bottom).
    •  The level of in-world and additional support Firestorm provides: in-world classes teaching how to use the viewer; in-world support groups providing “live” support in multiple languages, etc.
  • Shortfalls within the SL viewer were noted as:
    • Loss of simple quality-of-life elements (e.g. the chat bar) and lack of accessible in-world support.
    • A lack of general support documentation / material (in this, TPVs have a distinct advantage, in that users of those viewers are willing to produce their own tutorials and guides, whereas few do so where the official viewer is concerned).
    • General misapprehensions about viewers. for example:
      • The idea that the SL viewer “doesn’t have capability X or Y, as it remains hidden with Debug settings.
      • The belief that features capabilities added by LL are “Firestorm” (or whichever viewer is being used) simply because it is first seen in that viewer, and thus are “missing” from the official viewer.
      • The idea that LL “doesn’t support” older hardware; as Runitai Linden noted, LL does not intentionally seek to make the SL experience any worse for those on older / less capable hardware; when this happens, the Lab does make efforts to redress things.
  • [Video: 49:19-End] An extended discussion on the Derender capability within Firestorm, with pros and cons, together with whether it should be generally surfaced for new users, due to the impression it gives (“welcome to our world; yes some of it is naff, so you might want to derender it”).
    • Pros: the ability to stop unwanted objects being rendered in a scene either for a session or until cache is cleared. This is very hand for a variety of reasons such as in-world photography.
    • Con: the ability to de-render mesh clothing on other avatars.
    • The discussion also touched upon alternatives to derendering for certain use-cases (e.g. the ability to click-through something like mesh “rain” to touch a vendor board – something which can now be set, as Rider linden indicated).
    • Also mentioned was the option for a degree of automation to help deal with some instances where de-rendering might otherwise be used (e.g. some form of flag mechanism / land setting such that should someone enter a G/M public space with genitalia / “adult” attachments on display, the simulator orders the viewer to remove them (see below for this).

Post-Video Discussion

  • A discussion on streaming on Twitch to reach new users – which Philip Rosedale has previously noted, is a subject of ongoing discussions between LL and Twitch, with the caveat that seeing Twitch as a possible “marketing / promotional” channel for SL is not ideal, due to the younger age demographic of many Twitch users.
    • It was noted that VRChat, which has “adult” content manages to be able to have people stream from it to Twitch.
    • It was also pointed out that Twitch is a channel for content creators to produce tutorial-like live streams on how to use external content creation tools (Substance Painter, Blender, etc), to create content for SL – but they are unable to steam video of the content being used in SL via Twitch.
  • The idea of a flag mechanism was discussed in broader terms: as well as having a specific land control switch, having a switch in the viewer which derenders “adult” attachments on avatars. This:
    • Would provide the control at a per user basis (don’t want to risk seeing “adult” attachments? Leave the switch set; no objection – turn the switch off and allow “adult” attachments to be rendered.
    • Allows, when combined with the land control, the greatest flexibility of use: store owners or owners of G / M rated public regions, for example, could opt to set the flag at Land level, and thus automatically prevent rendering of any  / all “adult” attachments in their regions in all viewers in that region.
  • The above led to a conversation on Second Life continuing to allow adult content whilst working to ensure there are workable safeguards to ensure those not wishing to see it do not see it. This discussion touched upon:
    • Issues of Marketplace content not being properly flagged as adult / being tagged too broadly so that either someone with the MP content rating set to General or Moderate still gets to see adult content; or b) adult content appears in entirely unrelated categories.
    • The need for a more granular rating system. There are many reasons for this (e.g. Adult is often a catch-all, rather than indicating “sexual” (or possibly offensive): art galleries, for example, will often opt for an Adult rating, simply to avoid the risk of being reported for displaying nudity, genitalia, etc., within art.
  • Philip Rosedale asked about the appropriateness of clothing in public spaces (specifically indicating his own use of chaps with a “stained glass” crotch area in a public meeting venue – even through the chaps revealed nothing, they still drew people attention to his crotch).
  • Suggestions were made that the new user experience should provide mor details on common activities within Second Life, to give incoming joiners a clearer idea of what to expect / what they might discover.
    • This included an idea that anyone expression an interest in “Adult” content should be “sent straight to Zindra” – which (personal opinion here) I believe would be a bad move, as Zindra is most strongly associated with sexual content – and as noted earlier in the meeting, “Adult” in SL does not automatically equate to sexual activities. But, by pushing people who click the option merely out of curiosity directly to Zindra, risks reinforcing attitudes that SL is focused on sex / porn.
  • Philip also provided some updates on matters raised during his November 1st, 2024 Community Round Table:
    • That work is being put into place to better explain the user name selection in the join flow, and the difference between the user name and the Display name, to help overcome issues of people choosing user names they come to regret (e.g. “xyzmnop3210”).
    • A reiteration of the (oft-voiced at UG and Meet the Linden / Lab Gab technical sessions) fact that the reason Groups are capped for membership levels is that activities such as sending Group message comes an a non-trivial computational process (and associated cost) of the back-end systems having to look up which users are in a particular group in order to receive said message(s).
  • The above comments led to a series of personal requests being made directly to Philip, which as he pointed out, highlight the fact that prioritising requests is not easy  – those who talk loudest / most persistently do not necessarily represent the majority thinking, and thus their request  – even if apparently easy to achieve – many not reflect what “the community” (a term itself hard to quantify) actually wants.
    • In this, he specifically reiterated some of his comments from his Community Round Table about trying to find mechanisms by which the Lab can better engage with groups of users on topics / ideas, in order to get a broader representation of people’s views without either a) responding only to the most dominant voice in a group; or b) having a group so large, it is impossible to get a broad consensus on feedback / ideas.
  • Amidst the general airing of points-of view, Philip asked a question which is of potential relevance to many; as such I’ll include it here:

 

One of the things I’m trying to think about is how to make Second Life more accessible to all of you. What I mean by that is, for that one thing that brought you in, is Second Life also accessible to everyone else for whom that one thing is also true? So, for example, I spoke to someone the other day who is hard of hearing; and I can imagine that’s a pretty good reason to want to be in Second Life, because being in the real world sometimes can be quite difficult if you’re hard of hearing, right? Potentially, Second Life can make that easier, but only if we do the accessibility work to make that functional. 
So I kinda ask the broader question – and again, if you want to follow-up with me by e-mail, please do so. The broader question is, what is it that brought you here, and then is Second Life easy to use for everyone else like you, is kind-of the way I’m thinking about right now. It seem like so many things are hard; in different ways, Second Life is appealing, but then many, many other features  of it make it excruciatingly difficult. Like, we talked earlier about if I’m a teacher who wants to play around with using Second Life at university, but I’m so exposed to sexual content that I just decide “no”, that would be a perfect example of that; so in that case, Second Life is just not accessible to me as a university teacher, because it’s just too sexual.
  • The above led to a range of opinions on what SL is, griefing, accessibility in terms of supplied avatars, etc, running through the last 10 minutes of the session. However, given Philip’s question and the fact that some might wish to respond – to Philip via e-mail, not in the comments here, which he may not read! – I will close the summary here as it is already well into the realm of TL;DR!

 

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 #42: SL CCUG summary

Posted on by Inara Pey
Mad Hatter’s Tea Room, September 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, October 17th, 2024. There was no livestream or video for this meeting

Meeting Purpose

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

Official Viewers Update

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11th, promoted September 17th.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11074622243, September 30.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).

Near-Term Viewer Release Roadmap

  • ExtraFPS work remains focused on bug fixes.
  • The first maintenance RC to follow ExtraFPS will be the Maint B viewer, which will include updates put on hold during the focus on performance issues plus additional updates, some of which may be further “post-PBR” performance / aesthetic improvements.
    • Maint B, as noted previously in these summaries, will have updates to help with Linux support / builds.
  • Maintenance C is also being put together, but updates changes have not yet be specified, outside of a desire to keep the changes separate to Maint B in the interests of keeping updates easier to manage.

Avatar LookAt /  Eye Tracking in the Viewer

  • A conversation relating to avatar eye movement / use of Look At cross hairs (& the resultant drama it can cause (“Stop perving me!”), and whether because of the latter, the capability should be removed completely from the viewer.
    • The core problem is, even though the option for a user to see their own LookAts in the Official viewer is disabled by default, the data (cross hairs and avatar name) is broadcast to surrounding viewers, resulting in unwarranted drama (“Stop perving me!” or “You’re on the wrong viewer!”).
    • Various viewers handle this situation in different ways; some follow the SL viewer, other’s provide means to see the LookAt crosshairs from others whilst supressing their own LookAt data (e.g. so I can see your LookAt crosshairs (if not supressed), but you cannot see mine – possibly leading to more drama).
    • Given this, LL sought the best way to reduce the level of upset: remove the LookAt broadcast altogether, or limit it / make it subject to having be physically turned on through a debug. The consensus of replies appeared to be to limit it / disable it behind a setting.
  • This conversation also crossed-over into avatar head movement tracking the movements of the mouse (e.g. you move the mouse up to the menu bar and your avatars head tracks upwards, then you move to a toolbar to the side or bottom of the window, and your avatar’s head again tracks).
    • This is perhaps more immersion-breaking that Look Ats (drama on the latter notwithstanding) and as  some TPVs allowing such head movement to be disabled, there was a consensus that this should be disabled / removed from the viewer.

Graphics Team Work

PBR Terrain Transforms and PBR Terrain Painting

  • PBR terrain transforms: As per my week #38 update, PBR terrain Texture transforms for applying scale, offset and rotation to any one of the four PBR terrain materials, have been developed for use in the viewer.
    • The capability is a subset of the KHR texture transform.
    • Currently the viewer-side options are setting behind debug flags.
    • The simulator support for this work is currently targeting the Barbeque simulator update, which is due to start deployment after the  WebRTC simulator deployments.
  • PBR Terrain Painting: the work on PBR terrain painting (see my week #31 update for a summary and previous status) has been “shelved” for the foreseeable future.
    • While no specific reason for this was given at the meeting, it seemed implied that this work has been superseded by the need to focus on other work for the time being.

General glTF / Graphics Comments

  • In response to a question about additional  glTF work, Runitai Linden confirmed that user-made shaders will not be supported, but blend shapes and (possibly) animation of texture coordinate transforms from Blender.
  • Displacement maps won’t be supported for the time being as their is no available glTF specification for them.
  • Given the percentage of people not using PBR enabled viewers, LL is considering adding a simulator-side update that can detect a non-PBR viewer, and then take the base colour and Normal layer from the PBR material and move them to the Blinn-Phong parameter, so users on those viewers will at least see some surface detail on PBR objects rather than only seeing then a flat grey surfaces or untextured prims.

In Brief

  • A fair portion of the meeting was taken up with issues pertaining to the New User Experience / Marketplace issues – both of which those Lindens (Engineers) at the meeting were unable to directly address as these areas are outside of their remit.

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 #40: SL CCUG summary: tone mapping

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

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

Table of Contents

Meeting Purpose

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

Official Viewers Update

[Video: 1:18-2:30]

  • Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11th, promoted September 17th.
  • Release Candidate: ExtraFPS RC, version 7.1.11.11074622243, September 30.
    • Performance improvements: enhanced texture memory tracking, broader hardware compatibility and higher FPS gain.
    • Aesthetics improvements: new Antialiasing setting – SMAA; Contrast Adaptive Sharpening; Khronos Neutral Tone Mapping (can be changed to ACES via the RenderTonemapType Debug setting).

Near-Term Viewer Release Roadmap

  • ExtraFPS work is focuses on bug fixes with the aim to get it promoted to default viewer status ASAP.
  • The first maintenance RC to follow ExtraFPS will be the Maint B viewer, which will include updates put on hold during the focus on performance issues plus additional updates, some of which may be further “post-PBR” performance / aesthetic improvements.

WebRTC Status

[Video 2:34-3:41]

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

  • Still awaiting wider simulator RC deployment. Per recent SUG / TPVD meetings, this now looks set to commence on October 16th, although the date may still change.
  • In the meantime, WebRTC support is available on the following regions Pop Rock RC, comprising: WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4.
  • LL is already looking ahead to further work with WebRTC once it has been deployed, in terms of “Voice and media”. More to follow on this in the future.

Graphics Team Work

Linear Alpha Blending

[Video: 4:08-6:06]

  • Again, as per the previous CCUG meeting, 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.
  • For those with access to the Content Creation Discord channel, this work is now available in a pre-release viewer there.
      • Note: due to a request from Derrick Linden, I am unable to post information on how to access the Content Creation Discord channel. Requests to do so should be made to Vir or Derrick Linden.
  • This work is supported on (the Beta grid) – again, refer to the Discord channel for details on this.
  • Those using the Discord build are asked to provide feedback (with screen shots as appropriate).

Tone Mapping

[Video: 8:00-12:18 and 24:31-End]

  • Originally slated as being a part of the viewer to follow ExtraFPS, the Khronos Neutral tone mapper (another code contribution by Rye Cogtail), which should improve overall ambient lighting in SL, making things somewhat brighter and more vibrant.
    • Options for this are available within the ExtraFPS viewer as debug settings:
      • RenderToneMapType – set the desired tone mapper (either Khronos Neutral (new default) or ACES .
      • RenderToneMapMix – mix between linear and tone-mapped colours.
    • If this approach is continued, these options will likely become UI elements within the Sky settings, allowing the desired Tone Mapper  / mixing be set at parcel level for the viewer, together with Advanced Graphics options for determining which should be the general default.
    • Results to these have thus far been mixed, so more feedback is being sought – which is felt to be better (ACES or Khronos Neutral (or even something else, etc).
  • Some concerns have been voiced by creators over the idea that tone mapping can be user-configurable (“how can I make sure the tone mapping on my item is correct, if the user can change tone mapping in their viewer?”).
    • Allowing tone-mapping offers the ability for people to view Second Life as they prefer / set their regions / parcels to be viewer under specific lighting conditions; ergo offering tone mapping options via the EEP Sky settings as has been suggested above was seen by most at the meeting as a good thing.
    • Some questioned how consistency of appearance can be maintained (per the question above)  if they cannot be certain on the adjustments users make to their viewers.
    • One suggestion was for LL to designate one as the default that creators should be testing and creating against, and if the parcel is different, then it is up to the parcel owner to deal with.
    • Overall, keeping with Khronos  / glTF would be preferred,
  • Further help in setting the brightest / contrast for for scenes can also be offered through exposure control and the colour gradient, with Geenz working on these as well.
  • The above grew into an extended technical discussion through to the end of the meeting, please refer to the video.

In Brief (Q&A)

  • [Video: 12:23-13:30] A brief discussion on glTF punctual lights (coming with glTF scene import), which might also offer the opportunity to offer more lights on alpha (rather than just the 6 closest, as it currently the case).
  • [Video: 15:00-16:50] more Bakes on Mesh channels (e.g. individual left / right eye channels to allow for individual eye colours er eye:
    • Nothing currently planned beyond the existing Aux channels.
    • LL has had internal discussions on a “simplified editor for decorating houses, etc.”, and feedback has been requested as to what kind when / if the concept of layer channels is re-visited, it might be from the perspective of replacing them with something more accessible – but this is not something currently being investigated.
    • In terms of channels for individual eye colours (or similar), a feature request was requested.

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.