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

Sweetwater Valley, August 2022 – blog post

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, 2002 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.

2022 week #35: CCUG + TPVD meetings summary

WillowWood, July 2022 – blog post

The following notes were taken from:

  • My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, September 1st 2022 at 13:00 SLT.
  • My notes and the video from the Third-Party Viewer Developer (TPVD) meeting held on Friday, September 2nd, 2002 at 13:00 SLT. The video is provided by Pantera – my thanks to her for recording it, and 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: 1:00-2:20]

  • Release viewer: version 6.6.3.574158 – formerly the Profiles RC viewer, dated August 18, promoted August 30.
  • Release channel cohorts:
    • Izarra Maintenance RC, version 6.6.4.574724, September 1.
    • Maintenance 3 RC viewer, version 6.6.4.574727, September 1.
    • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.3.573877 issued August 15.
  • 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

  • LL are likely going to be updating the Windows viewer build tools to use Visual Studio 2022.
  • This will likely be ahead of the move to use Github as the main viewer repositories, as outlined at the previous TPV Developer meeting.

Materials and PBR Work

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

  • Overall, the work on the viewer side of things – rendering in support of glTF 2.0 standards (and consistency of results when going from a tool like Substance Painter trough the uploader to displaying in SL)  is now “near complete”.
  • It  is hoped that it will “not be long” now before a project viewer is more generally available, although there is still additional back-end work to be completed, together with adding support for things like transparency support, ensuring PDR rendering works under linden Water, and similar.
  • Again, the focus of this work for the first pass is “core” glTF 2,0 support.
    • Ratified (under ISO) extensions may be up for inclusion in future enhancements to the capability.
    • Non-ratified extensions will not be up for inclusion in future updates.
  • In order for to be compliant with glTF, tangents are going to have to be generated in mikkTSpace, where normal maps are applied. This means that existing normal maps within Second Life / normal maps generated without using MikkTSpace may not look correct when rendered via the PBR pipe.
  • [TPVD video: 28:41-30:55]:
    • Runitai Linden noted that this project has been a valuable experiment in real-time collaboration between the LL dev and members of the community through the Discord server.
    • He expressed thanks to the TPV developers and the creators who have assisted the graphic team both in the development of the PBR rendering path and in helping with the reflections probe development, both in terms of code contributions and in helping to identify and address edge-case issues.
    • He further noted It  is hoped more projects might by run this way.

Textures: Handling

[TPVD video: 5:19-10:22]

  • Also pulled into this work are improvements to the texture handling (previously DRTVWR-559), This involves  better core utilisation and VRAM usage.
  • For Windows, this work includes an API which:
    • More accurately track texture memory use in the viewer and report it back to the client operating system.
    • Should ensure all available video memory (i.e. that not being used by other applications) on  Windows systems is used by the viewer prior to any texture paging occurring.
    • Works with both Intel and AMD hardware (the latter is important that the OpenGL extensions commonly used by TPVs to achieve a more efficient use of VRAM apparently no longer work correctly on AMD hardware).
  • For Mac OSX, the new method is to use internal accounting to attempt to track how much video memory is free and then estimate a value of available memory for textures from that.
    • This is because the operating will not simply report the amount of free video memory (only how much is installed), ruling out the use of a more scientific approach.
  • Once available in production viewers, these changes should mean those running systems with more recent video cards with decent amounts of free video memory should see much improved texture fetching and loading and see a reduction of textures being paged out to cache (the blurring / sharpening / blurring of textures) seen when the viewer thinks it is using all available / allowed video memory.
  • A further change is to specify the maximum amount of system memory the viewer can use for textures (16 GB, if available on 64-bit systems; 4GB on 32-bit systems).

Puppetry Update

Please also refer to:

Notes:

  • The discussion on puppetry mentioned in  the above articles will be the first such meeting, and if there is demand for it, there will be a similar meeting on Aditi on alternate Thursdays from September 8th onwards, to be held in the theatre on Aditi Castelet region.
  • These meetings will (initially) be very development focused rather than creator / user focused, given the overall status of the project.
  • It is advisable that attendees use the Puppetry project viewer when attending these meetings (available from the Alternate Viewers page), so that they might see any demonstration which may take place during meetings.
  • [TPVD video 12:50-14:53]:
    • It’s important to notice that what has been made available is a very early stage “alpha” release.
    • The choice of  the  LLSD Event API Plug-in (LEAP) system means that it should be fairly easy to write third-party code to support capture devices (e.g. from Leap Motion through to (potentially) full body trackers – something Vru Linden is already tinkering with).
    • The Thursday meetings are being established to discuss precisely these kinds of opportunities and the potential for things like multi camera support, etc.
  • [TPV video: 31:09-33:24]  Given the success of the real-tome collaboration with PBR / Reflection Probes, it is likely the Puppetry project will also follow a similar approach and utilise a Discord channel for discussion and contributions, etc., over and above the fortnightly meetings on Aditi.

