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
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 188.8.131.525055 September 19.
- Project viewers:
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
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)
- 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
- 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
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
- 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.
- [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.
- Friday, November 25th, 2022.