2022 TPVD meetings week #23: PBR materials; textures

Village of Ahiru, 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, June 10th, 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: 1:23-2:39]

There have been no viewer updates through the week, leaving the current list of public official viewers as:

  • Release viewer: version – formerly the Performance Improvements viewer, dated May 25th – 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).
    • Nomayo Maintenance RC (Maintenance N) viewer, version, June 1.
    • Makgeolli Maintenance RC viewer (Maintenance M) viewer, version, May 12.
  • Project viewers:
    • Performance Floater project viewer, version, May 10.
    • Mesh Optimizer project viewer, version, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version, dated October 26, 2020.
    • Copy / Paste viewer, version, dated December 9, 2019.

General Viewer Notes

  • The Performance Improvements viewer has had a couple of “significant issues” raised against it, which are being pulled into the Maintenance RC channels for resolution. One of these might be BUG-232200 (extreme mouse sensitivity based on DPI), although no specifics provided at the meeting.
  • The Legacy Profile project viewer (finally) looks like it may be getting some attention in the near future, in the hope it can move forward to RC status at some point.

Additional Materials Support / PBR

[Video: 2:58-5:28]


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

Two area of work are currently in progress.

  • 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).
  • 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).

Current Progress

  • Simulator-side support for reflection probes is being added, together with updates to the EEP system in support of the changes. This work is being implemented so that (hopefully) viewers without the necessary rendering updates will not see any “breakages” to the environment as the simulator work progresses through Aditi to Agni.
    • These updates are currently on Aditi on the DRTSIM542 channel (Materials 1, Rumpus Room, Rumpus Room 2, Materials Adult).
  • LSL support for this work still TBD.
  • There is now a test version of the viewer for the materials work available through the SL Discord server #content-features channel.
  • A glTF importer will “hopefully be ready in the next week or so”, although it will be a work-in-progress,

Texture Rendering Improvements

[Video 5:30-18:15]

  •  There is a texture streaming overhaul in progress. This changes the number of threads used in texture decoding and how the decoding on the background threads is handled, and should see a noticeable improvement in texture rendering when available & incorporated into viewers.
    • This work will likely be available ahead of the materials work mentioned above, but it has not been determined if it will form a dedicated project / RC viewer or be folded into a Maintenance RC.
    • TPV developers who may have been working recently on the texture threads, may want to take note of this and listen to this portion of the video, given that a number of threads have been removed o eliminate conflicts.
  • Part of this work is focused on trying to get a “good honest answer” from the operating system running the viewer as to how much video memory is actually free for the viewer to use.
    • In general (and despite the VRAM slider) the official viewer typically uses between 512 MB and 2GB of video memory (when available on a system), but runs into trouble trying to balance using anything over 512 MB with the 512 MB “limit”, thus causing issues of texture thrashing.
    • This work will likely see the removal of said slider as well.
  • Once completed, these changes should see the viewer work more “cooperatively” with other applications running on a client system:
    • As video memory is required by other programs, to the viewer will relinquish it; as video memory becomes available, so the viewer will attempt to use it.
    • As video memory is relinquished, the viewer will attempt to “intelligently” unload textures – such as those in the background/occluded, those far away, etc., to reduce the amount of visible texture blurring / unblurring as textures are unloaded /reloaded.
  • This work will hopefully benefit the viewer across all operating systems, although there are issues around getting Mac OS to report the amount of free video memory, and AMD GPUs are also proving a little difficult in their reporting of memory use.
  • The structure being used for the Windows enquiries can be found here.

In Brief

  • [Video 22:50-27:52] Discussion on alpha masking on avatars / rigged mesh, including reports on some content with transparent rigged meshes appearing broken as a result of changes to the draw order.
    • A lot of the reported breakage appears to be the result of creators “cranking the handle” to achieve results, without actually fully understanding either what they are doing or how the viewer’s rendering system works.
    • The changes being made now are part of trying to make the draw order more logically consistent with a view “maybe someday” being able to explicitly set the ordering priority for the draw order.
  • [Video 28:11-36:00] Advanced Lighting Model (ALM) vs. non-ALM (aka “forward rendering”). LL are strongly leaning towards getting rid of the non-ALM rendering path, providing it can be shown that this does not adversely impact performance (e.g. ALM runs roughly as well as non-ALM for those using the latter) on the broad cross-section of hardware most commonly operated by SL users.
    • This may raise concerns among the minority on metered connections (as it will increase the amount of data crossing their network in handling materials, etc.), so consideration is being given to including a “data saving mode” into ALM that will prevent the sending for materials data.
    • Another problem is that of general education. A lot of people still think that enabling ALM means they “must” run with shadows enabled (which does cause a significant performance hit), without realising they can disable shadows from Preferences → Graphics the Shadows drop down. De-coupling automatic shadows enabling from ALM may help rectify this.
    • Similarly, local lights can be a performance hit with ALM as the number can be unlimited, as opposed to the cap of six rendered lights under non-ALM rendering), so the suggestion is to have a slider to allow the user define how many local lights are rendered in their view under ALM.
    • [Video: 38:22-39:48] removing the non-ALM rendering path would also mean the removal of the Atmospheric Shaders checkbox, the avatar cloth checkbox (which user generated content cannot access anyway), the Bump Mapping and Shiny (low, medium high) drop-downs,
  • [Video: 36:10-40:04] The Performance Improvements Floater viewer (still at Project viewer status at the time of writing, and not to be confused with the Performance Improvements viewer now at release status) makes some changes to graphics pre-sets:
    • The object mesh detail is not always set to Low (as per some TPVs already).
    • Changes to max no of non-impostor avatars is based on the graphics quality slider.
    • The core benchmarking for setting all pre-sets has been revised.
    • This work is all part of the “auto-FPS” improvements that for a part of the Performance Improvements Floater viewer.

Date of Next Meeting

Friday, July 8th, 2022.



5 thoughts on “2022 TPVD meetings week #23: PBR materials; textures

  1. I listened to the
    [Video 28:11-36:00] Advanced Lighting Model (ALM) vs. non-ALM (aka “forward rendering”) twice. I’m on a 2 year old MacBook Pro and my frame rate drops in half with ALM on, why is that a good thing? And I have shadows off. Per Apple’s latest event [last Monday] the mbp is the second best selling lap top in the world so why do they want to cut the frame rate in half?


    1. As per the video / notes – LL are only going to move in this direction providing it doesn’t unduly impact performance, and a lot of work is going into trying to improve the viewer’s overall performance (Performance Improvements Viewer, Improvements Floater viewer, etc). As Runitai mentions, the aim is to have ALM offering a similar performance to non-ALM for those reliant on the latter. Obviously, we have no idea how everything will work out long-term; and depending on how things go, these improvements made to the viewer in the interim may reduce the impact or the Lab may not go this routine. Again, it is a direction they are strongly leaning towards, not something (as yet) that will happen.


    2. Best selling does not necessarily mean best graphics – most people use Apple laptops for work on documents and 2D graphical work – anyone in design pretty much uses an Apple laptop because the team they work for bought it for them, so of course those numbers are going to be high. However, modern gaming PCs can be built for very cheap, and even my 2 year old gaming Dell laptop is able to render ALM with only a 10% frame rate drop.


    1. It was noted in the meeting that any change to force ALM on would be tied to removal of the forward renderer code (which internal testing has shown that proved beneficial to ALM performance), and a more general “optimization pass” would be undertaken on the deferred renderer (the ALM renderer), which is also expected to increase performance.
      TLDR; You can’t use the current release viewers as a benchmark for the (proposed) upcoming changes.


Comments are closed.