SL project updates 16 11/2: server / viewer / Aditi

The Mill; Inara Pey, March 2016, on FlickrThe Mill – blog post

Server Deployments Week 11 – Recap

There was no planned Main (SLS) channel deployment / restart for the week. On Wednesday, March 16th, the three RC channels were updated with an improved server maintenance project comprising script fixes and internal improvements. The lack of recent deployments remains down to ongoing infrastructure updates occurring across the Lab’s simulator servers.

SL Viewer

On Thursday, March 17th, the Maintenance RC viewer, version 4.0.2.312269, was updated to the de facto release viewer. This viewer does have an issue with invisiprims, which the viewer renders as solid  objects with invalid textures, rather than leaving them transparent, as intended, whether or not ALM is enabled (ALM having previously “broken” invisiprims) – see BUG-11562.

On Friday, March 18th, the HTTP / Vivox viewer was updated to version 4.0.3.312684, which I assume is a rebuild based on the new release viewer, potentially marking this viewer as the next-in-line for promotion (subject to updates with the Quick Graphics RC).

Aditi Inventory Syncing

The new process for syncing users’ Aditi inventory with their Agni inventory has not gone live as anticipated. however, all things being equal, it will be deployed in week #12. This means that, going forward, a user’s Aditi inventory will no longer be overwritten when they change their password and log-in to Aditi, nor will a password change be required to trigger an Aditi inventory sync.

Instead, anyone logging-in to Aditi will automatically have their inventory copied from Agni to Aditi a part of a new process (run at about 06:00 SLT each day). This will happen each time a persona logs in to Aditi, unless their inventory is already flagged for copying, and instead of overwriting a person’s existing Aditi inventory, the incoming Agni inventory will be merged with their existing Aditi inventory, with checks to avoid unnecessary duplication of items each time this occurs and to ensure thing like Trash contents and COF aren’t copied as well.

Other Items

Created Agents for SL?

Lucia Nightfire filed an interesting feature request, proposing the use of created agents in SL. A created agent is essentially the same as regular avatar or bot, but without an internet connection to the server. Created agents have an object-style inventory, and can attach things in a similar manner to regular avatars. Such an approach could allow the development of pets, breedables, ridables, NPC’s, monsters, game enemies, all without the associated cost and complexity of using other means of achieving the same result. See BUG-11368 for more.

What’s now interesting is that the request has been accepted by the Lab. This doesn’t mean it definitely will happen, but it means they are at least interested in considering the potential of the idea.

SL project updates 16 11/1: server / viewer

Suomi - Finland; Inara Pey, March 2016, on FlickrSuomi – Finlandblog post

Server Deployments

There is no planned Main (SLS) channel deployment / restart planned for the week. On Wednesday, March 16th, the three RC channels should be updated with an improved server maintenance project comprising script fixes and internal improvements.

The lack of recent deployments remains down to ongoing infrastructure updates occurring across the Lab’s simulator servers.

SL Viewer

It is anticipated that an RC viewer – mostly likely either the current Maintenance RC or the HTTP / Vivox RC will be promoted to the de facto viewer this week. However, at the time of writing, the list of official viewers still stood at:

  • Current Release version: 4.0.1.310054, dated January 15th – formerly the Maintenance RC viewer
  • Release channel cohorts:
    • Quick Graphics RC viewer, version 4.0.2.312297, dated March 11th
    • Maintenance RC viewer, version 4.0.2.312269, dated March 10th
    • HTTP updates and Vivox RC viewer, version 4.0.2.312094, dated March 9th
  • Project viewers:
  • Obsolete platforms viewer, version 3.7.28.300847, dated May 8, 2015

 

Project Bento User Group update 8 with audio

Project Bento – extending the SL avatar skeleton
Project Bento – extending the SL avatar skeleton

The following notes and audio were taken from the weekly Bento User Group meeting, held on Thursday, March 3rd at 13:00 SLT on Aditi. For details on each meeting and the location, please refer to the Bento User Group wiki page.

