Ethereal City Estate – Ethereal City Noir, May 2023 – blog post †
The following notes were taken from the Tuesday, June 27th 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.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
They are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Server Deployments
On Tuesday, June 27th, the simulator release 580543 was deployed to the SLS Main channel, placing all of the simhosts across the grid on the same release. This release includes:
PATCH method now enabled through LSL HTTP for both send and receive.
HEAD method now allowed through llHTTPRequest.
Linkset Size has been increased from 54 to 64m to match maximum prim size.
llGetAgentInfo can now detect scripted agent status.
On Wednesday, June 28th, the PBR Materials simulator code, currently on a limited Main grid deployment (Preflight channel only, I believe), will be updated. All other RC channels will be restarted without any changes to their simulator versions.
Viewer Updates
The Second Life Project Inventory Extensions viewer, version 6.6.13.580656, was issued on June 26th – see my overview for more.
The remaining viewers in the pipeline are:
Release viewer: Maintenance S RC viewer, version 6.6.12.579987, dated May 11, promoted May 16.
Maintenance T RC viewer, version 6.6.13.580419, June 7.
glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
Project viewers:
Emoji project viewer, version 6.6.13.580279, May 30.
Puppetry project viewer, version 6.6.12.579958, May 11.
Changes to How Asset UUIDs are Assigned
Right now when assets ids are assigned it is simply generated. We’re going changing that a bit. We’re going to start trying to de-dupe new assets. So if you were to upload to identical pictures of Kevin Bacon they would both end up with the same asset ID.
– Rider Linden
This is a major change to be deployed in an upcoming simulator release.
It will apply to textures, notecards, scripts (possibly gestures).
UUIDs for rezzed objects will remain unique.
The change also will not affect any UUIDs the viewer makes
The reason for this change is the Firestorm Bridge – which saves the same LSL script when it is created.
Refer to the latter half of the video below for further details on the discussion.
In Brief
Teleports:
Some are reporting increases in teleport failures, possibly the result of a failure mode wherein the simulator from which an agent (avatar) is departing closes the connection with the receiving simulator before the teleport has completed.
BUG-234022 “Teleport just before to change state will prevent the change state to occur” has also been filed, relating to issues with large scripts within worn attachments failing to correctly update on teleport / logging-in.
BUG-232037 “Avatar Online / Offline Status Not Correctly Updating” has seen some work put into it (currently with the Lab’s QA team) which many held ease the problem once it reaches a deployment status.
A general discussion on scripting issues – please refer to the video for details.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from the Tuesday, June 20th 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.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
They are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Server Deployments
There was no deployment on the SLS Main channel on Tuesday, June 20th. However, the simhosts were restarted.
On Wednesday, June 21st, the RC release deployed to the BlueSteel channel will be deployed to the rest of the RC simhosts. This release includes:
The “bot detection” update (i.e. AGENT_AUTOMATED constant for llGetAgentInfo() – so only detects if that flag is set, not if an agent is a bot or not.
The second part of the LSD rezzing fix + lLinksetDataDeleteFound and llLinksetDataCountFound, among other things.
Viewer Updates
No changes to the crop of official viewers for the start of the week, leaving the available list as:
Release viewer: Maintenance S RC viewer, version 6.6.12.579987, dated May 11, promoted May 16.
Maintenance T RC viewer, version 6.6.13.580419, June 7.
glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
Project viewers:
Emoji project viewer, version 6.6.13.580279, May 30.
Puppetry project viewer, version 6.6.12.579958, May 11.
In Brief
This was a solstice party week, so not a lot of technical discussion.
Depending on who was speaking, vehicle-based region crossings either appear to have improved for some reason, or at exactly the same.
There is a bug with the automated Map refresh / clearing which can result in regions removed from the grid being removed from the Map. Anyone noticing this is asked to raised a support ticket requesting the Map be updated.
The Lab is playing with an experimental capability for adding labelling to the Map – some of this was shown by Alexa Linden some time ago, but the experiments at the Lab are continuing, although it is not clear if any of this work will result in anything user-facing, as currently the overlay is effectively a replacement for the actual Map tile, hence why the examples below are on “empty” parts of the the Map.
The latest in LL’s experiments with Map overlays
llLinksetDataDeleteFound and llLinksetDataCountFound are awaiting documentation, but are now integrated into the next maintenance simulator.
A semi-entertaining discussion on Babylon 5 and Star Trek – who would’ve said Rider Linden is a B5 fan?! All I’ll say is not Zathras – because no-one ever listens to Zathras. Zathras, however, probably did say so. Even if only to Zathras.‡.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
‡ No, I’m not going to explain that further. Watch Babylon 5 and find out. You won’t regret it 🙂 .
The Last Aokigahara Souls, April 2023 – 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, June 15th, 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, together with viewer development work.
Usually chaired by Vir Linden, and dates and times can be obtained from the SL Public Calendar.
Conducted in mixed voice and text chat. Participants can use either when making comments or 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.
Viewer News
No official viewer updates up until the meeting, leaving the list as:
Release viewer: Maintenance S RC viewer, version 6.6.12.579987, dated May 11, promoted May 16.
Maintenance T RC viewer, version 6.6.13.580419, June 7.
glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
Project viewers:
Emoji project viewer, version 6.6.13.580279, May 30.
Puppetry project viewer, version 6.6.12.579958, May 11.
In addition:
Maintenance T is likely the next RC viewer in line for promotion to de facto release status; however, it currently has an elevated crashed rate compared to the current release viewer, so LL is looking to bring that down before any promotion in made.
The Emoji project viewer is liable to see further improvements to the Emoji picker in the UI.
All of the back-end work (simulator code and the inventory service) seen as necessary to support Inventory Thumbnails is now thought to be in place, opening the door for a Thumbnails project viewer “Soon™”, which is apparently awaiting QA clearance.
Apparently this now provides the option of displaying the contents of an inventory folder either as we’re currently familiar with them (icons and text) or in a “thumbnail view” – I’ll review this once the viewer is available.
It’s anticipated that as the feature goes mainstream, creators will include thumbnails with their product offerings, as well as users creating their own thumbnails of items already in their inventory.
A further Maintenance RC viewer (Maint U) is in development and could be surfacing “Soon™”.
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.
Substance Painter is also used as a guiding principal for how PBR materials should look in Second Life.
Up to four texture maps are supported for PBR Materials: the base colour (which includes the alpha); normal; metallic / roughness; and emissive, each with independent scaling.
Given the additional texture load, work has been put into improving texture handling within the PBR viewer.
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.
The overall goal is to provide as much support for the glTF 2.0 specification as possible.
To provide support for reflection probes and cubemap reflections.
There is another viewer RC in the works. This has been delayed whilst a number of bugs were resolved, but it is now with QA and pending their OK, it should be surfacing in the very near future.
The water fog density range has been updated in the PBR viewer. It was capable of being set from -10 through to 10, but is now “almost zero” through to 100, with the higher numbers indicating higher fog density (and lower visibility).
Sky settings:
As per my notes from the last CCUG, all “legacy” skies which do not have a probe ambience set, will have one automatically applied by the viewer.
This has lead to a checkbox being including in the Graphic Preferences to disable the automatic application. However, it is possible / likely the check box will be removed.
This will mean the only way to have “legacy” skies render as they did pre-PBR will be to set the probe ambience setting to zero in the sky settings.
Setting probe ambience to 0 effectively deactivates HDR rendering and tone mapping etc.
The above requirement to set the probe ambience to zero has two further impacts:
It will be the only means by which “legacy” materials can be rendered as they did pre-PBR; the viewer “hack” to desaturate and “nudge” the luminance of “legacy” materials to have them render as they did pre-PBR has been removed due to combination of factors, including a noticeable performance hit.
The hack that allowed full bright objects to be exempt from dynamic exposure (so they would always stay the same brightness no matter what the exposure) has also had to be removed from the viewer, again as a result of a noticeable performance hit (an extra texture sample for each pixel). So, full bright object will, in future versions of the PBR viewer, be subject to the same exposure rules as everything else in the scene.
This means that full bright objects will still appear to be lit by 100% of the light and be unaffected by things like local lights, but the overall dynamic exposure of the scene will also brighten / darken them in keeping with the rest of the scene, and tone mapping will be applied.
SL photographers who display their images in-world with full bright are going to need to experiment with using sky settings with tone mapping disabled when taking their shots in order to avoid it being applied twice to images (e.g. once when the snapshot was taken and again when displayed in-world) and having this unduly affect the full bright rendering of the image.
Glossy support led to performance hits, particularly when there were a lot of alpha objects in the scene being rendered.
This has now been mitigated via a number of means; e.g. SSR is not even applied if it exceeds a certain roughness value, nor is it applied to alpha blended objects (the “old fade-out” method is used – that is: the higher the roughness, the weaker the SSR and the greater the reliance on reflection probes).
There have also been some general adjustments to SSR to again try to reduce the performance hits, whilst also allowing more distant objects to be reflected off of surfaces – said to be noticeable on water and flat surfaces.
The SSR work provoked a reminder that it is important not to abuse the use of alpha surfaces when SSR is used in rendering.
For example:
If the object is just a single layer users will be looking through to see what lays beyond, than alpha blending “may be the right choice”.
However, alphas should not be used to create layered effects (e.g. setting the faces of a surface to transparent for a “window” and then applying a further alpha to give the window a “frosted glass” look, and having the viewer composite them when rendering. Instead, both alphas should be baked down into one material in PhotoShop (or similar) & applied).
This sparked a discussion on how general users who dabble in content creation and who may be used to working in certain ways, can be properly educated to understand things like this – which may be known and understood by mainstream content creators, but could easily pass others by, as there is no means within the viewer UI of telling what is “good” or “bad” techniques when banging things together (at least until frame rates disappear through the floor and into the cellar).
It was therefore suggested again that documentation on the wiki – “best practices” / a “bible” for PBR Materials creation / use really should accompany the formal release of PBR Materials, and this should be clearly pointed at though blog posts, etc.
PBR Terrain
Materials applied to Second Life terrains. Credit: Linden Lab
Per past meeting notes, Cosmic Linden is prototyping the application of PBR materials on terrain (see this blog post for more).
The focus currently is on adding triplanar mapping to the for terrain repeats, particularly on steep elevation changes (so as to avoid the all-too familiar “stretching” seen with textures).
The above does potentially incur a performance hit, as it is noted as being for “sufficiently capable machines”, so Cosmic has also been working on trying to optimise performance elsewhere in the use of materials on terrain, as well as carrying out some bug fixing.
Important notes with this work:
It is not terrain painting. It is the application of PBR materials – terrain painting is described as “something that’s on the radar” at LL.
The work does not include support for displacement maps.
The work is currently only viewer-side, with no corresponding server-side support, the idea here being to prototype what might be achieved and testing approaches / results.
In Brief
It was re-iterated that long-term graphics support on the MacOS side will be MoltenVK (with Vulkan the likely route for Windows), with Zink also being looked at.
New user retention:
It has been suggested that as many in the various SL communities – those running Community Gateways, content creators, etc., – all have a interest in the new-user experience and brining people into SL, that a semi-regular “New User Experience” meeting might be established by LL at which ideas can be more readily discussed, feedback given and communities and creators more directly engaged with LL’s own efforts (e.g. developing an ecosystem of clothing, etc., to support the (still) upcoming new starter avatars. etc.).
It was pointed out that one of the best ways to encourage retention is for existing users to be welcoming, polite and supportive of new users (clubs that have scripts auto-ejecting people just because they are only a handful of days old or on the basis that an avatar is not PIOF, for example, aren’t exactly rolling out the welcome mat, for example).
The above spun into a general discussion on content, content moderation, and similar.
There was a general discussion on Land Impact (LI) and how it is “too high” – although this is highly subjectively, given the diversity of content and its uses in SL (static, animated, Animesh, etc. – how high is “too high”? Is “too high” down to more a lack of understanding of actual rendering + simulator load costs than an objective measurement? etc.). That said, it was acknowledged that more could be done t help “improve” LI in some areas.
The above spun into a discussion on physics costs, and how convex hull physics forms are not the most efficient for SL due to the complexity of the tools used to create them, and the ease with which mistakes can be made in creating them, with indications that as the glTF project moves towards support for mesh uploads how physics shapes are used / applied is likely to be be revised.
Next Meeting
Thursday, June 29th, 2023.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a gathering of people every week. They are taken from my list of region visits, with a link to the post for those interested.
Burrow Wood: Road to Nowhere, April 2023 – blog post †
The following notes were taken from the Tuesday, June 13th 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.
Meeting Overview
The Simulator User Group (also referred to by its older name of Server User Group) exists to provide an opportunity for discussion about simulator technology, bugs, and feature ideas.
They are open to anyone with a concern / interest in the above topics, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab.
Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
Server Deployments
On Tuesday, June 13th:
The SLS Main channel servers were updated with a simulator release providing support for the new inventory thumbnails viewer capability soon to be forthcoming. See my recent TPVD meeting summaries for more on this capability. This project – or at least the simulator element – is apparently known as “Manicure” internally at the Lab!).
The Preflight RC channel was updated with simulator support for glTF PBR materials – see below for more on this deployment.
One Wednesday June14th, the BlueSteel RC channel will be updated with a maintenance release, which include:
The “bot detection” update (i.e. AGENT_AUTOMATED constant for llGetAgentInfo() – so only detects if that flag is set, not if an agent is a bot or not.
The second part of the LSD rezzing fix + lLinksetDataDeleteFound and llLinksetDataCountFound, among other things.
glTF PBR Simulator Deployment
The Preflight channel is a small channel compromising the following controlled access regions: Preflight 0] though Preflight 8, Rumpus Room 1 through Rumpus Room 5 and Testylvania Sandbox.
Access to these regions must be requested – but will remain limited; the purpose of this deployment is for small-scale testing of the PBR materials support on the Main grid.
A larger, more public deployment of the simulator PBR support code will be forthcoming, so those who do not have access to the Preflight regions should consider waiting for that deployment.
Viewer Updates
No changes to the crop of official viewers for the start of the week, leaving the available list as:
Release viewer: Maintenance S RC viewer, version 6.6.12.579987, dated May 11, promoted May 16.
Maintenance T RC viewer, version 6.6.13.580419, June 7.
glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
Project viewers:
Emoji project viewer, version 6.6.13.580279, May 30.
Puppetry project viewer, version 6.6.12.579958, May 11.
In Brief
PBR Terrain Work
To re-iterate:
This work is in development, but is a follow-on to the current PBR Materials project, not a part of it.
It is primarily viewer-side changes, allowing the application of PBR materials instead of the current terrain textures. It is *not* PBR terrain painting.
Extensions to the project are being discussed internally at the Lab, but the real focus will be on this initial work for the time being, and further information can be found in this official blog post.
Discussions on the work are held at the content Creation User Group meetings – see my meeting summaries or attend the meetings in person.
The PBR terrain project will allow PBR materials to be used on Second Life terrain in place of textures. Credit: Linden Lab
Inventory Thumbnails
This is primarily a viewer-side project which keeps coming up for discussion at the SUG meetings.
It will allow persistent thumbnail images with a maximum resolution of 256×256 to be produced, which can be stored within inventory with the items they represent such that they display an image of an item to be displayed on Mouseover.
Testing is currently underway to limit the impact the inclusion of thumbnails may have on inventory load time, texture memory use.
The viewer is not yet ready for a project viewer release, but the Lab is working on a blog post to outline more of the intended functionality of this capability.
In General
BUG-232037 “Avatar Online / Offline Status Not Correctly Updating” has further fixes in the works. No estimated time for deployment.
There is still upset circulating about the reduction in Linden Water reflections as a result of performance optimisations to help offset the impact of PBR rendering in the viewer. Currently, there are no plans to offer higher quality reflections in the future, but it is hoped that evolving work on screen space reflections will offset so of the loss of quality. For discussions on this, please see my Content Creation User Group (CCUG) summaries or attend the meetings in person.
A general discussion on updating Linden trees / plants, re-introducing the “wind” to sway trees, how physics calculations and costs are made / arrived at (with the latter noted as potentially being for a future (e.g. not this year) internal discussion at the Lab, so outside of the scope of comment from the La at present).
It was noted that there is a further simulator update in development which is hoped will reduce the hit simulators take when handling avatars arriving in a region (and with a focus on better handling of attachments). No ETA on when this will see the light of day.
A further discussion on region crossings and vehicles, which also rolled into vehicles hitting ban walls and avatars being ejected / vehicle returned, and a means of preventing this by forewarning on an impending region / parcel with access control enabled. Please refer to the video for all of this.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
The following notes were taken from my audio recording and chat log transcript of the TPV Developer (TPVD) meeting held on Friday, June 9th 2023 at 13:00 SLT. These notes are via a combination of my own chat log transcript of each meeting, and / or the video recording made of each meeting by Pantera Północy and embedded at the end of this article. My thanks, as always, to her for recording these meetings. Note that the following is a summary of the meeting as a whole, and not a transcript of everything discussed.
Meeting Overview
The TPV Developer meeting provides an opportunity for discussion about the development of, and features for, the Second Life viewer, and for Linden Lab viewer developers and third-party viewer (TPV) / open-source code contributors to discuss general viewer development.
glTF / PBR Materials viewer, version 7.0.0.580330, May 25.
Project viewers:
Emoji project viewer, version 6.6.13.580279, May 30.
Puppetry project viewer, version 6.6.12.579958, May 11.
General Viewer Notes
The glTF / PBR material viewer (and project) are in bug fixing mode, specifically with some QA questions / concerns on the server side of things.
Inventory thumbnails viewer: work is progressing, and the simulator support code has been deployed to the simulator RC channels and is expected to go to the SLS Main channel in week #24.This will potentially allow the first release of an Inventory Thumbnails project viewer.
LL has completed the move of viewer builds to Github Actions, and has now successfully completed the first viewer builds along this new process. Th next step is to move all viewer-related work away from Team City completely.
Prototyping is underway for the support of planar mirrors in SL and for the application of PBR materials on terrain (note, again, this is not PBR terrain painting, it is using PBR materials in place of the default terrain textures – see this blog post for more).
A test build of a viewer supporting the application of PBR materials for terrain has been made available through the Content Creation Discord server for limited testing, and feedback is being taken on this.
BUG-232037 “Avatar Online Offline Status Not Correctly Updating” was raised again, although more strictly a simulator issue. The precise cause(s) of the problem are still being investigated. Anecdotal evidence from some quarters claims the issue is getting worse, but whether this is objectively the case is questionable.
Next Meeting
Friday, July 7th, 2023.
† The header images included in these summaries are not intended to represent anything discussed at the meetings; they are simply here to avoid a repeated image of a rooftop of people every week. They are taken from my list of region visits, with a link to the post for those interested.
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, June 8th, 2023 Puppetry Project meetings. Notes in these summaries are not intended to be a full transcript of every meeting, but to highlight project progress / major topics of discussion.
Meeting And Project Overview
The Puppetry User Group exists to provide an opportunity for discussion about the development of, and feature for, the upcoming Second Life Puppetry project(see below for details), bugs, and feature ideas.
Those encountering issues in logging-in to Aditi should contact Second Life support for assistance.
Generally on alternate Thursdays to the Content Creation meetings.
Comprise a mix of text and voice – attendees can use text only, if preferred, but should enable to hear comments / responses given in voice.
These meetings are open to anyone with a concern / interest in the Puppetry project, and form one of a series of regular / semi-regular User Group meetings conducted by Linden Lab. Dates and times of all current meetings can be found on the Second Life Public Calendar, and descriptions of meetings are defined on the SL wiki.
General Project Description as Originally Conceived
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 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.
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).
Additional Work Not Originally In-Scope
Direct avatar / object / avatar-avatar interactions (“picking up” an apple; high-fives. etc.).
Animations streaming: allowing one viewer to run animations and have them sent via the simulator to all receiving viewers without any further processing of the animations by those viewers.
Enhanced LSL integration for animation control.
Adoption of better animation standards – possibly glTF.
Given the project is incorporating a lot of additional ideas, it is likely to evolve into a rolling development, with immediate targets for development / implementation decided 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.
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.
The viewer remains at version 6.6.12.579958, issued on Thursday, May 11th.
This update includes access to Rider Linden’s experimental attachment point tracking & forwarding to the server feature.
It also includes various incremental improvements to handling puppetry, such as support for parsing binary LEAP data from the LEAP script.
Work has slowed a little due to Linden staff being out-of-office recently (hence why no meeting since May 11th), and personnel on the Puppetry project also working on other simulator projects.
This has notably impacted Leviathan Linden’s work on Inverse Kinetics (IK), which has had a knock-on impact slowing Rider Linden’s work on LSL support for driving puppetry.
However, progress has resumed on the IK work and while described as currently “not stable”, and problems are still to be solved in situations where a target position is too far away for a joint in the skeleton to reach, or where multiple joints (e.g. 5 or 6) are involved.
One issue that is proving difficult to handle is the default avatar mesh joint weighting is incorrect along the forearm and wrist. What is required is two distinct joints at the forearm to do mesh bending correctly: a hinge at the elbow and also a twist constraint along the forearm bone, toward the wrist, rather than (as is currently the case) treating the wrist as a ball joint. This may be the subject of further internal discussion at LL as Leviathan gets more of the IK work nailed down.
WRT IK:
Leviathan is looking to solve the targeting issues first, then work back to ensure that there are no collisions between a limb and avatar body (e.g. reaching across the avatar’s body to pick something up, and the avatar’s elbow / part of the arm appears to go through the body).
Forward And Backward Reaching Inverse Kinematics (FABRIK) – which is the fundamental algorithm for suggesting new joint positions in a range of applications, including 3D modelling – is the route of choice of the Lab; however, adopting to FABRIK is taking some trial and error.
Additional Notes
Aura Linden is here but she is working on the Animation importer project which has been split off from the Puppetry project. Currently, the status is animations can be import import animations from some tools/formats, but others aren’t working yet.
It was noted at the last meeting, that for animation import, LL is looking towards using / supporting Assimp (github: https://github.com/assimp/assimp), which supports some 30-40 animation formats, converting them to it ownformat for ease of import to multiple platforms. Notably, it supports .FBX and glTF, so it fits with the Lab’s goal of utilising glTF for materials, mesh imports, etc.