2022 CCUG meeting week #26 summary: materials + graphics update

The Pond, May 2022 – click any image for full size

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, June 30th 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

One Wednesday, June 29th, The Maintenance M(akgeolli) RC viewer, version 6.6.1.572458 was promoted to de facto release status.

No changes to the rest of the official viewers through until Thursday, June 30th, leaving them as:

  • Release channel cohorts:
    • Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
  • 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.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this project.

Outline of Work

  • Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
    • 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).
    • It applies to both PBR generated content, once available, and to legacy content.
  • Creating a materials type with an associated inventory asset. This  will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.
  • Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
  • The initially supported capabilities are:
    • RGB albedo + transparency.
    • RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
    • RGB emissive.
    • RGB normal (- alpha).
    • Double-sized supported (disables backface calling before issuing the draw call).
    • Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
  • In addition:
    • There will be an ability to “preview” materials on an item within your own viewer (similar in nature to Local Textures) before actually uploading them.
    • LSL support is still being defined, but should at least allow individual texture UUIDs to be replaced under script control.
    • The approach being taken is to may the system extensible so that further capabilities / plug-ins / options can be added with relative ease in the future.
    • However, Displacement maps will not initially be supported due to not being defined in the core of glTF 2.0; nor will any extensions that are not adopted into the core glTF standard (either glTF 2.0 or 3.0).
  • Test Windows viewers for the on-going work are available within the #content-features channel of the Second Life Discord server (join the server and request channel access here) for content creator testing and feedback.

Materials Progress

Screen Cap from a video by Runitai Linden showing (l) the basic PBR Materials UI, and right, materials assets in inventory, which can be dragged / dropped onto objects / object faces in-world (centre)
  • There is further work required on the back-end inventory services and asset store, and on some of the shaders in the viewer, before any of this work is ready for public testing on Aditi.

ALM Proposal / Work – Recap

At the #week #23 TPVD Developer Meeting (notes here), it was indicated that LL are “leaning” towards removal of the non-Advanced Lighting Model (ALM) (aka “forward rendering”) rendering path from the viewer, leaving just ALM rendering (aka deferred rendering”).

  • Were this to be done, it would only be done if 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.
  • The work will include:
    • A slider to manage the number of rendered local lights to lightening the load of rendering illumination on lower specification systems.
    • A “data saving mode” primarily intended to help those on metered connections by culling the download of additional materials / PBR maps and potentially downloading lower resolution textures mips, all of which will reduce the data passing over their connections. However, it will result in a much poorer visual experience once the PBR work has been implemented, and the hope is the mode will only be used in the minority of cases.
  • Given the ongoing work to support PBR and a more rounded set of materials, moving to deferred (ALM) rendering without fallbacks to non-ALM rendering – providing, again, the caveats noted above can be met / implemented – will in general help ensure a more reliable / consistent viewing experience across a broad range of hardware.

In Brief

  • The work to make full use of available video memory on a client computer is being put out to a hardware compatibility lab to help ensure the code changes are doing what they are supposed to be doing on a wide variety of hardware. These tests will also look at the impact of running the viewer with ALM active all the time across all hardware configurations.
  • On Animation:
    • The Puppeteering project highlighted at Grumpity and Mojo Linden’s Meet the Lindens session came in for criticism, but it was suggested people give the system a chance to reach a more advanced stage before judging, as the video presented in the talk does not do the work justice.
    • Vir indicated that while there is an understanding at the Lab that people would like the animation system overhauled:
      • Such a project currently isn’t on the roadmap
      • However, consideration is being given to allowing an on-the-fly adjustment of animation priorities.
      • Requests for additional animation work were requested via Feature Request Jira.
    • Runitai Linden suggested that as glTF supports animations it might – in the future – be a possible option for animation improvements. However, note that moving in this direction is also not part of the current roadmap.

Next Meeting

  • Thursday July 7th, 2022.

2022 CCUG meeting week #24 summary: Materials, ALM

Luane’s World, May 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, June 16th 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

No changes to the list of official viewer through until Thursday, June 16th, leaving them 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 Status

  • Bugs are still being ironed-out of the release version of the Performance Improvements viewer.
  • It is hoped the Legacy Profiles project viewer will start to move forwards once more.
  • There’s a further dedicated graphics project viewer in the wings, which may be appearing in the near future.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this work, with notes specific to the reflection probe work available in my week #22 and week #20 meeting summaries.

