Category: SL User Group Meetings

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 5th, 2024. Tis meeting was also livesteamed on You Tube by the Lab. The video is embedded at the end of this summary, my thanks to the Lab for providing it.

Table of Contents Meeting Purpose Official Viewer Status WebRTC Status Graphics Team Updates Performance and Aesthetic Improvements Linden Water PBR Terrain Work In Brief Next Meeting

Meeting Purpose

• 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 related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
• Meeting dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
• The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers Update

[Video: 0:57-3:05]

• Release viewer: version 7.1.10.10800445603, formerly the DeltaFPS RC (multiple performance fixes, etc), dated September 11th, promoted September 17th.
• Release Candidates(s):
  • None at present.

Near-Term Viewer Release Roadmap

As a reminder, linden Lab is focused to bringing viewer performance back up to levels equal or close to “pre-PBR” performance,. This involves both further adjustments in the wake of the PBR releases and also fixing issues not directly related to PBR, which were coincidentally introduced with Graphics Featurette viewer release. This work is currently focused on, but not limited to, the following viewer updates from LL:

• Atlasaurus, promoted to release status on August 16th, 2024.
• DeltaFPS, promoted to release status (and thus superseding Atlasaurus) on September 17th, 2024.
• ExtraFS, a new viewer that will be issued as a release candidate viewer in the near future.

Once ExtraFPS reaches at least RC status, work will commence on resuming the normal follow of maintenance update viewers, etc., as per the more usual flow of viewer updates.

• The first maintenance RC to be issued will likely include contributions to help with Linux support in the viewer.
• It will also likely also include a round of further “post-PBR” performance / aesthetic improvements.

WebRTC Status

[Video 3:10-5:30]

Summary

• A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
• Key benefits:
  • WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
  • Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
  • Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.

Status

• WebRTC is now fully supported in the official viewer.
• Back-end deployment – WebRTC support is available on the following regions Pop Rock RC, comprising: WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4.
• Not that during the transitional period of moving from Vivox to WebRTC, there is no bridging between WebRTC peer-to-peer  / ad-hoc and Vivox.
• There will be an updated Echo Island specifically for WebRTC, which will be be available soon.

Graphics Team Work

Performance / Aesthetics Improvements

[Video: 7:40-14:39]

• DeltaFPS has a major change to the texture streaming system utilising the GPU:
  • Until now, the approach has been to drop the texture resolution down to a very low resolution (often causing a texture to blur on-screen) and then use the CPU to bring it back up to the appropriate resolution for display.
  • With DeltaFPS and going forward, the GPU is used to generate a copy of the texture at the appropriate resolution for display, and this is then used in rendering, with the higher-resolution version then discarded.
  • The overall results of this is a) there should be a lot less visible blurring of textures as they are loaded; b) the CPU load should be reduced; c) texture loading should be a lot smoother and faster.
• The upcoming ExtraFPS viewer includes texture rendering improvements for rigged attachments:
  • Currently the viewer  does not have an clear idea as to the size of a rigged attachment, other than it being possibly as big as the avatar, so all attachments essentially get the same texture resolution no matter how small there actually are, which can impact performance.
  • With ExtraFPS the texture resolutions for attachments will be more correctly calculated by their size, reducing the texture rendering overheads (e.g. rather than the texture for buttons on a jacket being loaded at its full 2K resolution, a much lower resolution sample for the texture is used unless the camera is zoomed right in on a single button, when higher resolution are used until zoomed out again).
  • This should mean that general viewer performance in crowds of avatars is improved, as the viewer isn’t trying to load high-resolution textures across every attachment in its view.
  • Note: this change is purely with regards to attachment textures, it does not change attachment LODs.
• Anti-Aliasing:
  • ExtraFPS will support Subpixel Morphological Anti-Aliasing (SMAA).
  • In addition, as as per the previous CCUG meeting, Rye Cogtail from the Alchemy team is planning (or already has) submitted contribution to improve the FXAA code for inclusion in the ExtraFPS viewer.
  • Those requiring more insight into anti-aliasing and the various types of AA, including FXAA and SMAA, can find out more in What Is Anti-Aliasing? TAA, FXAA, DLAA And More Explained, via Digitaltrends.
