Day: August 6, 2022

2022 week #31 CCUG and TPVD meetings summaries

Posted on by Inara Pey
The Shambles, June 2022 – click any image for full size

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, August 4th 2022 at 13:00 SLT.
  • The video recording by Pantera Północy of the Third-Party Viewer Developer (TPVD) meeting on Friday, August 8th, 2022 at 13:00  SLT. This video is embedded at the end of this summary, my thanks to her as always for recording the meetings.

These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in both meetings, and is not intended to be a full transcript of either.

Common to Both Meetings

Official Viewers Update

[TPVD meeting Video: 0:00-0:43]

  • On Thursday, August 4th, 2022, the Maintenance 2 RC viewer, version 6.6.2.573358 and dated August 1st, was promoted to de facto release status.
  • On Friday, August 5th, the Maintenance (N)omayo RC viewer was updated to version 6.6.3.573882.

The remaining official viewer pipelines are as follows:

  • Release channel cohorts:
  • Project viewers:
    • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.
    • Performance Floater project viewer, version 6.5.4.571296, May 10.
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Copy / Paste project viewer, version 6.3.5.533365, dated December 9, 2019.

Graphics Preferences Updates

[TPVD Meeting Video: 5:05-17:26]

  • LL is deprecating a number of Graphics Preferences from the viewer. These include:
    • A number of obsolete options (e.g. terrain detail slider, avatar cloth option).
    • The removal of the abilities to turn off the Advanced Lighting Model (ALM) and turn off atmospheric shaders.
  • The latter two have been previously indicated, and form a part of the PBR  / materials work, where the plan is to eventually have two rendering paths: ALM with PBR support and ALM without PBR support.
  • HOWEVER:
    • While the options to disable ALM / Atmospheric Shaders are being removed from the official viewer, the actual rendering code for non-ALM rendering (aka forward rendering) is not at this point being removed.
    • The rendering code will not be removed from the viewer until such time as Linden Lab has a high level of confidence there is no significant impact on users’ SL experience in having to run with ALM enabled all the time, across the vast majority of supported hardware / edge-cases do not emerge where forward rendering is required.
  • There is still work to be done in order to get ALM running at the (generally faster) frame rates seen with non-deferred rendering, and these are said to be “coming in” to the viewer.
    • This work includes adding a slider for the number of local lights, so that users on lower specification hardware can dial-down the number of such lights that are rendered, thus helping to boost performance.
    • However, it was noted that if some doe experience issues due to running their viewer at High / Ultra settings (and their hardware cannot really handle this with ALM enabled), the will be encouraged to lower the quality slider.
  • Work still to be done on implementing a “data saving” / low bandwidth mode for those on metered Internet connections that will reduce the amount of data (e.g. materials maps) the viewer has to receive. However, the extent of this work and what it touches on in the viewer is still being specified / investigated.
  • LL is “reasonably confident” that content will look as intended under both non-PBR and PBR rendering, and that it will run as well under ALM as it does currently with ALM turned off.
  • It is hoped that eventually Second Life will reach a point where the ability to “turn off” PBR rendering could be removed from the viewer – however, it is acknowledged that there is hardware feature required by PBR that isn’t support by all client systems, so this dependency needs to be removed before this can be done.

CCUG Meeting Specific

Materials and PBR Work

Please also see previous CCUG meeting summaries for further background on this project.

  • Work is progressing both on the back-end and with the viewer, although the latter is not ready for any form of public consumption.
    • The plan remains to produce a test view that will be made available in the near future, and have regions on Aditi (the Beta grid) where it can be tested. Most of the viewer-side work is focused on bug fixing.
  • Overall, the focus remains on supporting the core glTF 2.0 specification, particularly now this is a recognised international standard (ISO/IEC 12113:2022).
    • This will provide six supported channels remain Albedo, Normal, Emissive, Ambient Occlusion, Roughness, and Metal.
    • Subsurface scattering and terrain support will not be part of the initial release.
  • While interest has been expressed in seeing a glTF mesh uploader in the viewer, this will also not be a part of the initial PBR supporting viewer; the focus is on getting the adopted core specification elements working before attempting to add additional capabilities.

Custom Pivot Points