Outline of Work

  • Work on an implementation of reflection probes which can be used both with PDR shading and with legacy content.
    • 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).
    • It applies to both PBR generated content, once available, and to legacy content.
  • Creating a materials type with an associated inventory asset. This  will initially comprise the ability to copy a texture entry (with its specific parameters) to inventory, to be followed by initial work to work implement a PBR graphics pipe in the viewer.
  • Test Windows viewers for the on-going work are available within the #content-features channel of the Second Life Discord server (join the server and request channel access here) for content creator testing and feedback.

Reflection Probes Progress

  • Simulator-side support for reflection probes has been on test using an experimental view and simulator-side updates available on Aditi through the DRTSIM542 channel (Materials 1, Rumpus Room, Rumpus Room 2, and Materials Adult).

Materials Progress

  • Prototype Materials editor

    Work is continuing on glTF materials import, and the hope is to have something that is functional within “the next week or two”. This uses the same unpacking mechanism as Unreal 4.

  • Materials will be uploaded with an additional editor (shown right), which will allow some manipulation and delivery the materials as an inventory item when uploaded.
  • Supported textures / capabilities:
    • RGB albedo + transparency.
    • RGB Occlusion/Roughness/Metalness: R = occlusion, G = roughness; Blue = metalness.
    • RGB emissive.
    • RGB normal (- alpha).
    • Double-sized supported (disables backface calling before issuing the draw call).
    • Two-sided lighting (so if the back of a triangle is visible, it flips the normal around).
  • Functionality not initially supported will be the ability to change the UVU wrapping Mode (so everything will sill be repeat); no ability to change the metification / magnification filter per texture;
  • The process separates the materials from the mesh, so the materials can’t know if things like tangents are present.
  • Texture will initially have to be packed by a creator’s preferred toolset; once the project gets to a state of polishing, the importer should re-pack the textures itself, unless importing from a non-glTF source, in which case self-packing will still be required.
  • Normals will likely be MikkTSpace, as per the glTF specification, but work needs to be done to see if supporting this could lead to clashes with the current normal maps rendering. This does mean that current Normal maps will not work on PBR materials.
  • Uploads will be L$10 per texture, so L$40 if all four used.
  • Brad Linden is working on getting the import into inventory working.

ALM Proposal / Work

At the #week #23 TPVD Developer Meeting (notes here), it was indicated that LL are “leaning” towards removal of the non-Advanced Lighting Model (ALM) (aka “forward rendering”) rendering path from the viewer, leaving just ALM rendering (aka deferred rendering”).

  • This was triggered as a result of a bug report which initially appeared to suggest the Performance Improvements viewer unintentionally alters the render order of object faces. While it later proved that the issue was more an edge-case in the way a piece of content had been created, efforts to try to correct it and to ensure it rendered as desired in both ALM and non-ALM rendering, raised the question as to whether it would simply be easier to remove the non-ALM path.
  • Were non-ALM rendering to be removed from the viewer, it would:
    • Only be done if 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.
    • Include a slider to manage the number of rendered local lights, as these are unlimited under ALM but can cause performance issues on low-end systems; thus a slider will help those on lower spec hardware to determine how many local lights they wish to have rendered.
    • Likely include a “data saving mode” that will prevent the download of materials for those on metered connections (to reduce the amount of data crossing their connection) and / or help those who find that materials loading can impact performance. This will have a UI warning that when employed, some objects may not look the way they are supposed to look.
  • In terms of the last point above and “data saving mode” the focus is currently on how many users would need it *if* the Lab goes forward with the idea. This will help determine how much the mode is needed and how best to approach it.
  • Given the ongoing work to support PBR and a more rounded set of materials, moving to deferred (ALM) rendering without fallbacks to non-ALM rendering – providing, again, the caveats noted above can be met / implemented – will help ensure a more reliable / consistent viewing experience.

Rigged Attachment Render Order

