Tag: TPVD meetings 2022

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.

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.
  • [Video: 30:53-31:55] This viewer also includes a fix for handling object occlusion.
• 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).