Kokua 4.0.1.37934

kokua-logoNicky Perian announced the release of Kokua 4.0.1.37934 on Tuesday, March 1st 2016.

The update sees Kokua gain parity with the latest release version of the viewer from Linden Lab (version 4.0.1.310054 (Maintenance release) at the time of writing), and also with the February 26th release of RLV version 2.9.16 from Marine Kelley.

Not that if you are currently still using a test version of the viewer, the automatic update feature will not function. A separate download and install is required.

CEF Updates

This release incorporates the Chromium Embedded Framework (CEF) updates for media from the Lab, as well as the assorted crash and bug fixes from the Maintenance release. Also included for CEF are a series of contributed updates for Linux, coming by way of Drakeo and including work by Nicky Dasmijn of Firestorm and Henri Beauchamp of CoolVL. Commenting on this, Nicky points out:

Drakeo’s development focus is media and providing Slackware viewer packages. Upstream CEF frequently issues security updates and Drakeo puts those into his own Slackware packaged viewers and contributes updates to Kokua. These security updates from CEF come more often than the Kokua release cycle, however, our Test viewers can be used to maintain a level of currency. Please remember that Linux viewers are Alpha and that is even more the case now that we no longer have the benefit of Linden Lab’s Quality Assurance run through of new features added to Linux viewers. We do our best to provide stable Linux viewers, but with the vast number of Linux distributions problems will occur that may not have timely solutions.

Inventory Updates

Transferable Items Filter

Kokua 4.0.1 includes a new Transferable Items Only inventory search filter. When active, this will limit the main inventory display to transfer enabled items only.

To prevent possible confusion / worry about inventory loss, the option does not persist between log-in sessions when enabled.

The new Transferable Items Only filter for inventory searches
The new Transferable Items Only filter will display only those items which are transfer enabled in your inventory

OpenSim Exportable Parameter

Kokua 4.0.1 adds an Exportable parameter to the Item Profile floater for OpenSim grids, allowing content creators to easily mark items they build as being exportable to other grids. The option is not displayed by the floater when logged-in to Second Life.

The OpenSim only Exportable parameter
The OpenSim only Exportable parameter

Do Not Let Me Fly

A new option added to Preferences  > Kokua and to the Commands menu is Do Not Let Me Fly. As the name suggests, when checked, it prevents your avatar from flying even where flying is enabled.  The option is specifically intended for use in combat zones where flying within the region may still be enabled, to prevent any risk of accidentally flying (such as when jumping an obstacle) and interrupting the combat flow.

The Do Not Fly option will prevent you avatar for accidentally flying whilst still allowing Page Up to be used for jumping
The Do Not Let Me Fly option will prevent you avatar for accidentally flying whilst still allowing Page Up to be used for jumping

Under the Hood

In addition to the above, the release includes numerous under the hood improvements and updates, all of which are listed in the downloadable change log for those interested.

Related Links

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

SL project updates 16 9/1: server deployments; SL viewer, misc news

Casabalanca: Rick's Café Américain - "Of all the gin joints, in all the towns, in all the world, she walks into mine."
Casablanca: Rick’s Café Américain – “Of all the gin joints, in all the towns, in all the world, she walks into mine.” – blog post

Server Deployments

The Main (SLS) channel was updated on Tuesday, March 1st, with the server maintenance package deployed to the three RC channel is week #8. This comprises a server crash fix and “minor internal improvements.”

The server deployment thread lists any RC deployments for the week as “TBD”. however, speaking at the Simulator User Group meeting on Tuesday, March 1st, Simon Linden indicated it is unlikely there will be any RC deployment until week #10 (week commencing Monday, March 7th 2016). These will apparently have an update that addresses a means by which a simulator can be intentionally crashed.

SL Viewer

