2022 TPVD meetings week #19 summary: PBR materials

RockMead, April 2022 – blog post

The following notes were taken from the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) of the Third-Party Viewer Developer (TPVD) meeting on Friday, May 13th, 2022 at 13:00  SLT. These meetings are chaired by Vir Linden, and dates for them can be obtained from the SL Public Calendar.

Important: as from this meeting, the TPV Developer meeting has moved to a four-week schedule.

Please note that this is a summary of the key topics discussed during the meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:00-6:22]

On Thursday, May 12th:

  • The Makgeolli Maintenance RC viewer (Maintenance M) viewer updated to version 6.5.6.571575.
  • The Performance Improvements RC viewer updated to version 6.6.0.571736.

On Tuesday, May 10th, the Performance Floater and Auto-FPS project viewer updated to version 6.5.4.571296.

The rest of the currently available official viewer versions remain as:

  • Release viewer: version version 6.5.5.571282 – formerly the MFA RC viewer, dated April 26, promoted Wednesday, May 4th – NEW.
  • Project viewers:
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The Performance Improvements RC viewer remains the next in line for promotion to de facto release status, the latest update to this viewer awaiting data on crash rates prior to potentially being promoted.
  • MFA Enforcement: the eventual plan with multi-factor authentication (MFA) is to “enforce” it for all users who have opted-in to using it so that when logging-in to SL on a viewer without MFA support, they will see a message requesting they either swap to using one with MFA support or disable MFA from their Second Life account dashboard.
    • It is not clear when such enforcement will commence. However, the official viewer, Catznip, Kokua and Cool VL are all known to support MFA, and an MFA version of Firestorm is in the works, so it is likely that the “enforcement” could come in the relatively near future.
    • There will be no change to logging into the viewer for users who have not opted to use MFA or who decided to disable it on their account.
  • https://viewer-login.agni.lindenlab.com/ is a URL referenced in the viewer log-in code, but is currently a redirect and not actually used. LL is therefore planning on removing it.

Additional Materials Support / PBR

[Video: 7:19-20:36]

Note: please also refer to my recent (April / May) CCUG meeting summaries.

Two area of work are currently in progress.

Materials Assets Support

One element of work is to provide “full” Physically Based Rendering (PBR) materials support utilising the glTF specification.

  • This work is currently focused on implementing a new materials asset type that will allow materials surfaces created utilising the PBR workflow to be imported to SL and then applied to their desired object face(s).
  • LL hopes that creators using PBR will also supply textures entries (e.g. a diffuse map + normal & specular maps (if required) + associated parameters as we know them today in the build floater) so that systems / clients that cannot / do not run the supporting PBR code can display these texture entries instead, rather than leaving objects with blank faces.
    • It has been suggested than any such use of “fallback” texture entries be an automated process, rather than something that has to be done manually by the creator.
    • Longer term, there will be some form of LSL support for this as well, although the extent of this has yet to be fully determined. However, it is liable to be along similar lines to texture application using LSL.
  • Once defined, the materials assets will be stored using the glTF 2.0 specification.

Reflection Probes / Environment Maps

A parallel piece of work is adding sport to SL for reflection probes to update the generation of the environment maps (because the current cube mapping used by SL is limited and would not work will with PBR).

  • The key point here is that the introduction of reflection probes + updated cube maps will work with both “PBR” and “legacy” content.
  • This work has been underway for the last couple of weeks, including input from some content creators / viewer developers.
  • “Outdoor” probes will likely be subject to automated placement, but with a hierarchy applied such that they don’t override probes placed inside structures.

General Notes

  • The majority of discussions on this work are being handled through the Second Life Discord server, within the #content-features channel.
    • Access to this channel must be specifically requested by content creators after they have joined the Discord server.
  •  In terms of user testing, the approach to this work is similar to that taken with Mesh:
    • Testing will initially be carried out on Aditi (the beta grid) as things develop, allowing various “PBR” and “legacy” content to be uploaded and tested, well before anything is implemented on the main grid or made widely available to users through the viewer.
    • Content creators wishing to test content are strongly advised to join the Discord discussions and join in with testing from there.
  • glTF mesh object uploads: this is on the roadmap of things the Lab would like to include in the initial project. However, depending on how work progresses and time frames imposed, it may not form a part of the initial work that is shipped and slip to being “tackled at some point”.
  • Support for materials variants within the glTF assets (e.g. to allow colour variants in fatpack items) is also under internal discussion at the Lab.

In Brief

  • [Video 21:09-23:30] The simulator fixes for off-line Group and Friend invites failing to update following acceptance should be surfacing on the RC channels in week #20.
  • [Video 22:44-27:40] a discussion on rigged meshes and bounding boxes focused on a change that was made to overcome issues of people creating oversized bounding boxes for their rigged meshes in order to avoid providing LODs (and forcing the viewer to always render them at a performance impact) that was recently reverted.
    • Runitai Linden explained that the revision was actually the result of changes made within the Performance Improvements Viewer that clashed with the rigged mesh bounding box changes, and that there is still an open issue to ensure the rigged mesh bounding box is always an appropriate size.
    • This rolled into a broader discussion on the complexities of rigged mesh visual size, scaling, bounding boxes / LODs selection, impact of the animation system, etc.
  • [Video 28:04-End] The above leads into a discussion on LODs in general and the idea of auto-LODding content vs. (good and bad) custom LOD creation (and what constitutes “good” LOD modelling – e.g. basing on surface area or triangle count?), LOD / LI conflicts, and trying to strike an equitable balance such that LODs can be “properly” defined and used.
    • As this discussion covers a lot of ground, I refer those interested to the video.

2022 CCUG meeting week #18 summary: reflection probes

