2022 week #50: CCUG and TPVD meetings summary

Power up for Charge, October 2022 – blog post
The following notes were taken from:

  • My audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, December 15th 2022 at 13:00 SLT.
  • My chat log transcript and video recording by Pantera Północy of the Third-Party Developer Meeting (TPVD) held on Friday, December 16th, 2022 at 13:00 SLT. My thanks to her for the video (embedded towards the end of this article).

These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar; also note that the following is a summary of the key topics discussed in the meetings and is not intended to be a full transcript of either meeting.

Official Viewers Status

[Video: 1:44-2:13]

Available Viewers

  • On Friday, December 16th, Linden Lab issued the Maintenance (Q)uality RC viewer, version 6.6.9.577220, with several new features and various fixes.
  • On Wednesday, December 14th, the Love Me Render (LMR) 6 graphics improvements project viewer updated to version 7.0.0.577157.

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

  • Release viewer: Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.8.576863 Monday, December 12 – NEW.
  • Release channel cohorts:
    • Performance Floater / Auto-FPS RC viewer, version 6.6.8.576737, November 28.
    • VS  2022 RC viewer, version 6.6.8.576310, issued November 4 – utilises Visual Studio 2022 in the Windows build tool chain.
  • Project viewers:
    • Puppetry project viewer, version 6.6.8.576972, December 8.
    • PBR Materials project viewer, version 7.0.0.576966, December 3.
      • This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.

CCUG Specific

glTF Materials and Reflection Probes

Project Summary
  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • To provide support for reflection probes and cubemap reflections.
  • The overall goal is to provide as much support for the glTF 2.0 specification as possible.
  • The project viewer is available via the Alternate Viewers page, but will only work on the following regions on Aditi (the Beta grid):  Materials1; Materials Adult and Rumpus Room 1 through 4.
Status
  • Please also see previous CCUG meeting summaries for further background on this project.
  • The focus remains on bug and regression issue fixing within the viewer and quality of life improvements.
  • There has been a discussion on revising the workflow for setting reflection probes & in providing a debug setting to make things easier to see when manipulating reflection probes.
    • This has been prompted be those testing the PBR viewer setting-up their own reflection probes incorrectly (e.g. by making the probe sphere / cube shiny prior to converting it to a reflection probe – which should NOT be done), failing to achieved the anticipated results and then filing bug reports.
    • It is possible that some of the required workflow could be factored into the UI itself to off a more intuitive sense as to how reflection probes are supposed to work.
    • An alternative to this might be to introduce a new “reflection probe” prim type, which includes all the core parameters – however the additional work and messaging required to achieve this would lead to a further lengthening of the project’s development time.
    • Tutorials to help people get to grips with reflection probes (and, I presume, PBR as a whole are “in the works”).
  • Screen Space Reflections (SSR): Geenz Linden is working on this within the PBR viewer. Whilst a checkbox for SSR has been added to the viewer, there is further work to be done on the integration and rendering sides (e.g. getting SSR to work on water & transparent surfaces).
  • Hardware profiling / optimising the viewer is still on-going (although it is likely that whatever is done, SSR will result in a noticeable performance hit if enabled).
  • [TPV Video: 9:11-10:44] The decision has yet to be made on whether or not to axe the forward rendering (i.e. non-ALM) path from the viewer.
    • This decision is awaiting more information on hardware performance on lower-spec systems using the updated deferred rendering (i.e. ALM) rendering path.
    •  It is known that Mac rendering performance on the PBR viewer is particularly bad, which may be down to a configuration issue.