Currently, the official viewer from LL remain unchanged from the end of last week:

  • Current Release version: 4.0.1.310054, January 15 – formerly the Maintenance RC viewer download page, release notes
  • Release candidate viewers:
    • Maintenance RC viewer version 4.0.2.311655, dated February 26th
    • HTTP updates and Vivox RC viewer version 4.0.2.311302, dated February 22nd
    • Quick Graphics RC viewer version 4.0.2.311103, dated February 17th
  • Project viewers:
    • Project Bento (avatar skeleton extensions) version 5.0.0.310099, dated January 20th
    • Oculus Rift project viewer version 3.7.18.295296, dated October 13th, 2015
  • Obsolete platform viewer version 3.7.28.300847 dated May 8th, 2015.

OpenSSL Update

As noted in my last TPVD meeting notes, the Lab were awaiting an update to OpenSSL. This has now been released and there is minimal impact for SL. This therefore should require any fast-tracked update to the viewer.

Grid-wide Experiences

The simulator user group meeting saw a general discussion about allowing broader access to the Experience Keys database (the KVP) without land owners necessarily having to grant permission to specific Experiences.

The idea here is that there are applications which rely on persistent data or utilise grid-wide data exchange (e.g. a teleport network, a vending system network, etc.), and applications which require script settings survive the script reset. Currently, the way to achieve this is to use external data stores (see BUG-11499 for one example).

Some feel that if there were a way to dissociate the KVP database from things like avatar influences, then it could be used for such applications, removing the need for external data stores and the rick of those data stores vanishing / not being available. However, this is not something the Lab is particularly keen on, for a number of reasons. For example, it could result in their servers storing a lot of data and carrying a lot of database quires and updates, something that might not scale terribly well with volumes and associated storage space cost. Nor would it necessarily safeguard the data any better (if the Experience owner downgrades to Basic or ceases paying their Premium subscription, the data will be lost).

During the discussion Oz indicated that the Lab has no plans to make grid wide experiences available any time soon, due to concerns about how “certain internal features” would scale.

2016 viewer release summaries: week 8

Updates for the week ending Sunday, February 28th

This summary is published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.

