Category: SL User Group Meetings

The following notes were taken from my audio recording and chat log transcript of the Content Creators User Group (CCUG) meeting held on Thursday, September 21st, 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 the location for the meetings.
  • Open to all with an interest in content creation.
• The notes herein are drawn from a mix of my own chat log and audio recording of the meeting, and are not intended to be a full transcript.

Viewer Updates

The Inventory Extensions RC viewer updated to version on Thursday, September 21st. The rest of the current list of official viewers remains as:

• Release viewer, version 6.6.14.581101, promoted August 23.
• Release channel cohorts:
  • Maintenance W RC viewer, version 6.6.15.581670, September 11.
  • glTF / PBR Materials viewer, version 7.0.0.581684, September 8.
  • Emoji RC viewer, version 6.6.15.581551, August 31.
  • Maintenance V(ersatility) RC viewer, version 6.6.15.581557, August 30.
• Project viewers:
  • Puppetry project viewer, version 6.6.12.579958, May 11.

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 for glTF as a whole 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

• SL Wiki: introduction / overview / guide to authoring PBR Materials.
• List of tools and libraries supporting glTF: https://github.khronos.org/glTF-Project-Explorer/ – note that Substance Painter is also used as a guiding principal for how PBR materials should look in Second Life.
• Second Life University: How to Create PBR Materials.
• PBR / glTF release candidate viewers can be downloaded from the SL Alternate Viewers page.
• Content test regions are available at: Rumpus Room, Rumpus Room 2, Rumpus Room 3, Rumpus Room 4, Rumpus Room 5.
• Also see previous CCUG meeting summaries for further background on this project.

General Status

• A update is coming up for deployment which should fix the protocol issue which has been a issue for the last several weeks (and noted in these summaries). Once deployed:
  • It will require those testing PBR materials to make sure they are using the latest RC viewer, or they will not be able to see edits to materials in-world.
  • Any scripts which have been created for handling PBR materials will need to be re-compiled as a result of a fix to prevent a conflict with one of the LSL constant values.
• Concern has been raised about lighting using reflection probes, specifically where probes do not fit with a specific structure, leading to the indirect lighting from the probe “leaking through walls, floors, ceilings. This is seen as something to address once Vulkan support has been implemented, as this will open the door to the use of things like shadow atlases.

Ambient Lighting / Sky Brightness

• A “big change” is being implemented in how environment ambience interacts with reflection probe ambience in an attempt to overcome the issue of “non-PBR” EEP enlivenments looking overly dark on the glTF/PBR viewer code.
• Essentially, this will mean that environment ambience should be pretty much unchanged, unless one or more reflection probes with an ambience setting greater than zero but less than 1 are used within a scene.
  • If the probe’s ambience is set above 0 but below 1.0, then the probe’s ambience will be mixed with the environment (sky) ambience.
  • If the probe’s ambience is set to greater than 1.0, then the environment ambience will be completely ignored in favour of the probe’s indirect lighting ambience within the probe’s sphere of influence.
• This should allow for a better balance, in that interior scenes can be set to utilise probe ambience, allowing for darkened room / cave, etc., interiors, without making the environment outside the influence of the probe(s) unduly dark / darker that it should be.
• In addition, the tone mapping in the PBR renderer is being adjusted to prevent the viewer crushing colour values below 22 (i.e. towards their darker tones). This will better align the HDR colour mapping to SRGB without over-saturating blacks.
• Longer-term, LL is considering a tone map / texture look-up people can plug-in to for sky settings, but for now the drive is to just drive home the idea that with PBR, tone mapping is now a part of the render pipe, and creators should not bake their preferred tone mapper into their content.

Mirrors

• Mirrors are a part of the glTF / PBR materials project, but something of a separate tranche of work.
• The idea is provide the means to have via high resolution reflections (i.e. mirrors) within a scene.
• Initially only one active mirror surface per scene will be active for any viewer.
• The process will use the PBR reflection probes mechanism, combined with a automated “Hero Probe” mechanism which with generate high resolution (512×512) “reflections” for the mirror.
• The system will operate on the basis of avatar / camera proximity to a mirror surface triggering the closest reflection probe to become a “Hero Probe” for that avatar / camera. This means that if there are multiple mirrors placed within an environment, only the one closest to a given avatar / camera will be active and display the “reflections” generated by the reflection probe.
• Depending on testing and performance, the number of mirrors might be expanded to two – one for mirror surfaces and one for Linden Water to generate high resolution water reflections where appropriate.

