There was no scheduled deployment to the Main (SLS) channel this week. All three RC channels received the same server maintenance package, comprising a fix for (non-public) BUG-11163llHTTPRequest returns 400 from some sims and not others, and some minor improvements. Assuming nothing goes sideways with this update, it should be promoted to the Main channel in week #15 (commencing Monday, April 11th).
It is currently not clear if there will be a further update to the TC channel in week #15; this will apparently be determined on work being carried out over the next few days.
SL Viewer
Current Release Version – HTTP / Vivox Updates
The HTTP / Vivox RC viewer was promoted to the de facto release viewer at the end of week #13. Version 4.0.3.312816 (dated March 23rd) presents a complete replacement of the under the hood HTTP infrastructure, replacing the self deleting responders with coroutine implementations for improved performance and stability, and to provide finer grained concurrency allowing the Viewer greater control over the numbers and types of HTTP requests that can be simultaneously outstanding.
The HTTP changes affect all areas of the viewer that use Sim Capabilities. These include, but are not limited to:
Alongside of this work, undertaken by Rider Linden to extend Monty Linden’s previous work on HTTP, this viewer sees the removal of a considerable amount of deprecated and unused code, and a range of Voice fixes and improvements.
Remaining Viewer Channels
The promotion of the HTTP / Vivox viewer leaves the remaining viewer channels as follows:
Release candidate cohorts:
Quick Graphics RC viewer, version 4.0.2.312297, dated March 11th – awaiting update to bring it to parity with the release viewer
Project Viewers:
Oculus Rift project viewer updated to version 3.7.18.295296 on October 13, 2015 – Oculus Rift DK2 support (download and release notes)
Obsolete platform viewer, version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7 – expect this viewer to potentially vanish once TLS 1.2 is implemented.
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.3.312816 (dated March 23) – formerly the HTTP / Vivox RC viewer download page, release notes
The following notes and audio were taken from the weekly Bento User Group meeting, held on Thursday, March 31st 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.
Viewer Status
A new version of the Bento project viewer was released on Tuesday, March 29th. Version 5.0.0.313150 includes the latest updates to the Bento skeleton and the work that has been undertaken to hook-up some of the Bento bones to respond to the appearance sliders in the viewer. The skeleton changes are:
Some renaming and position tweaks for the face joints
New face joints to allow better slider support, including teeth, eye corners
The EyeAlt bones are no longer children of mFaceRoot
4th joint added to the hind limbs.
The slider updates mean that many of the face sliders will now work for suitably rigged mesh heads.
The focus now is very much on finalising the skeleton, and subject to possible show stoppers turning up as more work is done on hooking bones into the appearance sliders, the hope is that the skeleton will not now undergo further significant change. This should allow for in-depth testing of the skeleton without risk of further updates breaking content.
In particular, the Lab is looking to get feedback on any problems encountered with the skeleton, and whether some of the new additional bones are actually useful in achieving what has been hoped in requesting them – such as the additional joints requested for hexapods, etc.
Should it turn out that these joints are not useful, then the Lab needs to know sooner rather than later so that they can be tweaked, if possible. Also, if the joints are seen as not useful at all, than the Lab would also like to know, so that some might be removed to help reduce the overall complexity of the skeleton.
The areas the Lab are keen to see feedback on comprise:
The new “hind” limbs
The four additional spine joints
The additional branch in the wings to allow for wing folding
Testing the face sliders with animations – there is a concern that animations may conflict with slider settings used to reposition the facial bones.
There are also new .dae models which work with the new skeleton available on the Bento test page on the wiki.
Next Steps: Viewer and Sliders
From the Lab’s perspective, the immediate next steps in the projects are:
Have a final skeleton and slider configuration by the end of week #14 (week commencing Monday April 4th (allowing a few more days for the Avastar team to complete work on linking facial bones, etc., to the appearance sliders
Issue an updated project viewer ASAP after next week, which will include the finalised skeleton and sliders, together with available bug fixes (see below)
Once the updated project viewer is out, the Lab will be focused on the remaining bug fixes and collecting feedback based on creators’ experiences in using the new skeleton, testing the sliders with and without animations, etc.
To help people with this, the Lab encourage anyone working on content exercising elements of the new skeleton they are comfortable in sharing to the common pool of work on the wiki (link above)
There are also some additional attachment points to be added to allow for things like the “hind” limbs. However as noted in my week #8 report, there are a number of limiting factors in adding attachment points, one of which is presenting them through the viewer UI, which has certain limitations. Another issue is that there is a hard limit to the total number of attachment points, which makes it difficult to accommodate every which might logically require attachment points associated with it.
Slider Work
It should be made clear that no new appearance sliders are being added to the viewer’s appearance controls for Bento. Rather, as noted in my week #9 update, a slider parameter has been identified which allows some of the existing sliders to work with bone rotations / translations (for Bento) as well as with the morphs used to animate the default avatar skeleton.
There are some sliders in the head which don’t currently seem to work, although this may be due to further work waiting to be carried out in hooking things up. A suggestion has been made to add a new chin joint to make the chin more mobile and allow for versatile jaw shapes, but it’s not clear if further joints will be added at this point in time due to the growing complexity of the skeleton.
Teager shows a WIP set of bird wings designed to utilises the Bento skeleton extensions
In addition to the facial slider support means that things like increasing height should allow wings to increase proportionally. However, documentation on what has been hooked-up to the sliders has yet to be written, mainly because the work is still ongoing, so currently the only way to get the information is via the avatar.lad XML file.
A couple of discussion points on bones and sliders revolve around the wings and “hind” leg bones. On the one hand, there are instances where having these hooked into sliders makes sense – such as having the “hind” leg bones for quadruped avatars, so that if the avatar’s height is increased, the hind legs adjust as well.
However, as things like the “hind” leg bones and the wing bones are designed to be re-tasked, there are potential use cases where this linking could be undesirable, and tends to steer various bones to only be used for certain types of content, rather than leaving things more open for content creators to determine how to just the bones. One potential work-around for things like the “hind” bones would be to provide an additional set of sliders specifically for them; however, due to the amount of work involved in developing and implementing the necessary viewer updates, including the UI changes that would be required, this is currently out-of-scope for Bento.
There are no scheduled deployments or restarts planned for the week. The next deployment should occur in week #14 (week commencing Monday, April 4th, when the release candidate channels should receive a server maintenance package containing some (as yet) unspecified fixes.
SL Viewer
The Project Bento viewer, containing the new avatar skeleton extensions, updated on Tuesday March 29th to version 5.0.0.313150. The remaining viewer channels remain unchanged from the end of week #12:
Current Release version: 4.0.2.312269, dated March 17th – formerly the Maintenance RC viewer
Release candidate cohorts:
HTTP updates and Vivox RC viewer, version 4.0.3.312816, dated March 23rd – probably the next viewer in line to be promoted to the de facto release status
Quick Graphics RC viewer, version 4.0.2.312297, dated March 11th – possibly to go through a further update (tests were being carried out with the Avatar Complexity settings in week #12)
Project viewers:
Oculus Rift project viewer updated to version 3.7.18.295296 on October 13, 2015 – Oculus Rift DK2 support (download and release notes)
Obsolete platform viewer, version 3.7.28.300847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Aditi Inventory Problems
As noted in part #2 of my last project update, there are issues with the new Aditi inventory syncing mechanism.
One issue is that items created on Aditi following one inventory syncing process will disappear from inventory when logging into Aditi following the next inventory syncing run (see BUG-11651).
This is likely the result of the viewer using the same cache, regardless of the grid you log-in to. The current fix is therefore to clear the viewer cache completely or to delete the inventory .gz files from your cache folder), and then log back into Aditi.
However, this approach in turn causes an issue of its own.
When logging back into Agni (the main grid) after clearing cache as described above, the Aditi assets will appear to be listed in your Agni inventory. However, any attempt to rez or wear or share the assets from Aditi will result in an error message, because the assets themselves are not physically part of your Agni inventory. Again, the solution is to clear cache / remove the inventory .gz files from your viewer cache and re-log into Agni.
Also noted in the JIRA is this issue results in some very odd duplication of Calling Cards on Aditi.
The Solution
The desired fix is to have different inventory caches for each grid visited, and as noted in the JIRA report, this is how the Lab intends to proceed.
Invisiprims
As noted in the part #3 of my last project update, there is a new issue with invisiprims, which sees any object, worn or in-world, using the texture UUIDs associated with them rendered at a solid grey or black surface or object, regardless of whether ALM is enabled in the viewer or not. Prior to this issue occurring, the result of a change made in the current release viewer (version 4.0.2.312269), invisiprims would either mask whatever was behind them with ALM off, or simply be ignored if the viewer was running with ALM enabled.
The new invisiprim issue is that regardless of whether a viewer is running with ALM disabled (l) or enabled (r), worn or in-world objects using them now appear either solid grey or black (click image for full size, if required)
As having grey surfaces and objects appearing on avatars in in-world (remembering that there is a lot of old, No Mod content in-world which makes extensive use of invisiprims and their associated textures, and this approach makes them look very unsightly to anyone viewing them), the suggestion has been put forward that the viewer should be modified to simply ignore the invisiprim texture UUIDs or treat them simply as “normal” transparent textures regardless of whether or not ALM is enabled in the viewer, and a fix has been submitted to the Lab to achieve this.
Asked during the Simulator User Group meeting on Tuesday, March 29th, if the Lab had reached a decision on adopting the fix, Simon Linden said, “We were talking about it earlier … nobody wants to do anything to break content; so we have the hole-in-the-water use, which is nice for boats and such.”
Oz Linden then added, “We’re going to do some testing of alternatives… so I guess the answer is that we don’t have a final decision yet.”
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.
HTTP updates and Vivox RC viewer updated to version 4.0.3.312816 on March 23rd – combines the Project Azumarill RC and Vivox Voice RC updates into a single viewer (download and release notes)
Invisiprims: with ALM disabled (left) and ALM enabled (right); and as they appear now in the official viewer, with or without ALM enabled (click for full size, if required)
As noted in my week #11 update, the current release of the LL viewer now effectively “breaks” the remaining invisiprim capability in the viewer, with any object or surface using them rendered as either solid grey or black, something which is seen as less than optimal with regards to long-standing in-world content, prompting some debate as who should be done with invisiprims going forward.
To understand what has been discussed, and what is likely to be done, it is necessary to dip back into some history.
Background
One upon a time, Invisiprims were the means of achieving an alpha mask effect. For example, their use in footwear meant that an avatar’s feet could be masked to prevent them showing through shoes and boots. They could also be used in-world as well, a typical example being their use to mask Linden Water from being seen inside boat hulls or things like dry docks – one of the most famous examples being the dry dock at Nautilus (shown below).
As it used to be: the Nautilus dry dock uses an invisiprim to mask the Linden Water. For the last several years, this has only worked when the Advanced Lighting Model (ALM) in the viewer is disabled
Invisiprims were able to do this by making use of two unique texture UUIDs within the viewer which, when called, would act as alpha masks. However, this always came as a cost to rendering, and could lead to unpredictable results (e.g. glitches with rendering, odd interactions between the invisiprim textures and other textures, etc.). Because these issues became particularly problematic when using some of the advanced rendering capabilities (what is now called the Advanced Lighting Model or ALM) in the viewer, a decision was taken a number of years ago to have ALM ignore the alpha masking effect of the invisiprim texture UUIDs.
Thus, anyone running the viewer with ALM enabled for the last several years has not seen the masking effects of invisiprims; avatar body parts show through wearable items which use them, for example (hence the adoption of more efficient alpha layers by clothing and accessory designers). Nor do in-world invisiprims act a masks for things like Linden Water when viewed with ALM active (as illustrated below), although they would still alpha mask if ALM was disabled in the viewer.
Following the changes made a few years ago to the Advanced Lighting Model, the “magic” invisiprim texture UUIDs are ignored during rendering, with the result that they no longer mask things like Linden Water when seen in a viewer with ALM enabled
While this latter point – the lack of ability to hide things like Linden Water from view – may have appeared less than perfect at the time the changes were made, it has over the ensuing years become accepted behaviour when seen in-world. So what has now changed to once again make invisiprims a subject of discussion?
The New Problem and Its Proposed Solution
In short, a recent change to the viewer rendering system, (found in the current release viewer, 4.0.2.312269) means that anything using the invisiprim texture UUIDs is now seen as a sold grey or black surface / object regardless as to whether ALM is enabled in the viewer or not. This has led a lot of long-standing, No Mod in-world content looking distinctly odd and unsightly (shown below, again using the Nautilus dry dock).
A change to the 4.0.2.312269 release viewer means that invisprims now render as solid grey or black surfaces / objects whether or not ALM is enabled in the viewer. With in-world content, this has led to some unsightly results, such as the Nautilus dry dock looking like it has been filled with cement (click image for full size, if required)
BUG-11562 was raised highlighting this latter impact to in-world content, with a request that the change be updated so that any surface using the “magic” invisiprim UUIDs is simply rendered as “invisible” (i.e. transparent, as is the case when running with ALM enabled). There has also been some debate among TPV developers about how to adopt the Lab’s code change, as well as the matter being discussed at both the Open-Source Developer meeting and the TPVD meeting held on March 25th, 2016 (audio extract below).
The latter discussions have resulted in both the Lab and TPV developers agreeing that the best solution would be to follow the BUG-11562 suggestion, and have surfaces and objects using the invisiprim UUIDs render and transparent objects whether or not ALM is enabled in the viewer.
A change to support this has already be submitted to the Lab to achieve this. Subject to further testing, it, or a solution similar to it, is likely to be integrated into a future viewer update.
Noire’leans – blog post
![[G]aio; Inara Pey, March 2016, on Flickr](https://farm2.staticflickr.com/1581/25472227673_4c0f1a4312_o.jpg)
Inara Pey: Living in a Modemworld 