2024 week #43: SL TPVD meeting summary

Grauland / Primary Colors, September 2024 – blog post

The following notes were taken from my audio recording + the video recording by Pantera (embedded at the end of this summary) of the Third-Party Developer meeting (TPVD) held on Friday, October 25th, 2024. My thanks to Pantera as always for providing it.

Meeting Purpose

  • The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month on a Friday, at 13:00 SLT at the Hippotropolis Theatre.
  • Dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
  • The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers Status

[Video: 0:00-2:30]

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

Upcoming Viewers

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

WebRTC

[Video 2:31-4:20]

Summary

  • The replacement of the Vivox Voice service and plug-in, with the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
  • Key benefits:
    • WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
    • Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
    • Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.

Status

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

Graphics Work

[Video: 5:28-end]

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

In Brief

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

Next Meeting

† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.