Category: SL User Group Meetings

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

Posted on by Inara Pey
Raion No Su, August 2022 – blog post

The following notes were taken from Pantera’s video recording of the Third-Party Viewer Developer (TPVD) meeting held on Friday, Third-Party Viewer Development meeting held on Friday, October 28th, 2022 at 13:00 SLT. My thanks to her for recording it, and it can be found at the end of this article. Times stamps to the video are included where relevant in the following notes. These meetings are chaired by Vir Linden, and their dates and times can be obtained from the SL Public Calendar.

This is a summary of the key topics discussed in the meeting and is not intended to be a full transcript.

Official Viewers Status

[Video: 0:00-2:00]

Available Viewers

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

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

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

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

General Viewer Notes

  • The Performance Floater project viewer (which includes UI updates and the Lab’s new Auto-FPS feature) has been undergoing a lot of work to reconcile the Lab’s auto-FPS work with that of Firestorm is still expected to appear as a RC viewer Soon.
  • The Windows viewer built using Visual Stood 2022 is now awaiting its debut as a RC viewer, also expected Soon.

Github Changeover and Streamlining the Code Contributions Process

[Video: 2:56-8:08]

Github Work

As previously announced, there is an initiative to improve continuous update integration in the viewer and improve the viewer deployment process.

  • For TPVs and developers, the most visible aspect of this is moving the viewer repositories from BitBucket to Github. This includes the viewer code base and the other public code bases currently in BitBucket (Autobuild, LLCA, etc.).
  • There is still no firm date as to when the actual switch-over to using the new repositories will occur, but the viewer development team is working steadily towards it, and the plan remains to provide plenty of advanced warning to TPVs on when LL plan to cut over to the new repositories before making a clean cut-over.

Code Contributions Process

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

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

Linkset Data (LSD)

[Video: 8:24-10:50]

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

PBR: Materials and Reflections

[Video: 11:02-13:50]

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

Reflection Probe Mutability

[Video: 15:15-28:00]

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

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

Removal of Forward Rendering and Possible Project Impact

[Video: 42:49-46:15]

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

In Brief

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

Next Meeting

  • Friday, November 25th, 2022.

2022 Puppetry project week #43 summary

Posted on by Inara Pey
Puppetry demonstration via Linden Lab – see below.  Demos video with the LL comment “We have some basic things working with a webcam and Second Life but there’s more to do before it’s as animated as we want.”

The following notes have been taken from chat logs and audio recording of the Thursday, October 27th Puppetry Project meetings held at the Castelet Puppetry Theatre on Aditi. These meetings are generally held on alternate weeks to the Content Creation User Group (CCUG), on same day / time (Thursdays at 13:00 SLT).

Notes in these summaries are not intended to be a full transcript of every meeting, but to highlight project progress / major topics of discussion.

Project Summary

  • Previously referred to as “avatar expressiveness”, Puppetry is intended to provide a means by which avatars can mimic physical world actions by their owners (e.g. head, hand, arm movements) through tools such as a webcam and using technologies like inverse kinematics (IK) and the  LLSD Event API Plug-in (LEAP) system.
    • Note that facial expressions and finger movements are not currently enabled.
    • Most movement is in the 2D plain (e.g., hand movements from side-to-side but not forward / back), due to limitations with things like depth of field tracking through a webcam, which has yet to be addressed.
  • The back-end support for the capability is only available on Aditi (the Beta grid) and within the following regions: Bunraku, Marionette, and Castelet.
  • Puppetry requires the use of a dedicated viewer, the Project Puppetry viewer, available through the official Second Life Alternate Viewers page.
  • No other special needs beyond the project viewer are required to “see” Puppetry animations. However, to use the capability to animate your own avatar and broadcast the results, requires additional work – refer to the links below.
  • There is now a Puppetry Discord channel – those wishing to join it should contact members of LL’s puppetry team, e.g. Aura Linden, Simon Linden, Rider Linden, Leviathan Linden (not a full list of names at this time – my apologies to those involved whom I have missed).

