Category: SL Tech

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, June 15th, 2023 at 13:00 SLT. 

These meetings are:

• For discussion of work related to content creation in Second Life, including current work, upcoming work, and requests or comments from the community, together with viewer development work.
• Usually chaired by Vir Linden, and dates and times can be obtained from the SL Public Calendar.
• Conducted in mixed voice and text chat. Participants can use either when making comments  or ask or respond to comments, but note that you will need Voice to be enabled to hear responses and comments from the Linden reps and other using it. If you have issues with hearing or following the voice discussions, please inform the Lindens at the meeting.

The following is a summary of the key topics discussed in the meeting, and is not intended to be a full transcript of all points raised.

Viewer News

No official viewer updates up until the meeting, leaving the list as:

• Release viewer: Maintenance S RC viewer, version 6.6.12.579987, dated May 11, promoted May 16.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Maintenance T RC viewer, version 6.6.13.580419, June 7.
  • glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
• Project viewers:
  • Emoji project viewer, version 6.6.13.580279, May 30.
  • Puppetry project viewer, version 6.6.12.579958, May 11.

In addition:

• Maintenance T is likely the next RC viewer in line for promotion to de facto release status; however, it currently has an elevated crashed rate compared to the current release viewer, so LL is looking to bring that down before any promotion in made.
• The Emoji project viewer is liable to see further improvements to the Emoji picker in the UI.
• All of the back-end work (simulator code and the inventory service) seen as necessary to support Inventory Thumbnails is now thought to be in place, opening the door for a Thumbnails project viewer “Soon™”, which is apparently awaiting QA clearance.
  • Apparently this now provides the option of displaying the contents of an inventory folder either as we’re currently familiar with them (icons and text) or in a “thumbnail view” – I’ll review this once the viewer is available.
  • It’s anticipated that as the feature goes mainstream, creators will include thumbnails with their product offerings, as well as users creating their own thumbnails of items already in their inventory.
• A further Maintenance RC viewer (Maint U) is in development and could be surfacing “Soon™”.

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.
• There is a general introduction / overview / guide to authoring PBR Materials available via the Second Life Wiki.
• Substance Painter is also used as a guiding principal for how PBR materials should look in Second Life.
• 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.
• Given the additional texture load, work has been put into improving texture handling within the PBR viewer.
• 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.
• The overall goal is to provide as much support for the glTF 2.0 specification as possible.
• To provide support for reflection probes and cubemap reflections.
• The viewer is available via the Alternate Viewers page.
• Please also see previous CCUG meeting summaries for further background on this project.

Status

• There is another viewer RC in the works. This has been delayed whilst a number of bugs were resolved, but it is now with QA and pending their OK, it should be surfacing in the very near future.
• The water fog density range has been updated in the PBR viewer. It was capable of being set from -10 through to 10, but is now  “almost zero” through to 100, with the higher numbers indicating higher fog density (and lower visibility).
• Sky settings:
  • As per my notes from the last CCUG, all “legacy” skies which do not have a probe ambience set, will have one automatically applied by the viewer.
  • This has lead to a checkbox being including in the Graphic Preferences to disable the automatic application. However, it is possible / likely the check box will be removed.
  • This will mean the only way to have “legacy” skies render as they did pre-PBR will be to set the probe ambience setting to zero in the sky settings.
  • Setting probe ambience to 0 effectively deactivates HDR rendering and tone mapping etc.
• The above requirement to set the probe ambience to zero has two further impacts:
  • It will be the only means by which “legacy” materials can be rendered as they did pre-PBR; the viewer “hack” to desaturate and “nudge” the luminance of “legacy” materials to have them render as they did pre-PBR has been removed due to combination of factors, including a noticeable performance hit.
  • The hack that allowed full bright objects to be exempt from dynamic exposure (so they would always stay the same brightness no matter what the exposure) has also had to be removed from the viewer, again as a result of a noticeable performance hit (an extra texture sample for each pixel). So, full bright object will, in future versions of the PBR viewer, be subject to the same exposure rules as everything else in the scene.
    • This means that full bright objects will still appear to be lit by 100% of the light and be unaffected by things like local lights, but the overall dynamic exposure of the scene will also brighten / darken them in keeping with the rest of the scene, and tone mapping will be applied.
    • SL photographers who display their images in-world with full bright are going to need to experiment with using sky settings with tone mapping disabled when taking their shots in order to avoid it being applied twice to images (e.g. once when the snapshot was taken and again when displayed in-world) and having this unduly affect the full bright rendering of the image.