TPVD In Brief

  • [TPVD video: 2:26-4:15] Inventory Updates:
    • This is something the Lab is considering, and has been looking for feedback from users on possible approaches. – see also the previous CCUG  / TPVD  meetings summary.
    • If / when this work goes ahead, it will also involve some general code and other technical tidying-up,  including:
      • Reducing the number of different AIS APIs currently in use.
      • Removing deprecating (and eventually removing) UDP messaging paths for inventory, together with outdates inventory caps (particularly as the latter are superseded.

 

Next Meetings

  • CCUG: Thursday, September 15th, 2022.
  • TPVD: Friday, September 30th, 2022.

2022 week #31 CCUG and TPVD meetings summaries

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.

2022 TPVD meetings week #27

Village of Ahiru, April 2022 – blog post

The following notes were taken from the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) of the Third-Party Viewer Developer (TPVD) meeting on Friday, July 8th, 2022 at 13:00  SLT.

Please note that this is a summary of the key topics discussed during the meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:08-2:30]

  • Maintenance Optimisations RC version 6.6.2.573065 issued on Thursday, July 7th, This viewer:
    • Incorporates the Build Copy / Paste capability (also found in the Copy / Paste Project viewer).
    • Assorted UI improvements / clean-up (e.g. such as with the Build Edit folder).
    • Apparently includes the ability to hide the World Map Legend
    • Is likely to be fast-tracked to release status “in the next couple of weeks”.

The rest of the current crop of official viewers remains as follows:

  • Release viewer: version 6.6.1.572458 – formerly the Maintenance M(akgeolli) RC viewer, promoted June 29th.
  • Release channel cohorts:
    • Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
  • Project viewers:
    • 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.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.

General Viewer Notes

  • Following the promotion of the Maintenance Optimisation RC viewer, the focus will be on the Legacy Profile viewer to get that to RC status.
  • There are some crash-on-exit issues with the official viewer the Lab is attempting to fix.

RequestImage UDP Message

[Video: 2:50-4:44]

  • Since 2015, assets have been delivered to the viewer via HTTP using CDN capabilities.
  • However, the RequestImage UDP messaging capability for delivering textures has remained in place on the simulator, and it has been noted that some viewers continue to use it directly or as a fallback, requiring the simulator to carry out checks with the CDN service when textures cannot be found.
  • LL would like to completely remove all reliance on the simulator for texture fetching / checking, and have everything via HTTP and the viewer / asset system / CDN.
  • To this end the RequestImage message will be deprecated and removed “very soon”.
  • Viewer that us (or actually rely on) it are therefore asked to ensure they only use the HTTP route.
  • [Video: 6:55-7:24] Going forward, the simulator code will track deprecated messaging that TPVs may or may not be using, allowing LL to them TPV where such message paths are still being used and which have been earmarked for removal from the simulator.

In Brief

  • [Video 5:42-6:25] A bug introduced into one of the upload paths this week resulted in the CDN service delivering PNG data in place of JPEG2000 (primarily for profile pictures), which resulted in some viewers experiencing clogging of their texture processing pipes. This issue has now been fixed.
  • As a part of general discussions, Alexa Linden indicated she’d like to start reducing the time it takes for code contributions from TPVs and third-party developers to be integrated into the core SL viewer code. This includes receiving reminders about old code contributions that may have fallen by the wayside.

Mojo’s Wishlist Ideas

[Video: 8:21-pretty much to the end]