Cherishville, March 2022 – blog post

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, May 4th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Official Viewers Update

  • On Wednesday, May 4th, the de facto release viewer was updated to version 6.5.5.571282, formerly the MFA RC viewer, dated April 26. See my notes on this viewer here.
  • On Thursday, May 5th, the Performance Improvements RC viewer updated to version 6.6.0.571507.
    • The focus for this viewer is now bug and crash fixes, rather than adding functionality.
    • This update also sees the viewer merged with the release viewer MFA code base, and so will require anyone who uses MFA and who has not logged-in to Second Life using an MFA token to do so -follow the link above for details.

The rest of the official viewers remain as:

  • Release channel cohorts:
    • Makgeolli Maintenance RC viewer (Maintenance M) viewer, version 6.5.5.570983, April 26.
  • Project viewers:
    • Performance Floater project viewer, version 6.5.4.569531, March 18.
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

Graphics Update

  • During the previous CCUG meeting, the potential direction for Physically Based Rendering (PBR) materials support was discussed at length, and concerns were raised that for PBR to be effective, SL’s lighting / reflections model would need to be updated.
  • As a result, these branches of work have commenced:
    • The foundational work in creating a materials type with an associated inventory asset, as per the week #16 meeting. This  will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory.
    • Foundational work on the PBR graphics pipe in the viewer.
    • Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content. This formed the focus of this meeting.

Reflection Probes

  • Runitai Linden envisages two forms of reflection probes:
    • Those that are part of a scene’s environment and are automatically placed, but which can (hopefully) be adjustable by scene builders – this is the current focus of the work, with the reflection probes married to the octree so they will align with octree nodes.
    • Reflection probes which can be specifically placed within structures by their creators (e.g. a probe within each room of a house) or which can be created and added to a legacy structure.
      • These would override “environment reflection probes” to prevent clashes (so that, for example, your nice shiny kitchen worktop is not reflecting the sky outside, but is offering reflections of the static objects on and around it.
      • Their size would be based on the volume they are attached to, which would allow for parallax correction, allowing the reflections to be accurately generated within a room space.
“Environment reflection probes” used with legacy content: on the left, shiny surfaces of a prop engine as most of us are used to seeing them today. Right: the same engine but with its shiny surfaces now showing reflections generated via a reflection probe in the scene. Credit: Runitai Linden
  • These probes:
    • Comprise an object (prim) defined as a reflection probe which essentially uses the 360º snapshot code viewer to produce a cube map of its surroundings with each face set to 512×512 resolution (so 6 x 512×512), which can then be used to generate object “reflections” on surfaces within their volume of control.
      • This will require some additional checkboxes to be added to the build floater / viewer, but otherwise means probes can be inserted into “indoor” scenes using the existing build toolset.
    • Capture everything except avatars (so no reflections of your avatar walking past a shiny surface).
    • Initially trigger the generation of their cube maps by the viewer on entering a scene.
      • Maps are cached on disk, with up to 64 held in memory.
      • Currently only 8 maps are active at any one time. However, given sampling of just 8 maps for rendering can take up to 70% of an RTX 3080 GPU, this number is likely to be dropped to 4, unless a more targeted means of sampling for a given pixel can be determined.
    • Are updated whenever the number of objects in them changes or the Day Cycle changes, although the update rate is no more than one probe per frame.
    • Include Fresnel calculations when generating cube maps.
Glossiness and reflection probes: in this image, the centre left row of spheres have a white face, and the centre right all have black faces. Each pair, front-to-back, has a matching and increasing level of glossiness applied. Note how the greater the amount of glossiness, the sharper the reflections of the probe’s cube map. Credit: Runitai Linden. 
  • The overall aim of this work is to provide a means to support more physically accurate reflections in SL than can be currently generated (seen as a requirement for PBR support). This work can then both:
    • Be integrated into the PBR work as that is added to Second Life.
    • Improve the existing SL environment map so that legacy content does not clash with PBR content as badly as might otherwise be the case – although it will not be a perfect blending of the two.
    • However, it will be “very, very hard for this to not break [some] content”, although the overall result should improve so SL looks.
    • Given this, the capability will need a lost of assistance with testing.
  • Concern has been raised about how to limit / control the use of probes so as not to cause potential performance issues (e.g. by creators including a probe with all of their products that have a shiny / reflective surface).
    • The plan is to have every single pixel in a rendered scene covered by at least one probe via the automatic placement, so objects that are outside certainly should not need their own reflection probes.
    • Even so, it has been suggested that time is taken to produce a “best practices” guide to using reflection probes and to provide examples of bad probe set-ups.
  • It was also suggested that a flag for “do not reflect” should be provided to help control what is included in a cube map in a given setting. It was not clear if this would be possible, so the question was set aside for the next meeting.
  • General Notes:
    • This work is still in its early stages, and elements may change.
    • Several aspects of reflection generation have yet to be tackled (e.g. handling 100% transparent and 100% alpha textured surfaces).
    • The work has yet to be tied-into the existing graphics controls in the viewer so that everything works consistently and logically.
    • Some of the additional work required for generating reflections might be compensated for by optimising other elements of the shader system as this work progresses.
    • At some point this work will be available within a project viewer for testing on Aditi.

Note: while reflection probes formed the core of this meeting, this does not mean this work will be shipped ahead of the more PBR-related work. All three project branches are in their early stages, and so no decision on prioritisation among them has been taken.

PBR-Specific Work

  • The PBR graphics pipe is still being plumbed-in.
  • No work has really started with the PBR shader set.
  • The plan is still to follow the glTF specification.
    • As this embraces the PBR Metallic Roughness workflow, this will be the first to be supported.
    • If demand surfaces, LL might add Specular Glossiness as a follow-up.

Next Meeting

  • Thursday May 19th, 2022.

2022 CCUG + TPVD meetings week #16 summary (PBR)

Seagull Rock, March 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, April 21st 2022 at 13:00 SLT.
  • The video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) from the Third-Party Viewer Developer (TPVD) meeting on Friday, April 22nd, 2022 at 13:00  SLT.