Bugs, Feature Requests and Code Submissions

  • For those experimenting with Puppetry, Jiras (bug reports / fixes or feature requests) should be filed with “[Puppetry]” at the start of the Jira title.
  • There is also a public facing Kanban board with public issues – those experiencing issues can also contact Wulf Linden.
  • Those wishing to submit code (plug-ins or other) or who wish to offer a specific feature that might be used with Puppetry should:

Further Information

Meeting Notes

Protocol Overhaul

At the previous meeting, Leviathan Linden noted the project team is going to overhaul the Puppetry/LEAP protocol. Since then:

OpenXR Support

Leviathan Linden asked for feedback on what the requested “OpenXR support” mean to those requesting it – e.g.: Is it to run an OpenXR app and have a VR experience in SL,  or is it to run an OpenXR app as a plug-in to provide measurement input to Puppetry?

The general response was a mix of both:

  • To generally provide the means for “proper” hardware support for motion capture such that puppetry isn’t just a “best guess” response via a webcam
  • To allow for more accurate interactions between avatars and objects; eventually moving to provide full support for VR headsets and controllers (requiring the ability to intact with scripted devices, operating levers, controls, etc., which could be correctly interpreted and acted upon by said scripts).

Currently, LL are more willing to consider OpenXR support as a part of the Puppetry work whilst regarding it as a potential step towards wider VR support in SL in the future.

Avatar Constraints / Interactions

The above question led to a broader discussion on avatar-to-avatar and avatar-to-object interactions starting with the avatar constraints / collision system.

  • As they are right now, avatar constraints and collisions within SL have been adequate for the platform, but lacking (collisions, for example have no concept of the avatars arms / legs, limiting interactions with them and other objects).
  • OPEN-368 “[Puppetry] [LEAP]: Location Constraints” is a feature request outlining the benefits of overhauling the SL avatar constraints system to allow better interactions with objects, etc. This is currently open to those wishing to add further comments and feedback.
  • The question was raised as to how “fast” / reliable the required communications (including all the required bone interactions) could be made in order to ensure adequate / accurate response times with actions (e.g..so when shaking hands, he hands of each avatar arrive at the same point at the seem time to be seen as  shaking in both viewers).
  • Also discussed was determining how “reactions” might best be defined – could it be as “simple” a pre-set animation?
  • One issue with this – interactions, OPEN-368, etc., – is that direct hooks from Puppetry to LSL had been seen as outside the scope of the project, simply because puppetry and the LEAP API are entirely viewer-side, and LSL simulator-side.  However, the discussion opened a debate on whether some means for this interaction should be provided, with two options being put forward:
    • Broadening the LEAP protocol, essentially using it to make the viewer scriptable with plug-ins that run on their own threads.
    • Providing a specific LSL function that would enable LSL to be able to communicate / interact with the LEAP protocol / JSON (as is the case with the RLV / RLVa APIs used by some third-party viewers).
    • Both of these approaches were seen as potentially “doable”, if beyond the intended scope of the puppetry project.
  • A further issue  with interactions and bone tracking (which would be required for accurate avatar-based interactions) as that bone tracking via LSL is as best limited to non-existent; this raised the subject of possibly using attachment points as a proxy.
    • An additional problem here is whether or not is possible to track the location of the attachment points in 3D space relative to any animation the avatar is playing (e.g. if an animation causes the avatar to raise their arm, is it possible to check the position of the wrist point)? This is currently something of an unknown, as it would either:
      • Require the simulator to inject a lot of additional calculations for joint and attach positions;
      • Or require a  new (optional) protocol where the viewer would just supply its in-world positions at some frame rate – which would require some calculation overhead on the part of the viewer;
      • Or – given work is in-hand to add the in world camera position relative the viewer, and also the avatar’s world orientation and look at target – provide a straight dump of the animation mixdown together with the skeleton data, enabling the processing to be carried out in a module rather than the viewer.
  • As a result of these discussions, time has been requested to investigate the various options (which will likely include a determination of what, if anything is to be included in the current project in terms of these additional capabilities).