In terms of render order of object faces on rigged meshes, LL are considering adding a “render order number” that can be used by creators to ensure the orderly rendering of faces for transparent rigged attachments (thus allowing pre-loading of textures on “invisible” faces, etc.).

  • This would hopefully overcome issues of implicit render ordering (which may change due to other viewer dependencies), and of interpretations of the rendering order by creators that can lead to the kind of issue noted in the ALM discussion above.
  • There are complications in attempting this -e.g. render order is not per object, but per mesh, and is part of an overall schema for rigged attachments (attach order, linkset order, face index order); questions around overall outfit changes, where multiple attachments are being made, etc.
  • Providing such an approach does not break masses of existing content, it would allow creators to continue to use the implicit ordering (and risk odd behaviours should LL make changes in the future that affect the order), or use the ordering system to explicitly set the order, no matter what changes might occur down the line.
  • None of this work should impact the attachment order, but could significantly reduce the number of avatar draw calls.

Next Meeting

  • Thursday June 30th, 2022.

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

 

2022 CCUG meeting week #22 summary: reflection probes update

Deer River Spring, April 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, June 2nd 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

  • A new Maintenance RC viewer – Maintenance N, code-named Nomayo – version 6.6.1.572179 – was issued on June 1st. The viewer should offer improvements on media playback of web content, etc.

The rest of the official viewers remain as:

  • Release viewer: version 6.6.0.571939 – formerly the Performance Improvements viewer, dated May 25th – NEW.
  • Release channel cohorts:
    • 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.

Reflection Probes

Additional information available within my week #20 CCUG meeting summary.

  • A reflection probe will be a sphere or cube (mesh, prim or sculpt) set within a scene with specific properties allowing it to create a cube map of all objects within its bounding box. Anything within that bounding box with a “reflective” (shiny) surface (with the possible exception of worn attachments) will then offer “reflections” based on that cube map.
  • Cube maps for probes are a purely viewer-side artefact, and are updated approx. once every 30 seconds at 60 fps, although this will “get smarter” in the future and be based on actual probe location (e.g. in or out of the current field of view, etc.).
  • So, think of probes as mapping where reflections should be coming from in a scene, not as a tool for deciding which object should be reflecting things.
  • The viewer will hopefully be able to handle up to 256 probes at any one time (the number of probes in a region can be unlimited), each with a (current) maximum effective draw distance of 64 m.
  • Probes will:
    • Be detected by the viewer on load, much like lights already are (reflection probes use a lot of the code originally developed for light state management), with revisions to prevent issues associated with lighting such as flickering.
    • Have an influence volume, an ambience setting (which overrides the environment ambience) and a “near clip” parameter to help control what is rendered into the cube map (e.g. so items close to the centre of the probe and which might otherwise dominate any generated reflections, are not rendered into the cube map).
    • Require “PBR enabled”, and when this is set, legacy objects using glossiness and / or environment shine will render the reflection generated by a cube map respectively in accordance with the degree of glossiness / the sky environment, as well as any objects using the upcoming PBR materials.
      • There are a lot of nuances with the above bullet point such that legacy content won’t simply “work” with reflection probes, some degree of adjustment on object glossiness / shine might be required.
    • Work independently of LOD.
  • Probes will not be designed for use as attachments.
  • The work at the moment is getting things to a basic state of “feature complete” such that a formal test viewer can be offered publicly for detailed testing on Aditi, and feedback taken on improvements / changes / additions.

In Brief

  • Custom pivot point work: currently awaiting simulator updates & will require viewer-side changes; the focus is slowly moving towards trying to move the latter part of the work forward “in the not too distant future”.
  • It was noted that the mesh optimiser (as in the current release viewer) still has issues that need to be addressed,
    • One such issue is when the LOD generator is implicitly asked to simplify a model, and it cannot hit a target without destroying UV seams, it will destroy the UV seams (whereas GLOD will delete triangles, leaving holes in models). This appears to be happening on models with a lot of UV islands, resulting in texels becoming visible when they should never be drawn.
    • LL acknowledges that neither the optimiser issue nor the GLOD issue are ideal.
    • Issues with the mesh uploader are requested via Jira with objects included, if possible.
  • In response to a question, LL currently have no plans to alter the LI calculations for Animesh, however, with the performance improvements (and given part of the LI “penalty” was to compensate for the performance hit of animating Animesh characters), there is a suggestion it should perhaps be re-visited, particularly given most at the meeting with an opinion felt the 15LI penalty was a “blocker” to developing Animesh content.
  • The above points led to a general discussion on LODs, decimation, Land Impact based on size, the ARCTan project (still something LL would “like to get back to”), the impacts of draw calls over poly counts, etc., but with no actionable points raised.
  • There is a fork in the texture rendering pipeline underdevelopment that should, once available, ensure that only the required texture resolution is loaded when it is required (e.g. so the tiny buttons and the little broach and the earring etc., on an avatar won’t all be displayed at 1024×1024 all the time, but the system will only ever download at use a 128×128 version of the textures used).
  • Work is also in progress to ensure the official viewer uses all available video memory. This will eventually see the VRAM slider in Preferences → Graphics vanish.
    • Note that this is available video memory – not necessarily the total on your system; obviously, running SL and multiple browser tabs and other windows will impact how much memory the viewer can actually access, leading to the potential of textures being uploaded.

