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.

2 thoughts on “2022 CCUG meeting week #24 summary: Materials, ALM

  1. I bet most of the LL developers all have fancy high-end desktops, and because they sit around a lot, they have ALM on all the time.

    I have a fancy desktop with a RTX graphic card, lots of RAM and a good processor, but I do not have ALM on all the time. I prefer to have a larger draw distance (400m) which makes sailing and fling better, and allows me to keep about 16 sims visible in the minimap. I can turn on ALM with a quick preset, and I do for photos, but turning it off for general use is fine for me.

    If LL do make everything ALM only, then they have to make some easy-to-use performance sliders that allow people on laptops and less powerful PCs to get around with ease. And people like me to switch between high performance mode and a less graphic-intensive mode to travel around. Do a survey, I would suspect that most people don’t use high-end desktops.

    Like

    1. Most of the Lab folk use fairly mid-range systems for corporate use, together with the SL viewer only; so yes, they are well aware of average performance (although what they use for personal time in-world is purely there own choice, as it is for all of us). They also have a broad cross-section of hardware on which to test and re-test.

      In terms of sliders, etc., as stated in the summary, they are looking at ways to mitigate real (or perceived) performance impacts including the “data saving mode” and the local lighting slider (as to a slider to “switch between [graphics] mode[s]” – that is already in the viewer, under Preferences > Graphics.

      Also, the majority of users have yet to experience the real FPS gains presented by the Performance Improvements viewer updates (which for me, more than doubles my FPS with Shadows either enabled or disabled).

      In the majority of cases, running with ALM ON should not pose a significant performance hit for either mid-or high-end rigs. Problems tend to occur because by default, enabling ALM / pushing up the quality slider in Preference > Graphics can turn on Shadows; and people don’t actually appreciate they can be turned off again without disabling ALM.

      In this respect, the easiest way to move between shadows on / off, actually isn’t to toggle ALM: rather, it is to spend 5 minutes or so setting-up Graphics Presets options (I actually use four: one for outdoors, long DD and Shadows on (photography); one for outdoors, long DD and shadows off (flying / sailing); one for indoors, shadows off / low DD; one for indoors shadows on, low DD (photography) – ALL with ALM on – and I’m on an 8+ year old Haswell i5 16GB system with a 4GB GTX 970 GPU). Swapping between them is a two-click use of the Graphics Presets drop-down available on all viewers.

      Like

Have any thoughts?

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.