2023 week 5: SL CCUG meeting summary

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, January 19th 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, and are chaired by Vir Linden. Dates and times can be obtained from the SL Public Calendar.

Notes:

• These meetings are conducted in mixed voice and text chat. Participants can use either to make comments / 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.

Official Viewers Summary

Available Viewers

• On Thursday, February 2nd, 2023:
  • The Maintenance Q(uality) viewer, version 6.6.9.577968 was promoted to de facto release status.
  • The PBR Materials project viewer updated to version 7.0.0.577997.
• On Friday, February 3rd, 2023 the Maintenace R RC viewer updated to version 6.6.10.578087 – translation updates and the return of slam bits.

The remaining official viewer pipelines are unchanged, as follows:

• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Performance Floater / Auto-FPS RC viewer, version 6.6.9.577251, January 4, 2023.
• Project viewers:
  • 7.0.0.577780, January 25, 2023 – This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
  • Puppetry project viewer, version 6.6.8.576972, December 8, 2022.

General Viewer Notes

• It is believed the next viewer due for promotion will be the Performance Floater / Auto FPS viewer, at which point all viewer releases will officially all be based on VS 2022 for Windows, as this is the first RC viewer merged with the VS 2022 release process (previously a separate viewer build fork).

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.
• To provide support for reflection probes and cubemap reflections.
• The overall goal is to provide as much support for the glTF 2.0 specification as possible.
• 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.
  • It is currently to early to state how this might change when glTF support is expanded to include entire objects.
• The project viewer is available via the Alternate Viewers page, but will only work on the following regions on Aditi (the Beta grid):  Materials1; Materials Adult and Rumpus Room 1 through 4.
• Please also see previous CCUG meeting summaries for further background on this project.

Status

• Viewer:
  • The latest update to the viewer includes improvements to probe light blending (e.g. between overlapping manually-placed probes), additional work on radiance and irradiance, and the resolution quality of reflections set back up to 256×256 per face (but will downgrade to 128×128 if the viewer has less than 2 GB of available VRAM). All of this should leave the visual quality of reflection probes “pretty close” to what will be seen in the RC / release version of the viewer.
  • However, there is still a hard transition line between line between overlapping automatic probes and manually place probes, and LL want to encourage those using probes to use full scene manually-placed probes to ensure a much better quality of reflections.
  • Automatically-placed probes have had parallax correction removed, this should prevent the issue of people seeing the ray traced sphere of the probe rather than the reflection of the environment. Parallax correction is now only available with manually-placed probes.
  • Screen Space Reflections (SSR) have also been integrated with the reflection probes so that when the viewer does a look-up on a reflection probe and SSR in enabled, if there is an available SSR that gives a better result than the (generally automatic) reflection probe’s sample, it will be used instead.
  • In addition, there has been further work on optimisation and frame rate smoothing.
  • Still to be addressed in the viewer:
    • Some general artefacts still requiring clean-up, notably water reflections / light speckling, objects being rotated in reflections, and some remaining issues with colour curves on HUD attachments.
    • Further UI work.
    • There are some glTF materials caching issues which have yet to be addressed.
• LL is in the process of finalising compliance with the glTF standards. This does not impact viewer and glTF testing on Aditi (the beta grid), but will require updates to the viewer which are likely to come into force during RC / beta testing, meaning that only the updated viewer should be used from that point forward. However, it should not impact / alter overall functionality within the viewer.
  • This is the result of an incorrect assumption being made about some of the data required by the glTF specification would “always be there”, when in fact the filtering process LL uses to ensure glTF files uploaded do not contain anything malicious was dropping some of that data (so the visuals were correct, but the data was “wrong” compared to the standard).