Date of Next Meeting

  • Thursday, November 10th, 2022, 13:00 SLT.

2022 SUG meetings week #43 summary

Posted on by Inara Pey
Green Acres, August 2022 – blog post

The following notes were taken from the Tuesday, October 25th, 2022 Simulator User Group (SUG) meeting. They form a summary of the items discussed and is not intended to be a full transcript. A video of the entire meeting is embedded at the end of the article for those wishing to review the meeting in full – my thanks to Pantera for recording it.

Server Deployments

Please see the forum deployment thread for the latest updates.

  • On Tuesday, October 25th, the Main SLS and Events channels were restarted without any simulator update being deployed.
  • On Wednesday, October 26th, the simhosts on the RC channels were to be updated with the new Linkset Data capability.
    • This feature works similarly to Experience Key-Value store, but the data lives with the object that sends and receives the data. Only scripts in the same linkset will be able to read the data written with this feature.
      • Further information can be found in the SL Wiki.
      • The capability can also be discussed in the SL forums.
    • However, a late-breaking issue revealed by the Lab’s QA team means that the deployment mat not take place until week #44 (commencing, Monday, October 31st).
    • If delayed, this potentially allows a further week for additional updates to the capability.
    • I will have a special Guest Article by Neobokrug Elytis explaining this new capability and its significance after the deployment has been made.

Available Official Viewers

On Tuesday, October 25th, Linden Lab release the Maintenance N RC viewer, version 6.6.6.575990. 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.

The remaining official viewer pipelines stay as follows:

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

Script Compilers

  • Rider Linden raised the question about removing the LSO bytecode compiler (non-Mono), or forcing all compilers to use Mono.
  • This would not prevent compiled LSO scripts from running using the LSO VM, it would just prevent further scripts being compiled outside of the IL → Mono compiler.
  • The main reason for considering this approach would make it much easier for LL to expand LSL without having to drag the old version along.
  • Currently, this is an idea the Lab is considering – not something being actively pursued; but based n the feedback from the meeting, it may become an active project – if so, the Lab will make clear what is being done in advance through the forums and seek broader feedback from creators / scripters., and proving the LSO runtime remains in place, as noted above.

In Brief

  • BUG-232792 “llLinksetData batch notifications” has been raised and is awaiting formal review by the Lab at the time of writing. This would only be implemented once the upcoming LSD capability has been deployed.
  • There was a general question on the DMCA process, which actually falls outside the scope of the SUG meeting.
    • A  problem here is that with the suspension of the Governance User Group meetings, there is no public forum where issues relating to content theft / the DMCA process can be directly discussed with members of the Governance Team.
  • BUG-232037 “Avatar Online / Offline Status Not Correctly Updating” – LL believe that have a “handle” on the where the issue is originating, but there has been no time to take a deep dive into the actual cause as yet

2022 week #42: CCUG meeting summary: PBR Materials

Posted on by Inara Pey
Storybook, August 2022 – blog post

The following notes were taken from  my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, October 20th 2022 at 13:00 SLT. 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.

PBR: Materials and Reflections

  • Please also see previous CCUG meeting summaries for further background on this project.
  • Work is now entering a “public alpha” mode which will commence with the release of a formal project viewer, in order to put the viewer before a wider group of creators and obtain their input / feedback in addition to that gained during the “closed alpha” with those on the Discord channel.
    • This project viewer could be available in the next week(ish), subject to QA testing.
    • It is hoped this “alpha testing” will show that minimal changes to behaviour / functionality will be required, but it will allow LL time to gather broader stats on performance (particularly on hardware specs they have not bee able to test), and allow for additional tuning and optimisation.
    • LL are aware there are some performance regressions within the viewer (together with some issues with AMD drivers) that need to be addressed before it can proceed beyond project viewer status, but these are not seen as blockers to this wider testing, as they can be noted within their viewer release notes.
    • It is also noted that permissions will be “a little bit broken” to start with, and some edge case rendering cases may appear broken -but issues like this will be documented in the project viewer release notes.
    • Once these issues have been ironed out, it is anticipated that there will be no FPS loss when comparing the PBR Materials viewer to the current release viewer.
  • Following this “open alpha”, the viewer will move to “beta mode” (presumably as it reached RC status), when the focus will be on bug fixes rather than adding / changing features.; as such, the project viewer phase is seen  as crucial in obtaining feedback encompassing concerns over things like file formats, functionality, concerns over changes to the rendering pipe, etc.