• Tone mapping:
  • The viewer update after ExtraFPS should include the Khronos Neutral tone mapper (another code contribution by Rye Cogtail), which should improve overall ambient lighting in SL.
  • To help with this, the viewer will include additional user controls. During the previous CCUG meeting, these were described as a combo box and a slider within the Advanced Graphics settings, together with a new new control – Tone Mapping Strength – to alter the linear alpha colour.
• Linear alpha blending:
  • Again, as per the previous CCUG meeting, in order for PBR lighting to render anywhere close to correctly, alpha blending had to be switched from SRGB to linear colour space. This can cause some older content using Blinn-Phong, to look either more opaque or more transparent than in did pre-PBR.
  • A fix for this giving people the ability to adjust the alpha/gamma on per texture entry for the object (including no mod items) is in development, and will likely surface in the viewer after ExtraFPS.

Linden Water

[Video: 11:52-12:40]

• Linden Water reflections have been reduced in quality with PBR. Geenz linden is experimenting with using elements of the mirror reflection code to try an improve them, but was not at the meeting to provide and update.
• This work is also not a current priority, as Geenz is focused on the performance improvements work.
• Adjusting screen space reflections (SSR) to correct the issue is not an option as “SSR has it own bunch of problems”.

PBR Terrain Work

[Video:39:34-41:44]

• Texture transforms (as a subset of the KHR texture transform) for applying scale, offset and rotation to any one of the four PBR terrain materials, are in development for the viewer, and are currently behind a feature flag and is awaiting further work on the server-side, which is currently in a very preliminary state.
• The server support is available on Aditi (the Beta grid), those wishing to test it should contact Cosmic Linden.
• In addition, an LSL API for manipulating PBR terrain materials has been requested, but this is not something that is currently being worked upon.

In Brief

• [Video: 14:48-17:18] Will GLTF mesh uploads address the issues of random linkset ordering (i.e. currently, when uploading a multi-object .DAE file, it is turned into a linkset with random ordering, so the root object can never be know until post-upload)?
  • Yes. What should happen is whatever the hierarchy is used within Blender (or similar glTF-compliant mesh modelling tool us used) should be reflected in SL after upload.
  • The basic interoperability between Blender and SL can be found here in the Blender documentation, although note that LL are not going to support extensions like Clearcoat, Sheen and Anisotropy with the initial release.
• [Video: 18:25-30:15] In-world build tools:
  • As a part of the upcoming glTF scene import support, the in-world build tools will be given the ability to edit such scenes (subject to permissions). These will likely take the form of a Scene Explorer and Scene Management tools.
  • LL has had internal discussions on a “simplified editor for decorating houses, etc.”, and feedback has been requested as to what kind of improvements to the existing in-viewer toolset / additional tools people would like to see.
  • This sparked a brief conversation on possible improvements to the build tools / options, together with a discussion on the growing complexity of wearable layers (due to creators effectively “splitting off” face !skins” into layers, which can cause issues with the ordering of layers, and the ability to “lock” the ordering of specific items in a layer class  – e.g. the “face tattoo” should always be “below” any “make-up” tatt0o, etc.) .
  • Please refer to the video for more.
• [Video: 30:35-36:20] A general discussion on getting started on avatar rigging and animation + suggested resources (e.g. AvaStar, AvaStar discord channel, Bento Buddy; making the avatar UV files, etc., more accessible via secondlife.com rather than being buried in the SL Wiki) – again please refer to the video.
• [Video: 36:25-38:32 and 57:39-end] Generative AI and SL content creation:
  • Some basic internal experimentation has been carried out with meshy.ai. It is described as “compelling” in terms of content creation, but “definitively cost prohibitive to host such a thing”.
  • As such LL are brainstorming how they might interact with such a tool from SL, should they opt to go that particular route.
  • In addition, other AI tools are being speculatively looked at as well.
  • Please refer to the video for more.
