The following notes were taken from the video recording of the Third-Party Viewer Developer (TPVD) meeting held on Friday, May 10th, 2024. My thanks as always to Pantera for recording the TPVD meeting and providing the video, which is embedded at the end of this article.
- The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development. This meeting is held once a month the third or fourth Friday, at 13:00 SLT at the Hippotropolis Theatre.
- In regards to meetings:
- Dates and times are recorded in the SL Public Calendar.
- Commence at 13:00 SLT on their respective dates.
- Are conducted in a mix of Voice and text chat.
- Are open to all with an interest in either content creation or viewer development.
- The notes herein are a summary of topics discussed and are not intended to be a full transcript of either meeting.
Official Viewers Status
- The Maintenance X RC (usability improvements) updated to version 7.1.7.8974243247, May 8.
- The WebRTC Voice work was released as a project viewer, version 7.1.4.8947030231, May 8.
- The Puppetry project viewer has been withdrawn.
The rest of the current crop of official viewers stands as:
- Release viewer: 7.1.6.8745209917, formerly the Maintenance Y/Z RC ( My Outfits folder improvements; ability to remove entries from landmark history), dated April 19 and promoted April 23 – No Change
- Release channel cohorts:
- Maintenance C RC (reset skeleton in all viewers), version 7.1.7.8820704257, May 6.
- Materials Featurettes RC viewer, version 7.1.7.8883017948, May 2.
- Maintenance B RC (usability updates / imposter changes), version 7.1.7.8820696922, April 29.
General Viewer Notes
- Maintenance X looks to be the next viewer in line for promotion – most likely in week #20.
- Following the promotion of Maintenance X, the focus will be on getting the Materials Featurettes viewer promoted, as the simulator-side support for this is already available across the Main grid ( although see below).
Viewer Code White Space
- White spacing in viewer code has long been an issue in that it can be a mix of both tabs and spaces.
- A move to standardise on either tabs or spaces has been mooted but never formalised because of the concerns that any bulk change would produce conflicts in things like code merges.
- Signal Linden has been investigating this, and found that providing an appropriate command line option is given, such conflicts between white space using tabs and white space using spaces can be avoided.
- As a result, the current Maintenance X viewer does standardise white space.
- To avoid potential conflicts when merging to this code base after Maintenance X goes to de facto release status, Signal has produced documentation on how to make such a merge.
- Those involved in viewer development (TPVs and self-compilers) are encouraged to read this documentation prior to merging with Maintenance X.
Graphics / Materials Featurette Update
- The is the viewer with the new PBR terrain code, support for 2K texture uploads, and PBR mirrors.
- The Graphics team believes all issues considered to be showstoppers for this viewer have now been fixed, and the viewer is going through what is hoped will be a final QA pass.
- However, there is one remaining issue which can crash the viewer, but this might be down to running the viewer on unsupported hardware as much as requiring a fix.
- Remaining issues / updates will be handled through the main glTF development branch of the viewer.
- As the server team has switched to the Git Flow Git branching strategy, and there are conversations about moving to this for the viewer as well.
- As such, the glTF development branch is a step towards the use of Git Flow.
- If the approach works for the glTF work, it will likely be adopted for all viewer development work.
- There was a brief debate as to whether the Featurettes viewer will be available for promotion sooner rather than later, with Dan Linden indicating that there is still “quite a bit of testing” still to be done.
glTF Scene Import
- More generally covered in my CCUG meeting summaries.
- This is a glTF project to allow glTF scenes (objects, materials, animations, etc) can be imported to SL as assets and brought in-world as a series of nodes rooted in a prim, with the nodes updated with both tools in the viewer and / or using LSL, and ensuring they stay in synch with all viewers looking at them.
- Overall, the idea is a “one touch” import to get a scene from Blender to SL, where it should appear exactly as it is in Blender, modify it as required in SL via the build tools / LSL or – subject to permissions – export it back to Blender for update.
- Currently at the prototyping stage, with test viewers and test regions on Aditi able to preview a scene (that is, see it within the viewer without the scene being physically imported into SL) for reference purposes, .
- Work is “almost” at a point where a scene can actually be uploaded to SL and stored as an inventory asset and then downloaded and rendered by the viewer – although more back-end work (such as with the CDN pipes) needs to be carried out.
- There are multiple questions still to be addressed concerning the overall data model (LOD generation, LI, linking etc., scene export (for updating) and working with the SL permission system, physics / collision shapes, etc.), so definitive answers to question on these topics cannot be properly addressed at present.
- A video demonstrating how this works can be seen at 44:43.
- This moved into a general discussion on the glTF work – please refer to the video below and my CCUG updates, as linked to above.
WebRTC Voice Update
Summary
- A new project intended to move Second Life away from reliance on the Vivox voice service and plug-in, and to using the WebRTC communications protocol (RTC=”real-time communication”).
- Roxie Linden is leading this work.
- WebRTC is something of a “defacto standard”, being built-in to most web browsers and supporting wide range of real-time communications tools in common use (e.g. Google Meet), supporting audio, video and data communications.
- In terms of audio / voice (the primary focus here), WebRTC has a number of standard features expected of audio communications services (such as automatic echo cancellation, better noise cancellation and automatic gain control, etc.) and offers much improved audio sampling rates for improved audio quality.
- WebRTC will be supplied within the viewer using a library and wrapper. This will mean no requirement to run a third-party voice plugin (SLvoice.exe, as supplied by Vivox) going forward.
- Care is being taking to address potential security issues (e.g. preventing eavesdropping, exposing users’ IP address (by using an internal proxy server), etc.).
- The switch to WebRTC also opens the door to adding new features and capabilities to SL Voice, some of which have been long-requested.
- Feature requests for WebRTC made via the WebRTC board on the SL Feedback Portal are being evaluated and some are being actioned, together with issues being investigated.
- LL will be looking to Linux devs to help give feedback on how well WebRTC is working on their Linux viewers.
Status
- As noted above, a WebRTC project viewer is now available via the Alternate Viewers page.
- Viewer work is currently focused on bug fixing, and the hope is the viewer will move from project status to RC status “pretty shortly”.
- The overall hope is that as WebRTC is a library + wrapper, changes will be fairly localised within the viewer, speeding the implementation process.
- The schedule for WebRTC is described as “pretty aggressive” and TPV developers are encouraged to look at the code repository.
- Work is in progress / has been completed on getting a simulator Snack RC channel set-up with the required back-end support for WebRTC voice – but this will be spatial voice only, not peer-to-peer / Group or ad-hoc Voice communications for the time being.
- Region names for this channel were not given at the meeting.
- In line with the aggressive viewer development cycle, the team is looking to have WebRTC support available across at least one full RC channel by the end of June (simulator update schedules permitting) and potentially have the back-end support live across the Main grid by the end of July 2024.
- Those wishing to test peer-to-peer, Group and ad-hoc Voice via WebRTC can do so via the Aditi (Beta grid) webRTC1 test region.
- There will be further updates to the WebRTC library during the development cycle, as the Lab updates to the latest releases from the WebRTC open-source development website.
- As the work progresses, there will be a blog post to provide and overall update on the work, including the proposes schedule for deployment and explanations of any caveats / potential roughness during the transition (see below as well).
WebRTC and Vivox Voice Support
- The initial versions of the viewer (project and RC) will support both WebRTC and Vivox for Voice.
- As peer-to-peer / Group or ad-hoc Voice support for WebRTC is added to the back-end, things might “get a little weird” as the viewer swaps between WebRTC and Vivox, but Roxie Linden is trying to ensure things are correctly negotiated (e.g. if there is a Group chat going on with everyone using WebRTC, and someone joins from a region still using the Vivox back-end, the viewer will negotiate everyone to using Vivox.
- This means that for purely testing WebRTC for Group, peer-to-peer and ad-hoc Voice (as support for these are added to the simulator code), it is important for all testers to be on regions with WebRTC support only.
- Voice will not travel across region boundaries between regions using WebRTC and Vivox (and vice-versa)
- This should not be an immediate issue, but might become noticeable during the transitional period when WebRTC support is being deployed across the main simulator RC channels and before it is grid-wide.
- Voice will obviously work across regions using the same voice service (e.g. between regions which are both running WebRTC).
- Given the aggressive schedule for the work, it is hoped that support for both WebRTC and Vivox within the viewer will be for a limited duration.
SL21B – glTF and Blinn-Phong
- To ease the workload for creators building for SL21B (opening on Friday, June 21st, 2024), Linden Lab has stipulated they do not have to include Blinn-Phong (aka “SL legacy materials”) fallbacks in their build if they opt to use glTF PBR materials.
- This means viewers, in keeping with the expected behaviour, should only display the glTF materials, and should not under any circumstance attempt to display any fallback (as doing so will result in content rendering as grey or white objects).
- This is likely to impact any viewers that do not support PBR materials (and content will not look “right”).
- However, the above should not be taken to mean that LL are looking to “get rid of” Blinn-Phong (e.g. objects have been created using Blinn-Phong only, they will continue to display using Blinn-Phong reflections, etc.).
- Runitai Linden also noted:
Sometime between now and then, we’ll likely start making the LSL scripts that modify Blinn-Phong parameters modify their PBR equivalents, or do nothing when a PBR material is applied. So llSetColor, for example, would set the base colour, not the diffuse colour. That should make life a lot simpler for scripters going forward, as scripters have been giving us feedback that trying to do something simple like that with existing scripts is impossible as they have to do a check to see if a glTF material is applied, and if there is then use llSetPrimParams and if there isn’t, use llSetColor.
- It was unclear if this will require a conversion to linear colour (as glTF uses SRGB), given the LSL for GLTF_BASE_COLOR requests linear colour – or whether there is a conversion from linear colour to SRGB when using GLTF_BASE_COLOR. This is to be looked into.
In Brief
- [Video: 30:10-37:47] 2K textures:
- There have been concerns raised over “abuse” of 2K textures (e.g. people being “forced” to use them because “everyone else is”).
- Runitai Linden is of the opinion that with functional texture streaming, use of 2K textures is not as big a problem as is being presented in some cases, because the full 2K texture is not necessarily downloaded rendered by the viewer until the viewer zooms right in on the object face using it; otherwise the texture should be displayed at the pixel resolution (e.g. if the face is only taking up 64×64 pixels, then the 64×64 version of the texture is selected and used.
- Bakes on Mesh support for 2K textures: this is currently not a project under consideration, but the Lab acknowledged that this might need to be re-thought in terms of what is required and scheduling priority.
- It was noted that updating the Bake Service would not be sufficient for 2K texture use, as the service also composites wearable textures, so the allowed texture resolution for all wearable layers will have to be updated in order for BoM to effectively support 2K textures.
- That said, updating BoM to support 2K textures is seen by the Lab as a matter of “when” and not “if”. In this, it was further noted that support for the work being shown through the Feedback Portal from users will help LL determine / re-evaluate the priority of the work compared to other projects.
Next Meeting
- 13:00 SLT, Friday June 7th, 2024, at the Hippotropolis Theatre.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.