There are not currently project, by Mojo Linden continues to seek feedback on them.

  • He reiterated the idea mentioned at the week #27 CCUG meeting of using low-poly bakes to help “increase” visibility across Mainland regions to try an instil a greater sense of scale of the continents.
    • Mojo noted this could perhaps leverage the Map service in some manner (a problem being that the Map service currently doesn’t know about mesh geometry).
    • In raising the Map service, he also noted LL is also aware of the issues within that service that need to be addressed, and that this is really down to determining the optimum time to doe so, rather than having technical reasons why it cannot be improved.
  • He floated the idea of introducing some means of hidden surface removal, particularly for avatars to remove the need for alpha layers, etc., to hide body parts, the idea being to reduce the complexity of avatar rendering.
    • There are edge cases with this – such as an item of clothing with both an “outside” and “inside” texture (such as a lining on a jacket) – what happens to the “inside” texture, does it get culled?
  • He also floated the idea of fully baking the avatar’s appearance such that avatar and clothing are baked as one as a final step of changing appearance, reducing the overall render cost and complexity.
    • It is not clear if this would allow avatar appearance to be changed in “real time” or not (e.g. Sansar bakes avatars, but does so using a separate environment in which to modify an avatar’s appearance).
    • The fact that rigging can be variable between clothing and bodies, etc., might also need to be worked around, as baking would likely require committing to a single set of weights.
  • It is possible the use of baked avatars would allow for an alternative form of avatar impostor for use within large events with a lot of avatars in a single space, the bakes – whilst lower poly than would be the case in less-crowded environments – offering a better visual result than the current impostor system.
  • A lot of technical questions were through out by those at the meeting as to how LL see baked avatars, etc., “working”. However, as Mojo notes, he’s putting ideas forward to see if there is interest in pursuing them rather than presenting any actual projects; as such answers would be sought collaboratively if it were deemed something that should be looked at more formally / in-depth.

Date of Next Meeting

Friday, August 5th, 2022.

2022 TPVD meetings week #23: PBR materials; textures

Village of Ahiru, April 2022 – blog post

The following notes were taken from the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) of the Third-Party Viewer Developer (TPVD) meeting on Friday, June 10th, 2022 at 13:00  SLT. These meetings are chaired by Vir Linden, and dates for them can be obtained from the SL Public Calendar.

Important: as from this meeting, the TPV Developer meeting has moved to a four-week schedule.

Please note that this is a summary of the key topics discussed during the meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 1:23-2:39]

There have been no viewer updates through the week, leaving the current list of public official viewers as:

  • Release viewer: version 6.6.0.571939 – formerly the Performance Improvements viewer, dated May 25th – 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).
    • Nomayo Maintenance RC (Maintenance N) viewer, version 6.6.1.572179, June 1.
    • Makgeolli Maintenance RC viewer (Maintenance M) viewer, version 6.5.6.571575, May 12.
  • Project viewers:
    • 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.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The Performance Improvements viewer has had a couple of “significant issues” raised against it, which are being pulled into the Maintenance RC channels for resolution. One of these might be BUG-232200 (extreme mouse sensitivity based on DPI), although no specifics provided at the meeting.
  • The Legacy Profile project viewer (finally) looks like it may be getting some attention in the near future, in the hope it can move forward to RC status at some point.

Additional Materials Support / PBR

[Video: 2:58-5:28]

Summary

Note: please also refer to my recent (April / May) CCUG meeting summaries.

Two area of work are currently in progress.

  • One element of work is to provide “full” Physically Based Rendering (PBR) materials support utilising the glTF specification.
    • This work is currently focused on implementing a new materials asset type that will allow materials surfaces created utilising the PBR workflow to be imported to SL and then applied to their desired object face(s).
  • A parallel piece of work is adding sport to SL for reflection probes to update the generation of the environment maps (because the current cube mapping used by SL is limited and would not work will with PBR).

Current Progress

  • Simulator-side support for reflection probes is being added, together with updates to the EEP system in support of the changes. This work is being implemented so that (hopefully) viewers without the necessary rendering updates will not see any “breakages” to the environment as the simulator work progresses through Aditi to Agni.
    • These updates are currently on Aditi on the DRTSIM542 channel (Materials 1, Rumpus Room, Rumpus Room 2, Materials Adult).
  • LSL support for this work still TBD.
  • There is now a test version of the viewer for the materials work available through the SL Discord server #content-features channel.
  • A glTF importer will “hopefully be ready in the next week or so”, although it will be a work-in-progress,

Texture Rendering Improvements