• Screen Space Reflections (SSR) – (non-SL overview):
  • Glossy support led to performance hits, particularly when there were a lot of alpha objects in the scene being rendered.
  • This has now been mitigated via a number of means; e.g. SSR is not even applied if it exceeds a certain roughness value, nor is it applied to alpha blended objects (the “old fade-out” method is used – that is: the higher the roughness, the weaker the SSR and the greater the reliance on reflection probes).
  • There have also been some general adjustments to SSR to again try to reduce the performance hits, whilst also allowing more distant objects to be reflected off of surfaces – said to be noticeable on water and flat surfaces.
• The SSR work provoked a reminder that it is important not to abuse the use of alpha surfaces when SSR is used in rendering.
  • For example:
    • If the object is just a single layer users will be looking through to see what lays beyond, than alpha blending “may be the right choice”.
    • However, alphas should not be used to create layered effects (e.g. setting the faces of a surface to transparent for a “window” and then applying a further alpha to give the window a “frosted glass” look, and having the viewer composite them when rendering. Instead, both alphas should be baked down into one material in PhotoShop (or similar) & applied).
  • This sparked a discussion on how general users who dabble in content creation and who may be used to working in certain ways, can be properly educated to understand things like this – which may be known and understood by mainstream content creators, but could easily pass others by, as there is no means within the viewer UI of telling what is “good” or “bad” techniques when banging things together (at least until frame rates disappear through the floor and into the cellar).
  • It was therefore suggested again that documentation on the wiki – “best practices” / a “bible” for PBR Materials creation / use really should accompany the formal release of PBR Materials, and this should be clearly pointed at though blog posts, etc.

PBR Terrain

• Per past meeting notes, Cosmic Linden is prototyping the application of PBR materials on terrain (see this blog post for more).
• The focus currently is on adding triplanar mapping to the for terrain repeats, particularly on steep elevation changes (so as to avoid the all-too familiar “stretching” seen with textures).
• The above does potentially incur a performance hit, as it is noted as being for “sufficiently capable machines”, so Cosmic has also been working on trying to optimise performance elsewhere in the use of materials on terrain, as well as carrying out some bug fixing.
• Important notes with this work:
  • It is not terrain painting. It is the application of PBR materials – terrain painting is described as “something that’s on the radar” at LL.
  • The work does not include support for displacement maps.
  • The work is currently only viewer-side, with no corresponding server-side support, the idea here being to prototype what might be achieved and testing approaches / results.

In Brief

• It was re-iterated that long-term graphics support on the MacOS side will be MoltenVK (with Vulkan the likely route for Windows), with Zink also being looked at.
• New user retention:
  • It has been suggested that as many in the various SL communities – those running Community Gateways, content creators, etc., – all have a interest in the new-user experience and brining people into SL, that a semi-regular “New User Experience” meeting might be established by LL at which ideas can be more readily discussed, feedback given and communities and creators more directly engaged with LL’s own efforts (e.g. developing an ecosystem of clothing, etc., to support the (still) upcoming new starter avatars. etc.).
  • It was pointed out that one of the best ways to encourage retention is for existing users to be welcoming, polite and supportive of new users (clubs that have scripts auto-ejecting people just because they are only a handful of days old or on the basis that an avatar is not PIOF, for example, aren’t exactly rolling out the welcome mat, for example).
  • The above spun into a general discussion on content, content moderation, and similar.
• There was a general discussion on Land Impact (LI) and how it is “too high” – although this is highly subjectively, given the diversity of content and its uses in SL (static, animated, Animesh, etc. – how high is “too high”? Is “too high” down to more a lack of understanding of actual rendering + simulator load costs than an objective measurement? etc.). That said, it was acknowledged that more could be done t help “improve” LI in some areas.
• The above spun into a discussion on physics costs, and how convex hull physics forms are not the most efficient for SL due to the complexity of the tools used to create them, and the ease with which mistakes can be made in creating them, with indications that as the glTF project moves towards support for mesh uploads how physics shapes are used / applied is likely to be be revised.

Next Meeting

• Thursday, June 29th, 2023.

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