Perpetuity, February 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, April 6th, 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. They are usually chaired by Vir Linden, and 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.
Additional note: unfortunately, physical world matters meant I missed the initial part of the meeting, and as it is held in voice, there is little by way of chat transcript to reflect initial discussions prior to my arrival.
Official Viewer Status
On April 6th:
Maintenance T(ranslation) RC viewer, version 6.6.11.579154, was issued.
The PBR Materials / reflection probes project viewer updated to version 7.0.0.579241.
The rest of the current official viewers remain as:
Release viewer: Maintenance R viewer, version 6.6.10.579060, dated March 28, promoted March 30th.
Release channel cohorts:
Maintenance S, version 6.6.11.579153, March 31st.
Performance Floater / Auto FPS RC viewer updated to version 6.6.11.579238, April 4th.
Project viewers:
Puppetry project viewer, version 6.6.8.576972, December 8, 2022.
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 viewer has been updated to maintain parity with the release viewer, and work continues to get the viewer to a position where it can move to RC status.
Once it does go to RC status, it is expected to remain there for “a few months”.
Currently, the viewer is at a point where creators who wish to make content using PBR tools such as Substance Painter can do so and work to the rule-of-thumb that if it looks the same in both Substance Painter and the glTF viewer, than all is well and good – BUT, if the SL version looks noticeably different in the viewer, then a bug report should be filed, the issue should not be worked around.
Getting the simulator support for glTF moved to Agni is now being considered.
With regards to Bakes on Mesh, glTF Materials work in a similar manner to the current materials – the result of the BoM process gets fed into the base colour (+ the emissive map) like it does with the diffuse map for materials at present.
This does not mean BoM is glTF materials enabled; that still requires an update to the Bake Service to support materials data.
Updating the Bake Service is still seen as a “high value” future project.
The Sun midday position of the Sun has been adjusted so that it is no longer directly overhead, but is angled to appear as it would at a latitude of around 40ºN/S in spring.
Left: the glTF viewer repositions the midday Sun so it is in similar position as it would appear in the physical world at a latitude of around 40ºN/S in the spring, as opposed to being directly overhead as seen in the image on the right. Credit: Runitai Linden
Automatic alpha masks are turned off in the PBR viewer, and are likely to remain this way unless a compelling reason emerges for this not to be the case. So the Develop(er) → Rendering → Automatic Alpha Masks option for deferred rendering is off (and the one for forward rendering removed, as the glTF viewer does not support forward rendering).
HDRi Sky Rendering
In order to get parity with High Dynamic Range Imaging (HDRi) environment maps has meant the sky as rendered on the glTF viewer is essentially HDR with added dynamic exposure. Without this change, the sky was lighting everything as if it were a “giant blue wall” rather than a bright sky.
This has impacted EEP (the Environment Enhancement Project, and means that the sky can look over-exposed under some settings.
LL is trying to zero in on a sky of sky parameters that is acceptable to most EEP settings. However, the issue is particularly noticeable for EEP settings which use “day for night” (e.g. they utilise dark sky tinting, etc., and replace the Sun texture with a planet or moon or some such, because the HDR rendering assumes that because the Sun “up”, there should be a brighter lighting used in the sky.
The choice here is:
Should the parameter be adjusted for uniformity (and some EEP settings require adjustment), or
Should additional control be supplied to allow additional control over the sky brightness, etc., to deal with EEP settings where the above issues occur?
The problems with this second approach are that:
It “severely” fragment the expected colour space in the process, leaving content creators having to work with multiple lighting models (e,g. as with working with ALM on or off at present)?
It is akin to LL removing the ability to disable ALM in the PBR viewer and remove the older forward rendering code, only to then implement another “button” to alter the environment rendering, rather than keeping things uniform.
This topic has been the subject of heated debate within the Content Creation Discord channel.
In Brief
Priorities for graphics / content creation work after glTF Materials are currently planar mirrors and then glTF mesh imports.
The following notes were taken from the Tuesday, April 4th 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, April 4th, the SLS Main channel servers were updated with the simulator release 579022 which adds several new LSL methods, including methods to hash strings, replace substrings, and get additional data using llGetEnv and llGetSimStats. It also cleans up some unused codepaths to make future improvements easier.
On Wednesday, April 5th:
The majority of RC simhosts will be restarted and remain on simhost 579022.
The Bluesteel RC channel simhosts will be updated with simulator release 579248, an update to 579022 containing a series of bug fixes and doubles the linkset data memory limit to 128KB.
Wiki entries for the above functions are still in progress.
Upcoming Simulator Releases
The next two week or so should see simulator release intended to address some long standing bugs:
The issue with a vehicle colliding with the avatar that was riding it on a region crossing.
Throttling on erroneous llReturnObjectsByOwner.
A number of internal bugs plus some further issues if the fixes can be completed an passed to QA.
Viewer Updates
On Tuesday, April 4th: Performance Floater / Auto FPS RC viewer updated to version updated to version 6.6.11.579238.
The remaining viewer pipelines stand as:
Release viewer: Maintenance R viewer, version 6.6.10.579060, dated March 28, promoted March 30th.
Maintenance S RC viewer, version 6.6.11.579153, March 31st.
Project viewers:
PBR Materials project viewer, version 7.0.0.578921, March 23 – 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.
llReturnObjectsByOwner() and OnwerID
Leviathan Linden has been looking at a non-public bug, BUG-11770, regarding throttle behaviour for llReturnObjectsByOwner().
He has noted that if returns are too fast, it will block the owner_id, potentially indefinitely.
While there is a workaround – where if you try to return a different owner_id, then it will unblock the first – this is described as “not very useful” as it requires a 2-hour wait before it really has an effect, and even then might not work without a region restart.
Instead, Leviathan has suggested a more optimal throttle would be one that limits the rate of return if it threatens to kill the database service, but then gradually opens up again as the database catches-up with the returns requests.
Other suggests included:
Rather than llReturnObjectsByOwner() simply finding all the objects on the parcel and trying to return them all in a single operation (thus hitting the database service), the object are effective batched and returned by said batches, with a further suggestion that while this is happening, the selected objects are locked / frozen to prevent them being used / moved until returned.
One concern with this approach is people arriving during a return operation and witnessing objects in-world mysteriously vanishing.
If BUG-8383 “Feature Request: Parcel and script options to return no-copy objects and delete copy objects” were to be implemented, it would reduce the strain on the data servers; however concern was raised that deletion of copy items could lead to lost work on sandboxes.
It was also suggested it would be useful if there was an LSL function to detect the amount of objects (e.g. a “llCountObjectsByOwner” function), which could compare it to the upper limit of returns, so that people could know if a return operation will fail due to the throttle before making the attempt.
Leviathan is taking the feedback gained to consider what can be done.
In Brief
The issue of Friends not correctly showing as on-line (or off-line) is receiving attention within LL, and apparently “multiple issues” have been found, which are likely to take “a bit of time to get them all fixed”.
Please refer to the video for the rest of the meeting discussions.
Celestial Glade, February 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, March 30th, 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. They are chaired by Vir Linden, and 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.
Additional note: unfortunately, physical world matters meant I missed the initial part of the meeting, and as it is held in voice, there is little by way of chat transcript to reflect initial discussions prior to my arrival.
Official Viewer Status
On March 30th, the Maintenance R viewer, version 6.6.10.579060, was promoted to de facto release status.
On March 31st, the Maintenance S RC viewer updated to version 6.6.11.579153, bringing it to parity with the above release viewer.
The rest of the current official viewers remain as:
Release channel cohorts:
Performance Floater / Auto FPS RC viewer updated to version 6.6.10.578172, February 21, 2023.
Project viewers:
PBR Materials project viewer, version 7.0.0.578921, March 23 – 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.
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 viewer is still being progressed, and will likely update to keep in line with the current release viewer.
There is still a bug with glow which needs to be addressed, but this is not seen as a significant issue in terms of fixing.
Information in support of PBR materials and reflection probes is in development. This includes new wiki pages and – at least for reflection probes, if not both, new tutorial videos.
A very much Work In Progress version of the wiki information can be found in: PBR Materials.
The methodology for modifying PBR materials via script is to have the materials contained within glTF assets which can be stored in inventory (containing an LLSD header and glTF JSON, with the texture / material UUID stored in the image URI field), with LSL APIs used to modify the parameters within the glTF file.
Manual modification of the parameters can be done via the viewer UI in a similar manner to manipulating textures, etc., currently offered by the viewer.
The LSL APIs will work in a similar manner to functions such as llSetPrimPratams, etc. The only thing that cannot be changed in is actual image data.
For testing, it was noted the “local materials” should allow Materials to be tested directly from a user’s computer in a similar manner to local textures (and only visible in that user’s world view), which dynamic updating of the materials in the session as they are locally modified.
In Brief
Requests have been made for a more visual coding capability in SL to help those who are not programmers / scripters, with the likes of capabilities similar to Blueprints in Unreal Engine. While such tools as the latter are acknowledged as being useful for putting snippets of code together, the notion of a visual coding system is seen by LL as potentially cumbersome for the results they would garner.
The following notes were taken from the Tuesday, March 28th, 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, March 28th, the SLS Main channel servers received the Estate Level Scripted Agent Controls (aka “Ban the Bots”).
On Wednesday March 29th, all simhosts on the RC channels will be updated to run the same simulator release, comprising the new LSL Functions llList2ListSlice, llSortListStrided, and llListFindListStrided (per BUG-231545). It also has a fix for DATA_SIM_STATUS from llRequestSimulatorData(), and doubles the amount of memory available for Linkset Data (LSD) to 128k.
Estate Level Scripted Agent Controls (aka “Ban the Bots”)
This is the simulator update referenced in the March 10th Lab Gab session – see: Lab Gab summary: Grumpity, Mojo & Patch – SL Mobile, land, bots & more – Bots and Policies).
The update includes a console variable that can be set by estate managers to either True or False. When set to True it will prevent Scripted Agents from entering regions in an estate (those required by the estate can be added to the access list so they can continue to access regions).
This will be supported in time by a viewer UI update to allow the option to be managed more directly – but it will still be a while before this UI change surfaces in the viewer.
There will be a policy change update published soon which will further cover these changes and the operation of Scripted Agents.
Further changes have been suggested within the Lab – notably to traffic – but it has yet to be decided on whether / when these will be implemented. In the meantime, please also refer to this FAQ.
Maintenance S RC viewer, version 6.6.10.578270, issued February 24.
Performance Floater / Auto FPS RC viewer updated to version 6.6.10.578172, February 21, 2023.
Project viewers:
PBR Materials project viewer, version 7.0.0.578921, March 23 – 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.
This was another meeting with live music, so technical discussions were not up to the usual amount.
There was a general discussion on testing vehicle region crossings and on the deployment of the LSL functions currently being deployed and mentioned above. Please refer to the video for details.
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, March 23rd, 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 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 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.
An updated version of the project viewer is still “close” – it did not make it past QA, but it is hoped it will be available soon.
Leviathan Linden is working on the IK system in order to try to make it more robust to handle the kind of work Rider Linden is doing, but is not at the point of having anything ready for delivery into a viewer, although the idea was to have something possibly ready by the viewer update after the one that is still waiting to be cleared for project release.
Server-Side Work
Following the meeting, the current Puppetry test regions on Aditi were due to be updated with a simulator version which merges the server-side Puppetry code with the latest release of the simulator code.
Rider Linden is continuing to work on llSetAttachmentPoint, intended to allow avatars “pick up” objects using puppetry. At the time of the meeting he was completing work on ANIM_POS/ROT_TARGET which is intended to try to keep the attachment point directed at an object in world (as opposed to a fixed location or a location relative to the avatar.
This uses a command to tell the viewer to carry out the necessary IK work to move an attachment point as close to a location as it can get, using the target object’s UUID / location as reported by the simulator.
The idea is that this functionality will work not only with hands / arms but also with other appendages (e.g. wings).
In theory, this should also allow avatars to touch attachment point on other avatars (e.g. holding hands), however, exactly how this works within the framework of the Permissions system – in terms of others accepting / refusing any direct interaction through something like a dialogue request as we see today – has yet to be worked out.
This led to a broader discussion on attaching object to avatars, the core of which is summarised below.
Object Parenting vs. Temp Attachments
The idea of being able to use Puppetry to reach out and grasp a (suitably scripted) object in-world – for example, an apple, a bottle or similar) raised questions on how the process will work.
Currently, “temp” attachment can be made to avatars (e.g. via an Experience), but this still actually requires the object being temporarily transfers to the avatar’s inventory (where it does not how up) and from there attached to the relevant attach point (e.g. a hand).
This is somewhat slow and cumbersome – particularly if you want to do something with the object (e.g. if it is a ball, throw it), as the object needs to be picked up, held, follow the throwing motion of the avatar’s arm, detach at the point of release, resume its status as a physical object in-world, have direct and velocity applied, and then move in the direction of the throw.
The suggestion was made that to simplify things, a concept of avatar-to-object parenting needs to be introduced to SL – so when the ball is picked up, it immediately becomes a child of that avatar – no need for the passing to inventory, attaching from there, detaching to inventory / deletion, etc., as seen with temp attachments.
Developing a hierarchy scheme for SL is already being mused through the Content Creation User Group, so it was suggested this could help present a road to object parenting with avatars. However, as it will take some time for any hierarchy system to be developed and implemented – and given it falls outside of the Puppetry project – , its might mean that existing mechanisms may have to be accepted, even if they do place some limitations on what might be achieved until such time as a hierarchy system can be introduced.
As an alternative, it was suggested that the physics engine might be used to attach a degree of object parenting to an avatar:
The physics engine allows actions to be created, which are updated every sub-step; so in the case of a physical object, it should be possible to write an action that says, “Follow the hand of the avatar picking you up”.
Then, as long as a the physics engine knows the position of the “holding” hand, the object could move with it; while there would be a small degree of physics lag, as long as the viewer knows to render the object at the avatar’s hand, rather than where the physics updates are saying he object is, this should not be visually noticeable.
This approach would not require an explicit hierarchy system, but it would require the viewer to send updates on the avatar’s hand position to the simulator’s physics engine – which is available.
The idea is modelled on the old physics action that perhaps most famously allowed a beach ball to be grabbed and pushed / lifted up onto a table as a part of the orientation process to using SL incoming new users used to go through, and can still be used today to push suitably scripted objects around.
If possible, this approach would also need some form of constraints and permissions (e.g. you don’t really want to make your entire building capable of being grabbed and shunted around willy-nilly).
General Notes
There was a general conversation on Permissions within avatar-to-avatar interactions and where they need to fall.
As noted above, there will need to be some form of explicit granting of permission for Puppetry-generated hugs, handshakes, high-fives, etc.
However, concern was raised about permissions being needed for basic one-way interactions – such as pointing at someone. The concern here being that the LookAt debug targets has become so conflated with ideas of “privacy” tools (“Stop looking at me, perv! You don’t have permission!”) TPVs have surfaced the means to disable LookAts being sent via a viewer so that people do not get shouted at if their LookAt cross-hairs happen to reside on another avatar. Thus, the worry was that if there is a similar kind of visual indicator used for Puppetry, it might result in a similar reaction.
The short answer to this was, no, it should not be an issue as avatar locations can already be obtained through LSL without the need for a visual indicator being generated by the viewer.
The following notes were taken from the Tuesday, March 21s, 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, March 21st, the SLS Main channel servers were restarted without any deployment, leaving them on simulator version 577734.
On Wednesday, March 22nd, one half of the RC channel servers will receive an update to their current simulator release, the remainder will gain the Estate Level Scripted Agent Controls (aka “Ban the Bots”).
Estate Level Scripted Agent Controls (aka “Ban the Bots”)
This is the simulator update referenced in the March 10th Lab Gab session – see: Lab Gab summary: Grumpity, Mojo & Patch – SL Mobile, land, bots & more – Bots and Policies.
The update includes a console variable that can be set by estate managers to either True or False. When set to True it will prevent Scripted Agents from entering regions in an estate (those required by the estate can be added to the access list so they can continue to access regions).
This will be supported in time by a viewer UI update to allow the option to be managed more directly – but it will still be a while before this UI change surfaces in the viewer.
There will be a policy change update published soon which will further cover these changes and the operation of Scripted Agents.
Further changes have been suggested within the Lab – notably to traffic – but it has yet to be decided on whether / when these will be implemented.
Viewer Updates
There have been no official viewer updates to mark the start of the week, leaving the various pipelines as follows:
Release viewer: Maintenance Q(uality) viewer, version 6.6.9.577968 Thursday, February 2.
Maintenance S RC viewer, version 6.6.10.578270, issued February 24.
Performance Floater / Auto FPS RC viewer updated to version 6.6.10.578172, February 21, 2023.
Project viewers:
PBR Materials project viewer, version 7.0.0.578792, March 15 – 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.
LSL XML-RPC
Linden Lab is going to be picking a date for shutting down LSL XML-RPC functionality completely. This has been deprecated for well over a decade, and and LL has long been warning about shutting it down, and the vast majority of traffic has moved to HTTP-In, as recommended as a secure means of communications. Given the low volume of traffic – given as only a few dozen requests per hour, LL would rather put resources towards new developments, rather than supporting an outdated and insecure service. The next step will be a blog post with a date, and maybe some circuit-breaking exercises where we will shut it off temporarily, to make sure all creators have moved their services away from LSL XML-RPC.
In Brief
There was a fair amount of discussion concerning the Puppetry project. However, as this will be subject to a meeting on Thursday, Marcg 23rd, for which I plan to have a summary, I’ll leave updates on this work until then.
BUG-227303 – “collisions makes a script stop running and revert its mono status” – this bug is still awaiting work by LL.
Please refer to the video below for general discussions.
Inara Pey: Living in a Modemworld 