• In an effort to have media on a prim work on glTF materials in a similar manner to the current SL materials (where setting a face to media on an object overwrites the diffuse (texture) map), setting media on a PBR materials face will overwrite both the diffuse and emissive maps, whilst sill allowing media to be viewed on a shiny surface, et., as per the current behaviour.
• There is concern about the impact of allowing “double-sided” materials as a part of glTF PBR (e.g. the risk of over-use, potential performance impacts, etc.).
  • LL acknowledged that a lot of samples they’ve tested from Sketchfab do contain a a lot of “unnecessary” double-sided surfaces, and so are considering implementing a check and warning on import where this occurs.
  • There is currently a checkbox for enabling / disabling double-sided materials in the PBR viewer’s materials editor, but LL’s view is that allowing double-sided content is not going to “ruin SL forever” – a view not necessarily shared by some creators.

Vulkan

• It is possible that 2023 will see the resumption of work to add support for the Vulkan / MoltenVK (for OS X) API alongside of OpenGL, as the latter is both growing increasingly long in the tooth and is gradually being deprecated / no longer used / supported on a number of fronts.
• Within LL, it is believed that implementing this support will not only get SL past the issue of OpenGL’s status, but also offer performance improvements within the viewer (e.g. allowing SL to be less CPU-bound and make more use of the GPU, reducing the volume of draw calls, etc.).

In Brief

• LL have been experimenting with pulling purchased content using glTF materials from Sketchfab and importing it to SL. The process is not easy, and it is acknowledge more work needs to be done to smooth this out at some point in the future – it will not be improved before the current project moves to a release status.
  • This raised the question of licensing, rights, mesh uploads to SL and the Terms of Service, with a not from LL that this likely needs to be reviewed as a whole, and guidelines provided to specify requirements for uploading content purchased by / built via 3rd party sites and things like license compliance (together the the need for LL to determine the means of gatekeeping things like license compliance).
  • Routes to upload from the likes of Sketchfab would be beneficial, as it would mean creators used to building for those platforms could pull their content into SL without having to learn a further (esoteric) set of content creation requirements.
• There was a general discussion on texture compression with glTF (which remains in place for all maps other than normal map, where compressed lossless is viewed as important), and on glTF allowing backward-facing normal maps (unsupported with the current SL materials system), and possible problems / benefits these might lead to.
• In terms of which parts of the glTF specification SL is supporting, LL will likely produce a living document that will detail the initial support, and which will be updated when further support is added / certified by Khronos.
• For future work, it appears at present that supporting glTF mesh imports would take priority over implementing glTF materials extensions from the specification.
• Related to the above point, discussions are in progress within LL on how to continue to support COLLADA (.DAE) mesh imports into SL without actively supporting COLLADA format.
  • Reasons for sunsetting direct COLLADA import to SL include:  there are still a lot of traps creators can fall into with the SL implementation of COLLADA support which can be a barrier to entry for those wishing to engage in SL as creators (similar traps do not exist within the glTF standard); maintaining the COLLADA importer adds cost and overheads, as every importer update has to be tested against it and adjustments made where they break COLLADA uploads.
  • One option under consideration is the use of the Open Asset Import Library (Assimp). This acts an an intermediary (so .DAE files get converted to the glTF mesh format), allowing a route of upload for COLLADA file to SL without LL having to maintain the COLLADA import mechanism directly, reducing the overheads of having to both test against it and maintain COOLADA import support.
  • This route would also allow other mesh formats (e.g. .FBX) to be “supported”, with the glTF specification support document mentioned above, available for creators to check which elements within the glTF specification they may need to add in order to get a like-for-like between their build format (.DAE. .FBX, etc.), and glTF.
  • Concern was raised about what the removal of direct COLLADA import might do the the market for full permission .DAE files which can be purchased through the SL Marketplace for upload to SL (although it is not clear how big this market is).
  • It is hoped that any approach taken would offer at least a robust a means of importing COLLDA meshes as the current importer.
• Also under internal discussion is how to support hierarchies in the context of glTF assets and what that means (e.g. import an asset with a node graph hierarchy, attach it to a mesh, and then manipulate the hierarchy via the edit tools or LSL).

Next Meeting

• Thursday, February 16th, 2023.