Note that this update is not intended to offer a full transcript of the meeting, nor does it present the discussion points in chronological order. rather, it represents the core points of discussion to Project Bento, grouped together by subject matter were relevant / possible, together with any additional discussion on potential future projects the Lab might be willing to examine for possible adoption in the future.

Skeleton and Viewer Status

Bento viewer work is now focused on finalising the new skeleton, working on bug fixes and investigating hooking the new skeleton into the appearance sliders where is can be done.

It’s anticipated that there will not be any further significant changes to the bones within the skeleton, although there has been some discussion on adding a couple of extra bones into the “hind” limbs. Content creators are therefore being encouraged to develop new test models utilising the skeleton, as available in the current project viewer (version 5.0.0.311861 at the time of writing).

A couple of issues have come to light with the additional bones. In the first, the alternate eye bones weren’t quite lined up with the original eyes, and this is being fixed. There  also appears to be some issues arising from the inclusion of additional spine bones, which is discussed below.

Appearance Sliders

The Lab has been investigating the potential of modifying the appearance sliders (controlled through the avatar.LAD file). This means taking some of the sliders that are based on morphs which deform the default avatar, and allowing them to also be utilised by the Bento skeleton when an avatar mesh employing the skeleton is worn. This work looks “promising”, although the number of sliders means that it is unlikely all of them will be dual-purposed in this way. However, as a part of this work, the Lab will be addressing the slider bugs which have been reported against the latest Bento skeleton as well.

Vir discusses the current status with the Bento skeleton and project viewer

Attachment Points

Some additional attachment points were added specifically for use with the new skeleton, and consideration is being given to adding some more (such as to the new “hind” limbs – which can be used for a variety of purposes other than “just” hind legs, as noted in my last update).  Currently, no clear preference for extra attachment points has been expressed by content creators working on Bento. One group of suggested attach points put forward in the meeting was for rear left leg and rear right leg (upper and lower). rear hip, rear groin, rear left foot, rear right foot, and rear back (for rideable centaurs/saddles).

Responding to this Vir indicated some of these may already be possible, and that others such as those for the hind legs / back are hard to determine as the joints are repositionable,. The suggestion for catering to some of these bones might be to reposition existing attachment point to suit, or the possible inclusion of a new hip root attachment point for the “hind” bones root.

The question was also raised on whether attachment points are lag producing in the same way joints can be. Vir indicated that lag isn’t really an issue with attachment points on their own (although animating them can obviously add an overhead). However, there are other issues with regards to UI / menu management which can make additional attachment points a problem.

For example, there is only a single menu structure available for selecting an attachment point for an item directly from inventory. So the more attachment points added, the more unwieldy the menu gets. The same issue isn’t so apparent when attachment an object from in-world, where the code allows for sub-menus to be added.

The Bento attachment points have added to an already large inventory attachment menu, although the in-world attachment menu has been broken down for easier locating on attach points (click for full size)
The inventory attachment point menu (left) is currently monolithic in nature, making it unwieldy when adding further attachment points, such as for Bento. Things are easier on the in-world attachment menu allows for easier addition of attachment points through sub-menus (right) – click for full size, if required

Another limiting aspect with attachment points is that there is a hard limit on the total number of joints which can be used (thought to be 255). so if an attachment point was added to every bone, this would likely be exceeded, so things like an attachment point for every finger would probably be out of the question.

Issue Updates

Work is continuing on issues of avatar deformation, but as yet there have been no major breakthroughs.

However, problems appea rto have arisen as a result of the new spine bones. In particular, quadruped avatars appear to “dip” their forelegs and shoulders forward when shifting between certain animations. The precise cause is unclear (this may not even be a new issue, just one that is exacerbated by the new bones), but it could be the result of an interpolation issues, an i-k (inverse kinematics issue) or even some issue relating to bipedal animations (a human avatar tends to lean into something like a walk, and this default movement might be affecting thing). However, the larger the quadruped avatar, the more pronounced the up-and-down motion of the forelegs seems to be.

wolf-2_001
The “scrunching” issue, possibly the result of a missing transform, but apparently related to the inclusion of the new spine bones