These meetings are chaired by Vir Linden, and their respective dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in each meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:22-2:00 + notes from CCUG meeting]

The list below reflects the rest of the currently available official Second Life viewers:

  • Release viewer: version version 6.5.4.570575 – formerly the Lao-Lao Maintenance RC viewer, promoted Monday, April 18.
  • Release channel cohorts:
    • Performance Improvements RC viewer version 6.6.0.570163, dated April 4, issued April 14(?).
    • MFA RC viewer, update to version 6.5.4.569725, on March 24.
  • Project viewers:
    • Performance Floater project viewer, version 6.5.4.569531, March 18.
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The focus remains on fixing the bugs reported on the Performance Improvements RC viewer so that it can be the next viewer promoted to de facto release status. The RC version has been updated but has yet to be issued.
  • The promotion of the Lao-Lao viewer to release status means the current RC viewers are going through the merge with that codebase, and a new Maintenance RC should be appearing soon.
  • The Copy / Paste project viewer has been languishing in project viewer hell for some time whilst the focus on viewer work has been elsewhere. It is hoped that this well move forward once more Soon™.
  • [Video 6:26-7:35] Additional work is being carried out on the Legacy Profiles viewer (such as allowing the avatar UUID to be accessed via scripts by the likes of greeters that display the avatar image, etc.).

CCUG: Additional Materials Support / PBR: Hitting the RESET Button – CCUG Meeting

This formed the core of the CCUG meeting. The notes below should also be referenced with my notes from the previous CCUG meeting.

  • As previously noted LL had proposed a two-step approach towards moved to “full” Physically Based Rendering (PBR) materials support to give a high fidelity to SL rendering where PBR materials are used.
  • Significant concerns were raised about this approach at the last two meetings (e.g. a lot of creators do not use PBR-based workflows – a requirement for glTF – and so moving in this direction could create extensive issues for those creators).
  • As a result of the feedback, discussions at the Lab have been focused on an alternate approach:
    • Creation of a materials inventory type with an associated asset which could potentially have different forms (e.g. in one state it could be associated with PBR, another simply specify the legacy texture / materials parameters)
      • Where the PBR materials are specified, render using a  new “PBR render path”; if the legacy parameters are used, render via the existing render path.
    • Move directly to a PBR implementation.
    • This would initially be limited to the materials aspect of glTF and not support any geometry for objects that can also be held by a glTF file (so no uploading for uploading complete mesh objects as glTF) – which is not to stay upload support for other formats wouldn’t be added at some point in the undefined future).
  • However – the above bullet points are all still under discussion at the Lab, so no final decision on the overall approach has been made.
    • It has also been noted that whatever happens, a significant requirement will be to provide specifications on which materials types are going to be supported, and what people can expect.
    • It is hoped that at least some of the Lab’s approach can built off of existing specifications rather than reinventing the wheel, then extended into those “optional” materials should be supported.

