2023 week #33: SL CCUG meeting summary: glTF PBR; Senra

Chang’an, May 2023 – click any image for full size – blog post

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday,  August 17th, 2023. 

  • The CCUG meeting is for discussion of work related to content creation in Second Life, including current and upcoming LL projects, and encompasses requests or comments from the community, together with viewer development work.
  • As a rule, these meetings are:
    • Held in-world and chaired by Vir Linden.
    • Conducted in a mix of voice and text.
    • Held at 13:00 SLT on their respective days.
    • Are subject to the schedule set within the SL Public Calendar, which includes locations for both meetings (also included at the end of these reports).
    • Open to all with an interest in content creation.

Additional note: this meeting suffered several drop-outs (for whatever reason) plus my own Internet connection also went out; as such this is not a complete reflection of the meeting and all topics.

Viewer Status

General Viewer Notes

  • There are a couple of issues with the Inventory Extensions RC viewer which need to be addressed before this progresses to being ready for promotion to release status.
  • The internal discussions on font changes in the Emoji viewer (see my last CCUG / TPV meeting summary) will likely be split into a separate project, allowing the Emoji viewer to progress forward as it is.

glTF Materials and Reflection Probes

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • The overall goal is to provide as much support for the glTF 2.0 specification as possible.
  • Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
  • In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
  • As a part of this work, PBR Materials will see the introduction of reflection probes which can be used to generate reflections (via cubemaps) on in-world surfaces. These will be a mix of automatically-place and manually place probes (with the ability to move either).
  • The viewer is available via the Alternate Viewers page.

Further Resources

General Status

  • The communications bloat driven by multiple script-driven glTF materials updates generating multiple connections between the viewer and the simulator (thus impacting performance) continues to be addressed. The outcome of this work is liable to result in protocol changes as and when the work is complete.
  • A number of permission-related fixes have been implemented.

Lighting / Ambient Lighting

  • The issue over the rendering changes the glTF project will bring to Second Life. It has been well-established that the PBR system removes the forward render pipe (aka “non-Advanced Lighting Model (ALM)”) from the viewer’s renderer.
  • Equally, over the last several meetings (and as noted in my CCUG summaries covering PBR) there has been discussion on the fact that PBR utilises HDR + tone mapping with rendering  / lighting. This is a significant change to Second Life, particularly when it comes to the amount of rendered ambient light (until now SL has rendered a lot of additional ambient light), resulting in two related issues:
    • Because it is intended to mimic real-world ambient lighting, environments rendered on the PBR viewer with HDR + tone mapping enabled can look a lot darker than when viewed with a non-PBR viewer, and baked lighting really does not work (and can end up looking very bad) – scripted / direct lighting is required – something for which many store owners and users in general might not be prepared.
    • While disabling the ambient HDR rendering is possible within the PBR viewer (potentially eliminating the above issues), it conversely results in any PBR content within the scene looking “bad” or “broken”, risking content creators trying to find workarounds to the glTF specification in order to make their content “look good” under either lighting condition – something they absolutely should not do.
  • Discussions are still on-going at the Lab on how best to handle this conflict between PBR and non-PBR rendering as the latter is deployed and gradually gains broader use. As a part of this, it has been recognised that one of the most direct means to alert users is via communication.
  • To this end, a form of “best practices” and guidelines for PBR are being developed with the intention to make them available to users in advance of PBR being fully deployed / released. Expect to (hopefully) hear more about this via future CCUG meetings.

Mirrors

  • Geenz Linden is currently refactoring the Hero probes which will be automatically selected for generating higher resolution reflections based on an avatar’s proximity to a planar mirror surface (and initially limited to 1 (or possibly 2 per scene  – the second being for Linden Water reflections, but this has yet to be confirmed).
  •  This work will see the Hero probes treated as their own class of reflection probes with their own filtering, etc., to avoid conflicts (debugging, etc.) with the “general” reflection matte manger. This will also better support the higher resolution of the Hero probes and possibly allow for additional Hero probes to be supported within the viewer in the future.

Building Tools

  • PBR will see a significant change to the Edit / Build floater as the project becomes more widely deployed, and this has started internal discussions at LL about the state of the in-world build tools, and what might be done to improve them for general use. Ideas put forward at the meeting included:
    • More flexible means of cutting holes in prims (e.g. offset from the Z axis of the prim), such as through the introduction of a Boolean support.
    • Making text entry within the floater consistent (e.g. clicking on some fields, the existing content is highlighted for over-writing, in others it isn’t).
    • Inclusion of a prim alignments capability (as found in some TPVs) as a default tool + making the alignment more flexible that just to the sides / edges of the bounding boxes of the objects.
    • A broader range of primitive shapes (e.g. simple step units) and improved tools for torturing prims to produce custom shapes.
    • Better exposure of some of the build options on the official viewer (e.g. making the Local Textures option a radio button option in the Texture tab, rather than hidden in a drop-down) to make them more visible.
    • Also making it clearer that an object includes Local Textures, such as via a pop-up, to remind the creator to apply an actual texture to the affected face(s).
    • Better tools  / support for making clothing.
    • Better UDIM support for UV maps.
  • These idea will be fed back into discussions at LL.

Senra Avatars

[Note: this section is abbreviated as I lost my Internet connection for some 14 minutes of the meeting & this was followed by the meeting being disrupted a further 2 times.]

  • Further discussion over the continued confusion / concern over the Senra avatar system (outside of the ongoing disquiet over the licensing agreement), including:
    • Frustration / confusion over the amount of conflicting information being offered by Linden Lab – e.g. the dev kit application form states applicants “must” own a store but Patch Linden has stated in a forum post that owning a store “is not” a requirement.
    • Negativity on the use of an application requirement at all:
      • Some see it as presenting an unnecessary barrier for some (e.g. users who just want to create Senra-related items for their personal, rather than commercial, use).
      • Concerns over privacy / security with the devkit application form being outside of SL (where it is subject to potential abuse) rather than – as with the Mesh Upload Status form  – being included within the Secondlife.com dashboard,  where it would be both secure and firmly linked to an account.
    • Further questioning as to why AvaStar has been determined to be a core requirement for the devkit, rather than simply relying on Blender.
  • More general frustration was voiced at the idea that the “Senra team” only appear to be willing to engage through the forum threads on the topic, and then only in what is perceived as being a narrow focus of engagement, with no-one appearing willing to attend the CCUG meeting – which given Linden Lab want creators to produce content for Senra would seem to be a pretty good place for them to actively address feedback in real time, at least in lieu of any Senra-focused meeting(s).

In Brief

  • While they are not in anyway directly connected or related, Cosmic Linden noted that her work on enabling PDR materials as terrain textures in the viewer is being used as a testbed for possible approaches to enabling PBR with avatar Bakes on Mesh – although the latter is not currently an active project.

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.