2022 TPVD meetings week #23: PBR materials; textures

2 weeks ago 12
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 6.6.0.571939 – 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 6.6.1.572179, June 1.
    • Makgeolli Maintenance RC viewer (Maintenance M) viewer, version 6.5.6.571575, May 12.
  • Project viewers:
    • Performance Floater project viewer, version 6.5.4.571296, May 10.
    • 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 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]

Summary

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

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

Published by Inara Pey

Eclectic virtual world blogger with a focus on Second Life, VR, virtual environments and technology.

Post navigation

Read Entire Article