Next Meeting

  • Thursday June 16th, 2022.

2022 CCUG meeting week #20 summary: reflection probes update

Lemon Trees Mediterranean – 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 19th 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 18th, the Performance Improvements RC viewer updated to version 6.6.0.571869.

The rest of the official viewers remain as:

  • Release viewer: version version 6.5.5.571282, – formerly the MFA RC viewer, dated April 26, promoted Wednesday, May 4th – Non change.
  • Release channel cohorts:.
    • 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.

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this work. In summary:

Three core elements of work:

  • 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.
    • 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).
    • It applies to both PBR generated content, once available, and to legacy content.
  • 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, to be followed by
  • Initial work to work implement a PBR graphics pipe in the viewer.

Reflection Probes

  • Additional information available within the week #18 CCUG meeting summary.
  • This work is close to feature complete.
    • The viewer gets to work with 256 reflection probes, which take the form of spheres or boxes within a region.
    • Anything within a sphere or box will receive reflections from the cube map rendered from the centre of the sphere / box.
    • Some of these probes will be automatically placed in open areas of land where there are objects, etc., by the viewer.
    • Additional probes can be created by users using prims tagged as probes and placed where they want to influence the reflections being generated (e.g. inside rooms, etc.).
    • Baking for reflection probes will be automatic, and updates will be handled at least once every 30 seconds.
  • A test viewer has been available within the #content-features channel of the Second Life Discord server (join the server and request channel access here) for content creator testing and feedback.
  • There is a performance hit with the capability, and this is still being adjusted so that it will hopefully not be overly onerous.
  • Elizabeth Jarvinen (Polysail) is working  on the current light shader to enable legacy content to receive the reflection probes without looking “too different” and look like it belongs in the environment along with PBR content.

Materials /PBR Work

  • Progress continues in developing a “materials” type with an associated inventory asset capable for containing PBR materials data.
    • LSL access to said materials is regarded as being “tricky”, simply because the materials will be an asset type loaded by the viewer.
    • What is being proposed is to have the ability to “override” elements of the asset (e.g. colour or texture) via LSL by applying the changes to the properties of the object face to which the materials is applied.
      • So, for example, the LSL override says, “OK. I know this material has a texture UUID inside it – I don’t know what it is, but I want this face to use MY texture UUID instead” – so the material asset itself is not changed / updated, but the UUID defined by the LSL code is displayed, rather than the texture UUID defined by the asset.
      • If the materials asset type subsequently be changed, then the overrides applied via LSL to the object face are automatically dropped until such time as new overrides are applied.
    • This is seen as the most flexible approach, as it protects the integrity of the materials asset (in a similar manner to texture data) whilst also allowing the flexibility of using colour variants against an asset type (such as in the case of a sweater using a single materials asset, but with multiple colour options in the pack or in allow a HUD to alter the tint of an object that uses a materials asset).
  • Nothing of significance to report on the PDR shader work.

In Brief

  • Custom pivot point work: currently awaiting simulator updates & will require viewer-side changes.
  • A fix has been implemented in the viewer to speed-up opening media / web floaters (such as search). This should be surfacing in the next Maintenance RC viewer (“Maint N” to follow the Makgeolli  Maintenance RC).
    • An upcoming simulator release should have a fix for objects failure to rez when users first log-in. .

Next Meeting

  • Thursday June 2nd, 2022.

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.