Official LL Viewers

  • Current Release version: 4.0.1.310054, January 15 – no change download page, release notes
  • Release channel cohorts (See my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Maintenance RC viewer version updated to 4.0.2.311655 on February 26 – 38 updates, fixes and tweaks for memory leaks (download and release notes)
    • HTTP updates and Vivox RC viewer updated to version 4.0.2.311302 on February 22 – combines the Project Azumarill RC and Vivox Voice RC updates into a single viewer  (download and release notes)
  • Project viewers:
    • No updates.

LL Viewer Resources

Third-party Viewers

V4-style

V1-style

  • Cool VL Viewer updated as follows: Stable version to 1.26.16.14 and Experimental branch to 1.26.17.12, both on February 27th (release notes).

Mobile / Other Clients

  • Group Tools updated to version 2.2.37 on February 28 – no release notes

Additional TPV Resources

Related Links

SL project updates 16 8/2: TPVD meeting

Imesha; Inara Pey, February 2016, on Flickr Imesha – Blog post

The following notes are primarily taken from the  TPV Developer (TPVD) meeting held on Friday, February 26th, 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.

Server Deployments – Recap

There was no scheduled Main (SLS) deployment on Tuesday, February 23rd. On Wednesday, February 24th, all three RC channels received the same new server maintenance package, comprising a server crash fix and “minor internal improvements.”

RC and Project Viewers

RC Viewers

[00:58] The Current Maintenance RC viewer was updated to version 4.0.2.311655 on Friday, February 26th. This should have a fix in it for a significant crash problem it has been experiencing. Otherwise all the current RC and project viewers remain as per part #1 of this week’s updates, with no view promotion to de facto release status as bugs in the three RC viewers continue to be worked on.

[00:49] It is now believed that the major issues with the HTTP / Vivox viewer have now been resolved, with the version released on Monday 22nd February (4.0.2.311302) performing “pretty well” within its cohort. [23:45] It is hoped that Rider is in the process of clearing the last significant bug which is stopping this viewer from progressing forward.

[01:20] The Quick Graphics viewer (version 4.0.2.311103, dated February 17th at the time of writing) is continuing to gather fixes for assorted issues. Oz is reasonably certain the anticipated update for this viewer will be released as an RC in week #9 (week commencing Monday, February 29th), which could mark its last RC update, making it eligible for promotion to the de facto viewer.

[26:43] At the current rate of progress it is likely these three RC viewer could all be vying for promotion to release status at around the same time.

Project Viewers

[01:49] As per my last Project Bento report, work is being put into the final version of the Bento skeleton. Once this work has been completed, there should be a further viewer update. This could likely be the last iteration of this viewer as a project viewer prior to it progressing to release candidate status at some point in the future.

[02:04] The Oculus Rift viewer update is also still in progress, with what is regarded as the last major bug now having been fixed, so an update will now be appearing “soon”.

OpenSSL

[02:46] There is a new version of OpenSSL  coming out. Depending on the vulnerabilities it fixes, it is possible this will be folded into the current release viewer to get this out of the door, but no firm decision on this will be taken until the update is available.

64-Bit Project

[03:30] Work is progressing on the 64-bit viewer build for Windows and Mac, with the Windows tool chain and infrastructure being rebuilt to support both 32-bit and 64-bit builds (once live, the Mac viewer is likely to be 64-bit only).

Viewer Stats

[04:48] The Lab gathers statistics on viewer log-ins and crash rates (and has long done so). The former allows them to gather data on the numbers of users logging-in by operating system, by operating system flavour (32-bit of 64-bit) and by viewer build (using the viewer channel number).

Changes to how the stats are gathered, coupled with other factors means that they have not been disseminated to TPVs was once the case. However, this now seems likely to resume from March, with TPVs being furnished with their own stats and those for the Lab’s viewers.

Firestorm see this as useful as it allows them to directly compare their most recent releases crash rates not only with previous releases of their viewer, but also with the crash rates of the versions of the Lab’s viewer using  the same core code base, thus potentially helping to identify potential underlying causes of any elevated crash rates they may be experiencing.

This discussion on stats segued into a general discussion on viewer channels, viewer spoofing (an illegal viewer trying to appear as a legal viewer), blocking viewers by channel number, etc., which can be heard within the video.

Future Viewer Projects

Visual Outfits Browser  Viewer

[24:00] The Visual Outfits viewer is not publicly visible, but is designed to provide a means by which users can store and browse images associated with their outfits in inventory. There is currently no time frame for when this viewer will reach a public status (project or RC).

Inventory Code Improvements

[27:14] In September 2015 I blogged about the inventory improvements projects being undertaken by Aura Linden. This is a two-step project:

  • The removal of redundant inventory messaging paths from within the viewer because they have been replaced by more robust mechanisms or they no longer have any server-side support and so are redundant
  • A complete rationalisation of the inventory code within the viewer to  more closely couple functions with their actual purpose, followed by a refactoring of the code to make it easier to maintain going forward.

It had originally been indicated that the first part of this work might appear within a project viewer before the end of 2015. However, as it is utilising HTTP, it has been delayed pending the release of the HTTP updates viewer.

It is now anticipated that once the HTTP updates reach release status, the initial phase of the inventory work will be released and allowed to progress through to a release status and gain adoption by TPVs. Once this has been done, the Lab will start removing legacy APIs from the simulator code.  One consequence of this will be that very old viewer versions which do not support the Advanced Inventory System (AIS v3) code updates (which have been available in most recent viewer releases for some time),  will no longer be unable to log-in to SL as a request of inventory load failures.

Continue reading “SL project updates 16 8/2: TPVD meeting”

Project Bento User Group update 6 with audio

Project Bento extends the avatar skeleton, adding a significant set of bones (e.g. 30 for the face, 30 for the hands 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, February 25th 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 the audio excepts are not necessarily chronological, one to the next. Items such as wing bones were discussed at a couple of different points in the meeting, but the comments have been drawn together in an attempt to present a complete discussion of the subject; however, the subjects within each audio extract are provided in the order the discussion proceeded (i.e. the initial part of the discussion on wings is presented first, and the that later additional discussion presented at the end of the audio).

This was a short meeting, with the primary topic of conversation being finalising the Bento  skeleton in terms of additional bones and bone sets, following the recent survey (see my week 4 update).

Additional Tail / Limb Bone Sets

Vir indicated that he, Cathy Foil and Matrice Leville have been discussing a couple of ideas. The first is to cull some of the additional wing bones to produce a second set of “tail” bones, which could then be used for a variety of purposes, including creating additional limbs, or a new limb and additional animation options on the existing tail, etc. This approach would see each of the tails have 5 bones, compared to the current tail having six bones.

The second idea revolves around creating a pair of new limb bones using bones taken from the wings, and which would share the same mPelvis anchor point within the skeleton along with the existing tail (which would retain its existing 6 bones). This would simplify the creation of hind legs on avatars, allowing the tail to be moved”backwards” with them. At the same time, it would mean the additional limb bones could also be used for other purposes, if required.

This sparked a discussion on what might be the optimal approach to additional bone sets, naming conventions and whether any additional bones were in fact required, given there is now the ability to translate bone positions as well as rotate them. Vir agreed that naming does need to be considered, as that using terms like “tail” should mean the bones are limited to that particular use.

Concern was also raised on whether adding additional bone might add to the Bento time frame and if there might be other impacts. With regards to the latter, Vir indicated his hope is to run a stress test once the skeleton is finalised.

Other suggestions have been to simple add further bones to existing sets – such as with the hands, as suggested by Gaia Clary in the forums, although this has seen been seen as perhaps not as required as originally thought. Vir also reiterated that any additional limb bones could be used for arms as well as legs,

Medhue Simoni demonstrates an alternative use for "wing" bone sets, which he uses to animate his elephant's ears
Medhue Simoni demonstrates an alternative use for “wing” bone sets, which he uses to animate his elephant’s ears

There has also been some discussion on the forum concerns limitations within the wing bone sets, which could be solved through the addition of wing “fingers” which would allow better animation of bat / dragon wings, with an explanation on how provided by Teager, who also explains the differences involved in animating such wings and those of birds.

Overall Status for Skeleton

In terms of any consensus for additional bones, it is Vir’s view that there is slightly more interest in having additional limb bones rather than a “two tails” approach, together with additional bones for wings (which could also be used for things like ears, etc.).

Vir will be taking this into account when defining the final skeleton, which he hopes to have available for people to review and test by the next meeting. However, he did warn that the overheads in getting the work completed, tested and signed-off might impact on this target, but it is one he’ll push for.

Issues Update

Additional Spine Joints

Vir is investigating problems with adding extra spine joints in the avatar, and has come across two issues. The first is that doing so can cause the current version of the Bento viewer to crash, although he believes he has a fix for this problem. The second, and more serious issue, is that additional spine joints, whilst working for mesh avatars, it will break the rendering of the default avatar. This appears to be a complex issue, and Vir isn’t confident it is one which might be fixed in time for the initial Bento deployment.

Avatar Deformations

A rather squished Dan Linden
A rather squished Dan Linden

Dan Linden continues to try to hunt down the cause of avatar deformations (BUG-11157). It has been noted that this is a complex problem, involving multiple factors – something which makes it hard to reproduce in a consistent manner. Following investigations, as I’ve previously noted, one causes appears to be scripted deformers which can have an adverse impact on avatars, in that they can continue to run when changing from one avatar to the next, causing the newly worn avatar to deform when seen by others.

However, the issue seems to be slightly broader than this, in that it appears a deformer used by one avatar can appear to impact another avatar when seen by others, whether or not that avatar is using the Bento skeleton.

An example of this occurred during the meeting, when Dan Linden, who was using the default avatar skeleton, arrived just as someone else was swapping avatars using deformation scripts. The result was that for myself and another attendee at the meeting, Dan’s avatar appeared deformed when viewed using the Bento viewer, while others who arrived a little later saw him normally. However, even the circumstances under which this situation occurred seemed to vary when put to a short test following the meeting, highlighting the fact that determining precise causes remains difficult.

Useful Links