Reflection Probes

  • LL is concerned that reflection probes may prove to be an Achilles Heel with the new capabilities, simply because the technique  in using them by the industry as a whole is somewhat counter-intuitive.
  • The core issue is getting people’s heads around the idea that the “shiny thing” is not itself the probe; but the probe must be correctly set, including its influence volume.
    • Typical documentation on setting-up reflection probes, such as that provided by Unreal and Unity – both of which share the same concepts around the influence volume as the SL implementation (although the latter has fewer parameters), doesn’t always make for easy reading.
    • The influence volume is a particular issue for SL due to the use of the automatic probes which exist within a region, and which are unlikely to always be in the right place, so may need to be countered by manually-placed probes.
  • One significant concern arising from this is that content will be sold with it own reflection probe which is precisely the wrong thing to do, as it could lead to dozens of probes in a single room, none of which have influence volumes that eat into viewer resources when a single probe for the room as a whole would achieve the same results.
    • A way around this would be to offer the means to disable the reflection probe as supplied within individual objects sold by creators.
    • However, this then begs the questions to what happens if said content is sold No Mod – blocking any ability to disable the associated reflection probe? Would it be sufficient to let market forces determine the success of such items?
  • No definitive  solution for this has been determined – other than the need for full and proper education for creators (with documentation) – both of which assume creators will a) want to be educated; b) RTFM; and the meeting time drew to a close whilst this was still under discussion, so will likely be picked up at the next meeting.

