Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates from the week through to Sunday, February 12th, 2023
This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Official LL Viewers
Release viewer: Maintenance Q(uality) viewer, version 6.6.9.577968, promoted Thursday, February 2, 2023- no change.
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, February 9th, 2023 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
General description of the project and its inception:
LL’s renewed interest in puppetry was primarily instigated by Philip joining LL as official advisor, and so it really was about streaming mocap. That is what Philip was interested in and why we started looking at it again. However since Puppetry’s announcement what I’ve been hearing from many SL Residents is: what they really want from “puppetry” is more physicality of the avatar in-world: picking up objects, holding hands, higher fidelity collisions.
As a result, that is what I’ve been contemplating: how to improve the control and physicality of the the avatar. Can that be the new improved direction of the Puppetry project? How to do it?
Leviathan Linden
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.
This project is taking in a lot of additional ideas – animation standards, improving the current animation system, enabling truer avatar / avatar and avatar object interactions such that it is likely to evolve into a rolling development, with immediate targets for development / implementation as they are agreed upon, to be followed by future enhancements.
As such, much of what goes into the meetings at present is general discussion and recommendations for consideration, rather than confirmed lines o development.
There is 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.
Leviathan Linden has been experimenting with animation streaming over the viewer’s animation channel, such that whatever is sent from the controlling viewer is played directly by all receiving viewers without any further processing of the animations by those receiving viewers.
This had been discussed in previous meetings as a potential means of lightening the load of animation data processing individual viewers would have to perform, reducing the potential performance impact in situations where animation synchronisation is important. It also lays something of a further foundation for more procedural-based animation processing, allowing viewers to work smarter – sending less data more frequently, which will in turn help enable synchronised animations through puppetry, such as spontaneously sharing a high five.
With this initial test, featuring just one viewer using puppetry and one receiving it, actually revealed a more noticeable lag in streaming compared to individual processing and playback of received animation data. It is not clear at this time whether this would worsen in situations where multiple puppetry animations are being streamed / received.
The videos were initially posted to the restricted-access Second Life Content Creation Discord server, and then combined into a single video by Kadah Coba, which is reproduced here as an animated GIF – my thanks to Kadah for the work in combining the videos.
Puppetry streaming test: top – animation played in one viewer (large image) with data sent for processing by a receiving video (inset). Bottom: the same animation played on the same viewer and then streamed to the receiving viewer (inset) and played on receipt without any additional animation processing.
Leviathan notes this is a very quick and dirty test, requiring “some hackery” within the viewer’s animation code, but does not (as yet) require any changes to the server-side puppetry management code.
Further refinement of the code is required, together with further testing to see if the approach can be smoothed / improved, as such, the work is not currently fit for integration into the Puppetry Project viewer, although it has been suggested it might be offered as a temporary, separate test viewer to allow broader testing.
On potential issue is that the streaming is currently dependent on the reliability of the originating viewer; if it is running at a low FPS, potentially causing the receiving viewers see a “choppier” result with lagging and smooth animations within the stream.
LSL Integration
See: OPEN-375: “LSL Functions for reading avatar animation positions”.
Rider Linden has been working on an LSL API to control animation on an avatar.
Conceptually it would behave like LEAP from LSL. The simulator will send the animation instructions down to the targeted viewer which will perform the IK and animation, and then send the results back as though they were coming from any other LEAP plugin. Targeting objects should be possible with the API (although I’ll add a world position/rotation parameter so you don’t have to do the math yourself).
– Rider Linden
This work is possibly best described as moving a step towards enabling an avatar using puppetry to reach out and pick up an apple by allowing a script to position the avatar’s hand at the location of the apple, from where the user can use a supported capture tool to “pick up” the apple.
The envisioned actions would be: the user move their avatar’s arm towards the apple, the apple detects the collision between the avatar hand and itself and attaches to the hand as if it has been directly picked up.
Further work is required involving collisions between the apple and the avatar’s hand, so the apple knows it is being “grabbed”. This might be achieved by using an existing collision event as the trigger for attachment, or an entirely new event.
One problem is to avoid having multiple extra collision objects bouncing around the physics engine for every single attachment point on an avatar (55 in total), which would add-up, performance-wise, very quickly.
One suggestion for mitigating this is that as region knows where your hand is (which is true with the attachment update stream), it could be possible by implementing a new “grab” action that works in the physics simulation for picking up small objects; however, it would likely need some hint/magic on the viewer to render the object “at the hand” rather than “near the hand”..
Beyond this, there is also additional work to allow avatar-to-avatar interactions via puppetry – such as the aforementioned high five – which involves addressing some permission issues.
In Brief
Concern was raised that emphasis on puppetry over the traditional canned animation assets is that it could make SL inaccessible for some (because of the need for additional motion capture hardware, a possible need for more powerful client computers, etc). In response, those at the meeting pointed out:
The approach being taken by the Lab is not new – it has been a common factor (albeit implemented in a verity of ways) within games for well over a decade, and is used in multi-player games without participants being “lagged” to the point where gameplay is broken.
What is being proposed with Puppetry is not even “new” (in the broadest sense); rather it is adding a further layer of animation capabilities to Second life which can enable a greater sense of interactivity to the platform.
In terms of hardware, it was further pointed out that while some at the meeting are using VR hardware – headsets and peripherals – all that is actually required to start leveraging the capabilities (and as LL have demonstrated in the animated GIF forming the banner of this summary is a basic webcam.
In a more general conversation, it was pointed out by those at the meeting and the Lab engineers that:
Whilst things like streaming puppetry animations may at times result in more visible lag / animation desynchronization, it offers so much more in the way of avatar interaction with the world, it would be more than worthwhile.
This work is purely about puppetry and interactivity; it does not actually alter the way more general animations – walking, standing, etc., work, as the underpinning locomotion engine within the simulator and how the viewer calculates motion based on data from the simulator is not being altered.
Instead, the LSL API (and the LEAP API?) will enable general avatar orientation and attachment point orientation / movement to ensure that arm correctly reaches out to “grab” the apple mentioned above, by effectively running in conjunction with the locomotion engine.
Angel Mist – The Cloud Garden, December 2022 – blog post
The following notes were taken from the Tuesday, February 7th, 2023 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
On Tuesday, February 7th 2023, the simhosts on the Main SLS channel were restarted without any change to their simulator code, leaving them on release 577734.
On Wednesday, February 8th, 2023, the RC channels will also be restarted without any version update.
Available Official Viewers
There have been no updates to the current list of available official viewers, leaving them as:
Release viewer: Maintenance Q(uality) viewer, version 6.6.9.577968 Thursday, February 2, 2023.
Performance Floater / Auto-FPS RC viewer, version 6.6.9.577251, January 4, 2023.
Project viewers:
PBR Materials project viewer, version 7.0.0.577997, February 2, 2023. This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
Puppetry project viewer, version 6.6.8.576972, December 8, 2022.
In Brief
The announcement about the Group Chat History gave rise to a discussion on the capability and making it more robust and deeper (e.g. be presenting more than just the last hour of group chat when used), together with general improvements to chat history management (timestamps, etc.). Please refer to the video for the full context.
BUG-229675 “Stopping llSetKeyframedMotion should always succeed and never shout an error” was again raised and noted as a not unreasonable request. Again, please refer to the video for further details.
Wednesday February 1st issues: a post-mortem on these was published on Thursday, February 2nd – please read it here for specifics.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates from the week through to Sunday, February 5th, 2023
This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Official LL Viewers
Release viewer: Maintenance Q(uality) viewer, version 6.6.9.577968, promoted Thursday, February 2, 2023.
Release channel cohorts:
Maintenance R RC viewer, version 6.6.10.578087, February 3 – translation updates and the return of slam bits.
Project viewers:
glTF / PBR Materials viewer, version 7.0.0.577997, February 2, 2023. This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
Jitters Coffee Shop, Heterocera – December 2022 – blog post
The following notes were taken from my audio recording and chat log transcript of the Content Creation User Group (CCUG) meeting held on Thursday, January 19th 2023 at 13:00 SLT. These meetings are for discussion of work related to content creation in Second Life, including current work, upcoming work, and requests or comments from the community, and are chaired by Vir Linden. Dates and times can be obtained from the SL Public Calendar.
Notes:
These meetings are conducted in mixed voice and text chat. Participants can use either to make comments / ask or respond to comments, but note that you will need Voice to be enabled to hear responses and comments from the Linden reps and other using it. If you have issues with hearing or following the voice discussions, please inform the Lindens at the meeting.
The following is a summary of the key topics discussed in the meeting, and is not intended to be a full transcript of all points raised.
Official Viewers Summary
Available Viewers
On Thursday, February 2nd, 2023:
The Maintenance Q(uality) viewer, version 6.6.9.577968 was promoted to de facto release status.
The PBR Materials project viewer updated to version 7.0.0.577997.
On Friday, February 3rd, 2023 the Maintenace R RC viewer updated to version 6.6.10.578087 – translation updates and the return of slam bits.
The remaining official viewer pipelines are unchanged, as follows:
Performance Floater / Auto-FPS RC viewer, version 6.6.9.577251, January 4, 2023.
Project viewers:
7.0.0.577780, January 25, 2023 – This viewer will only function on the following Aditi (beta grid) regions: Materials1; Materials Adult and Rumpus Room 1 through 4.
Puppetry project viewer, version 6.6.8.576972, December 8, 2022.
General Viewer Notes
It is believed the next viewer due for promotion will be the Performance Floater / Auto FPS viewer, at which point all viewer releases will officially all be based on VS 2022 for Windows, as this is the first RC viewer merged with the VS 2022 release process (previously a separate viewer build fork).
glTF Materials and Reflection Probes
Project Summary
To provide support for PBR materials using the core glTF 2.0 specification Section 3.9 and using mikkTSpace tangents, including the ability to have PBR Materials assets which can be applied to surfaces and also traded / sold.
To provide support for reflection probes and cubemap reflections.
The overall goal is to provide as much support for the glTF 2.0 specification as possible.
In the near-term, glTF materials assets are materials scenes that don’t have any nodes / geometry, they only have the materials array, and there is only one material in that array.
It is currently to early to state how this might change when glTF support is expanded to include entire objects.
The project viewer is available via the Alternate Viewers page, but will only work on the following regions on Aditi (the Beta grid): Materials1; Materials Adult and Rumpus Room 1 through 4.
The latest update to the viewer includes improvements to probe light blending (e.g. between overlapping manually-placed probes), additional work on radiance and irradiance, and the resolution quality of reflections set back up to 256×256 per face (but will downgrade to 128×128 if the viewer has less than 2 GB of available VRAM). All of this should leave the visual quality of reflection probes “pretty close” to what will be seen in the RC / release version of the viewer.
However, there is still a hard transition line between line between overlapping automatic probes and manually place probes, and LL want to encourage those using probes to use full scene manually-placed probes to ensure a much better quality of reflections.
Automatically-placed probes have had parallax correction removed, this should prevent the issue of people seeing the ray traced sphere of the probe rather than the reflection of the environment. Parallax correction is now only available with manually-placed probes.
Screen Space Reflections (SSR) have also been integrated with the reflection probes so that when the viewer does a look-up on a reflection probe and SSR in enabled, if there is an available SSR that gives a better result than the (generally automatic) reflection probe’s sample, it will be used instead.
In addition, there has been further work on optimisation and frame rate smoothing.
Still to be addressed in the viewer:
Some general artefacts still requiring clean-up, notably water reflections / light speckling, objects being rotated in reflections, and some remaining issues with colour curves on HUD attachments.
Further UI work.
There are some glTF materials caching issues which have yet to be addressed.
LL is in the process of finalising compliance with the glTF standards. This does not impact viewer and glTF testing on Aditi (the beta grid), but will require updates to the viewer which are likely to come into force during RC / beta testing, meaning that only the updated viewer should be used from that point forward. However, it should not impact / alter overall functionality within the viewer.
This is the result of an incorrect assumption being made about some of the data required by the glTF specification would “always be there”, when in fact the filtering process LL uses to ensure glTF files uploaded do not contain anything malicious was dropping some of that data (so the visuals were correct, but the data was “wrong” compared to the standard).
In an effort to have media on a prim work on glTF materials in a similar manner to the current SL materials (where setting a face to media on an object overwrites the diffuse (texture) map), setting media on a PBR materials face will overwrite both the diffuse and emissive maps, whilst sill allowing media to be viewed on a shiny surface, et., as per the current behaviour.
There is concern about the impact of allowing “double-sided” materials as a part of glTF PBR (e.g. the risk of over-use, potential performance impacts, etc.).
LL acknowledged that a lot of samples they’ve tested from Sketchfab do contain a a lot of “unnecessary” double-sided surfaces, and so are considering implementing a check and warning on import where this occurs.
There is currently a checkbox for enabling / disabling double-sided materials in the PBR viewer’s materials editor, but LL’s view is that allowing double-sided content is not going to “ruin SL forever” – a view not necessarily shared by some creators.
Vulkan
It is possible that 2023 will see the resumption of work to add support for the Vulkan / MoltenVK (for OS X) API alongside of OpenGL, as the latter is both growing increasingly long in the tooth and is gradually being deprecated / no longer used / supported on a number of fronts.
Within LL, it is believed that implementing this support will not only get SL past the issue of OpenGL’s status, but also offer performance improvements within the viewer (e.g. allowing SL to be less CPU-bound and make more use of the GPU, reducing the volume of draw calls, etc.).
In Brief
LL have been experimenting with pulling purchased content using glTF materials from Sketchfab and importing it to SL. The process is not easy, and it is acknowledge more work needs to be done to smooth this out at some point in the future – it will not be improved before the current project moves to a release status.
This raised the question of licensing, rights, mesh uploads to SL and the Terms of Service, with a not from LL that this likely needs to be reviewed as a whole, and guidelines provided to specify requirements for uploading content purchased by / built via 3rd party sites and things like license compliance (together the the need for LL to determine the means of gatekeeping things like license compliance).
Routes to upload from the likes of Sketchfab would be beneficial, as it would mean creators used to building for those platforms could pull their content into SL without having to learn a further (esoteric) set of content creation requirements.
There was a general discussion on texture compression with glTF (which remains in place for all maps other than normal map, where compressed lossless is viewed as important), and on glTF allowing backward-facing normal maps (unsupported with the current SL materials system), and possible problems / benefits these might lead to.
In terms of which parts of the glTF specification SL is supporting, LL will likely produce a living document that will detail the initial support, and which will be updated when further support is added / certified by Khronos.
For future work, it appears at present that supporting glTF mesh imports would take priority over implementing glTF materials extensions from the specification.
Related to the above point, discussions are in progress within LL on how to continue to support COLLADA (.DAE) mesh imports into SL without actively supporting COLLADA format.
Reasons for sunsetting direct COLLADA import to SL include: there are still a lot of traps creators can fall into with the SL implementation of COLLADA support which can be a barrier to entry for those wishing to engage in SL as creators (similar traps do not exist within the glTF standard); maintaining the COLLADA importer adds cost and overheads, as every importer update has to be tested against it and adjustments made where they break COLLADA uploads.
One option under consideration is the use of the Open Asset Import Library (Assimp). This acts an an intermediary (so .DAE files get converted to the glTF mesh format), allowing a route of upload for COLLADA file to SL without LL having to maintain the COLLADA import mechanism directly, reducing the overheads of having to both test against it and maintain COOLADA import support.
This route would also allow other mesh formats (e.g. .FBX) to be “supported”, with the glTF specification support document mentioned above, available for creators to check which elements within the glTF specification they may need to add in order to get a like-for-like between their build format (.DAE. .FBX, etc.), and glTF.
Concern was raised about what the removal of direct COLLADA import might do the the market for full permission .DAE files which can be purchased through the SL Marketplace for upload to SL (although it is not clear how big this market is).
It is hoped that any approach taken would offer at least a robust a means of importing COLLDA meshes as the current importer.
Also under internal discussion is how to support hierarchies in the context of glTF assets and what that means (e.g. import an asset with a node graph hierarchy, attach it to a mesh, and then manipulate the hierarchy via the edit tools or LSL).
Cover Second Life front-end web properties (Marketplace, secondlife.com, the sign-up pages, the Lab’s corporate pages, etc.).
They are not intended for the discussion of Governance issues, land fees / issues, content creation & tools, viewer or simulator development / projects. Please refer to the SL calendar for information on available meetings for these topics.
A video of the meeting, courtesy of Pantera, can be found embedded at the end of this article (my thanks to her as always!), and subject timestamps to the relevant points in the video are provided. Again, the following is a summary of key topics / discussions, not a full transcript of everything mentioned.
Updates for January 2023
Land Portal Release
[Video: 06:00-08:00] The new Land Portal has been launched. This is intended to be a central hub from which to get to all aspects of land “ownership” – purchasing regions, renting land from a private estate, renting or purchasing Mainland; obtaining a Linden Home.
[Video: 10:33-10:49] There are currently no actual functionality changes to the pages behind the portal – these will come in time.
[Video: 8:51-9:22] The first of the Land pages to undergo update and improvement will be the Linden Homes page. This will make it easier to see and select available Linden Home styles – but this update “will be a while” before it is surfaced.
Translations for the Portal and the Land pages will come in due course.
The Portal has been used as something of a prototype, bringing together tools and technologies the Lab intend to use to build-out updated versions of their websites and portals, and ensure they are mobile-friendly.
A portion of the new land portal front-end – click to visit
A technical blog post on what the web tools and ongoing website redesign means will be published be the Lab in the near future.
The deployment of the Marketplace Search updates has been further delayed, as indexing all searched to date is taking longer than anticipated to complete.
All other work is completed – the code is in place and ready to go – but LL want to ensure that search and order histories all remain in place when the switch is thrown.
once fully deployed, the new MP Search will have a close parity with the updated web search deployed in 2023, including its own relevance engine.
One idea being floated internally at LL is the idea of awarding worn / attached items a “gold star” to items with a “low Land Impact”.
The suggested approach would be to have some form of automated “side bake” mechanism which takes avatar attachments and assesses their LI, and then awards them a “gold star” on the basis of whether or not they remain within some defined “LI threshold”. “Gold star wearables” would then be searchable as a category / categories within the MP.
The core aims of this would be to:
Encourage wearable items creators to ensure their clothing and avatar attachment are more render performant/efficient (avatars currently have perhaps the highest performance impact, as no real constraints are currently placed on the complexity of worn items, so there is no incentive to model them as efficiently as possible).
Encourage consumers to consider what they are purchasing and its impact (“the gold star means it is better for you and SL”).
This does raise concerns of further gaming of LOD (level of detail) in order to bring items in under the threshold, with the result that while they gain the “gold star” they nevertheless immediate collapse into one (or a small group) or triangles when seen from even a minimal distance – with creators who do so then “recommending” users set their viewer’s LOD rendering unnaturally high – and in the process further negatively impacting viewer performance.
Alternatives offered at the meeting:
Utilise the revised avatar complexity calculations which form a part of the ARCTan project by which to measure the complexity of worn items (the problem here being the ARCTan project stalled some 2+ years ago and has yet to be re-started).
Utilise the “good LOD” calculations used for Animesh to encourage creators to model their clothing / attachments responsibly.
General Marketplace Discussion / Exchange of Ideas
Variants (officially “Styles” – e.g. having multiple colour options for an item in a single listing) was again raised. No further direct feedback on this was given; however, at the January meeting it was indicated the work (which has apparently largely been done) is being “re-prioritised” in the face of the delays in deploying the updated MP Search.
“One click demos” were suggested for the MP – being able to click on an attachment offing in the Marketplace and the item is temporarily worn in-world. This is something Garfield Linden indicated was of interest to him, and requested a Feature Request Jira on the idea.
Search:
Phonetic searching was requested (particularly handy for those not well-versed in the currently-supported languages / dyslexia, where fuzzy search might over-compensate with results). Sntax [sic] Linden acknowledged the “appeal” of phonetic searching.
Filtering clothing / attachments by body type: this is something the Marketplace Team are already looking at in terms of the “most popular” bodies – although how representative this might be of SL’s diversity is hard to determine.
Pay what you want – suggested as a possible option to allow merchants to offer items for free, but with the option for buyers to offer a “tip” in payment.
The functionality for this may be overly complicated to implement.
However, in considering Marketplace updates / a rebuild, LL have looked at options for offering coupons, sales, and “price changey” options, so this idea will be added to the list for further internal discussion.
It was acknowledged that Marketplace load times in the viewer’s browser (and the load times of other SL web properties a user may already be logged-in to) are “to darn high”, and that there are “performance skirmishes” to be had in this area.
A suggestion was made for the Marketplace to support “related items” between stores. This would require engagement by Merchants, but the idea would be if Merchant A produced items intended for use with something Merchant B produces, they could mutually list one another’s products as being related. It could also be technically complex to implement.
Marketplace and CasperVend integration: this is something LL would like to do following the purchase of CasperTech, and have had discussions about, but there are no firm plans as to have it might be tackled as yet.
Inara Pey: Living in a Modemworld 