There have been numerous requests over the years for allowing custom pivot points in mesh at upload (while pivot points can be defined in a .DAE file, they are currently ignored at upload). However, investigation has suggested provision of a solution is more complex than had been thought, prompting a discussion that ran through the majority of the meeting. The following is an attempt to provide a reasonable summary of that discussion.

  • Arbitrary pivot points can be defined using LSL. However, this is far from perfect.
    • It places a severe load on the simulator due to the number of object updates (rotation and translation)  that must be exchanged between the simulator and viewers as the object is moved.
    • As rotation is, by default around an object’s or linkset’s centre, LSL solutions often rely on workarounds by creators to achieve a desired result (such as by physically placing a small mesh triangle away from the object and then linking them, so as force the centre point between them to be offset relative to the object). Unfortunately, such techniques can have issues of their own (bounding box sizing, physics upsets, etc).
    • It relies on somewhat arbitrary interpolation to achieve a smooth rotation / pivot.
  • Some years ago, a code contribution was made to LL which would enable the pivot points / offsets set within a mesh .DAE be preserved at upload (e.g. by the addition of a simple check box in the uploader which would instruct it to import the file with the offset data).
    • Unfortunately this solution has its own potential limitation – it effectively bakes the offset point into the object, precluding any further manipulation of the offset were any required – it is thus not viewed by the Lab as optimal unless it can be shown it would in fact work for the vast majority of potential use-cases requiring custom pivot points.
  • One alternative solution might be to add a new parameter to all volumetric primitives which defines their origin point / centre. This would potentially be more flexible that the above approach, but also carries issues of its own, including:
    • It still may not work for all use-cases, leading to further alternative approaches being taken, leading to potential conflicts in execution between to different approaches.
    • What happens in linkset where child prims are specifically targeted for manipulation? if a custom pivot point is set within the root of the object, will it play nicely with the child prims that are themselves being manipulated (e.g. moved), or will things like scaling errors be introduced?
  • Perhaps the biggest issue identified with providing support for custom pivot points (and which has bearing elsewhere within and for Second Life) is that the platform has no real concept of a node hierarchy – it simply sees all items in the linkset as “children” of the root, whether or not they are linked to it directly or “via” other items in the linkset. (e.g. if you link prims “A” and “B” together, A is a “child” of “B”; if you then link “B” to “C”, SL sees “A” and “B” as equal “children” of C; whether in a node hierarchy, “B” would be seen as a child of “C”, but “A” would remain a child of “B”).
    • Such a hierarchy would more readily allow for pivot points, as they would be executed according to their parent child relationships, eliminating the need for additional script calculations to ensure the correct rotation / positioning of child primitives.
    • Unfortunately, implementing a node hierarchy at this point in Second Life’s development is not a trivial undertaking, and more work is required to fully understand the overall benefits implementing it would bring compared to the potential issues / drawbacks – and there does seem to be an appetite among some at the Lab to move in this direction.
  • Overall, no solid conclusions were drawn at the meeting – other than the fact that more structured discussion is required (including encompassing avatar attachments, which have their own raft of considerations).
  • In the meantime it has been suggested that an “amend” version of the code contribution that would allow pivot points / offsets defined within a mesh during creation are recognised and maintained by the uploader, rather than being ignored, is implemented within a test viewer, and this could be made available to creators for review / testing.

TPVD Meeting Specific

Changes to the Official Viewer Repositories and Build Process

[Video: 1:12-4:42]

  • This is an initiative to improve continuous update integration in the viewer and improve the viewer deployment process.
  • For TPVs and developers, the most visible aspect of this is moving the viewer repositories from BitBucket to GitHub.  This includes the viewer code base and the other public code bases currently in BitBucket (Autobuild, LLCA, etc.).
  • There are a number of reasons for doing this, including future potential to:
    • Automate pull requests for code.
    • Potentially simplifying the Code Contribution licence.
  • There work is being carried out in two phases: move the repositories to GitHub and then establish the infrastructure to take advantage of GitHub’s capabilities.
  • LL expects to spend a “couple of months” getting things in place before they are ready to offer a more precise timeline on the repository migration (which will be of core value to viewer developers), and will be looking to discuss this in future TPVD meetings.

Next Meetings

  • CCUG: Thursday August 18th, 2022.
  • Friday, September 2nd, 2022.