Forward Rendering + Deprecating OpenGL 2.0

  • As has been previously stated by LL (and covered in these CCUG summaries), a key change that the PBR work will bring to the viewer is the removal for the forward rendering pipe – otherwise know as “disabling ALM”.
    • To help with this, LL have implemented additional optimisation within the PBR viewer designed to help low-end systems perform better with ALM (Advanced Lighting Model) always on, and more optimisations are to be added to the viewer.
    • However, one of the areas of feedback the Lab would like to obtain during the “alpha testing” is how well low-end hardware they may not have been able to test functions when running the PBR viewer.
    • Obviously, removal of forward rendering  will mean the final end to invisiprims, which have for the last 10+ years required ALM to be turned off in order to mask other elements (e.g. system body parts, Linden Water, etc.).
  • It is acknowledged that forward rendering currently offers better anti-aliasing than ALM, but a means to improve this under ALM is being looked at.
  • The PBR Materials viewer will effectively see support for OpenGL 2 finally deprecated in the viewer, the minimum requirement being OpenGL 3 (Open GL 4 being required for reflection probes).
    • This thought to impact around 0.5% of all Windows / Linux users (stats still are collected for Linux, and many of those might be bots utilising older clients, with the majority of users – even those on elderly hardware – trending towards OpenGL 4 (which has been available for around a decade).
    • Given given basic GPU cards such as the Nvidia GTS 250 (introduced in 2009) and many laptops with integrated graphics can support at least OpenGL 3, it is hoped that even those still running OpenGL 2 will be able to updated to OpenGL 3 to avoid issues.
      • If you are concerned about your hardware supporting OpenGL 3, go to Help → About in your viewer, and you can check the OpenGL version you are running from there – most people will likely find they are running a version of OpenGL 4. Those on Mac OS systems might also use this tool to check.
    • The testing period will be sufficient enough for LL to determine whether they need to address the lack of OpenGL 2 support in future iterations of the viewer.
If you are worried about your older hardware supporting PBR Materials correctly, use Help → About to check the version of OpenGL you are using; you will likely find it is at least OpenGL 3, if not OpenGL 4+

Alpha Modes

  • With the PBR / Materials viewer, alphas are (as previously reported) move to linear colour space, which may cause problems for some pre-PBR content.
  • This is not been an issue for those creators working within the close Discord channel group using pre-release viewers (particularly given some TPVs already use linear colour space), but LL expects to get fuller feedback on the move once the project viewer is ready for use on a much broader basis.
  • If the move doesn’t work for pre-PBR content with alphas, the result might be that legacy content and PBR content will not alpha sort against each other, forcing an artificial sorting (e.g. sort rigged mesh alphas first, then sort non-rigged over).

In Brief

  • The question was asked about SL supporting the Open Asset Import Library for mesh imports.
    • It was described as a “cool but bloated”, and “great when you want broad spectrum asset import and don’t really care about doing it super well for any particular format, not so great when you want to support one thing really well.”
    • As such, LL would rather focus on just support glTF mesh, and as a part o this, as the viewer progresses and glTF mesh import is added, support for importing COLLADA files will likely be discontinued in the official viewer, and creators will be pointed to a COLLADA-to-glTF converter.
  • Terrain textures: LL is still looking at options for a future project to improve terrain textures.
    • One user-generated suggestion that has been accepted  for consideration is BUG-232769.
    • The Graphics Team are also looking at materials paint maps for terrain.
      • IF this approach were to be adapted it might comprise of a set of four materials per parcel, which could be painted onto the terrain “at some fidelity” (e.g. around 1/4 m or so), over the existing elevation-based texturing.
      • This would allow parcel owner to, or example, “paint” something like a cobblestone path through a part of their parcel or add high quality grass for  lawn, etc.
      • In particular, it could enable creators to provide “terrain ready” materials packs others can purchase and use in their parcels.
    • Note that currently, these are ideas. There is no actual project for revamping terrain textures in progress at the moment.
  • It was reiterated that there is an internal move to update the Second Life minimum system requirements to reflect the versions of required APIs which must be run on client hardware rather than specifying specific hardware (CPU, GPU, memory, etc.) as is currently the case.
  • The hoary old complaint of aviators having to fly through parcels with different EEP settings was again raised as an “issue”  (while not perfect, applying a preferred EEP setting to your avatar – Fixed Sky or Day Cycle – still seems the easiest option to overcome this rather than working to re-jig the viewer as a whole).
  • A  reminder Local KVP / “Linkset Data” should be deployed to the simhost RC channels in week #43. I’ll have a post out on this during that week.
    • When testing this capability it is important to not that data committed to a linkset will not survive the move of the linkset to a simulator channel that does not have the necessary support for the capability; ergo, all testing must take place within the defined RC channels following the initial deployment.
    • There will be a special article on this capability in these pages once it has rolled to RC.

Next Meeting

  • Thursday, November 3rd, 2022.

2022 SUG meetings week #42 summary

Posted on by Inara Pey
Green Acres, August 2022 – blog post

The following notes were taken from the Tuesday, October 18th, 2022 Simulator User Group (SUG) meeting. They form a summary of the items discussed and is not intended to be a full transcript. A video of the entire meeting is embedded at the end of the article for those wishing to review the meeting in full – my thanks to Pantera for recording it.

Server Deployments

Please see the forum deployment thread for the latest updates.

  • On Tuesday, October 18th, the Main SLS and Events channels were updated with server release 575585.
    • This release should contain two new functions llGetObjectLinkKey (specified under llGetLinkKey) and llSHA256String.
    • In addition, a slight change to the simulator code may help with the issue of people’s on-line / off-line status not being properly reported. It  is not an actual fix for the problem, but LL would like feedback as to whether people are seeing an improvement. See : BUG-232037 for more information on the issue.
  • On Wednesday, October 19th, the simhosts on the RC channels will be restarted but remain on simulator release 575585.

Available Official Viewers

  • Release viewer: version 6.6.4.575022 – hotfix for Crash at ~LLModalDialog() – promoted September 15 – no change.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself).
    • Maintenance 3 RC viewer, version 6.6.5.575257, September 23.
    • Maintenance P (Preferences, Position and Paste) RC viewer version 6.6.5.575055 September 19.
  • Project viewers:
    • Puppetry project viewer, version 6.6.3.575529,  October 12.
    • Performance Floater / Auto-FPS project viewer, version 6.6.5.575378, October 4.
    • Love Me Render (LMR) 6 graphics improvements project viewer 6.6.2.573263, July 21.