Cube Maps / Reflection Model

  • A concern was raised that current cube mapping used by SL is limited, and would need to be updated to a higher resolution for PBR support to be effective.
    • LL are aware of the limitations of the current cube map and would be “looking to address that” – although indicated this may not be done for the initial release of any related work.
    • This led to concerns that any release of PBR materials support without any corresponding update to SL’s cube mapping will result in creators attempting to implement their own workarounds to perceived limitations, resulting in content at odds with any cube mapping updates the Lab does make.
    • This latter point wasn’t seen as a problem, as LL’s view is that any updates to SL’s cube map will only be relevant to content created after the update, and it was further suggested that any “initial” updates to support PBR (and sans cube maps updates, environment maps, etc., might not even be user-facing, but purely for internal use / testing.
  • A similar concern was raised over the current reflection model + environment maps – that if not considered / managed as a part of the PBR project, it will lead to very poor results or limit the use of PDR materials.
    • Again, LL’s view is that reflection map / probes / environment maps re something that will be tackled “later”; some creators are of the opinion that it needs to be tackled as a core element of the work.
    • LL suggested that they might offer support of static environment maps initially, and then move towards the ability to cast reflection probes to allow reflections to be dynamically generated. However, all of this is still being discussed internally at the Lab.
  • It was also pointed out that lighting / reflections in PBR are calculated on physical properties (e.g. lumen equivalency) – which currently isn’t possible in SL without significant update to the rendering system. This was again seen as something that could be handled “later”.
  • Concerns were also voiced over the idea of things being set aside for “later” on the basis that LL has a long track record of breaking projects down into “iterative phases” – only to deliver the first one or two, and then push further work off into the future for assorted reasons (Examples:. the original materials project, Animesh, Experience Keys, EEP, the in-world aspect of ARCTan (allowing for the fact ARCTan as a whole seems to have become stuck)), with the results they become “someday / never”.

General Questions

  • Will the addition of broader materials support with PBR lead to alterations to the land impact formula?
    • Potentially for content using PBR, but this has yet to be fully determined. The feeling among creators is that a re-balancing of the LI formula would be required.
    • However, LI calculations themselves are in need of overhaul to more accurately reflect the cost of rendering objects (something the Lab has planned to do as “phase 2” of adjusting rendering calculations as a whole under project ARCTan, so while not intrinsic to PBR, LI / rendering costs might be reviewed as an adjunct to this work.
  • Will this lead to an increase in region land capacities? No.
  • Will it apply to all new content, post implementation? Yes, with the exception of system avatars and content requiring the the Bake Service.
  • Will this approach allow scripted update / changes to materials on faces? That is something that will likely have to be “tackled latter”.
  • Will this mean further updates to the uploader? most likely, yes.

TPVD: Off-line Friendship / Group Offers + Simulator Capabilities

[Video: 3:22-6:14]

  • Monty Linden has been working to fix issues of off-line friendship and Group invitation offers failing.
  • This has required a complete overhaul of the related capabilities for handling such offers, with the focus being primarily on getting them working again. Although “at some future time” the functionality might be revisited to do “something bolder and more interesting with it.”
  • This work is going to QA, and will be moving to Aditi (DRTSIM-537) for further testing.
  • At the same time, Monty has also be updating the Simulator Capabilities wiki page
    • The focus had been on making sure the list of capabilities in up-to-date.
    • Work will now be going forward to update / provide the underpinning documentation for all the capabilities. This will be done on an as time permits basis.

TPV In Brief

  • [Video 7:38-26:00] Extensive discussion on updating / refactoring the viewer code, updating the viewer build process, LL’s thinking on moving to more recent graphics APIs (e.g. Vulkan) and the problems involved,
    • Some of this has been covered previously in these summaries (e.g. options for future graphics APIs, the number of users running systems unable to run Vulcan, etc).
    • Much of the discussion is well into the long grass of viewer code, etc., and thus you are referred to the video.
  • [Video: 26:25-37:10] Accessibility options (close captions for when Voice is being used; text to speech, etc).
    • Accessibility is something that is looked at during general UI design work, but there is no project looking at specific questions of accessibility. However, it is recognised that perhaps a more formalised approach to handling accessibility should be adopted.
    • The issue of allowing Voice to be set so that all speakers can be heard equally irrespective of distance from the listener (as once supported by several TPVS, see: BUG-23172) is apparently difficult to implement in the current Vivox implementation and so has been subject to discussions between LL and Vivox.
    • The question was asked if TPVs felt effort should be pushed into a significant Vivox update.
      • A suggested response was given that any attempt to update to Vivox 5 would require a “wholesale change” to the Voice service, LL might be better looking at alternative offerings that offer better means of support.
      • Based on feedback from the meeting, Mojo suggested the keenness for LL to focus on  large Voice related project isn’t there.
  • [Video: 37:43-43:05] Pathfinding:
    • It was suggested that Pathfinding could be improved if the options in the viewer were all moved to a single tab on the Build / Edit floater. LL agreed this would be beneficial and requested a Jira on the idea.
    • LL more broadly noted that Pathfinding could benefit from a re-visit / update, although there are no current plans for any work. Some ideas for potential work have been submitted via BUG-229442. This in turn leads to a broader discussion on some of the additional issues with Pathfinding (lack of cohesive documentation, complexity of use, lack of automatic region rebakes, etc.).
  • [Video: 43:05-46:49] The above flows into a discussion on custom pivot points, some that was being worked on by LL but has been on the shelf of late, and the complexities involved.
  • [Video: 48:15-60:00] A general discussion on land impact calculations and making them more reflective of the cost of rendering (particularly textures, etc.).
    • This touches upon the ARCTan project, which was originally initiated to overall the formulas used to calculate both avatar complexity and the complexity of in-world objects – the latter of which may have led to adjustment in LI calculations, although ARCTan went on to initially focus on avatar complexity prior to being suspended altogether.
    • Folded into this is further discussion of alternate methods of calculating LI (e.g. through object geometry – although this doesn’t necessarily account for draw calls, which tend to be a big hit for the viewer), and ideas for encouraging best practices / finding a balance between control and offering the ability to create and upload.
  • There is further informal discussion after the meeting has ended. Please refer to the video if interested.

 

2022 CCUG + TPVD meetings week #14 summary

Bella’s Lullaby, March 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, April 7th 2022 at 13:00 SLT.
  • The video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) from the Third-Party Viewer Developer (TPVD) meeting on Friday, April 8th, 2022 at 13:00  SLT.

These meetings are chaired by Vir Linden, and their respective dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in each meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:00-1:11 and 2:05-243] + notes from CCUG]

The list below reflects the rest of the currently available official Second Life viewers:

  • Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – No Change
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • MFA RC viewer, update to version 6.5.4.569725, on March 24.
    • Performance Improvements RC viewer version 6.6.0.569349, dated March 14.
    • Lao-Lao Maintenance RC viewer, version 6.5.4.569191, issued on March 11.
  • Project viewers:
    • Performance Floater project viewer, version 6.5.4.569531, March 18.
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The focus is on fixing the bugs reported on the Performance Improvements RC viewer so that it can be the next viewer promoted to de facto release status. The RC version has been updated but has yet to be issued.
  • The Performance Floater project viewer includes the auto-FPS capability that is similar in nature to Firestorm’s Auto Tune capability designed to help maintain a given viewer frame rate (see here for more), and the aim is to try to sync these two approaches up before the Lab’s viewer moves to RC status.
  • The server-side work required for the Legacy Profiles viewer had been deployed, so that viewer should be updated and appearing soon.

Additional Materials Support – CCUG Meeting

