Tag: Content Creation 2022

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, March 17th 2022 at 13:00 SLT.
• My audio recording and the video recording by Pantera (embedded at the end of this piece, my thanks to her as always for recording the meetings) from the Third-Party Viewer Developer (TPVD) meeting on Friday, March 4th, 2022 at 13:00  SLT.

These meetings are chaired by Vir Linden, and their respective dates and times can be obtained from the SL Public Calendar.

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

Available Viewers

[Video: 0:35-3:15 + notes from CCUG]

• The Performance Floater project viewer updated to version 6.5.4.569531, on March 18th. This viewer includes the Lab’s implementation of automatic adjustments to the viewer to try to maintain FPS. Monday, March 21st: Appears to have either been rolled back, or update to official viewers list was premature.

The list below reflects the rest of the currently available official Second Life viewers:

• Release viewer: version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – 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).
  • MFA RC viewer, version 6.5.4.569309, issued on March 15.
  • Performance Improvements RC viewer version 6.6.0.569349, dated March 14.
  • Lao-Lao Maintenance RC viewer, version 6.5.4.569191, issued on March 11.
• Project viewers:
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• It is hoped that those using the official viewer and who are in the Performance Improvements RC cohort (or opt to manually install this viewer) will see noticeable performance improvements in terms of frame rates and fewer viewer stalls, when compared to previous SLV releases.
  • The RC has already seen some new bugs raised against it, and these are being worked on (e.g. BUG-231936).
  • It is still hoped this will be the next promotion to de facto release status, but this hinges on bug fixing and a decision on whether or not to release MFA as a dedicated viewer.
  • It is acknowledged that the work in this viewer and the Performance Floater project viewer needs to be reconciled with the work carried out by Beq Janus of the Firestorm team, whose code will be in the upcoming Firestorm 6.5.3 release.

MFA Viewer

• Summary:
  • Multi-factor authentication (MFA) is coming to the viewer.
  • As MFA is implemented in the official viewer, there will be a “grace” period to allow TPV adopt the viewer code.
  • During this period, users will be able to access SL on TPVs as they currently do now, regardless of whether or not they have opted-in to MFA.
  • After this “grace” period, all users who have opted in to MFA will be required to authenticate themselves when using any viewer to log-in to Second Life (with the usual 30-day period of valid authentication, as per secondlife.com MFA), but those who have not opted-in to MFA will see no difference in their log-in steps, regardless of whether the viewer they are using supports MFA.
• The RC version of the viewer, version 6.5.4.569309, was released on March 15th. This appears to have an authentication bug – BUG-231938 – related to how pass codes are parsed by the viewer.

• [CCUG meeting] The decision has yet to be taken on whether to maintain MFA as a dedicated viewer update or possibly merge it with another RC viewer (e.g. the Maintenance RC) to streamline the number of active viewer versions and the QA process.

Mirrors! (Maybe)

[Video: 4:05-16:29]

• In-world mirrors that reflect that reflect their surroundings – including avatars – have long been a requested capability in SL. Over the years, various attempts have been made to fake mirrors, such as using Linden Water and static photographic sets, though to “cheating” using projectors (albeit sans reflecting avatars) and the old means of duplicating sections of a build and inverting it so it appears to be reflections on a polished floor.
• In 2014, Zi Ree of the Firestorm team developed a means of generating real time reflections, including avatars, within the viewer, and produced a video on the idea. At the time, due to various reasons (most notably the impact on performance), LL decided mirrors could not be supported, which has tended to remain their position since.