This problem is further compounded by a problem whereby if the avatar mesh is animated while ignoring the spine bones, then the avatar can end up being distorted following something like a relog; the spine bones must be keyframed in order for the avatar mesh to remain correctly formed.

One possible explanation for this latter issue is that there might be a missing transform in the hierarchy data, such that the weights associated with a joint are skipped, together with any child joints, causing the model to collapse.

As it is, the model in question, animations, etc., are being passed to the Lab so that they can investigate and test things.

Other issues have also been seen with the additional spine bones, which might be down to order of use or correct alignment, as the method by which they have been implemented, in order to preserve backwards compatibility with the avatar skeleton, is complicated.

Continue reading “Project Bento User Group update 8 with audio”

SL project updates 16 10/2: TPVD meeting

Heritage: Wrecks
Heritage: Wrecksblog post

The following notes are primarily taken from the  TPV Developer (TPVD) meeting held on Friday, March 11th, 2016. A video of the meeting is embedded at the end of this report, my thanks as always to North for supplying it, and time stamps in the text relate to this recording.

RC Viewers

[00:00] All three RC viewers currently in the release channel have been updated as follows:

  • The HTTP / Vivox RC updated on Wednesday, March 9th to version 4.0.2.312094
  • The Maintenance RC viewer updated on Thursday, March 10th to version 4.0.2.312269
  • The quick Graphics RC viewer updated on Friday, March 11th to version 4.0.2.312297

All three of these viewers are now showing lower crash rates than the current release viewer, so one is mostly to be promoted at the new de facto release viewer early in week #11 (week commencing Monday, March 14th). [00:50] However, this is unlikely to be the Quick Graphics RC viewer, as there is at least one remaining bug which is in line for fixing prior to the viewer being promoted.

Project Viewers

[01:40] Work is progressing on updating the Oculus Rift project viewer, but problems have been encountered with the latest Oculus SDKs which are proving to be non-trivial to correct. The Lab hasn’t given up, but it does mean any update to this viewer is liable to be a little later rather than sooner.

[02:30] Working is also continuing with the final definition of the Bento skeleton, as well as investigations into hooking the skeleton into some of the shape sliders. This work is liable to see a further release of the viewer with the further skeleton updates before it hopefully moves fully into a bug fixes phase (which could be extensive).

64-bit Viewer Update

[13:21] The lab is making good progress on the Windows and Mac 64-bit versions of their viewer. This has been thanks in part to the work completed in updating the viewer build tool chain during 2014/5. As a result, it is possible that 64-bit project viewers might be appearing in the next few weeks, allowing for an update to the Havok libraries.

TLS Update

[02:58] Beehu Linden requested all TPVs ensure they are able to support TLS 1.2. The Lab is now actively engaged in removing support for all earlier version of TLS (which includes all versions of SSL).

As previously noted, this work is being carried out in respect of compliance requirements. It means that once complete, anyone who is using a viewer that does not have the requisite TLS 1.2 code updates (already in the 4.0+ versions of the official viewer and all viewers utilising the code base from the Lab’s 4.0 viewers) will not be able to do any interactions with cashier or anything that involves money and Second Life.

The next release of Firestorm, tentatively scheduled for around the mid-week of week #11 will have TLS 1.2 support.

Other News

New Registration API

[06:10] As I’ve recently reported, and Ebbe Linden indicated in his VWBPE address, there has been a delay in the roll-out of the new trial community Gateway programme due to issues with the new user registration API (one of them being a user signing-up through it cannot pick their avatar, they are given either the default male or female Character Test avatar).

These issues are being addressed, and an updated registration API is due to be released later in March or early in April. However, this version will not have the new feature set indicated by Ebbe in the VWBPE address, but will work “better” than the current API.

The new features as indicated by Ebbe are still expected to be released, but will come after this initial update, and currently do not have a firm ETA, although it is not anticipated there will be an extended delay between the initial update and an update with the new feature set.

Grid Status RSS Feed

