Day: September 6, 2024

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.