• [Video: 45:59-49:50] a request for additional LSL functions llGetSTPos and / or llGetUVPos get a world positioning from a texture coordinate. The short answer was no, and for a combination of reasons, but might be something for the upcoming viewer-side Luau scripting. Please refer to the video.
• [Video 50:36-57:29] General discussion on the feedback portal, feature requests, duplication of requests etc.

Next Meeting

• CCUG: 13:00 SLT, Thursday, October 3rd, 2024, at the Hippotropolis Campsite.

Footnotes

† 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 5th, 2024. The meeting was also livesteamed on You Tube by the Lab. The video is embedded at the end of this summary, my thanks to the Lab for providing it.

Table of Contents Meeting Purpose Official Viewer Status Viewer Performance – Priorities Viewer Aesthetic Updates WebRTC In Brief Next Meeting

Meeting Purpose

• 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 related viewer development work. This meeting is held on alternate Thursdays at Hippotropolis.
• Meeting dates and times are recorded in the SL Public Calendar, and they re conducted in a mix of Voice and text chat.
• The notes herein are a summary of topics discussed and are not intended to be a full transcript of the meeting.

Official Viewers Status

• Release viewer: version 7.1.9.10515727195, formerly the Atlasaurus RC (object take options; improved MOAP URL handling) promoted August 26.
• Release channel cohorts:
  • DeltaFPS RC, version 7.1.10.10708851543, updated September 5.
    • Performance boosts. Memory management has been optimized and users will experience a higher FPS across various systems. A comprehensive range of bug fixes are also provided. This includes better PBR material handling and resolving frequent crashes. See the release notes for more.
    • UI for scheduling region restarts now available via a new button located in the Region/Estate floater. (Note: there is currently an issue with scheduled region restarts working correctly and a fix is due to come in the next server release).

Viewer Performance – Priorities

[Video 1:15-3:03]

• The performance setbacks between the original PBR viewer release (7.1.6) and the Graphics Featurettes viewer (7.1.8), and which particularly negatively hit the Firestorm PBR release were again covered (for additional content, see my August 30th TPVD meeting summary).
• This has resulted in a “significant portion” of the viewer development work being focused on recovering performance and rectifying the underpinning bugs and issues – some of which are not specific to the PBR implementation itself. Some of this work has been surfaced in the DeltaFPS viewer, but more is to come.
• The above work also folds into it various fixes for crashes and bugs and a number of Visual Aesthetics (as in how SL looks – see below).
• This work will impact other areas of viewer work, so glTF projects like the PBR Terrain Painting and Transmission / IOR work are going to be pushed back somewhat, as is work on the viewer-side implementation of Laua scripting support. However, all of these work is still on the roadmap, just delayed.
• [Video: 8:24-8:56] Cosmic Linden has been working on an improvement to avatar loading to assist with performance improvements, and this has been pushed to the DeltaFPS RC viewer, together with working on bug fixes.
• [Video: 9:00-9:54] Runitai re-iterated that the Graphics Featurette viewer introduced the major performance hits (some of which are related to bounding box management and memory management, the the TPVD notes linked-to above), and DeltaFPS sees a good improvement in performance over Graphics Featurettes, and the viewer in development (“ExtraFPS“) that will follow DeltaFPS should see performance return to levels seen with the initial PBR release.
• [Video: 45:46-46:36] Which is not to say there are not additional PBR-related performance problems – such as those tied to specific GPU such as the Nividia GT1030 2Gb. These are also the subject of fixes being implemented in either the DeltaFPS viewer or the upcoming ExtraFPS viewer that will follow it.

Viewer Aesthetic Updates

[Video: 4:54-8:10]

• Linear alpha blending: in order for PBR lighting to render anywhere close to correctly, alpha blending has to be switched from SRGB to linear colour space. This can cause some older content using Blinn-Phong to look either more opaque or more transparent than in did pre-PBR.
  • The fix for this will likely be to add the ability for people to set and alpha/gamma ramp on an item, which can be modified per texture entry, adjusting how transparent the item is on a curve.
    • This should help with a range of issues – particularly those associated with pre-PBR hair, as has been noted by an number of users.
    • To help with this, the new alpha/gamma ramp value will still be adjustable even if the content is No Mod, so as to allow users to adjust legacy content affected by the issue, rather than having to wait for  fixes from content creators.
  • This fix will hopefully follow in the ExtraFPS viewer after DeltaFPS, but in the meantime will be made available in a viewer build available through the Content Creation Discord group‡ for those wishing to test it once the initial work has been completed.
  • Runitai Linden also indicated that as an extension to this work, LL might be able to find a way to apply the adjustment automatically, rather than people having to manually set it, but also noted any automatic solution would be “hard”.