Please also refer to my notes from the previous CCUG meeting.

  • The basic idea remains:
    • Providing the ability to import a glTF file with is single material within it containing all the textures / maps and colour parameters for a given face. Exactly which maps (normal, specular, emissive, roughness, albedo, occlusion, etc.) is still being defined.
    • When uploaded, the material then becomes an inventory asset.
    • When the asset is applied to the face of an object, it overrides the texture parameters for that face (diffuse, normal spec maps, full bright, etc.), with the options to edit these parameters in the Build / Edit tool disabled until such time as the material is removed from that face.
      • However, the face-related options – rotation, repeats per metre, offsets, etc., – would remain accessible.
    • This approach would faces to be textured under the existing system and have a materials asset applied so that viewers without the new materials code would render the “legacy” texture parameters for the object face, whilst viewers with the updated code would render the settings specified by material.
  • What is the benefit of this?
    • It moves SL towards proper support for PBR and the improvements that will bring.
    • Very simply put from an end-user perspective: it will help add depth to Second Life by improving the way surfaces appear be giving them improved surface texturing, reflectivity, and so on; and it will no longer require end-users fiddling around with textures and normal / specular maps to achieve something; they’ll have a simple asset they apply to (say) a wall, and that’s it.
  • The first pass of this work will provide support for Adobe Substance 3D Painter, and as such, LL are looking for feedback from creators who use Substance Painter in terms of how they use it, what kind of materials they are creating, and how they would like those materials represented in Second Life, what maps they would ideally like to see supported.
  • A concern raised with this approach is that glTF does not natively support non-PBR workflows, which is a problem for those who use Substance Painter “non-PBR” (such as clothing creators), and this needs to be taken into consideration.
    • One route around this is the suggestion that the materials actually be built at import time, rather than just built within Substance Painter and exported to glTF for import.
  • It was requested that some form of UI element should be added to the viewer to allow material assets to at least be inspected. While this is something that will be provided, it will not be in the first phase of the work.
  • Rendering for these “new” materials will be entirely separate to the existing rendering path for SL’s existing materials system, allowing for a more “industry standard” approach to be used with the new materials.
  • Whether or not a fee is to be charged for importing these materials is still TBD (and somewhat complex, if the importer is to support using texture files previously uploaded to SL, rather than having to import them again).
  • Longer-term the idea is at when PBR support is added, it will only work with these material assets; texture entries will continue to be handed as they are now (as noted above).
    • PBR itself is a complex issue both technically and in terms of content, and it is already envisaged that it will give rise to differing environments in-world (e.g. locations that are “PBR enabled” and require people to be running viewers capable of supporting PBR).
    • This is because SL content being what it is, there is no easy way to “PBR-ify” it all, and gain a uniform (or even desirable) result – particularly where content has been designed under the existing rendering capabilities to produce a specific result.
  • Given the complexities / impact of such a project, LL recognises there is a need to provide the means for ongoing real-time exchange of ideas / gathering creator input.
    • Neither the CCUG nor the SL forums are seen as a good fit for this kind of interaction.
    • The preferred option voiced in the meeting was to use Discord as a host. Server details TBD at this time, if this is selected.

From the TPVD Meeting

  • [Video: 4:41-9:10] It has been pointed out the 30-day validity period for an MFA token seems unusually long, and a request has been made to reduce it.
    • In particular, testing the MFA code and token refresh when looking at the viewer code is more difficult when the tester has to wait a month between tests and checks / retries.
  • [Video: 11:54-20:10] Beq Janus and Vaalith Jinn are working on “temp mesh” – a means to preview mesh and rigged mesh in-world without necessarily having to log to the Beta grid and upload there. As per the video, there are some issues (such as the temporary creation of linksets), but overall it is hoped with work will result in a usable capability.
    • This conversation folds into itself a broader discussion on purely viewer-side rendering (as opposed to rendering asset data coming via the CDN)
  • [Video: 20:12-25:16] Bandwidth setting confusion:  A claim was made the turning up the official viewer’s network bandwidth setting improves texture download speeds for those on faster Internet connections, prompting a request for the default setting being turned up.
    • Given that the network bandwidth setting is supposedly only for UDP messaging, and all assets, including textures, are transmitted via HTTP via CDN(s), some understandable doubt was cast on this.
    • While not ruling out changing the bandwidth setting causing a degree of improvement, Runitai’s thoughts on the matter (through looking at the code) fall into two areas:
      • Any actual delay in texture fetching is more likely to be with some of the background thread handling which has yet to be updated.
      • It is more likely that issues in texture loading / handling may be related to a number of issues, including a) the viewer mistakenly believing it is running out of VRAM (due to some coding errors) and immediately loading / unloading textures on the background threats; b) changes in how texture are actually downloaded and passed to the decode thread as a result of the move to HTTP that may be having an impact.
    • [Video: 28:53-29:35] In respect of this last bullet point above, it was indicated that TPVs tend to handle texture decoding, etc., somewhat differently, this is not believed to be an issue. A request has been made for a TPV to consider making a code contribution on this, so that LL can investigate making similar changes.
    • [Video: 32:53-44:20] Further discussion on texture fetching and the way the viewer code is generally conservative in this area.
      • [Video: 36:41-41:28] (overlapping with the above)] there is a restatement of the concern that raising the UDP bandwidth setting “because higher is better” could trigger a microburst buffer overrun on the server-side routers were the setting to be raised across all viewers. It is believed the servers are fairly well protected, but this needs to be confirmed by the infrastructure team before any such change is made.
  • [Video: 25:55-30:48] VRAM detection / use: changes are being tested (on Windows at present) whereby rather than setting a minimum default for VRAM (512 MB, a long-time sticking point for many users), LL are shifting to having the viewer query the operating system as to how much VRAM is free.
    • As an example of the potential improvement this has given, a system with 10 GB VRAM will see the viewer use as much of that VRAM as is available, whereas previously, the viewer would get up to using around 1.5 GB and then switch to texture paging.
    • Finding a similar solution for Mac system is somewhat more difficult due to the fact the only reliable report OS X provides is on the amount of installed VRAM, not how much may actually be available for an application to use / how much a process is using.
  • [Video: 45:14-47:16] does increasing the bandwidth setting improve teleporting between region?
    • Anecdotally, this appears to be the case for some.
    • However, whether there is a direct correlation between increasing the UDP bandwidth and inter-region TPs improving is hard to prove, although it is possible a message packet related to TPs is hitting the throttle and getting dropped without any attempted re-try.
  • [Video: 49:11-54:43] custom chat ranges: server-side support for extending chat ranges within regions beyond the default 20 metres (seen as useful for venues hosting meetings, presentations, etc.), was deployed some time ago, but is currently only available on Linden-controlled regions.
    • Wider availability of the capability has hit some privacy concerns (e.g. people believing their chat is limited to 20m in a public region being overheard by someone on the other side of the region). As such, the capability is awaiting viewer-side updates that make it clear to people entering regions where the chat range has been extended that this is the case.
    • This information is actually being sent to the viewer (RegionInfo in the RegionInfo 5 block), but the IU to handle it has yet to be added (and TPVs may not have been aware of its availability so they could create their own notifications).