• However, Mojo Linden (VP of Engineering) is now prepared to consider possibly enabling some implementation of mirrors in SL, although how this might be done is open to discussion, particularly as the potential for a massive performance impact is still very much a concern.
• Suggestions made by Mojo on how this might be done included:
  • To have user-initiated “mirrors” (that is, there are “mirror” objects in a space, but the rendering of their “reflections” is only triggered for a viewer based on something like their proximity to the object).
  • To possibly limit mirrors in terms of what they reflect (such is things that are directly in front of them, rather than much further in the background or only render avatars with the background left white.
• In terms of “triggering” mirrors, there was discussion on whether this should be automated or with user-controlled input:
  • Automated within the viewer:
    • The viewer detects the “mirror” object based on proximity, per above & renders the reflections. Discussion on this included the ideas that there could also be a Graphics preference option to completely enable or disable all mirror rendering by the viewer and a slider / drop-down to set the overall quality of the rendering of reflections (as is we already have for graphics quality (slider) and water reflections quality (drop-down)).
    • Automated via LSL (setting / unsetting flags on objects that trigger “reflection” rendering) or possibly using the interest list.
  • User controlled input: reflections are toggled in a manner similar to Media On A Prim: the user touches the “mirror” surface  and “reflections” are rendered only by their viewer – although this seems clunky / immersion breaking, even if it is an approach taken by games such as Cyberpunk 2077.
• One suggestion from those at the meeting was to take the Linden Water planar reflections (which are rendered anyway, whether the Linden Water is visible or not) and render them at a lower resolution in screen space.
  • Using the Water planar could help with things like reflective floors, mirror walls, etc., although screen space rendering in SL can be subject to clipping.
  • Screenspace reflections (SSR) have appeared in some TPVs – like Firestorm and Niran’s Viewer, but how well these work is open to question – for Firestorm, there were issues with the release of materials that resulted in the code being removed.
  • One  suggestion make for limiting performance impact was to limit the viewer to rendering only the nearest mirror surface and either use SSR for the remaining mirrors or, don’t render them at all
•  A lot depends on potential use-cases, and whether expectations can be managed – as there is a potential that any solution will not be able to meet all requirements, simply because of the risk of performance impact.
• Everything on mirrors is purely at the discussion stage right now and there is currently no formal project – and indeed, there might never actually be any project to implement mirrors; however, that the topic is being discussed by LL marks a significant shift in thinking.

In Brief

From the Content Creation Meeting

A lot of general discussion on a number of topics, none of which is currently the focus of any Lab project, including:

• Using physics to allow more “wiggling parts” – such as ears, etc., – on mesh avatars: a lot of this would come down to positioning the most suitable bones and rigging to them.
• Controlling / ordering joint position overrides (BUG-231904 / BUG-231579): this is currently handled by mesh UUID – which can be random from the POV of the user. However, trying to order using the order things are added to an avatar could lead to race conditions, as the outfit system doesn’t have any concept of prioritising attachments, therefore a more structured schema – such as adding a specific field that could be set for objects – but even this could have conflicts and also likely to be a non-trivial piece of work.
• Expansion of supported upload formats for mesh (e.g. glTF) and use of techniques such as PBR, with a stated preference (from creators) for SL handling of reflections / reflectivity to be overhauled before any attempt is made to add PBR support.
• Expanding Bakes on Mesh to support materials – which as noted over the last several meetings would require a significant update to the Bake Service, which LL is not planning on doing in the foreseeable future.
  • A further complexity here is managing the proper ordering of the additional maps. Example: some users may want their shirt partially blended with their bra / vest normal; others might want their shirt to cover their bra /vest normal map whilst others may not want their bra / vest to have a normal at all; so how can these three states be collectively handled in terms of layering?
• Further discussion on terrain – which is the subject of a project for 2022, although there is some split about increasing the texel density / increasing the resolution/repeats (and thus reducing the blurriness) + allowing normal maps, or allowing more in the way of mesh terrain (heightmaps, etc.).
  • Another request for terrain has been to allow greater compositing of textures (e.g. for more graduation in changes of textures by height or offering greater depth to terrain by layering-up textures.
  • A further request has been to allow terrain painting – e.g., being able to “paint in” dirt patches on grass, etc.
• A request for a scripted means to apply EEP settings to oneself beyond the inventory Apply to Self such that (as an example), you buy a pair of sunglasses or tinted goggles, and they apply EEP setting that make your surrounding look darker. This would require a means to read and apply the contents of an object,

From the TPVD Meeting

• [Video: 16:31-27:45 and 28:58-42:30] A broad-ranging discussion on the viewer build process and tool chain, moving to more recent graphics APIs (the likes of Vulkan and Metals are under consideration), resource utilisation within the Lab, future work on improving the viewer’s threading capabilities, etc.
  • Outside of the ongoing (/periodic) tool chain updates and graphics API investigations, none of discussion points are subject to any immediate / near-term project.
  • It was again pointed out that a issue in considering replacements for / alternatives to OpenGL is that a lot of users run older PC harder which is incapable of running more recent APIs like Vulkan.
  • As most of which will likely only be of interest to viewer devs, please refer to the video.
• [Video 42:44-43:28] ARCTan project and Legacy Profiles:
  • Initiated in 2020, ARCTan is an attempt to re-evaluate both avatar rendering costs and the cost of in-world scene rendering, with the initial focus on avatar rendering cost / impact, itself running on two tracks:
    • Developing a new UI element in the viewer pull together information from various menus / debugs to display useable information on avatars / attachments that are heavy in rendering cost, and what can be done.
    • Gathering data with the intent to revise and improve the actual formulas used for calculating avatar complexity, making them more relevant.
  • ARCTan effectively went into hibernation as a singular project in the latter part of 2021, and is currently awaiting development bandwidth.
  • [Video 45:09-46:05] One of the issues with ARCTan was being able to pull together the data in a fine enough detail to make any UI used to make changes worthwhile. Beq Janus has tackled a lot of this work for the upcoming Firestorm release, and this is liable to be fed into projects like ARCTan and the Lab’s own work in improving viewer performance and making options visible to users.
  • Legacy Profiles is a project to move avatar profile information back into the viewer and away from using web pages. There is project viewer (see the list at the top of this article), but it has been awaiting some back-end server work to be completed, and it is hoped that the project will be moving forward “Soon™”.
• [Video: 43:54-44:44] CEF: Chrome Embedded Framework (CEF) is the API used to manage media in SL. The SL version is now running several releases behind the current CEF version, and while a need to update has been noted, it is liable to require some significant work (e.g. updated UI elements as well as under-the-hood changes).
• [Video 46:05-end] miscellany text conversations, mostly on the topics noted above.

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, March 3rd 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
• My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, March 4th, 2022 at 12:00 noon SLT.

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

Available Viewers

[Video: 0:41-2:10 and 7:41-9:00 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

• Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – NEW
• Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
  • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
• Project viewers:
  • Performance Improvements project viewer version 6.6.0.567604, dated January 24.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• The release of the Maintenance J&K RC as the de facto release viewer should see crash rates reduced for those on the official viewer (and hopefully for TPVs as the code is adopted).
  • This is the first official viewer to by built using Python 3.x.
  • It includes a fix intended to prevent the updater falling over on Mac OSX.
• The Performance Improvement viewer is still awaiting RC release, this is pending some final bug fixing.
  • [CCUG Meeting] The Performance Improvements viewer bumps the feature table version number. This means that those placed in the cohort when it goes to RC status will see their custom graphics presets reset (as will anyone else switching to it during RC and when it gets to release status).
• [CCUG Meeting] It appears the Mesh Optimiser viewer has a bug that is causing it to re-order triangles in an upload. So, if an explicit ordering is contained within a Blender export (e.g. for alpha sorting, for example), the Mesh Optimiser will effective destroy the ordering when running the LOD optimisation on upload. It’s not clear on how widespread the issue might be, as it has only been reported with alchemy-next thus far.
• [CCUG Meeting] the definitions for “Low”, “medium” and “high” on the graphics slider are being redefined within the Performance Floater project viewer. This will also see the number of non-imposter avatars set on a per detail level, rather than being set to 16 across the board.
• [CCUG Meeting] the benchmark for determining low-end systems is being adjusted to better reflect the number of uses coming into SL using low-end GPUs.

MFA Viewer

[Video: 9:12-13:42]

• Summary:
  • Multi-factor authentication (MFA) is coming to the viewer.
  • As MFA is implemented in the official viewer, there will be a “grace” period to allow TPV adopt the viewer code.
  • During this period, users will be able to access SL on TPVs as they currently do now, regardless of whether or not they have opted-in to MFA.
  • After this “grace” period, all users who have opted in to MFA will be required to authenticate themselves when using any viewer to log-in to Second Life (with the usual 30-day period of valid authentication, as per secondlife.com MFA), but those who have not opted-in to MFA will see no difference in their log-in steps, regardless of whether the viewer they are using supports MFA.
• The viewer-side code is currently going through QA. If is passes, it is hoped it will surface in week #10 (commencing Monday, March 7th).
• However, the decision has not yet been taken as to give it a dedicated viewer, or to merge the code into the next upcoming Maintenance RC viewer.

In Brief

From the Content Creation Meeting

• Viewer project work: the focus is on getting the Performance Improvements viewer stabilised and promoted to RC status (and thence to de facto release). After this, it is not clear what may come next, the options being:
  • Clearing the current backlog of project viewers.
  • Further viewer-side performance improvement work.
  • Additional maintenance viewers.
  • Other work still in early planning.
• Further materials / Bakes on Mesh (BoM) Discussion:
  • Materials support for Bakes on Mesh is commonly requested, but there are several impediments to this (e.g. the Bake Service would require significant update just to be aware of materials; there needs to be a means to define how materials should be ordered during compositing, how alpha channels are properly managed, etc.).
  • It was asked by LL if things might be improved with just the introduction of a new wearables type, capable of allowing a single materials map to be worn per outfit / look.
  • Cathy Foil has also demonstrated a possible approach – although this also requires some significant updates to SL, as well as work being carried out externally to to the platform by content creators – see the video below (originally produced as a demonstration for the Lab).

• • Before committing to considering any materials / BoM work, LL would like to see a properly scoped design documents explaining what is felt would be required (including supporting protocols, etc.), and how it might work.
• BUG-225519 “Mesh Uploader] Add option for automatic convex hull physics shape”.
  • This was a subject of discussion at the previous CCUG meeting, the request calling the provision of simpler physics shapes to be available for use when uploading a mesh than are currently available – the simplest being a “cube” mesh physics asset. This is something Firestorm already provides:

• • The question was raised as to what to do when uploaded multiple mesh objects, and the physics shapes don’t match the expected number (so four when uploading 5 objects, for example). The consensus at the meeting appeared to be to use whatever is defined as the default physics shape within the file itself.

From the TPVD Meeting

• [Video: 2:17-5:44] The Lab is considering moving the time of the TPVD meeting and adjusting the frequency so as to avoid running back-to-back (so to speak) with the Content Creation meetings, which inevitably leads to a lot of repetition between two meetings held less than 24 hours apart.
  • The straw poll of attendees pointed towards the meeting having a later start time than the current 12:00 noon. Exact time TBC.
  • There will be a move to try to have TPVD meetings on alternate weeks to the CCUG meeting.
• [Video 6:10-7:23] During the log-in process, a series of flags are set on logging-in to SL, including one called “Gendered”. This apparently meant something in the past, but since around the time of the introduction of Viewer 2.0 (2010), it has effectively been ignored. LL are therefore looking to possibly pull the code relating to it, but wanted to make sure there are no TPVs using it for some reason before doing so.
• [Video 13:54-17:14] The question was floated on the animation poser code contributed several years ago by NiranV Dean from his Niran’s Viewer, and whether it would be appropriate for TPVs to implement it if LL is not going to.
  • The Lab’s view is that the code does not support the “shared experience”, in that poses are only seen by the user setting them, nothing is sent to the simulator for over viewer to see. This requires additional code to overcome.
  • Currently, LL is planning some other work “related to avatar posing the movement”, and it is possible the poser code might get folded into that work.
  • While, in principle, there are no objections to other TPVs implementing the code, they would have to do so on the basis that the code only allows the user’s own avatar to be posed, and not extended to posing other avatars (which would not be seen by the users of those avatars).
• [Video 17:28-32:00] There have been some recent overlaps / crossed lines in aspects of viewer work between Linden Lab and TPV. As a result the question was raised by the Lab as to what could be done to improve communications between TPV and LL and vice-versa to avoid future misunderstandings.
  • One suggestion was to make the TPVD meetings more of a two-way discussion in terms of what both the Lab and TPVs are working on, etc., particularly if appropriate action points could be produced when required.
  • Another suggestion was to have the Lab create a secure sandbox environment in which they could gain greater familiarity with TPVs and their capabilities as a part of their own work time (policy dictates – with good reason – LL employees are only allowed to use TPVs on systems and accounts that have no direct association with the Lab).
  • An alternative to the above that was offered would be for LL staff to peek into the support groups, etc., run by TPVs to get an understanding as to what users are asking for, and what is being responded to.

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, February 17th 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
• My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, February 18th, 2022 at 12:00 noon SLT.
• It is a summary of the key topics discussed, and in the case of the TPVD meeting, timestamps to the relevant point of the video are included.

Available Viewers

[Video: 0:16-3:26 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

• Release viewer: version version 6.5.2.567427 – Mac Voice hotfix viewer, January 13 – no change.
• Release channel cohorts:
  • Maintenance J&K RC viewer, version 6.5.3.567451, issued on January 20th.
  • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
• Project viewers:
  • Performance Improvements project viewer version 6.6.0.567604, dated January 24.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• The Maintenance J&K RC viewer is still the next in line for promotion to de facto release status.
  • Progress of this viewer had been delayed due to the viewer updater needing to be updated from Python 2 to Python 3.
  • This change has now been made, and the viewer is ready to be issued as an updated RC viewer.
• Work continues on the Performance Improvements project viewer to lift that to RC status.
  • It was found that bump (normal) maps were being processed on the main viewer thread, causing the viewer to exceed 60 fps with Vsync enabled (which should hold it to 60fps), causing frame jitter. Bump map processing has therefore been moved to a separate thread.
  • There has been a pass to improve hardware compatibility with AMD GPUs.
  • An issue with rigged meshes failing to render in the thumbnail panels when editing an avatar’s shape has been addressed,
  • This could be the first in a series of viewers produced under the Performance Improvements banner, with the Lab already discussing additional improvements that could be made in future versions.
• The Performance Floater viewer is being updated with further options to manually adjust viewer settings to help maintain frame rates.

MFA Viewer

[Video: 3:58-6:43]

• As noted in the week #5 summary, multi-factor authentication (MFA) is coming to the viewer.
• The viewer-side code is complete, and had been awaiting the implementation of server-side support.
• The latter has now been deployed to the Main grid, so it is anticipated that an RC version of the official viewer will be available in the very near future.
• It is  recognised that TPVs will need time to integrate the necessary viewer-side code into their offerings, therefore:
  • As MFA is implemented in the official viewer, there will be a “grace” period to allow TPV adopt the viewer code.
  • During this period, users will be able to access SL on TPVs as they currently do now, regardless of whether or not they have opted-in to MFA.
  • After this “grace” period, all users who have opted in to MFA will be required to authenticate themselves when using the viewer to log-in to Second Life (with the use 30-day period of valid authentication, as per secondlife.com MFA).
  • Please refer to my week #5 summary for the full list of notes on MFA in the viewer.

In Brief

Content Creation Meeting

• Honouring joint rotation at mesh upload:
  • There are a number of long-standing bugs and requests concerning support (or lack that of) for maintaining mesh joint rotations at upload – currently, overrides are only provided for position and scaling.
  • The Collada .DAE file format does allow for rotation to be maintained through a number of ways, but currently SL doesn’t support all of them – hence when joint rotations tend to be ignored.
  • The general discussion leaned towards having the ability to override join rotation at upload would be a nice to have, with the view from LL that if done, it would be a check box at upload, so it would only apply to new content being uploaded, and not affect existing content.
• Preference over the above was expressed for the ability to scale bones via animations.
  • This could allow for things like animals to increase in size as they grow from kitten / cub / pup, etc., to adulthood; possible improvements to clothing; enabling more complex avatar animations etc.
  • One potential issue with this is that scaling by animation might / will conflict with the skeletal sliders.
  • Providing animation scaling adds a further point of complexity, presenting 3 points at which scale is being impacted: within the mesh (from values at upload), trough the application of animations and via the shape sliders. Ergo, some form of ordering hierarchy is potentially required to avoid conflicts between the three.
  • No conclusions were drawn on this in terms of possible implementation or further investigation of options.
• BUG-225519 “Mesh Uploader] Add option for automatic convex hull physics shape”.
  • Sparked an extended conversation on physics shapes and LI – not all of which, I confess, I could not entirely follow in listening back through the audio, as some of it depended on some in-world testing – and I was absent from my screen through the majority of the meeting, so did not get to see the in-world examples being manipulated.
  • Essentially, the feature request calls for the provision of simpler physics shapes to be available for use when uploading a mesh than are currently available – the simplest being a “cube” mesh physics asset. This is something Firestorm already provides:

• • The conversation also folded into it requests to have direct access to Havok (the physics engine) primitive physics shapes (sphere, cube, cylinder, etc., and the ability to upload them.
  •  For now, a contribution of the code used by Firestorm has been offered / requested.
  • This is turn lead to a discussion on, if implemented by LL, whether the default upload physics shape (Convex Hull) should be changed to “Cube” – with the preference being to leave it as is, although it was noted that with PBR set for future implementation, the upload mesh form may at some point need to be changed.
  • Given the confusion evident within the discussion, this also perhaps points to the need for the uploader to have a link to relevant and maintained documentation on best practices for mesh uploads, physics, etc.
• The end of the meeting featured a further request for materials support for Bakes on Mesh (BoM)
  • This is something which, as noted in the past, would require a not insignificant extension to how bakes are handled, together with and expansion of the Bake Service itself – particularly if it was expected that individual layers would have an associated normal and specular channel associated with them.
  • A suggested alternative would be to have a single normal and single specular channel then is applied to the entire bake. While this might work for specularity, it’s not clear how this would work with a normal maps and be effective when trying to define different fabrics through the use of normals.
  • Currently, LL have no direct plans to implement materials for BoM.

TPV Developer Meeting

• BUG-225696 “All offline inventory offers from scripted objects are lost” is to be the subject of a simulator-side project that is now “gearing up” to fix it “once and for all”, which is “coming for a near value of ‘Soon™’.
• There are a lot of “new initiatives” in the pipeline with LL beyond those outlined in things like the 2021 year-end review, but nothing that has reached a point where it can be discussed in detail at TPVD (or other) meetings.

The following notes were taken from:

• My audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, February 3rd 2022 at 13:00 SLT. These meetings are chaired by Vir Linden, and meeting dates can be obtained from the SL Public Calendar.
• My audio recording and the Video recording by Pantera (embedded at the end of this piece) from the Third-Party Viewer Developer (TPVD) meeting on Friday, February 4th, 2022.

So this document forms a summary of the key topics discussed, and in the case of the TPVD meeting, timestamps to the relevant point of the video are included.

Available Viewers

[Video: 0:19-0:52 + notes from CCUG]

This list reflects the currently available official Second Life viewers.

• Release viewer: version version 6.5.2.567427 – Mac Voice hotfix viewer, January 13 – 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 RC viewer, version 6.5.3.567451, issued on January 20th, combining the Jenever and Koaliang Maintenance viewers.
  • The Tracy Integration RC viewer version 6.4.23.563771 (dated Friday, November 5) issued Tuesday, November 9.
• Project viewers:
  • Performance Improvements project viewer version 6.6.0.567604, dated January 24.
  • Mesh Optimizer project viewer, version 6.5.2.566858, dated January 5, issued after January 10.
  • Performance Floater project viewer, version 6.4.23.562625, issued September 2.
  • Legacy Profiles viewer, version 6.4.11.550519, dated October 26, 2020.
  • Copy / Paste viewer, version 6.3.5.533365, dated December 9, 2019.

General Viewer Notes

• The Maintenance J&K RC viewer is likely the next viewer to gain promotion as the de facto release viewer.
• The Performance Improvements viewer is close to being ready for promotion to RC status, and is just pending some remaining bug fixes.
  • This viewer did have changes to alpha sorting for rigged attachment, but following reports of content breakage as a result of this change, which was more a technical change than a performance enhancement, it has now been reverted to expected alpha sorting behaviour to avoid the breakage issue. Instead, possible alternative approaches will be looked at in the future.
  • A future version of this viewer is to include a new UI element intended to help make adjustments to some of the high-impact graphics settings to help improve frame rates,
• LL is also completing work to switch the viewer over to using Python 3.

Viewer Multi-Factor Authentication Support – TPVD

[Video: 0:53-23:00]

Background

• In September 2021, Linden Lab introduced multi-factor authentication (MFA) utilising either a QA code + mobile device or a key number, for those pages of the SL website that provide access to users’ account information (see: Second Life Multi-Factor Authentication: the what and how, September 2021).
• When introduced, it was indicated that over time, the use of MFA would be expanded and improved, and would eventually include the viewer as well.
• Brad Linden is now working on implementing MFA for the viewer.

What This Means

• The work has reached a point where LL is close to having a viewer with MFA support ready for initial testing (as defined by  see: SL Wiki: Login MFA), together with updates to the back-end log-in service to support it.
• Viewer MFA will be based on users opting in to the capability via the secondlife.com dashboard, as described in the blog posted linked to above.
• It is  recognised that TPVs will need time to integrate the necessary viewer-side code into their offerings, therefore:
  • There will be a grace period between the initial introduction of the code in the official viewer and a time when all viewers / clients access Second Life will be required to support MFA to allow users who have opted-in to MFA to continue logging-in to SL.
  • During this grace period, all users on a TPV will be able to access Second Life, regardless of whether or not they have opted into MFA.
  • After the grace period has expired, all TPVs will be expected to support MFA, and those users on them who have opted in to MFA will be required to authenticate themselves when using the viewer to log-in to Second Life (with the use 30-day period of valid authentication, as per secondlife.com MFA).
  • During the grace period, users on TPVs that switch to support MFA will likewise need to start authenticating themselves when logging-in to SL.
• Again, this will only affect users who have opted into MFA (unless LL at some point decides all user must use MFA to access SL).
• MFA on the viewer will be a blanket action – there will be no additional MFA authentication for actions such as buying Linden Dollars through the viewer.
• Using MFA when logging-in to the viewer will not automatically also authenticate you on secondlife.com or vice-versa.

There was a broader discussion on providing alternative mechanisms by which users can opt-in and use MFA – such as e-mail – rather than relating on a mobile device and authenticator software. Such decisions fall outside the realm of the viewer development team, and so could not be answered directly (however LL have stated  additional / alternate methods of authentication will be added to the system at some point in the future).

In Brief

Content Creation Meeting

• BUG-231731 “Script text quality and performance” prompted questions on how it might be implemented given it has been accepted. Vir pointed out that “Accepted” does not necessarily mean it a Feature Request will be implemented forthwith, and as such, it will be raised for discussion once it has reached a point where LL is considering working on it.
• BUG-229205 “Re-enable PRIM_CAST_SHADOWS” came up for discussion, it is believed that the viewer-side code for it has been deprecated / removed, and the server also no longer recognises the function.
  • Runitai Linden suggested it is something that should be re-enabled on the grounds that it is “something that most graphics engines let you do.”
  • However, any final decision will be subject to further internal discussions within LL.
• Request: allow seated avatars to temporarily have a physics shape of none if explicitly set by script (potential use-case: an in-world game uses tiny vehicles in a scaled environment to simulate a larger playing field, but as the drivers are normal-sized avatars, they cause collisions between one another, impairing gameplay; disabling the avatar physics would  in theory prevent this, although it is not clear if such a change would be recognised by the simulator, where it is believed the expectation of avatar physics is  assumed throughout the code).
  • The discussion encapsulated requests such as BUG-5538, the need for an overhaul of the camera control system & better LSL access to same; better joystick control options, and better support for alternative input types.
  • The latter point in turn led to a discussion on wider HID support and even the potential for MIDI (Musical Instrument Digital Interface) support (having been a means to provide remote control and synchronisation prior to HID design becoming the “standard”) as a means to transport and synchronise joystick inputs from the viewer to the simulator in a generic, open manner.
  • All of this was spitballing, rather than the formulation of an actual project.

TPV Developer Meeting

• [Video 26:10-53:10] Animation Override Discussion – TPVD
  • This follows-on from the week #3 TPVD meeting.
  • Essentially what is being sought is a solution similar to the Firestorm AO (but without the apparent overheads) that effectively allows viewer-side replacement of animation states sent by the server with local animations, avoiding the need for scripted HUDS / attachments.
  • Much of the discussion at this meeting is clarifying the original request for Vir Linden’s benefit, although the consensus is that official a cap replacement for llSetAnimationOverride and allowing TPVs to implement their own viewer-side AO UI elements would be a good start.
  • Once this has been done, then discussion can turn to the more complex issue of adding further animation states.
  • A Cap and viewer-side controls will not fully eliminate scripted AOs (particularly in the case of non-human AO walks, sits stands, for example), but this shouldn’t negate the provisioning of a Cap.
  • Please refer to the video for the discussion – much of which is in text chat.