[07:13] The Lab is updating  the Grid Status page RSS feed. This involves a new feed format, and a test URL has been available (http://beta.status.secondlifegrid.net/feed) has been available for those who may poll the RSS feed for updates (e.g. to display grid status updates on viewer log-in splash screens or on a web page, etc) to be able to test they can receive and display the new feed. This work as part of a switch the Lab is making to a new hosting provider for a number of their web services (e.g. the knowledge base).

There is no confirmed ETA as to when the cut-over will occur; the Lab is waiting on feedback from the hosting provider, but the hope is the switch will be made around mid-April, possibly earlier. When it does happen, there will be no need to change any URLs, because the Lab will point their DNS to the new location.

FMOD Studio

[19:30] The Lab has traditionally utilised FMOD (up until its demise) and more latterly FMOD Ex within the sound system for the viewer. However, as a part of the 64-bi viewer build, they may dip into using the full FMOD studio.

SL project updates 16 10/1: SL viewer, Aditi inventory, PaleoQuest issues

Asphyxiation Point; Inara Pey, February 2016, on Flickr Asphyxiation Pointblog post

Server Deployments

There are no planned deployments / restarts for week #10.

SL  Viewer

The HTTP  / Vivox RC viewer updated to version 4.0.2.311980 on Friday March 4th. This release sees the CURL updated to 7.47.0, together with 10 further fixes and updates over the previous release, included HTTP fixes and fixes with issues within the viewer such as avatar bake fails, viewer crashes, notifications problems, and music stream failures.

The current Maintenance RC viewer updated on Wednesday, March 2nd to version 4.0.2.311770.

As noted in my last Project Bento update, the Bento project viewer updated to version 5.0.0.311861, also on Wednesday, March 2nd, and includes a new version of the Bento skeleton with additional bone sets and other revisions.

Aditi Inventory Syncing

Coyot Linden as he once looked (I need to update my images of him!)
Coyot Linden as he once looked (I need to update my images of him!)

As reported by Coyot Linden at the Simulator User Group meeting on Tuesday, March 8th, the new process for syncing users’ Aditi (Beta grid) inventories with their Agni (main grid) inventories is in the final stages of QA testing, and should be deployed either later this week or early in week #11.

I’ve covered on this subject a number of times since it was first noted as being in the works in December 2015, but in short.

  • Once in place, the new process will not require users to change their SL passwords in order to trigger their Agni inventory being copied over to Aditi. Instead, anyone logging-in to Aditi will automatically have their inventory copied from Agni to Aditi a part of a new process (run at about 06:00 SLT each day)
  • This will happen each time a persona logs in to Aditi, unless their inventory is already flagged for copying.
  • Instead of overwriting a person’s existing Aditi inventory, the incoming Agni inventory will be merged with their existing Aditi inventory – so items unique to a user’s Aditi inventory will no longer be lost as a result of their Agni inventory overwriting the Aditi inventory

In addition:

  • The process will not duplicate items previously copied to Aditi from Agni; however, if an item is renamed or moved to another inventory folder on Agni, it will be copied to Aditi
  • If an item is deleted from inventory on Aditi, but exists in inventory on Agni, it will be copied to Aditi the next time the process runs for that user
  • Inventory and folder links will also be copied from Agni to Aditi
  • Trash and the Current Outfits folder will be excluded from the copy process (the latter to prevent avatars on Aditi ending up wearing multiple outfits).

Other Items

PaleoQuest Banning Issues

PaleoQuest, the Lab’s dino-related quest game which features Experience Keys and which opened in July 2015, has always had some fairly strict rules on what is and isn’t allowed. However, these rules appear to have been recently updated, with the result that a number of users  have found themselves banned (or in receipt of a ban warning) where no infringements have taken place (see here, here, and here for examples).

One major cause of recent bans seems to be that the game is confusing HUDs worn by a user when trying to enter the game (or even in the middle of playing the game), with an attempt to wear a “fraudulent” game HUD, resulting in the wearer gaining an immediate ban, together with the following notice:

YOU ARE WEARING AN OBJECT THAT IS TRYING, WITHOUT SUCCESS, TO PASS ITSELF OFF AS A GENUINE PALEOQUEST HUD. THIS BEHAVIOUR IS ASSOCIATED WITH FRAUDULENT ATTEMPTS TO OBTAIN REWARDS IN THE GAME AND IS NOT TOLERATED. YOU HAVE BEEN BANNED FROM PALEOQUEST.

The problem with the bans has been further exacerbated by some who have raised support tickets having their bans reversed with a note that the system will be adjusted, while others appear to have had their tickets summarily closed.

As a result of this, and other issues encountered with the ban system during what is effectively “normal” game play, a bug report as been raised (BUG-11533). Should you find yourself banned from the game or in receipt of ban warnings whilst engaged in “legal” game play, you might want to add the specifics of your situation to the JIRA, and don’t forget to append information about your viewer / system from Help > About (+ viewer logs, if you have them).

Project Bento User Group update 7 with audio

Project Bento – extending the SL avatar skeleton
Project Bento – extending the SL avatar skeleton

The following notes and audio were taken from the weekly Bento User Group meeting, held on Thursday, March 3rd at 13:00 SLT on Aditi. For details on each meeting and the location, please refer to the Bento User Group wiki page.

Note that this update does not present the discussion in chronological order; items discussed have, wherever possible and without compromising the discussion itself, have been grouped together to try to present a complete discussion of the topics raised in turn.

New Project Viewer and Bento Skeleton

A new version of the Bento project viewer has been released. Version 5.0.0.311861, dated March 2nd, 2016, includes the updated Bento skeleton, which the Lab hopes will be the final version.  In particular this adds further new bones:

  • Four new spine joints: two between mPelvis and mTorso, and two between mTorso and mChest. By default these bones are folded up inside the current spine and will not affect the appearance of the avatar, but like other bones they can be repositioned in uploaded meshes, or animated according to need
  • New face bone root: rather than adding extra neck bones, the Lab have added an extra face bone root, which could be used as an extra neck bone if desired
  • Three new centre face bones along the mid-line of the face, two on the lips and one on the forehead
  • Two new joints for ears, allowing for floppy or otherwise more flexible ears
  • An additional pair of limbs, each with 3 joints apiece, and a new root bone to which they are connected. These are named “Hind” limbs, but using the root bone, the can be relocated to be used elsewhere – such as an extra pair of arms
  • One new bone for each wing to allow a simple fan as would be used in a bat-type wing.
  • Removal of two wing root bones: these were originally included as a workaround for the lack of joint translations. As this is now possible, only a single wing root bone is actually required
  • Various bone position changes.

As some of the existing bones have been removed or changed position, this does mean that content made using the original Bento skeleton will need to be updated in order to display as intended. Aditi servers have been updated with the new skeleton.

Vir discusses the new bones and the removal of some bones

The ability to add new spine bones is a direct result of the Lab being able to fix the two issues referred to in my last Bento update, the first of which would crash the Bento viewer if additional spine joints were added, while the second was that new spine bones would break the rendering of the default avatar.

In order for this to work, the new bones have an odd positioning / ordering within the skeleton, so they seem to “zig-zag” (spine 1 is located in chest, spine 2 in the pelvis, then comes the torso, etc). The reason for this was to allow all the original skeleton joints exactly where they had always been located, and to avoid the creation of any zero length bones, with the internal matrix maths (as well as some other programmes) doesn’t particularly like, as Vir explained which discussing the new spine bones.

Vir expands on the new spine bones and ordering

There may be some issues which are causing Blender to incorrectly display the new spine bone positions and orientation. One suggestion for those encountering similar issues is to visualise the bones by setting them to the polyhedral models where it is wider on one end than the other (I’m unfamiliar with blender, so not sure of the precise term for the visualisation) to make it easier to see the orientation of the bones, although this may not work.

Aki Shichiroji, who has experienced the problems, has indicated she’d talk a little more with the Avastar team about things. Certainly, Vir believes working with them is going to require a delicate touch when working with the spine bones in the likes of Maya and Blender, due to the risk of coincident bones.

Next Steps

The Lab intends to freeze the skeleton soon, and those wishing to test it are advised to do so over the next few days. Currently, the easiest way to obtain the latest version of the skeleton is directly from the new version of the project viewer (link above), although hopefully the wiki links, etc., will be updated soon.

There is liable to be one more update to the project viewer once the skeleton is frozen, after which the Lab will be turning attention to the avatar.LAD file, the other major configuration file for the skeleton, and finalising changes and corrections to the shape sliders and potentially adding some new attachment points which can leverage the revised skeleton.

The biggest issue as far as progress the project to initial deployment on the main grid is concerned, is bug fixing. There are still some significant problems yet to be resolved, which are dependent upon understanding the route cause of the problem and having the staff available to investigate them / resolve them:

  • Issues with the extra joints, such as the default avatar pose issue (see below)
  • The rendering deformations encountered at high altitude
  • The general avatar deformation issue seen within the Bento viewer (see here and here for further notes).

There are also a number of more general bugs to be corrected as well.

Overview of the next steps in the project from the Lab’s perspective

Default Avatar Pose Issue

foreleg crossing: issue may be deeper than thought
foreleg crossing: issue may be deeper than thought

There has been further investigation into the default avatar pose issue which can see quadruped avatars unnaturally crossing or folding their forelegs when shifting between animations (for background see here, here, and here).

It had been thought that the issue was due to the way that scripted animation override systems (e.g. the ZHAO and ZHAO 2) overlay the default server-side avatar poses, occasionally allowing these server-side animation to start playing when shifting between poses as a result of a message timing issue between server and viewer. The suggested solution was therefore thought to be to encourage creators to write AO for their Bento avatars which would utilise the llSetAnimationOverride capability introduced in 2013, which overwrites the server-side defaults with the animations of the creator’s choosing, thus preventing the “wrong” animation starting to be played.

However, more recent testing suggests that the issue can still occur when using llSetAnimationOverride.

A problem here has been that the JIRA specifying the issue and providing information on various tests, etc., carried out to date by the Lab has, not been publicly viewable (for valid reasons), making it hard for other outside the Lab attempting to investigate the problem to understand what has happened to date and report their own findings back to the Lab. Arrangements are now being made to clone the JIRA and make is public to eliminate this problem.

Other Items

Removing Mesh Upload and Display Restrictions

Second Life has always had a number of upload and display restrictions wherein creators were required to include certain joint positions whether or not they were in fact using them (the uploader wouldn’t check to verify whether the positions were actually used, just that they are listed). There were some checks which insisted that if the positions of some of these bones were changed, they all had to be changed.

This obviously limited the number of meshes rigged to bones from different creators that an avatar could wear, because there would inevitably be conflicts between the listed joints in each mesh. The checks themselves date back to when the Lab used a different method for tracking joint positions, and they don’t make a lot of sense today, and so work is in hand to remove them, and should be completed with the next release of the project viewer.

The upshot of this is that once done and available, avatars will be able to wear meshes from different creators, providing the mesh items only list the joints they actually use. This would allow, for example, this will allow someone to wear a centaur avatar from one creator and add a set of wings from another creator without the risk that the meshes would conflict because they list the same “required” joint positions. However, for this to work, it does mean that creators will need to ensure they list only the joints they require in order to offer some degree of “interoperability” between meshes.

Vir discusses the removal of the upload and display restrictions

Using Bones to Animate Hair and Clothes

One benefit from being able to rig and list only the bones which are being used, is that it potentially opens the door to creators being about to use some of the additional bones to animate things like hair and dresses.

For example, as bipedal, humanoid avatars are unlikely to require the tail bones or the “hind” limb bones, these could potentially be used to naturally animate a  mesh gown (particularly one with a long train) or long dresses. Similarly, the additional ear bones might be used to animate mesh hair.

Cathy Foil points-out the potential for clothing and hair makers as a result of the removal of the restrictions

Scripted Methods for Bone Positions

BUG-11407 is a feature request to provide scripted control of bone positions, allowing to an LSL command to pass an array of bone positions to the client to animate oneself, or, with permission granted, to animate another user.

Commenting on this at the meeting, Vir indicated that while such an approach is “interesting”, but due to the scope of things, has been considered to big an undertaking for the Bento project, and would likely have to be considered as a project in its own right. Rider Linden further suggested raising the idea for discussion at the Simulator User Group meeting.

Useful Links