Status

• An issue with the mirror code eating up all available VRAM has been addressed.
• A viewer build is being queued-up in preparation to be made available via the Content Creators Discord channel.
• Remaining work is seen as ensuring there is only one placement mode for Hero probes for mirrors, which should work on most objects and on ensuring culling works correctly (e.g. ensuring nothing behind the mirror surface gets rendered ad a reflection in the mirror.
• There may also be some data modelling changes and shader tweaks along the way.

Puppetry Project

Summary

• Previously referred to as “avatar expressiveness”, Puppetry is intended to provide a means by which avatars can mimic physical world actions by their owners (e.g. head, hand, arm movements) through tools such as a webcam and using technologies like inverse kinematics (IK) and the  LLSD Event API Plug-in (LEAP) system.
  • Note that facial expressions and finger movements are not currently enabled.
  • Most movement is in the 2D plain (e.g., hand movements from side-to-side but not forward / back), due to limitations with things like depth of field tracking through a webcam, which has yet to be addressed.
• The back-end support for the capability is only available on Aditi (the Beta grid) and within the following regions: Bunraku, Marionette, and Castelet.
• Puppetry requires the use of a dedicated viewer, the Project Puppetry viewer, available through the official Second Life Alternate Viewers page.

Status

• This project grew in scope following initial inception, with various additional elements of work / projects being identified through Puppetry User Group meetings. As a result, meetings were suspended on July 13th, 2023, and have remained dormant since.
• Currently, work related to scripted means of puppetry is blocked pending the IK work moving forward, and given that the IK work had expanded through the early part of the Puppetry work to become its own sub-project, both it and the scripted element of Puppetry have been placed on the back burner.
• A further consideration with Puppetry is that “glTF phase two” will likely implement a node hierarchy, which will have significant implications for animations and puppetry. As such, putting the core of the work on hold for the time being is seen as sensible. However, that the work is on hold should not be taken to mean Puppetry has been abandoned.
• Work is progressing on another spin-off piece of work: broadening SL’s animation import capabilities. As of July 2023, this work was leaning towards using Assimp (github: https://github.com/assimp/assimp), which supports some 30-40 animation formats (including the likes of .FBX and glTF), converting them to its own format for ease of import to multiple platforms, potentially including SL. However, no-one engaged in that work was available at the meeting to give an update on overall progress and current status.

In Brief

• Physics engine: the Havoc physics engine for SL has not been updated since 2012. There “is an awareness” within LL that work needs to be put into making the simulator’s physics system more up-to-date, however, exactly what path this may take (e.g. updating Havoc or switching to a new engine or simply exposing more of what the physics engine can do) has not as yet been determined.
• LL has noted the Unity situation regarding it new Install Policy due to be introduced from January 1st, 2024, given the SL Mobile application is built on the Unity Engine. Announced on Tuesday, September 19th, the announcement has generated considerable backlash from Unity developers and the situation is in a state of flux. As such, LL is watching developments in this area to see what direction Unity might ultimately take.
• Much of the meeting was taken up with discussions on tier and (particularly) with the idea of LL developing their own alternative to Flickr as a potential new revenue stream. This is something that may become the subject of a separate blog post.

Next Meeting

• 13:00 SLT, Thursday, October 5th 2023, at the Hippotropolis Campsite.

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

The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday,  September 7th, 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 the location for the meetings.
  • Open to all with an interest in content creation.
• The notes herein are drawn from a mix of my own chat log and audio recording of the meeting, and are not intended to be a full transcript.

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 for glTF as a whole 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

• SL Wiki: introduction / overview / guide to authoring PBR Materials.
• List of tools and libraries supporting glTF: https://github.khronos.org/glTF-Project-Explorer/ – note that Substance Painter is also used as a guiding principal for how PBR materials should look in Second Life.
• Second Life University: How to Create PBR Materials.
• PBR / glTF release candidate viewers can be downloaded from the SL Alternate Viewers page.
• Content test regions are available at: Rumpus Room, Rumpus Room 2, Rumpus Room 3, Rumpus Room 4, Rumpus Room 5.
• Also see previous CCUG meeting summaries for further background on this project.

General Status

• An update for the PBR viewer – version 7.0.0.581684 was issued following the meeting, on Friday, September 8th.
• Work is continuing on the communications bloat issue. This will utilise a new message type – GenericStreamingMessage.
• Bug fixing continues.

Ambient Lighting / Sky Brightness

• Also noted in previous summaries, there are some issues around ambient lighting where the PBR viewer is concerned. In particular, it tends to render a lot of EEP settings darker than users are used to (in part because the ambient environment lighting in SL has tended to always be over-saturated and bright), and the PBR viewer effectively reverses this to render environments more realistically.
• This has been an area of work for some time, with none of the results particularly satisfactory, so there is going to be a further round of changes. with the aim of making existing EEP sky settings render more closely to how the author may have intended, rather than remaining overly dark.
• In addition, the tone mapper in the PBR renderer is going to be adjusted to help reduce undue darkening of older EEP settings.
• These changes will not impact EEP settings which are created specifically using the PBR settings and capabilities.
• This work will mean there will likely be a couple more viewer passes as things are tested and adjusted.

Mirrors

• Mirrors are a part of the glTF / PBR materials project, but something of a separate tranche of work.
• The idea is provide the means to have via high resolution reflections (i.e. mirrors) within a scene.
• Initially only one active mirror surface per scene will be active for any viewer.
• The process will use the PBR reflection probes mechanism, combined with a automated “Hero Probe” mechanism which with generate high resolution (512×512) “reflections” for the mirror.
• The system will operate on the basis of avatar / camera proximity to a mirror surface triggering the closest reflection probe to become a “Hero Probe” for that avatar / camera. This means that if there are multiple mirrors placed within an environment, only the one closest to a given avatar / camera will be active and display the “reflections” generated by the reflection probe.
• Depending on testing and performance, the number of mirrors might be expanded to two – one for mirror surfaces and one for Linden Water to generate high resolution water reflections where appropriate.

Status

• The promised initial build of a PBR viewer supporting mirrors should be made available in week #37. Caveats for this build include:
  • It is not functionally complete and will not render as fully as LL would like.
  • It is not intended for primary use will likely look like it is breaking things.
  • There are already some known crash issues for Mac OS X which will not be fixed when the viewer is initially made available, but will be fixed in due course.
• The viewer will be made available via the CCUG Discord Channel, and an LSL script will be provided to allow for easy toggling through mirror options.

In Brief

• Senra:
  • Requests continue to be made to surface the new web-bases avatar creation / customisation tool through the viewer – even it is is just hooking it to the internal browser and providing an easy and obvious means of accessing it. The major reason this is being requested is to to help new users who may have become “lost” or confused in trying to customise their avatar view the viewer – which is clearly a very different experience to the web capability – to get back to something they understand and can readily re-use.
  • It was pointed out that Senra has yet to be featured in the Choose Your Avatar option in the viewer.
  • It was also pointed out that unlike the older “starter avatars” Sentra does not inherently have any form of outfit structure, so if items are worn directly from the Library, anything worn will be copied to the item type folder (shoes to shoes, hair to hair, etc.), rather than being placed within any form of “outfit folder”, making it harder for new users to understand what is happening with their avatar + the items they are using from the Library may end up getting copied multiple times into various folders in their inventory – potentially leasing to more confusion / frustration down the line.
  • This lead to a lengthy discourse through the greater part of the meeting, further demonstrating the need for a New User Experience User Group (or similar) where those actually responsible for projects like Senra could actually engage with users, address questions, etc., rather than cherry-picking if / what they want to respond to via the forums.
• The above spun-out into a broader discussion on the development of a Sansar-esque dressing room element in the local viewer of outfit / appearance changes (leaving an “untouched” version of the avatar within a region until the change / update is complete) and the complications of doing so (attachments require simulator rezzing, for example), and an general discussion on outfit changes, etc., without firm conclusions drawn.
• The question was asked about SL supporting vertex animation textures (VAT). This is seen by the Lab as something that might be investigated further down the glTF implementation road, alongside the likes of blend shapes.

Next Meeting

• 13:00 SLT, Thursday, September 21st 2023, at the Hippotropolis Campsite.

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