2022 CCUG + TPVD meetings week #11 summary: mirrors! (maybe)

Aurora Falls, February 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, March 17th 2022 at 13:00 SLT.
  • My audio recording and the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) from the Third-Party Viewer Developer (TPVD) meeting on Friday, March 4th, 2022 at 13:00  SLT.

These meetings are chaired by Vir Linden, and their respective dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in each meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:35-3:15 + notes from CCUG]

  • The Performance Floater project viewer updated to version 6.5.4.569531, on March 18th. This viewer includes the Lab’s implementation of automatic adjustments to the viewer to try to maintain FPS. Monday, March 21st: Appears to have either been rolled back, or update to official viewers list was premature.

The list below reflects the rest of the currently available official Second Life viewers:

  • Release viewer: version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – No Change
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • MFA RC viewer, version 6.5.4.569309, issued on March 15.
    • Performance Improvements RC viewer version 6.6.0.569349, dated March 14.
    • Lao-Lao Maintenance RC viewer, version 6.5.4.569191, issued on March 11.
  • Project viewers:
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • It is hoped that those using the official viewer and who are in the Performance Improvements RC cohort (or opt to manually install this viewer) will see noticeable performance improvements in terms of frame rates and fewer viewer stalls, when compared to previous SLV releases.
    • The RC has already seen some new bugs raised against it, and these are being worked on (e.g. BUG-231936).
    • It is still hoped this will be the next promotion to de facto release status, but this hinges on bug fixing and a decision on whether or not to release MFA as a dedicated viewer.
    • It is acknowledged that the work in this viewer and the Performance Floater project viewer needs to be reconciled with the work carried out by Beq Janus of the Firestorm team, whose code will be in the upcoming Firestorm 6.5.3 release.

MFA Viewer

  • Summary:
    • Multi-factor authentication (MFA) is coming to the viewer.
    • As MFA is implemented in the official viewer, there will be a “grace” period to allow TPV adopt the viewer code.
    • During this period, users will be able to access SL on TPVs as they currently do now, regardless of whether or not they have opted-in to MFA.
    • After this “grace” period, all users who have opted in to MFA will be required to authenticate themselves when using any viewer to log-in to Second Life (with the usual 30-day period of valid authentication, as per secondlife.com MFA), but those who have not opted-in to MFA will see no difference in their log-in steps, regardless of whether the viewer they are using supports MFA.
  • The RC version of the viewer, version 6.5.4.569309, was released on March 15th. This appears to have an authentication bug – BUG-231938 – related to how pass codes are parsed by the viewer.
The MFA RC viewer prompts those who have opted in to SL’s MFA capability to provide an authentication code / key (once every 30 days) in order to log-in to SL
  • [CCUG meeting] The decision has yet to be taken on whether to maintain MFA as a dedicated viewer update or possibly merge it with another RC viewer (e.g. the Maintenance RC) to streamline the number of active viewer versions and the QA process.

Mirrors! (Maybe)

