The following summary notes were taken from the Tuesday, March 22nd, 2022 Simulator User Group (SUG) meeting. It forms a summary of the items discussed, and a video of the entire meeting is embedded at the end of the article – my thanks to Pantera for recording it.
Server Deployments
There are no planned deployments for week #12, although all channels will be restarted – Main on Tuesday, March 22nd, RCs on Wednesday, March 23rd, 2022.
Available Official Viewers
All official viewer pipelines remain as follows:
Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – No Change
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:
Performance Floater project viewer, version 6.4.23.562625, September 2, 2021.
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.
In Brief
BUG-231876 “llRequestSimulatorData() frequently and silently fails” – a fix has been developed for this issue and is currently with QA for testing. If all goes well, the fix should be in an RC update in the next week or two. Leviathan Linden described the issue thus:
The problem was introduced after overhaul to the ScriptDataCache implementation.In short: when the cache was full then pending requests could sometimes be invalidated by a new request. There was not enough distinction between a valid but not yet expired value and a valid but not yet harvested by its request value.
The ScriptDataCache is currently limited to 8192 slots. Not all dataserver functions use it, but yes the only data therein are dataserver requests. Some dataserver requests used to use the cache but have been migrated over the years to use different web services instead of actually hitting the dataservers themselves. the DataServerCache size with my recent fix: only 1024 slots. The size of the cache shouldn’t really matter all that much when it is working correctly. That is… its size is really there to protect the dataservers from overload.
Monty Linden is poking at region crossing issues, but no updates. This sparked further general discussion on region crossings. Please refer to the video.
General discussion about two bugs that occur when the viewer is minimised, but where the simulator should really have authority (and thus the issue not occur):
BUG-202856 “Rotating a sitter’s rotation by script does not update their global rotation at the server if the sitter has their viewer minimised.”
BUG-230616 “A user’s scripts and attachments do not load in a region if they are teleported while their viewer is minimized. The server shows no attachments, scripts, script memory or timing.”
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.
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
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.
The MFA RC viewer prompts those who have opted in to SL’s MFA capability to provide an authentication code / key (once every 30 days) in order to log-in to SL
[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.
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.
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.
Wonderland 2.0, February 2022 – blog postThe following summary notes were taken from the Tuesday, March 8th, 2022 Simulator User Group (SUG) meeting. It forms a summary of the items discussed, and a video of the entire meeting is embedded at the end of the article – my thanks to Pantera for recording it.
Tuesday, March 15th saw the SLS Main channel updated to server release 569051, bringing it to parity with the RC channels. This release makes some improvements to the processes of simulator start-up and shutdown, as well as fixing a crash and a subtle bug in LSL math functions.
Wednesday, March 16th should see the RC channels restarted without any deployment.
Available Official Viewers
The Performance Improvements viewer was promoted to RC status with the release of version 6.6.0.569349 on March 14th. This viewer may have also absorbed the Tracy Integration viewer updates, which have been withdrawn as a dedicated RC viewer.
All official viewer pipelines remain as follows:
Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – No Change
Release channel cohorts:
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.
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.
In Brief
The Land Team still have yet to settle on a suitable EEP setting for the Mainland in order to alleviate the generally dark see to the day environment there.
BUG-231876 “llRequestSimulatorData() frequently and silently fails” – this issue has reproduced by the Lab and is being actively worked on.
Further discussions on the issue of vehicles hitting a parcel ban / ban lines are “bounced” (much like they do on reaching an edge of the grid) rather than avatars being unseated / dumped and the vehicle returned to the owner’s Lost and Found. Feature request BUG-231802 “Prevent vehicles from entering parcels their riders cannot access” has been accepted, but no ETA on implementation.
Additional discussions on scripting, and on media control.
Scripting options included further requests for parcel teleport routing capabilities, accurately positioning / seating avatars.
As conversations at SUG meetings tend to cover the same ground re: certain requests like these, a request was made for LL to provide a general workplan / response to such requests, so that people know what to expect.
Feature request BUG-231929 “llCanRez or something equivalent to check if an object can rez at the location it will try to in the future” is a request for a better way of detecting if a prim can be rezzed by an object on land rather than having to write a LSL function.
Multi-Factor Authentication (MFA) was raised, with the Lab re-iterating that the capability is being rolled out in stages. As I’ve reported in recent TPVD summaries, the next element is liable to be extending the MFA capability to the viewer – see: SL Wiki: Login MFA.
Whilst not a simulator issue per se, some creators at the meeting requested (again) that LL provide in-world mesh editing capabilities and “get rid of primitives” as “you can’t make much of anything with primitives anymore” – a comment that many of us who routinely build with primitives would likely strongly dispute. While there are no plans for LL to “replace” prims, what is likely required are broader options for importing content created using third-party tools.
The following notes cover the key points from the Web User Group (WUG) meeting, held on Wednesday, March 9th, 2022.
These meetings are generally held on the first Wednesday of the month, with dates and venue details available via the SL public calendar. A video of the meeting, courtesy of Pantera, can be found embedded at the end of this article (my thanks to her as always!). Again, the following is a summary of key topics / discussions, not a full transcript of everything mentioned.
The Marketplace variants project is now officially titled Marketplace Styles:
Most of the back-end infrastructure work to support different styles (e.g. different colour variants for an item in a single listing) is now complete.
The design of the front-elements (as will be seen by users) has now been approved.
It is hoped that prototyping will be available for viewing (e.g. through the Web User Group meetings) in the “next couple of months”.
Search Relevance project is now seeing plans being put together, and some of this may be available for viewing at WUG meetings in April / May 2022.
[Video: 43:59-45:24] Work currently underway is to track the relevance of a given search result (e.g. “user searched for X and gained these results. User then took option Y in that list of results” – where if Y= the first item in the list, relevance can be considered high; if they take the 100th option, then that suggests the relevance of ordering is not as good as it could be). The idea here being to be able to feed this back into improving the relevance of search results.
Premium Plus – an announcement is expected in March 2022.
The overall page of benefits has apparently been agreed (no details at present).
There are still some elements to be finalised (pricing?).
Marketplace Q&A
[Video: 5:00-6:16] Could Marketplace order history be sorted by item cost (e.g. most expensive at the top)? – seen as a reasonable suggestion, and a feature request – BUG-231907 – has been filed.
[Video 7:04-8:01] Sales tax: a reminder that as per the official blog post on the introduction of US sales tax, sales tax on applicable US purchases will be applied in accordance with local jurisdictional requirements (e.g. state-level laws, etc.). So if your state / jurisdiction does not charge for the sale of virtual goods and services, then LL will not apply it.
[Video: 8:37-9:39] Marketplace Sub-Brands: following the discussions in the February meeting, a project is now being scoped based on the feedback given. However, the development of any project is unlikely to surface in 2022.
[Video: 9:55-12:00] The question was asked if LL could provide the means for creators on the Marketplace to run collaborative sales / events – a shared page with links to items the creators participating in the event are including in it. This was referred to as an “interesting idea” and for a feature request Jira to be filed, preferably with some details on how this might work.
[Video: 14:26-15:00] A request was made for further community categories on the MP. Again, a feature request as been requested.
[Video: 20:52-22:10] A request was made for sellers to be able to disable customer reviews on the grounds it has become “normal” to see negative reviews. Whether or not this is the case, the majority of reviews are left in good faith, and while it can be frustrating to see negative reviews where the purchaser has failed to try a demo / not read supplied instructions, the view is that disabling reviews is not the answer.
[Video: 22:44-24:50] The suggestion was made in text later in the meeting to allow up / down voting of comments. However, unless carefully controlled (e.g. only allowing those who have purchased an item to up / down vote), then this is potentially open to abuse as well (e.g. a creator getting all their friends to down vote a negative review – or even one person down vote multiple times). As such, any implementation would require considerable forethought and design.
[Video 25:09-26:07] Could MP store owner be allowed to include links between their stores and the social media platforms they use? This has been tried in the past, but has not worded out. While there is no objection to trying for a better mechanism again, there is currently no work planned in their area. Again, specific ideas welcomed via feature request Jiras.
In Brief
The wiki has (after all) bee updated to HTTPs, and the syntax highlighting issue for the LSL pages has been addressed.
The Destination Guide is on the Web Team’s roadmap to receive and overhaul / face-lift, but no ETA at present. One of the aims of this work is to make it easier to find places that actually have people in them.
There was some discussion on the “new” look for Search, with some criticism for the places summary not showing traffic (a location must be clicked and seen in the expanded view to get traffic numbers). However, whilst experienced users find this useful, new users found the traffic reference confusing, and so it was purposefully placed in the expanded view.
It was again noted in the meeting that LL are looking at the new user experience from “top to toe” – from sign-up through getting in-world to customising an avatar, to finding things to do and people with whom to interact.
The following summary notes were taken from the Tuesday, March 8th, 2022 Simulator User Group (SUG) meeting. It forms a summary of the items discussed, and a video of the entire meeting is embedded at the end of the article – my thanks to Pantera for recording it.
Server Deployments
Tuesday, March 8th saw the SLS Main channel restarted, but no deployment.
Wednesday, March 9th should see a new simulator version deployed to the RC channels. It fixes a couple of crashes and hopefully will help with some of the regions becoming confused as to whether they are up or down.
Available Official Viewers
All official viewer pipelines remain as follows:
Release viewer: version version 6.5.3.568554 – formerly the Maintenance J&K RC viewer, promoted Monday, February 28 – NEW
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.
In Brief
BUG-231876 “llRequestSimulatorData() frequently and silently fails” has been reported a couple of times, the Lab are investigating and looking for reliable repros.
LL “have a few extra cycles to devote to scripting coming up”, and so ideas for priorities / options, etc., have been requested – feature requests should be filed by those who have them. So suggestions already include:
BUG-230935 “PARCEL_DETAILS_FLAGS and PARCEL_DETAILS_SCRIPT_DANGER for llGetParcelDetails()”.
BUG-230938 “Allow llGetParcelDetails() to see parcels in a neighbouring region”.
Provision of llWearFromInventoryTemp – which is seen as attractive by LL, but would require a much larger project.
This lead to a lengthy discussion, so please refer to the video from the 24.13 mark.
There was some discussion over what has been taken to be a media autoplay exploit that is allowing unauthorised access to people’s L$ balances. The precise details are unclear, other than and image of a Discord comment. Those who have seen the issue at events or have first-hand experience of the issue are asked to file a SEC Jira.
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.
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.
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.
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:
Physics models offer through the Firestorm mesh uploader – the shapes being continued within the viewer for application. Credit: Beq Janus
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.
Inara Pey: Living in a Modemworld 