• Auto-exposure: LL is looking to add controls for dynamic exposure (speed of transition, range, ability to turn off / on). These options will be made available via the Advanced Graphics floater, and maybe / someday via the the sky settings floaters.
• [Video: 10:03 -10:50] Anti-aliasing: there has been negative feedback from those who used to run the viewer with Advanced Graphics Model (ALM) disabled and who are forced to have it enabled all the time as a part of the PBR rendering, don’t like the look of Fast Approximate Anti-Aliasing (FXAA) as used in the viewer, so LL are adding support for Subpixel Morphological Anti-Aliasing (SMAA).
  • In addition, Rye Cogtail from the Alchemy team did a pass on the FXAA code and found it was not working as well as it should be.
  • Updates to FXAA and the addition to SMAA will be appearing in the viewer to follow DeltaFPS.
  • Those requiring more insight into anti-aliasing and the various types of AA, including FXAA and SMAA, can find out more in What Is Anti-Aliasing? TAA, FXAA, DLAA And More Explained, via Digitaltrends.
• Work is also being put into smoothing the problems created by switching from 8-bit colour precision to 16-bit float colour precision (which can be the cause of bugs wherein you go somewhere in SL and everything glitches to black or solid white). This work should surface through DeltaFPS.
• [Video: 11:05-11:45] The Sun is unrealistically dim. LL are considering adding a specific Sun intensity multiplier to Sky settings.
  • As a temporary fix, and whilst not specifically addressing the sun issue, the overall brightness in a scene can be adjusted via very small tweaks to the HDR slider in the Personal Lighting floater.
• [Video: 49:16-56:05] Tone mapping: Rye Cogtail from the Alchemy team has contributed the Khronos Neutral tone mapper for inclusion into the viewer.
  • This is not as dark as the current default in the viewer, and initially will use debugs to select which tone mapper is used (as the existing mapper will remain).
  • LL are looking to make this the default for tone mapping (subject to the outcome of testing), and the mapper is currently in the viewer Develop branch for TPV / viewer builders to take a look at.
  • When implemented the controls will likely be in the Advanced Graphics settings as a combo box and a slider. The control may also in the future be added to the sky settings.
  • In addition, there will be a new control – Tone Mapping Strength – to alter the linear alpha colour.
  • A key point to content creators on this is: you should not put the tone mapper in your textures (e.g. via the options available in PhotoShop when exporting textures) by bumping saturation, etc., and baking the tone mapper into the texture (as well and not baking things like reflections into textures).
  • WYSIWYG will still be possible providing creators select a tone mapper in SL that matches the mapper in their tool of choice or by using no post and working in linear + using the HDRI Preview option (Develop(er) > Render Tests) and use the same HDRI in SL as your content creation tool.

WebRTC

[Video 3:05-4:26]

Summary

• A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”). Roxie Linden is leading this work.
• Key benefits:
  • WebRTC supports a wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications, and is thus something of a “standard” approach.
  • Offers a good range of features: automatic echo cancellation, better noise cancellation and automatic gain control, much improved audio sampling rates for improved audio quality.
  • Opens the door to features and capabilities to voice services which could not be implemented whilst using Vivox.

Status

• WebRTC is now fully supported in the official viewer.
• The back-end deployment on the simulator servers is progressing (2 release candidate channels for simulator servers – BlueSteel and Ferrari – should now have WebRTC support), but this is not yet universal across the entire grid, and will take at least another 2 weeks to be grid-wide.
• Throwing the switch from running Vivox on the back-end to running WebRTC only will be dependent upon third-party viewers implementing and releasing the viewer-side WebRTC library.
• In the meantime, peer-to-peer and ad-hoc WebRTC can be tested on the WebRTC regions of WebRTC Voice 1, WebRTC Voice 2, WebRTC Voice 3 and WebRTC Voice 4. However, there is no bridging between WebRTC peer-to-peer  / ad-hoc and Vivox.