In Brief

  • Mirrors (in some capacity) are described as the “very next thing” the graphics team will commence work on after the PBR / reflection probes work gets to RC status (as Vir Linden pointed out, Mirrors currently require more reflection on how they are to be implemented!).
  • The meeting in places broadened into general discussion on content breakage (and the need, where possible, to maintain the functionality of content users have purchased in expectation of its longevity; the benefits / disadvantages with morph bones versus blend shapes for customising the avatar shape (and the possible routes to an “avatar 2.0”), the need for a better animation system (or even an actual animation system), etc.
    • Much of this was more esoteric in nature at this point in time, although the likes of Puppetry is laying the foundations for broader animation work; as does the glTF 2.0 specification, which is the baseline specification for the PBR / reflections probe work, and will be expanded upon in future projects  – such as with mesh uploads.
    • In terms of animation systems, some of the groundwork is already in place inasmuch as SL already effectively treats morph bones and animated bones as individual animation tracks, offering to potential for this to ne “unwrapped” and moved to a glTF approach to animation management.
  • Some of the above conversation touched on the ideas of market renewal / fragmentation. For example: the introduction of reflection probes offers a degree of market renewal for creators of buildings, skyboxes, etc., through the provisioning of new builds (or new versions of existing builds) leveraging the capability; however, the adoption of an upload schema for fully customised avatar skeletons might lead to greater market fragmentation (how do you ensure, for example, that human animation/pose A will work equally on custom human (style) avatar skeletons W, X, Y and Z, or will they each require custom animations?).

TPVD Meeting Specific

Inventory Thumbnails

[Video: 2:25-7:08]

  • A new project (commencing in 2023) to add thumbnail previews to inventory, allowing users to see a small image of a given object within inventory (thumbnails can be individual items or, if preferred an entire folder).
  • The first phase of the work is determining how to generate the thumbnail images in the first place on a manual or (preferably) automated basis, and then ensure it maintains an association with the object to which it is related (e.g. so if an item is sold or transferred to another user, the thumbnail goes with it).
  • Once this has been decided, the next phase will be to build-out the UI so that such thumbnails can be viewed from inventory
  • It is likely that thumbnails will have a fixed / limited size resolution, and will not be subject to any upload fee.
  • This work:
    • Is not an adjunct (or related) to the Outfit previews currently available in the viewer.
    • Will not prevent creators from including high resolution images with their products if they wish.
    • Will only apply to inventory objects where it makes sense (e.g. textures and notecards would likely be excluded).
    • Is seen as a possible foundational piece to adding new fields to the inventory database, which could open the door to further information fields being added to inventory in the future,

Github Move “Phase 2”

[Video: 7:12-8:18]

  • Following the switch-over to using Github for viewer code repositories on Monday, November 21st, 2022, work is now progressing on “Phase 2”.
  • This is remaining TeamCity operations with Github Actions for viewer builds (so those pulling an official viewer repo will be able to build it directly).
  • This work will also incorporate the rebuilding of those third-party libraries involved in the viewer build process, as and where required.

In Brief

  • [Video 16:10-18:41] LL has been digging into viewer crash rates by operating system, with the note that the number of crashes on the Mac OS appears to be disproportionately high. It is hoped that if the underlying causes can be readily identified, these issues can be subjected to rapid fixing. It was not clear at the meeting if those TPVs supporting OS X are seeing a similar elevated crash rate.
  • [Video 20:40-21:35] It is estimated that the split between viewer operating systems for the official viewer  is roughly:
    • 1-2% Linux (although this does not include running the Windows viewer under emulation on Linux).
    • 6% Mac.
    • The rest: Windows.
    • Firestorm appears to mirror the above.
    • [Video: 35:08-36:10] It is possible the the work on the viewer library refresh will allow LL to look again at the issue of providing a Linux viewer build.
  • The meeting has a general discussion on operating systems, & variants (64-bit vs. 32-bit), etc, and the lack of an official Linux build,
  • A reminder that Microsoft ceases official support for Windows 8 on January 10th, 2023. This means that from that date, Windows 8 will no longer be officially supported by Second Life as a viewer operating system, and LL will not guarantee the viewer will run as expected on Win 8 going forward from that date.

Linden Lab Holiday Closure

A reminder that Linden Lab will be effectively closed (outside of Support cover) from end of business (PST) on Friday, December 23rd, 2022 through until start of business (PST) on Monday, January 2nd, 2023.

Next Meetings

  • CCUG: Thursday, January 12th, 2023.
  • TPVD: Friday, January 20th, 2023.

2022 week #46: CCUG and TPVD meeting summaries

Vue Sur Mer, September 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, November 17th, 2022 at 13:00 SLT.
  • My audio recording and chat log from the Third-Party Viewer Developer (TPVD) meeting held on Friday, November 18th, 2022 at 13:00 SLT. Pantera attended the meeting, but was unfortunately held-up beforehand, so around the first 10 minutes is absent from her video (embedded at the end of this summary).

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

[Video: 0:00-2:00]

Available Viewers

The following reflect the list of current official viewers available through Linden Lab.

  • Release viewer: version 6.6.7.576223 – MFA and TOS hotfix viewer – November 1.
  • Release channel cohorts:
    • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.8.576431 on Monday, November 14.
    • VS  2022 RC viewer, version 6.6.8.576310, issued November 4 – utilises Visual Studio 2022 in the Windows build tool chain.
  • Project viewers:
    • PBR Materials project viewer, version 7.0.0.576331, issued on November 3.
      • This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
    • Puppetry project viewer, version 6.6.3.575529,  issued on October 12.
    • Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
    • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.

General Viewer Notes

  • There is unlikely to be any major changes to the list above in week #47, as this is a short working week for the Lab due to the Thanksgiving holiday (Thursday / Friday).

Github Changeover and Streamlining the Code Contributions Process

Github Work

As previously announced, there 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 is still no firm date as to when the actual switch-over to using the new repositories will occur, but the viewer development team is working steadily towards it, and the plan remains to provide plenty of advanced warning to TPVs on when LL plan to cut over to the new repositories before making a clean cut-over.

Status

  • The switch-over to using Github is now slated for “early in the morning” (PST / SLT) on Monday, November 21st, 2022.
  • This means that from the point of switch-over, the Bitbucket repositories will be locked and carry a warning that they are no longer current, and developers / viewer builders should use the GitHub repositories, as directed to in the warning.
  • The master viewer branch is already up-to-date on GitHub as of Friday, November 18th, 2022.
  • Notes on the switch-over were posted to developers on the open-source developers list.
  • There is no plan in place to phase out the Bitbucket repositories immediately, but they may well be removed in time.

PBR: Materials and Reflections

Project Summary

  • To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
  • To provide support for reflection probes and cubemap reflections.
  • The overall goal is to provide as much support for the glTF 2.0 specification as possible.

Status

  • Please also see previous CCUG meeting summaries for further background on this project.
  • The  viewer is available as a project viewer via the Alternate Viewers page, but will only work on the following regions on Aditi (the Beta grid):  Materials1; Materials Adult and Rumpus Room 1 through 4.
  • The focus is currently on reviewing bugs reported by those testing the viewer, and creators using glTF PBR workflows to create content are encouraged to test out their content on the project viewer to ensure things look as expected when imported into SL.
  • One aspect of SL that does require testing is EEP assets; changes have had to be made to the shaders which mean that commercial EEP settings may not render as expected (things like haze density my  be modified, etc).
    • EEP creators may therefore want to test their settings using the project viewer, and Jira issues – please include “non PBR viewer” shots of how the settings should look and shots taken with the PBR project viewer for easier comparison / understanding of the issues seen.
  • Issues with alpha blending are being investigated – particularly linear space alpha blending and how best to carry forward “pre-PBR” alpha blending, which does not use linear space.
  • It has been reported that the PBR project viewer generating some 10% more CPU temperature and 17% more GPU temperature – this may be the result of the viewer having to work that much harder with PBR in order to maintain frame rates.
  • Reflection probes: concern was again raised over people excessively using probes (e.g. attaching them to all their products / objects they own).
    • Providing a means for users to disable probes attached to objects they purchase has been previously discussed within the project / CCUG meetings.
    • It is hoped the latter (people just randomly setting-up probes all over their house / land) can be mitigated against through a mix of education and explicit warnings / actions in the viewer.
    • Concern was also raised about the potential of localised reflection probes (essentially an invisible prim) could interfere with intended interactions (e.g. a probe enclosing a chair could block people’s ability to sit on the chair). If cases like this are found in testing, a request has been made for bug reports.
    • The PBR viewer does include a Build / Edit option to “ignore invisible prims” so that when building / editing, an attempt to select an object within the volume of a reflection probe prim will ensure the object is selected, not the probe prim, but it is acknowledged that this kind of operation needs to be better integrated with other mouse click options.
  • (TPV Meeting video)
    • It was noted that this project also marks the start of the deprecation (and eventual removal) of some real-time console performance reports, such as Fast Timers.
    • It has been reported that some testing the PBR viewer are finding that within the texture console, Bias is constantly being reported at 5 (which tends to cause texture thrashing in non-PBR viewers). However, within the PBR viewer  a Bias of 5 should indicate that the viewer is swapping – and keeping to – a lower texture resolution, and so should not result in any texture thrashing.

Screen Space Reflections (SSR)

  • LL does have a “subtle” SSR system working to replace Linden water reflections as currently rendered.
  • There is some further work to be carried out before it is “viewer-ready”, with the focus being on ironing out the bumps and cleaning-up bugs.
  • It was made clear that while this implementation of SSR will be applicable to scenes as a whole, it is not intended to be a replacement for creating mirrors – and so expectations should be set accordingly.

CCUG Meeting Specific Notes

The majority of the meeting was given over to a general discussion, per the cliff-notes below:

  • VR hardware and Second Life:
    • While frame rates are not so much an issue now in broad terms, there is still the need to get a high frame rate on a consistent basis for VR viewing to be enjoyable – and this is still not a giving with SL.
    • However, VR isn’t just about headsets; its about the “full” experience in using a range of associated peripherals: controllers, haptic gloves, the ability to have a “full-body experience” that VR users would want and expect, such as seeing your hand and arm when going to pick something up, being able to grip an object in your hands and feel responses from it when using it (e.g. the strike of a blade against another or a baseball sat against the ball, etc.).
    • The level of support for this more complete sense of immersiveness requires some extensive re-engineering of Second Life (e.g. facilitating a full and proper Inverse Kinematics system  as a single example).
    • The Puppetry project may facilitate some work towards this. However, the focus of this project is not on providing any form of in-depth VR support (it is intended to work with a broader range of peripherals, notably webcams, although use of some VR software support via OpenVR is being considered), being intended for use by as broad a cross-section of SL users as might be interested in it.
    • Another problem is determining what people want from VR; is it purely a mechanism for games, or does it need to be capable of “realistic” social interactions (some do still proclaim games, other demand social capabilities; the truth is probably more a blending of the two, just like life in the physical realm).
  • New users and their experience:
    • Much was made of the need for a completely new avatar system (LL is actually working on a new all-mesh “starter avatar”, but using the existing skeleton) – but overhauling / replacing the current avatar system raises its own compatibility / market issues.
    • A fair point was raised by LL concerning the use of eviction / ban scripts that specifically ban avatars that are less than X days old and / or avatars that do not have Payment Information On File.
      • These tend to get used at event spaces etc., to try to prevent griefers / trolls using throwaway accounts from accessing the space, rather than using other available moderation tools (which, admittedly tend to require human intervention with the right permissions, which might not always be available).
      • The problem here is that often, a “genuine” new user will often sign-up, go through the new user experience, then try to go to a event – only to immediately find they are denied entry or are ejected without warning or explanation, and as a result, they log-out.
      • The need for improved tools to handle griefing and trolling are likely required – but no discussion on what form these might take.
  • Audio: a general conversation on the potential of “full” spatial audio, including directional (e.g. so an audio stream at a disco appears to be coming from the speaker system in the venue) and also sound volumes.
    • Nothing is currently planned for audio in the roadmap, but it was noted that the first test of using volumes (reflection probes) is in Aditi testing, and LL will obviously seeing how well that works.
  • It  was made clear that scripts will “NEVER” be allowed to create new assets (so no ability to generate notecards from a script). One of the reasons cited for this is the cost of storing assets if there is an uncontrolled ability to generate them through scripts (particularly given SL’s asset count is already in the petabytes range in terms of storage).

TPVD Meeting Specific Notes

Atlassian Jira and Bug Reporting

  • Atlassian has announced it will be restructuring how it licenses the Jira bug reporting product from 2024 onwards. Currently, LL can run a public-facing Jira reporting system that effectively allows every Second Life user to create an account on it to view all the public SL bug reports and feature requests.
  • Under the 2024 pricing restructure (which will be pretty much per-account), this will be prohibitively expensive for LL, so they are starting into the process of looking for an alternative means to provide some form of user-facing bug reporting mechanism.
    • one option being considered is to continue to use Jira internally (where the number of licensed accounts can be controlled), and use a different mechanism for public bug reporting, with a bridge between the two.
    • Another is to move away from Jira entirely.
  • No decision has been made as yet, but as Firestorm also use Jira, the suggestion has been made that the two develop a joint plan to resolve the situation in terms of future tools.
  • The topic lead to a general discussion on possible options, but no conclusions drawn – and there is sufficient lead-time on the matter for various options to be looked into, allowing for the time required to transition to any alternate that might be selected / finding the means to keep the wealth of information on the SL Jira available for reference.

General Notes

  • There is a report that Active Voice on at least some viewers is not updating correctly (e.g. following a teleport, and it is proving easier to enable  / disable Voice morphing vie the menu than to disconnect / reconnect Voice in order to correct.
    • The issue here is not so much which is the preferred method to correct the problem, but whether the Active Voice list failing to update is a widespread issue with viewers, and whether it can be reproduced on the official viewer & a bug report raised.
  • Beq Janus has written a post on alpha blending issues (see: Alpha blend issues? Get them sorted – subtitled Making it easier to avoid alpha-clashes with Second Life and OpenSim outfits). Rather than have me  decimate the discussion, please refer to the video fat 35:56 through video end for more.

Next Meetings

  • CCUG: Thursday, December 1st, 2022.
  • TPVD: Friday, December 23rd, 2022.

2022 week #43: TPVD meeting summary – with PBR updates

Raion No Su, August 2022 – blog post

The following notes were taken from Pantera’s video recording of the Third-Party Viewer Developer (TPVD) meeting held on Friday, Third-Party Viewer Development meeting held on Friday, October 28th, 2022 at 13:00 SLT. 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. 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 the meeting and is not intended to be a full transcript.

Official Viewers Status

[Video: 0:00-2:00]

Available Viewers

The Maintenance (N)omayo Hotfix viewer was promoted to de facto release viewer on Wednesday, October 26th, 2022.

  • This is an urgent fix for transparency “alpha” blending issues. In cases of many layers of textures that included transparencies, this would cause some of the lower layers to not render at all. There are no other functional changes.

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

  • Release channel cohorts:
    • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
  • Project viewers:
    • Puppetry project viewer, version 6.6.3.575529,  issued on October 12.
    • Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
    • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.

General Viewer Notes

  • 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 is still expected to appear as a RC viewer Soon.
  • The Windows viewer built using Visual Stood 2022 is now awaiting its debut as a RC viewer, also expected Soon.

Github Changeover and Streamlining the Code Contributions Process

[Video: 2:56-8:08]

Github Work

As previously announced, there 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 is still no firm date as to when the actual switch-over to using the new repositories will occur, but the viewer development team is working steadily towards it, and the plan remains to provide plenty of advanced warning to TPVs on when LL plan to cut over to the new repositories before making a clean cut-over.

Code Contributions Process

Alongside of this work, Linden Lab would like to streamline the current open-source code contribution process for the viewer. Under consideration for this are:

  • Simplifying the language within the contributor licence agreement (CLA) from the current version to something very much like this Github preview (top level here) – which has the backing of the Lab’s legal department.
  • Automating the acceptance / signing process, potentially by implementing a new pull process for contributions such that:
    • If the contributor has not signed the CLA, the request will be flagged as requiring a CLA and the contributor will receive a request to review and sign the new CLA using a bot process (possibly this one).
    • Once the CLA has been signed, the flag is cleared, the pull request is accepted, and the contributor’s details are securely recorded as having signed the agreement so there is no further need for them to review / sign the agreement on subsequent pull requests.
    • Note: as this will be a new CLA process with revised wording in the agreement, anyone who has previously signed a CLA with the Lab will also be required to sign via the new process the first time they submit a pull request.
  • The work is being led by Signal Linden, who has requested that anyone who contributes code to LL for the viewer contact him with any questions / concerns they may have with the proposed approach / language in the revised CLA.
  • Documentation on the new approach will be provided once the process has been finalised and is ready to be introduced.

Linkset Data (LSD)

[Video: 8:24-10:50]

  • As noted in my week #43 Simulator User Group (SUG) update, the planned deployment of the Linkset Data capability had to be postponed during a fall at the final QA hurdle.
  • At the time of the TPVD meeting, the deployment – the simhost RC channels – looks set to go ahead in week #44.
  • Additional notes:
    • A JIRA feature request has already been submitted asking for Linkset Data to be viewable through the viewer, and this will likely be added at some point in the future.
    • There will be an article on the significance of this change appearing in this blog following the RC deployment.

PBR: Materials and Reflections

[Video: 11:02-13:50]

  • Please also see previous CCUG meeting summaries for further background on this project.
  • Issues have emerged in messaging between the viewer in which materials are being manipulated and the simulator, and between the simulator and other viewers (so everyone is seeing the same thing), together with colour matching issues. These are currently being looked at by Runitai Linden.
  • The hope is that once these issues have been cleared, the viewer code should be in “pretty good order” for a formal project viewer to be made available for “open alpha testing” by all who wish to test the capability and offer feedback.
    • As with the “closed alpha” versions of the viewer, this will only work on the simulators on Aditi (the Beta grid) which have been updated with the PBR back-end support.
  • During the entire “alpha test” period on Aditi, LL reserves the right to completely wipe the test regions & desynchronise any viewers using them (to force viewer updates as bug are fixed / changes are made), so it is important the regions are only used for testing.
  • Once LL is confident with the back-end support and the stability of the viewer, then the simulator code will be extended to all of Aditi.
  • Once there is high confidence that the asset format will not have to change, the permissions system is being respected and there are no security issues, then deployment on Agni (the Main grid) will commence.

Reflection Probe Mutability

[Video: 15:15-28:00]

As per my week #42 CCUG meeting summary, there are concerns about reflection probes being used incorrectly / causing issues, particularly in the case of objects using their own reflection probes being sold as No Modify.

  • In summary:
    • Because the use of reflection probes is arcane and there is no guarantee those trying to employ them will do so “properly” – that is, creators will start adding them to all of their in-world products because they “look good”.
    • The issue here is, when all such products are put in one setting – such as a room – they effectively “compete” with one another, demanding viewer resources (whereas a single reflection probe within the room would do the same without being resource-heavy).
  • The above isn’t a problem where goods are sold with Modify permissions (allowing the user to make adjustments), but has been seen as potential problematic in the case of No Modify items sold with a reflection probe.
  • Therefore, the suggestion has been made to have reflection probes (and also lighting sources, which suffer a similar problem) mutable via check boxes within the build floater’s Features tab, so that users can disable what they see as unnecessary object-related probes and lighting within their scenes, even for No Modify items.
  • The general feedback during the week #42 CCUG meeting leaned towards this being viewed positively – although no conclusion was drawn; the idea was also looked upon with favour at this meeting.
  • In terms of disabling lighting, Runitai noted that disabling Full Bright would not be a part of making reflection probes / lighting sources mutable, as Full Bright has its own complexities.
    • This lead to a discussion on the pitfalls of Full Bright objects within scenes, breaking the visual fidelity of a setting (in the eyes of the observer) and the need to offer those viewing them a degree of control to eliminate them from their world-view, issues of how to control at the parcel level & the additional problem of dealing with avatar-attached Full Bright objects (although muting the avatar wearing the objects should eliminate this issue). Please refer to the video for specifics.

Removal of Forward Rendering and Possible Project Impact

[Video: 42:49-46:15]

  • As per past CCUG meeting summaries, LL had planned to disable all forward (non-ALM) rendering from the viewer with the release of the PBR Materials viewer.
  • Due to feedback voicing concern of this move, LL now plan:
    • To use November for further viewer rendering optimisation in order to try to ensure deferred (i.e. ALM enabled) rendering offers decent frame rates on as broad a selection of client hardware using SL as can be reasonably accounted.
    • At the end of this period of optimisation, a final decision will be made on whether or not to push ahead with disabling forward rendering or to maintain it.
  • If the decision is in favour of keeping forward rendering, then:
    • This will “almost certainly delay the release of the PBR Materials viewer”.
    • Should forward rendering be maintained, it will not have any PBR support going forward, and the Forward renderer itself would likely be changed so it is more like Forward+, and less like OpenGL Fixed Function.

In Brief

  • [Video 15:33-20:16 – via text] with the promotion of the official Legacy Profiles viewer, LL removed the means for uses to update their Profile pictures via the web feeds. This led to some upset among TPV users as the latter merged and released the code, as no forewarning of the change was given by LL for TPVs to pass on to their users. LL has noted the issue & will attempt to ensure clarification of such changes is given in advance in future.
  • [Video 28:04-37:37] a discussion on the merits (or otherwise) of trying to decrease the number of deltas between LL’s core viewer code and TPVs code bases in order to make merges and general code modification easier, particularly with core functionality.
    • This included a somewhat lengthy discussion on trying to standardise the use of things likes spaces and tabs in code headers, etc. (LL tend towards spaces and will likely continue to do so, at least some TPVs use tabs), and how best to achieve this – a discussion to be carried forward via the open source developers mailing list for discussion.
    • It was also noted that some of the deltas are the result of LL tending towards trying to keep the viewer “simple” to make it easier for newer users, and some TPVs trying to fulfil the needs of more established users by offering functions and capabilities LL have tended to retain as debug settings or turn down (if contributed), which can give rise to additional divergences in code, complicating merges – no definitive decisions were reached, and I refer readers to the video for the full context of the discussions.
  • [Video: 39:59-40:40] LL’s offices will be closed for the Christmas / holiday period from Friday, December 23rd through to start of business on January 2nd, 2023. This means week #52 of 2022 will be designated a No Change period without simulator official viewer releases, and a request the TPVs avoid releases that week. The US Thanksgiving No Change window is still TBA.
  • The last part of the meeting formed a general discussion on rendering, graphics, LL’s commitment to older hardware in common use as far as possible. Please refer to the video for the discussion;  however key points might be:
    • LL are not looking to “raise” the minimum specifications for minimum hardware required to run SL.
    • Rather, that are looking to revise the specifications to indicate what APIs are required in order to run SL (e.g.: Graphics: OpenGL 3.x (minimum); OpenGL 4.x (recommended).
    • The PBR Materials viewer will see OpenGL 2.x deprecated. However, it is estimated that less that 0.5% of Windows systems which use OpenGL 2 (OpenGL 4 has been available for more than a decade), and this is likely to be the result of a failure to update or the fact the hardware is being used by a bot service, rather than in any inability for it to support OpenGL 3 or later.
    • A reminder that Window 8.1 officially reaches end-of-life with Microsoft on January 10th, 2023, as so after that date will be regarded as no longer supported by LL.

Next Meeting

  • Friday, November 25th, 2022.

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

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.