[Video: 4:05-16:29]

  • In-world mirrors that reflect that reflect their surroundings – including avatars – have long been a requested capability in SL. Over the years, various attempts have been made to fake mirrors, such as using Linden Water and static photographic sets, though to “cheating” using projectors (albeit sans reflecting avatars) and the old means of duplicating sections of a build and inverting it so it appears to be reflections on a polished floor.
  • In 2014, Zi Ree of the Firestorm team developed a means of generating real time reflections, including avatars, within the viewer, and produced a video on the idea. At the time, due to various reasons (most notably the impact on performance), LL decided mirrors could not be supported, which has tended to remain their position since.

  • However, Mojo Linden (VP of Engineering) is now prepared to consider possibly enabling some implementation of mirrors in SL, although how this might be done is open to discussion, particularly as the potential for a massive performance impact is still very much a concern.
  • Suggestions made by Mojo on how this might be done included:
    • To have user-initiated “mirrors” (that is, there are “mirror” objects in a space, but the rendering of their “reflections” is only triggered for a viewer based on something like their proximity to the object).
    • To possibly limit mirrors in terms of what they reflect (such is things that are directly in front of them, rather than much further in the background or only render avatars with the background left white.
  • In terms of “triggering” mirrors, there was discussion on whether this should be automated or with user-controlled input:
    • Automated within the viewer:
      • The viewer detects the “mirror” object based on proximity, per above & renders the reflections. Discussion on this included the ideas that there could also be a Graphics preference option to completely enable or disable all mirror rendering by the viewer and a slider / drop-down to set the overall quality of the rendering of reflections (as is we already have for graphics quality (slider) and water reflections quality (drop-down)).
      • Automated via LSL (setting / unsetting flags on objects that trigger “reflection” rendering) or possibly using the interest list.
    • User controlled input: reflections are toggled in a manner similar to Media On A Prim: the user touches the “mirror” surface  and “reflections” are rendered only by their viewer – although this seems clunky / immersion breaking, even if it is an approach taken by games such as Cyberpunk 2077.
  • One suggestion from those at the meeting was to take the Linden Water planar reflections (which are rendered anyway, whether the Linden Water is visible or not) and render them at a lower resolution in screen space.
    • Using the Water planar could help with things like reflective floors, mirror walls, etc., although screen space rendering in SL can be subject to clipping.
    • Screenspace reflections (SSR) have appeared in some TPVs – like Firestorm and Niran’s Viewer, but how well these work is open to question – for Firestorm, there were issues with the release of materials that resulted in the code being removed.
    • One  suggestion make for limiting performance impact was to limit the viewer to rendering only the nearest mirror surface and either use SSR for the remaining mirrors or, don’t render them at all
  •  A lot depends on potential use-cases, and whether expectations can be managed – as there is a potential that any solution will not be able to meet all requirements, simply because of the risk of performance impact.
  • Everything on mirrors is purely at the discussion stage right now and there is currently no formal project – and indeed, there might never actually be any project to implement mirrors; however, that the topic is being discussed by LL marks a significant shift in thinking.

In Brief

From the Content Creation Meeting

A lot of general discussion on a number of topics, none of which is currently the focus of any Lab project, including:

  • Using physics to allow more “wiggling parts” – such as ears, etc., – on mesh avatars: a lot of this would come down to positioning the most suitable bones and rigging to them.
  • Controlling / ordering joint position overrides (BUG-231904 / BUG-231579): this is currently handled by mesh UUID – which can be random from the POV of the user. However, trying to order using the order things are added to an avatar could lead to race conditions, as the outfit system doesn’t have any concept of prioritising attachments, therefore a more structured schema – such as adding a specific field that could be set for objects – but even this could have conflicts and also likely to be a non-trivial piece of work.
  • Expansion of supported upload formats for mesh (e.g. glTF) and use of techniques such as PBR, with a stated preference (from creators) for SL handling of reflections / reflectivity to be overhauled before any attempt is made to add PBR support.
  • Expanding Bakes on Mesh to support materials – which as noted over the last several meetings would require a significant update to the Bake Service, which LL is not planning on doing in the foreseeable future.
    • A further complexity here is managing the proper ordering of the additional maps. Example: some users may want their shirt partially blended with their bra / vest normal; others might want their shirt to cover their bra /vest normal map whilst others may not want their bra / vest to have a normal at all; so how can these three states be collectively handled in terms of layering?
  • Further discussion on terrain – which is the subject of a project for 2022, although there is some split about increasing the texel density / increasing the resolution/repeats (and thus reducing the blurriness) + allowing normal maps, or allowing more in the way of mesh terrain (heightmaps, etc.).
    • Another request for terrain has been to allow greater compositing of textures (e.g. for more graduation in changes of textures by height or offering greater depth to terrain by layering-up textures.
    • A further request has been to allow terrain painting – e.g., being able to “paint in” dirt patches on grass, etc.
  • A request for a scripted means to apply EEP settings to oneself beyond the inventory Apply to Self such that (as an example), you buy a pair of sunglasses or tinted goggles, and they apply EEP setting that make your surrounding look darker. This would require a means to read and apply the contents of an object,

From the TPVD Meeting

  • [Video: 16:31-27:45 and 28:58-42:30] A broad-ranging discussion on the viewer build process and tool chain, moving to more recent graphics APIs (the likes of Vulkan and Metals are under consideration), resource utilisation within the Lab, future work on improving the viewer’s threading capabilities, etc.
    • Outside of the ongoing (/periodic) tool chain updates and graphics API investigations, none of discussion points are subject to any immediate / near-term project.
    • It was again pointed out that a issue in considering replacements for / alternatives to OpenGL is that a lot of users run older PC harder which is incapable of running more recent APIs like Vulkan.
    • As most of which will likely only be of interest to viewer devs, please refer to the video.
  • [Video 42:44-43:28] ARCTan project and Legacy Profiles:
    • Initiated in 2020, ARCTan is an attempt to re-evaluate both avatar rendering costs and the cost of in-world scene rendering, with the initial focus on avatar rendering cost / impact, itself running on two tracks:
      • Developing a new UI element in the viewer pull together information from various menus / debugs to display useable information on avatars / attachments that are heavy in rendering cost, and what can be done.
      • Gathering data with the intent to revise and improve the actual formulas used for calculating avatar complexity, making them more relevant.
    • ARCTan effectively went into hibernation as a singular project in the latter part of 2021, and is currently awaiting development bandwidth.
    • [Video 45:09-46:05] One of the issues with ARCTan was being able to pull together the data in a fine enough detail to make any UI used to make changes worthwhile. Beq Janus has tackled a lot of this work for the upcoming Firestorm release, and this is liable to be fed into projects like ARCTan and the Lab’s own work in improving viewer performance and making options visible to users.
    • Legacy Profiles is a project to move avatar profile information back into the viewer and away from using web pages. There is project viewer (see the list at the top of this article), but it has been awaiting some back-end server work to be completed, and it is hoped that the project will be moving forward “Soon™”.
  • [Video: 43:54-44:44] CEF: Chrome Embedded Framework (CEF) is the API used to manage media in SL. The SL version is now running several releases behind the current CEF version, and while a need to update has been noted, it is liable to require some significant work (e.g. updated UI elements as well as under-the-hood changes).
  • [Video 46:05-end] miscellany text conversations, mostly on the topics noted above.

2022 CCUG and TPVD meetings week #9 summary

Ravenport Reclaimed, February 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, March 3rd 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
  • My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, March 4th, 2022 at 12:00 noon SLT.

This is a summary of the key topics discussed and is not intended to be a full transcript of either meeting in its entirety. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:41-2:10 and 7:41-9:00 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

  • Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – NEW
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
  • Project viewers:
    • Performance Improvements project viewer version 6.6.0.567604, dated January 24.
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The release of the Maintenance J&K RC as the de facto release viewer should see crash rates reduced for those on the official viewer (and hopefully for TPVs as the code is adopted).
    • This is the first official viewer to by built using Python 3.x.
    • It includes a fix intended to prevent the updater falling over on Mac OSX.
  • The Performance Improvement viewer is still awaiting RC release, this is pending some final bug fixing.
    • [CCUG Meeting] The Performance Improvements viewer bumps the feature table version number. This means that those placed in the cohort when it goes to RC status will see their custom graphics presets reset (as will anyone else switching to it during RC and when it gets to release status).
  • [CCUG Meeting] It appears the Mesh Optimiser viewer has a bug that is causing it to re-order triangles in an upload. So, if an explicit ordering is contained within a Blender export (e.g. for alpha sorting, for example), the Mesh Optimiser will effective destroy the ordering when running the LOD optimisation on upload. It’s not clear on how widespread the issue might be, as it has only been reported with alchemy-next thus far.
  • [CCUG Meeting] the definitions for “Low”, “medium” and “high” on the graphics slider are being redefined within the Performance Floater project viewer. This will also see the number of non-imposter avatars set on a per detail level, rather than being set to 16 across the board.
  • [CCUG Meeting] the benchmark for determining low-end systems is being adjusted to better reflect the number of uses coming into SL using low-end GPUs.

MFA Viewer

[Video: 9:12-13:42]

  • Summary:
    • Multi-factor authentication (MFA) is coming to the viewer.
    • As MFA is implemented in the official viewer, there will be a “grace” period to allow TPV adopt the viewer code.
    • During this period, users will be able to access SL on TPVs as they currently do now, regardless of whether or not they have opted-in to MFA.
    • After this “grace” period, all users who have opted in to MFA will be required to authenticate themselves when using any viewer to log-in to Second Life (with the usual 30-day period of valid authentication, as per secondlife.com MFA), but those who have not opted-in to MFA will see no difference in their log-in steps, regardless of whether the viewer they are using supports MFA.
  • The viewer-side code is currently going through QA. If is passes, it is hoped it will surface in week #10 (commencing Monday, March 7th).
  • However, the decision has not yet been taken as to give it a dedicated viewer, or to merge the code into the next upcoming Maintenance RC viewer.

In Brief

From the Content Creation Meeting

  • Viewer project work: the focus is on getting the Performance Improvements viewer stabilised and promoted to RC status (and thence to de facto release). After this, it is not clear what may come next, the options being:
    • Clearing the current backlog of project viewers.
    • Further viewer-side performance improvement work.
    • Additional maintenance viewers.
    • Other work still in early planning.
  • Further materials / Bakes on Mesh (BoM) Discussion:
    • Materials support for Bakes on Mesh is commonly requested, but there are several impediments to this (e.g. the Bake Service would require significant update just to be aware of materials; there needs to be a means to define how materials should be ordered during compositing, how alpha channels are properly managed, etc.).
    • It was asked by LL if things might be improved with just the introduction of a new wearables type, capable of allowing a single materials map to be worn per outfit / look.
    • Cathy Foil has also demonstrated a possible approach – although this also requires some significant updates to SL, as well as work being carried out externally to to the platform by content creators – see the video below (originally produced as a demonstration for the Lab).

    • Before committing to considering any materials / BoM work, LL would like to see a properly scoped design documents explaining what is felt would be required (including supporting protocols, etc.), and how it might work.
  • BUG-225519 “Mesh Uploader] Add option for automatic convex hull physics shape”.
    • This was a subject of discussion at the previous CCUG meeting, the request calling the provision of simpler physics shapes to be available for use when uploading a mesh than are currently available – the simplest being a “cube” mesh physics asset. This is something Firestorm already provides:
Physics models offer through the Firestorm mesh uploader – the shapes being continued within the viewer for application. Credit: Beq Janus
    • The question was raised as to what to do when uploaded multiple mesh objects, and the physics shapes don’t match the expected number (so four when uploading 5 objects, for example). The consensus at the meeting appeared to be to use whatever is defined as the default physics shape within the file itself.

From the TPVD Meeting

  • [Video: 2:17-5:44] The Lab is considering moving the time of the TPVD meeting and adjusting the frequency so as to avoid running back-to-back (so to speak) with the Content Creation meetings, which inevitably leads to a lot of repetition between two meetings held less than 24 hours apart.
    • The straw poll of attendees pointed towards the meeting having a later start time than the current 12:00 noon. Exact time TBC.
    • There will be a move to try to have TPVD meetings on alternate weeks to the CCUG meeting.
  • [Video 6:10-7:23] During the log-in process, a series of flags are set on logging-in to SL, including one called “Gendered”. This apparently meant something in the past, but since around the time of the introduction of Viewer 2.0 (2010), it has effectively been ignored. LL are therefore looking to possibly pull the code relating to it, but wanted to make sure there are no TPVs using it for some reason before doing so.
  • [Video 13:54-17:14] The question was floated on the animation poser code contributed several years ago by NiranV Dean from his Niran’s Viewer, and whether it would be appropriate for TPVs to implement it if LL is not going to.
    • The Lab’s view is that the code does not support the “shared experience”, in that poses are only seen by the user setting them, nothing is sent to the simulator for over viewer to see. This requires additional code to overcome.
    • Currently, LL is planning some other work “related to avatar posing the movement”, and it is possible the poser code might get folded into that work.
    • While, in principle, there are no objections to other TPVs implementing the code, they would have to do so on the basis that the code only allows the user’s own avatar to be posed, and not extended to posing other avatars (which would not be seen by the users of those avatars).
  • [Video 17:28-32:00] There have been some recent overlaps / crossed lines in aspects of viewer work between Linden Lab and TPV. As a result the question was raised by the Lab as to what could be done to improve communications between TPV and LL and vice-versa to avoid future misunderstandings.
    • One suggestion was to make the TPVD meetings more of a two-way discussion in terms of what both the Lab and TPVs are working on, etc., particularly if appropriate action points could be produced when required.
    • Another suggestion was to have the Lab create a secure sandbox environment in which they could gain greater familiarity with TPVs and their capabilities as a part of their own work time (policy dictates – with good reason – LL employees are only allowed to use TPVs on systems and accounts that have no direct association with the Lab).
    • An alternative to the above that was offered would be for LL staff to peek into the support groups, etc., run by TPVs to get an understanding as to what users are asking for, and what is being responded to.