Local KVP / “Linkset Data”

From the server deployment thread:

We have a new feature build on Aditi for a new feature called Linkset Data. This feature works similarly to Experience Key-Value store, but the data lives with the object that sends and receives the data. Only scripts in the same linkset will be able to read the data written with this feature. For more details, see the in-progress wiki pages https://wiki.secondlife.com/wiki/LSL_Linkset_Data. You can try out the new LSL functions related to this feature at the following Aditi Mainland regions:
  • Blake Sea – Arabian ; Blake Sea – Atlantic ; Blake Sea – Beagle ; Blake Sea – Binnacle ; Blake Sea – Black ; Gothlauth ; Jigglypuff ; Mauve ; Moonberry ; Sapas ; Smithereens
We’re looking for feedback on this new feature including bugs and input on anything that might be missing or not work the way you’d expect. Please file a BUG Jira in all of those cases

This work is currently with the Lab’s QA team, and if cleared, could be a part of an RC channel deployment in week #43 (commencing Monday, October 24th, 2022.

These upcoming release sparked a conversation on data storage and access – please refer to the video for details.

In Brief

  • BUG-232037 “Avatar Online / Offline Status Not Correctly Updating” – LL believe that have a “handle” on the where the issue is originating, but there has been no time to take a deep dive into the actual cause as yet.
  • Further discussion on making multi-region crossings by vehicle more robust.
  • A general discussion on lighting.

2022 Puppetry project week #41 summary

Posted on by Inara Pey
Puppetry demonstration via Linden Lab – see below.  Demos video with the LL comment “We have some basic things working with a webcam and Second Life but there’s more to do before it’s as animated as we want.”

The following notes have been taken from chat logs and audio recording of the Thursday, October 13th Puppetry Project meetings held at the Castelet Puppetry Theatre on Aditi. These meetings are generally held on alternate weeks to the Content Creation User Group (CCUG), on same day / time (Thursdays at 13:00 SLT).

Notes in these summaries are not intended to be a full transcript of every meeting, but to highlight project progress / major topics of discussion.

Project Summary

  • Previously referred to as “avatar expressiveness”, Puppetry is intended to provide a means by which avatars can mimic physical world actions by their owners (e.g. head, hand, arm movements) through tools such as a webcam and using technologies like inverse kinematics (IK) and the  LLSD Event API Plug-in (LEAP) system.
    • Note that facial expressions and finger movements are not currently enabled.
    • Most movement is in the 2D plain (e.g., hand movements from side-to-side but not forward / back), due to limitations with things like depth of field tracking through a webcam, which has yet to be addressed.
  • The back-end support for the capability is only available on Aditi (the Beta grid) and within the following regions: Bunraku, Marionette, and Castelet.
  • Puppetry requires the use of a dedicated viewer, the Project Puppetry viewer, available through the official Second Life Alternate Viewers page.
  • No other special needs beyond the project viewer are required to “see” Puppetry animations. However, to use the capability to animate your own avatar and broadcast the results, requires additional work – refer to the links below.
  • There is now a Puppetry Discord channel – those wishing to join it should contact members of LL’s puppetry team, e.g. Aura Linden, Simon Linden, Rider Linden, Leviathan Linden (not a full list of names at this time – my apologies to those involved whom I have missed).