[Video 5:30-18:15]

  •  There is a texture streaming overhaul in progress. This changes the number of threads used in texture decoding and how the decoding on the background threads is handled, and should see a noticeable improvement in texture rendering when available & incorporated into viewers.
    • This work will likely be available ahead of the materials work mentioned above, but it has not been determined if it will form a dedicated project / RC viewer or be folded into a Maintenance RC.
    • TPV developers who may have been working recently on the texture threads, may want to take note of this and listen to this portion of the video, given that a number of threads have been removed o eliminate conflicts.
  • Part of this work is focused on trying to get a “good honest answer” from the operating system running the viewer as to how much video memory is actually free for the viewer to use.
    • In general (and despite the VRAM slider) the official viewer typically uses between 512 MB and 2GB of video memory (when available on a system), but runs into trouble trying to balance using anything over 512 MB with the 512 MB “limit”, thus causing issues of texture thrashing.
    • This work will likely see the removal of said slider as well.
  • Once completed, these changes should see the viewer work more “cooperatively” with other applications running on a client system:
    • As video memory is required by other programs, to the viewer will relinquish it; as video memory becomes available, so the viewer will attempt to use it.
    • As video memory is relinquished, the viewer will attempt to “intelligently” unload textures – such as those in the background/occluded, those far away, etc., to reduce the amount of visible texture blurring / unblurring as textures are unloaded /reloaded.
  • This work will hopefully benefit the viewer across all operating systems, although there are issues around getting Mac OS to report the amount of free video memory, and AMD GPUs are also proving a little difficult in their reporting of memory use.
  • The structure being used for the Windows enquiries can be found here.

In Brief

  • [Video 22:50-27:52] Discussion on alpha masking on avatars / rigged mesh, including reports on some content with transparent rigged meshes appearing broken as a result of changes to the draw order.
    • A lot of the reported breakage appears to be the result of creators “cranking the handle” to achieve results, without actually fully understanding either what they are doing or how the viewer’s rendering system works.
    • The changes being made now are part of trying to make the draw order more logically consistent with a view “maybe someday” being able to explicitly set the ordering priority for the draw order.
  • [Video 28:11-36:00] Advanced Lighting Model (ALM) vs. non-ALM (aka “forward rendering”). LL are strongly leaning towards getting rid of the non-ALM rendering path, providing it can be shown that this does not adversely impact performance (e.g. ALM runs roughly as well as non-ALM for those using the latter) on the broad cross-section of hardware most commonly operated by SL users.
    • This may raise concerns among the minority on metered connections (as it will increase the amount of data crossing their network in handling materials, etc.), so consideration is being given to including a “data saving mode” into ALM that will prevent the sending for materials data.
    • Another problem is that of general education. A lot of people still think that enabling ALM means they “must” run with shadows enabled (which does cause a significant performance hit), without realising they can disable shadows from Preferences → Graphics the Shadows drop down. De-coupling automatic shadows enabling from ALM may help rectify this.
    • Similarly, local lights can be a performance hit with ALM as the number can be unlimited, as opposed to the cap of six rendered lights under non-ALM rendering), so the suggestion is to have a slider to allow the user define how many local lights are rendered in their view under ALM.
    • [Video: 38:22-39:48] removing the non-ALM rendering path would also mean the removal of the Atmospheric Shaders checkbox, the avatar cloth checkbox (which user generated content cannot access anyway), the Bump Mapping and Shiny (low, medium high) drop-downs,
  • [Video: 36:10-40:04] The Performance Improvements Floater viewer (still at Project viewer status at the time of writing, and not to be confused with the Performance Improvements viewer now at release status) makes some changes to graphics pre-sets:
    • The object mesh detail is not always set to Low (as per some TPVs already).
    • Changes to max no of non-impostor avatars is based on the graphics quality slider.
    • The core benchmarking for setting all pre-sets has been revised.
    • This work is all part of the “auto-FPS” improvements that for a part of the Performance Improvements Floater viewer.

Date of Next Meeting

Friday, July 8th, 2022.

 

2022 TPVD meetings week #19 summary: PBR materials

RockMead, April 2022 – blog post

The following notes were taken from the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) of the Third-Party Viewer Developer (TPVD) meeting on Friday, May 13th, 2022 at 13:00  SLT. These meetings are chaired by Vir Linden, and dates for them can be obtained from the SL Public Calendar.

Important: as from this meeting, the TPV Developer meeting has moved to a four-week schedule.

Please note that this is a summary of the key topics discussed during the meeting and is not intended to be a full transcript of either. However, the video does provide a complete recording of the TPVD meeting, and timestamps to the relevant points within it are included in the notes below.

Available Viewers

[Video: 0:00-6:22]

On Thursday, May 12th:

  • The Makgeolli Maintenance RC viewer (Maintenance M) viewer updated to version 6.5.6.571575.
  • The Performance Improvements RC viewer updated to version 6.6.0.571736.

On Tuesday, May 10th, the Performance Floater and Auto-FPS project viewer updated to version 6.5.4.571296.