In Brief

• [Video 17:06-25:06] A discussion on Marvelous Designer (MD) cloth simulation within Second Life. This was done with Sansar, allowing clothing to be properly draped over an avatar body, and allowed for adjustments to be made prior to the finished results being baked-out (with automatic hidden surface removal).
  • Second Life utilises a different data modern to Sansar which introduces a range of complexities that would require significant re-working of how clothing  / mesh data is management, a potential re-writing of the entire Bake Service and other factors, all of which make MD integration a challenge.
  • Further complexities are added by the fact that unlike Sansar, which utilised a single avatar body type, SL has a plethora of bodies, and so using the cloth simulation against different body types (whether by creators or users) gets considerably more complicated, as do the requirements for data handling / storage and the costs involved.
  • As such, whilst these issues are not necessarily complete barriers to integration, they do mean that there are significant considerations involved, as well as significant changes to SL that would have to be made. Thus, it is not currently on the roadmap or under current consideration.
  • Please refer to the video for further details.
• [Video: 25:16-26:12] 2K texture support for Bakes on Mesh – while there was no precisely update available:
  •  It is believed the majority of the work in enabling 2K Bakes on Mesh is now done in terms of getting an early prototype put together on one of the Lab’s own development grids.
  • However, there is currently no public availability for the capability, not is there any release schedule. The work remaining “on-going”.
• [Video: 26:31-28:50] A brief discussion on creating content with both Blinn-Phong and PBR materials and some of the issues that can occur + some of the slight eccentricities (e.g. objects with both appearing to turn metallic when edited).
  • It was noted that as Blinn-Phong is still supported, creators can continue to use that in preference to PBR materials, although as time goes on the underpinning tools (like Blender) might move more and more into the glTF support arena and make it easier to produce glTF compliant content which can be used in SL.
• [Video: 29:14-30:57] Transmission and IoR: these are being implemented against the glTF extensions approved by Khronos. This work is focused on implementing them against the prototype glTF implementation, then it they pass that, the focus will move to integration with SL and how they work with glTF materials assets and how to apply them to mesh and prim faces.
  • However, as noted above, this work is currently paused pending completion of the performance improvements work, and is unlikely to resume until after the viewer following Delta FPS has surfaced.
  • It was also noted that it will still be a while before LL are confident enough with both Transmission and IoR to allow either to be added to content be users, even on a test basis.
• [Video: 40:22-41:48] The question was asked that, when SL gets glTF morph targets, if it would be possible to swap out vertex maps as well to change vertex weights so that it might be possible to deform clothing using the morph targets via script, then change the rigging, so an to allow one-size-fits-all clothing.
  • Runitai Linden noted that LL are aiming to hit all of the “musts” and “shoulds” in the glTF  specification. For morph targets, this means effectively having three channels per mesh that can be modified with the morph slider, thus limiting what could be done.
• [Video: 42:10-44:55] llSetAlpha / llSetColor, etc: LL is planning on making these functions implicitly access the PBR equivalents when a PBR material is present. However, this is hampered by the fact a good proportion of users are still on non-PBR viewers, so “there’s not good answer to which channel it should modify.” This means that currently, the easiest thing it to leave the functions “as is” until sufficient enough users are on viewer with PBR support.
  • This does not mean non-PBR content will no longer be a thing; just that creators should not have to make a non-PBR version of their content because there are people still using a non-PBR capable viewer.
• The last few minutes of the meeting are spent discussing what additional elements of the glTF specification have yet to be worked on.

Next Meeting

• CCUG: 13:00 SLT, Thursday, September 19th, 2024, at the Hippotropolis Campsite.

Footnotes

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

‡ Due to an express request from Linden Lab, I am unable to publish information on how to join the Content Creation Discord group. If you are a creator and are not a member, please contact Vir Linden via notecard or IM.