2022 week #39: CCUG & TPVD meetings – PBR and LOD

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, September 29th 2022 at 13:00 SLT.
• My notes and the video from the Third-Party Viewer Developer (TPVD) meeting held on Friday, September 30th, 2022 at 13:00 SLT. The video is provided by Pantera – my thanks to her for recording it, and it can be found at the end of this article. Times stamps to the video are included where relevant in the following notes.

Both 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 the meeting and is not intended to be a full transcript.

Official Viewers Status

[TPVD Video: 0:00-1:00]

No changes through the week, leaving the current crop of official viewers as:

• Release viewer: version 6.6.4.575022 – hotfix for Crash at ~LLModalDialog() – promoted September 15 – no change.
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • Maintenance 3 RC viewer, version 6.6.5.575257, September 23.
  • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
• Project viewers:
  • Puppetry project viewer, version 6.6.3.574545,  issued on August 30.
  • 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.

General Viewer Notes

• The next likely promotion to de facto release status will be the Maintenance 3 RC viewer.
• The Performance Floater project viewer (which includes UI updates and the Lab’s new Auto-FPS feature) has been undergoing a lot of work to reconcile the Lab’s auto-FPS work with that of Firestorm (by Beq Janus and released in Firestorm 6.5.3, March 2022), and so an updated version should be appearing Soon™, possibly in week #40.
• [Video: 28:10-32:35] The move to use Visual Studio 2022 in the Windows builds of the official viewer is moving ahead. Licenses are now in place, and an internal viewer (DRTVWR-568) built using VS2022 is being tested, and a project viewer may appear off the back of this.
  • In addition to this work, and as part of the migration to github, the third-party libraries used by the build process will be updated. This work will not include Clang.

Autobuild

[TPVD Video: 4:43-8:30]

• A new version of Autobuild has been released with some features TPV developers may be interested in:
  • zstandard, xz, gzip compression of package archives.
  • blake2b hash support.
  • Support for downloading packages from restricted sources such as private GitHub Releases and GitLab packages.
  • CPU count exported as AUTOBUILD_CPU_COUNT for build scripts.
• Signal Linden would like to hear from developers using a forked version of Autobuild could let him know what they need to be able to use the upstream version of Autobuild so that is is “simple to use” and has all the features TPV devs need to build their viewers.
• This discussion  included a conversation on using WSL in place of cygwin and on setting credentials to protect build packages that are not supposed to be redistributed.

PBR: Materials and Reflections

• Please also see previous CCUG meeting summaries for further background on this project.
• Test viewers continued to be made available to those on the Content Creation Discord channel, with work now focused on brining the viewer more into line with the release viewer so that it can move forward to a project viewer status for wider distribution.
  • Requests to join that channel should be made in person at CCUG meetings. I am no longer able (at LL’s request) to furnish such information.
• It currently looks as though the route to be taken in aligning the PBR / Materials viewer to the current viewers code is that users will not be able to disable PBR rendering, but will be able to turn off the new reflections  capabilities. This means that:
  • Objects with PBR materials on their faces will continue to show those materials, they just will not respond to reflection probes when the reflections capability is disabled.
  • Legacy materials (those we currently have today) should continue to look pretty much as they do at the moment.
• A major change between the PBR / Materials viewer and the current viewer is the former performs the majority of alpha blending rendering in linear colour space.
  • This can cause some different results to be displayed with alpha blending and the haze in some EEP settings.  However, the majority of colours should render the same as, or close to, how they appear now.
  • However, the benefit is it reduces the amount of work the GPU / CPU has to do in converting between different colour spaces (e.g. linear and RGB).