Bugs, Feature Requests and Code Submissions

  • For those experimenting with Puppetry, Jiras (bug reports / fixes or feature requests) should be filed with “[Puppetry]” at the start of the Jira title.
  • There is also a public facing Kanban board with public issues – those experiencing issues can also contact Wulf Linden.
  • Those wishing to submit code (plug-ins or other) or who wish to offer a specific feature that might be used with Puppetry should:

Further Information

Meeting Notes

New Viewer Version – 6.6.3.575529 Dated October 12th

  • This viewer uses a different, more efficient data format sending updates up to the region, and from the region to viewers.
    • The new and old formats and viewers are not compatible; someone on the new project viewer will be unable to see puppetry rendered for someone using the older viewer version, and vice-versa.
    • It is hoped that severe breakages between viewer versions like this will be avoided going forward, but this change was deemed necessary
  • This viewer also a crash (deadlock) fix, and puppetry animations should fade in/out when starting or explicitly stopping (animations may stop abruptly should the LEAP plugin crash, or the data stream is lost, etc.).
  •  Those self-compiling viewers with the puppetry code should ensure they are pulling the updated code from the  6.6.3.575529 (or later as new versions appear) repositories.

Protocol Overhaul

Leviathan Linden Linden noted the project team is going to overhaul the Puppetry/LEAP protocol.

  • The intent is to replace all the current LEAP commands (“move”, “set_this”, “set_that”, etc.), and replace with just two commands: “set” and “get”.
  • On the “set” side:
    • It will be possible set avatar joint transforms, or specify IK targets, and also set various configuration settings as necessary.
    • These set commands will be “incremental” in nature (so that changes can be made to reach the final state), and once set, they stay at the defined value until modified, cleared, or the plug-in “goes away”.
  • On the “get” side:
    • get_skeleton and any other get_foo commands (if used) will be replaced with {get: [skeleton, foo, …]}.
    • A message will be generated and set back to the viewer making the Get request, but the form of the message is still TBD.
  • Meanwhile, the viewer will only do IK for your own avatar, and will transmit the full parent-relative joint transforms of all puppeted joints through the server to other viewers, and LL will make it possible for a plug-in to just supply full parent-relative joint transforms if desired (e.g. no IK, just play the data)
  • This overhaul will also provide:
    • A way to move the Pelvis. This will include both a pre-IK transform (which is just setting the Pelvis transform) and also a post-IK transform, in case the avatar is to be moved after setting all the joints.
    • A “terse” format for the LEAP/Puppetry protocol to simplify some “set” commands to reduce data going over the LEAP data channel. It will be possible to mix these “terse” command with long-form explicit commands.
  • Leviathan plans to break all of this work down into a set of Jira issues and place them on the kanban board for ease of viewing.

The overall aim of this overhaul is to make the protocol more easily extendible in the future.

To the above, Simon Linden added:

The data stream is radically different than what we started with. Essentially your viewer will do the work for your avatar: send[ing] all data needed for your puppetry animations [so] the people seeing you just have to use those positions – no IK or significant processing. That should help out in the long run with crowds 

Example Script

Simon Linden has produced a simple example script that is pushed to the Leap repository:

  • It reads a JSON file and sends that puppetry data to the viewer.
  • Using it, is is possible to edit some values, save the JSON text file, and see bones move as an example of doing so.

In Brief

  • BUG-232764 “[PUPPETRY] [LEAP] Puppetry should be able to ‘Get’ and ‘Set’ avatar camera angle” has been raised to go with the protocol overhaul, and while it has yet to be formally accepted, has been viewed as a good idea by the Puppetry team.
  • Puppetry does not support physics feedback or collisions as yet, and work for it to do so is not on the short list of “things to do next”
  • There is currently an issue of “near-clipping” within a a first-person (e.g. Mouselook) view and using puppetry (so, for example, holding a hand up in front of your avatar’s face in Mouselook results in the hand being clipped and now fully rendering). This is believed to by an artefact of the viewer still rendering the head (even though unseen when in first-person view), and this interfering with rendering near-point objects like hands. The solution for this is still TBD.

Date of Next Meeting

  • Thursday, October 27th, 2022, 13:00 SLT.