The rest of the currently available official viewer versions remain as:

  • Release viewer: version version 6.5.5.571282 – formerly the MFA RC viewer, dated April 26, promoted Wednesday, May 4th – NEW.
  • Project viewers:
    • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
    • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
    • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

  • The Performance Improvements RC viewer remains the next in line for promotion to de facto release status, the latest update to this viewer awaiting data on crash rates prior to potentially being promoted.
  • MFA Enforcement: the eventual plan with multi-factor authentication (MFA) is to “enforce” it for all users who have opted-in to using it so that when logging-in to SL on a viewer without MFA support, they will see a message requesting they either swap to using one with MFA support or disable MFA from their Second Life account dashboard.
    • It is not clear when such enforcement will commence. However, the official viewer, Catznip, Kokua and Cool VL are all known to support MFA, and an MFA version of Firestorm is in the works, so it is likely that the “enforcement” could come in the relatively near future.
    • There will be no change to logging into the viewer for users who have not opted to use MFA or who decided to disable it on their account.
  • https://viewer-login.agni.lindenlab.com/ is a URL referenced in the viewer log-in code, but is currently a redirect and not actually used. LL is therefore planning on removing it.

Additional Materials Support / PBR

[Video: 7:19-20:36]

Note: please also refer to my recent (April / May) CCUG meeting summaries.

Two area of work are currently in progress.

Materials Assets Support

One element of work is to provide “full” Physically Based Rendering (PBR) materials support utilising the glTF specification.

  • This work is currently focused on implementing a new materials asset type that will allow materials surfaces created utilising the PBR workflow to be imported to SL and then applied to their desired object face(s).
  • LL hopes that creators using PBR will also supply textures entries (e.g. a diffuse map + normal & specular maps (if required) + associated parameters as we know them today in the build floater) so that systems / clients that cannot / do not run the supporting PBR code can display these texture entries instead, rather than leaving objects with blank faces.
    • It has been suggested than any such use of “fallback” texture entries be an automated process, rather than something that has to be done manually by the creator.
    • Longer term, there will be some form of LSL support for this as well, although the extent of this has yet to be fully determined. However, it is liable to be along similar lines to texture application using LSL.
  • Once defined, the materials assets will be stored using the glTF 2.0 specification.

Reflection Probes / Environment Maps

A parallel piece of work is adding sport to SL for reflection probes to update the generation of the environment maps (because the current cube mapping used by SL is limited and would not work will with PBR).

  • The key point here is that the introduction of reflection probes + updated cube maps will work with both “PBR” and “legacy” content.
  • This work has been underway for the last couple of weeks, including input from some content creators / viewer developers.
  • “Outdoor” probes will likely be subject to automated placement, but with a hierarchy applied such that they don’t override probes placed inside structures.

General Notes

  •  In terms of user testing, the approach to this work is similar to that taken with Mesh:
    • Testing will initially be carried out on Aditi (the beta grid) as things develop, allowing various “PBR” and “legacy” content to be uploaded and tested, well before anything is implemented on the main grid or made widely available to users through the viewer.
    • Content creators wishing to test content are strongly advised to join the Discord discussions and join in with testing from there.
  • glTF mesh object uploads: this is on the roadmap of things the Lab would like to include in the initial project. However, depending on how work progresses and time frames imposed, it may not form a part of the initial work that is shipped and slip to being “tackled at some point”.
  • Support for materials variants within the glTF assets (e.g. to allow colour variants in fatpack items) is also under internal discussion at the Lab.

In Brief

  • [Video 21:09-23:30] The simulator fixes for off-line Group and Friend invites failing to update following acceptance should be surfacing on the RC channels in week #20.
  • [Video 22:44-27:40] a discussion on rigged meshes and bounding boxes focused on a change that was made to overcome issues of people creating oversized bounding boxes for their rigged meshes in order to avoid providing LODs (and forcing the viewer to always render them at a performance impact) that was recently reverted.
    • Runitai Linden explained that the revision was actually the result of changes made within the Performance Improvements Viewer that clashed with the rigged mesh bounding box changes, and that there is still an open issue to ensure the rigged mesh bounding box is always an appropriate size.
    • This rolled into a broader discussion on the complexities of rigged mesh visual size, scaling, bounding boxes / LODs selection, impact of the animation system, etc.
  • [Video 28:04-End] The above leads into a discussion on LODs in general and the idea of auto-LODding content vs. (good and bad) custom LOD creation (and what constitutes “good” LOD modelling – e.g. basing on surface area or triangle count?), LOD / LI conflicts, and trying to strike an equitable balance such that LODs can be “properly” defined and used.
    • As this discussion covers a lot of ground, I refer those interested to the video.