• Linden Water still has to be incorporated into the new render pipe (notably the the reflection and refraction paths, which currently require the forward rendering ((i.e. non-ALM) path – a path being disabled in the viewer as a part of this work.
• [TPVD video: 1:34-3:15] texture overrides are likely to be handled via specifying a glTF complaint JSON blob per texture entry – although which fields will be supported is still TBA. It’s hoped that this approach will allow for rapid front-end / back-end support of features.
• Reflections: the blending between reflection probes is still “not great” so this may cause some issues with presenting reflections across large surfaces (such as the face of a large skyscraper or glass building), with the suggestion being to manually place additional probes.

LSL Support

• New PBR / Materials related LSL functions are to be introduced to allow for setting PBR materials on prim / object faces.
• These functions currently comprise:
  • llGetRenderMaterial(sideNum) –  Returns materialNameOrID
  • llSetRenderMaterial(materialNameOrID, sideNum)
  • llSetLinkRenderMaterial(linkNum, materialNameOrID, sideNum)
  • llGetPrimitiveParams([PRIM_RENDER_MATERIAL, sideNum]) – Returns [ materialNameOrID
  • ]llGetLinkPrimitiveParams(linkNum, [PRIM_RENDER_MATERIAL]) – Returns [ materialNameOrID, … ]
  • llSetLinkPrimitiveParamsFast(linkNum, [PRIM_RENDER_MATERIAL, sideNum, materialNameOrID])
• The standalone functions are seen as being in line with llSetTexture, and to be less verbose when typing, compared to typing a list as with Set /GetlinkPrimitiveParams.
• All of these functions work similarly to the functions for setting textures on the faces of prims (ex: llSetTexture), but instead of referencing an image asset, they reference a material, such as can be created with the Material Editor.
• materialNameOrID can be the material UUID string, or the name of a material item in the prim’s inventory.
• These functions are currently deployed on the Aditi PBR test regions (Rumpus Room and Materials Sandbox regions) for testing.

Land Impact / LOD Clamping

[TPVD video 39:15-meeting end + CCUG Meeting]

The core of both the CCUG and TPVD meetings was the issue of the user experience, in-world mesh LODs, Land Impact, and what might be done to improve things.

Side note: it was acknowledged that many of the issues raised also apply to mesh avatar clothing and avatar accessories, but due to the manner in which avatars are handled in general, this is seen as a separate issue, deserving of its own discussion and potential routes to improve.

The Problem

• Around 30% of SL users – and a lot who are entering SL for the first time – are on systems that require a reasonable LOD factor (e.g. no more than 2) in order to have a reasonable frame rate. Unfortunately, this leaves them with a “broken” view of the world, as a result of a lot of in-world mesh items being built so they need to be seen at higher LOD setting at even reasonable camera distances.
• This is the result of a combination of issues, including (but not necessarily limited to):
  • The Land Capacity / Land Impact (LI) system, and the need to manage the impact (LI) in-world builds builds have.
  • The failure / unwillingness of some creators to properly optimised the Level of Detail (LOD) generation of their models, despite knowing they should, and using the lowest LOD options they can in order to minimise LI (and thus have their models decimate  – fall apart – even when see from relatively close distances).
  • The ability to force the viewer to fully render any LOD model of an in-world object, no matter how poorly optimised, in full detail via the unsupported RenderVolumeLODFactor setting, with creators then telling customer to set their viewer to high LOD factor (sometimes double figures) – something which can severely impact frame rates.
    • “Unsupported” is here a deliberate choice of words. As Runitai Linden noted at both meetings, debug settings, whether exposed as a UI element by TPVs or not, are not regarded as being a core, supported part of the viewer and thus are subject to change / removal by the Lab.
  • Issues within the mesh uploader cost calculations which appear to penalise properly modelled LODs by increasing the cost of a model with “decent” LODs to upload.
• It is an issue that is seen as needing to be addressed, simply because new users are seen as coming into SL on lower-performing systems and having a bad visual experience. The question is how best to address it.

Possible Routes to Help Alleviate

• Enforced clamping of the RenderVolumeLODFactor debug setting to no more than 4.00 for all viewers. This has been the case for some time in the official viewer (with the Graphics Preferences slide clamped to a maximum of 2.00), a practice also employed by some TPVs.
  • There was a general level of support for such a move, the view being it would force those creators who persist in trying to circumvent LOD modelling in favour of gaining a lower LI on their items to no longer do so, and encourage those coming into SL mesh content creation to properly model LODs.
• Overhauling the LOD calculations for how objects are seen and rendered by the viewer, so that instead of only looking at the number of degrees on-screen the bounding sphere of an object takes up, the viewer scales its calculations in accordance with screen resolution.
  • This is seen by the Lab as a potentially good idea.

Other Points Raised in the Discussions

• [TPVD Video 51:41-53:26] – Proper LODs appear to be penalised with higher LI values. This is likely to be down to how LI is calculated across a regions as explained by Runitai, and the math involved is unlikely to be changed.
• [TPVD Video:  55:21-56:51] – Issues of render cost vs. download costs (getting all the asset data to the viewer for rendering) and what is seen as an imbalance between the two when rendering multiple copies of the same object. however, for the reasons given in the video, this is also unlikely to change.
• [TPVD Video: 57:25-58:38] – RenderDynamicLOD is a debug setting (again, unsupported), that, when set to FALSE, forces the viewer to select a LOD model for an in-world object, based on its size, and always renders that LOD model, irrespective of camera distance.
  • As such, it cannot be gamed to avoid LODs per se.
  • It can, in some circumstances, result in an improvement (perhaps only slight) in FPS. As such, it is possible this setting might be presented as an option in the Advanced Graphics Preferences at some point (thus making it a supported feature).
• [TPVD Video: 58:59-59:46] – In response to a suggestion made in chat that LL provide some form of “mesh inspection” service to ensure mesh items are decently optimised / modelled.
  • This was seen as antithetical to SL being a platform for content creation, as it would bottleneck the creative process and potentially deter creators.
  • It would also raise the question of how to review and “accept / refuse” all existing content within SL.
  • Instead, the preferable route is seen as trying to provide a means for creators to use them platform whilst ensuring that are encouraged to produce good looking, performant, content.
• [TVPD Video 59:49-60:43] – However, it was observed that at the end of the day, if content creators are unable / unwilling to adhere to some building principles which allow the world to scale well be providing properly optimised LODs, there is always the option of replacing all creator-generated LODs with auto-generated LODs.
  • This is something which may (please note the emphasis!) be done in the case of avatar clothing and accessories.
  • It  is also seen as something which might help enable SL to run graphically on mobile devices.

CCUG In Brief

• There was some confusion over LL providing “instanced” regions,  with some at the meeting being convinced it was a product offering indicated as “coming” or “premium”.
  • Currently, there are no clear plans for this to happen – the nearest to “instancing” the Lab offers is the cloning of event regions.
  • Instancing and on-demand products have been discussed at the Lab, but as pointed out in the meeting, providing them is not a certainty at present, and there are questions about what might happen WRT AWS fees, etc., should LL start to offer such a product (they may not actually go down as a result of unpredictability of use).
• Alpha masks for the additional AUX wearable channels – a feature request has been received and accepted for these to be implemented, but no time frame on possible delivery, due the the need for both viewer and simulator updates as part of the implementation.
• The question was asked of those attending the meeting as to which they would prefer to see: improvements to the in-world building tools or improving inter-operability with 3D tools.
  • This was something of a loaded question, inasmuch as those attending the CCUG are, for the most part, commercial content creators – people focused on generating income from their work. As such – and as demonstrated by the responses to the question (which included a call of in-world builders “leaching” off of others – hardly a fair categorisation) – inter-operability proved to be the more popular.
  • It was, however, acknowledged by Lab staff at the meeting that there are other creators in Second Life who are not necessarily driven by commercial aims but who can still contribute to the wider community and multiple ways and who still utilise the in-world tools, and as such, their feedback should also be sought.

TPVD In Brief

• [Video: 8:51-9:51] Multi-Factor Authentication: there is an upcoming update which will see MFA enforced viewer-side. When implemented, it will mean users who have opted-in to MFA will only be able to log-in to SL on viewers with MFA support; they will no longer be able to switch between viewers with / without MFA support.
• [Video: 9:59-11:00] Inventory Updates: discussed in previous meetings, it has been confirmed that as part of this work the AIS2 API will be deprecated and will “go away at some point”, and the viewer fully transitioned to AIS3 only.
  • This means that any new inventory fields added as a part of any forthcoming inventory project will only be accessible via AIS3.
• [Video: 12:11-17:05] Legacy Profiles:
  • It has been noted that the URL  Profile field is now completely missing from the legacy Profiles viewer code  from the Lab.  A Jira for this has been requested.
  • Viewer with the Legacy Profile code now also incorrectly report an avatar’s rezday (listing it one day early). This is a known issue and will be addressed, but requires a back-end update.
• [Video 32:51-39:14] A discussion on viewer code signing (e.g. for recognition of executables being from a trusted source) – please refer to the video.

Next Meetings

• CCUG: Thursday, October 6th, 2022.
• TPVD: Friday, October 28th, 2022.