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: 5.0.0.321958, dated December 1, promoted December 5 (no change) – formerly the Project Bento RC viewer download page, release notes.
The notes in this update are taken from the abbreviated TPV Developer meeting held on Friday, January 13th, 2017. The video of that meeting is embedded at the end of this update. My thanks as always to North for recording and providing it.
SL Viewer
The Maintenance RC viewer was updated to version 5.0.1.322791 on Thursday, January 12th. Otherwise the pipeline remains unchanged from part 1 of this week’s update. [34:20] this will likely be the next viewer to be promoted to release status.
64-bit Viewer
[03:07] It is anticipated that the 64-bit official viewer, version 5.1.0.501863 at the time of writing, will remain in the project cycle for some time. An update to it is anticipated in week #3 (week commencing Monday, January 16th, 2017). Currently, the project viewer isn’t being used by many, and the Lab hopes this number will pick up so that a little more feedback can be obtained.
Points of note with the 64-bit viewer and 64-bit plans:
The Mac version is currently without Havok support, an it will likely be 2+ weeks before it does.
There will also be a number Havok libraries build in support 64-bit, which will be made available to TPV sub-licensees, but this is unlikely to happen until the Lab starts building 64-bit release candidates.
KDU within the viewer is being updated to version 7.9.
[08:08] New packaging of the media code and a new version of CEF.
The viewer update code will be completely revised.
The crash reporting code may be updated.
[11:28] Eventually, the Lab plans to have the viewer available in both 32-bit and 64-bit for Windows, and 64-bit only for Mac OSX and Linux.
For more on Linux, see below.
Voice Updates
[07.18] Updates to Voice should be appearing in a viewer in the next 2(ish) weeks. This will include a new SL Voice plug-in from Vivox which includes a new Opus codec, as well and bug and exploit fixes.
360-Snapshot Viewer
[08:33] Work will resume on this project viewer, version 4.1.3.321712 at the time of writing, once work on the CEF updates (noted above) have been completed.
Linux and the Viewer
[10:08] Currently, the Lab have not carried out any work on a 64-bit version of the viewer on Linux. However, thought is being given on how to move forward with Linux, and it is hoped that the Lab will have some ideas to put to the TPV / open-source community by the next TPV Developer meeting. It is also hoped that by that time, the Lab will have started work on a 64-bit Linux version of the viewer.
Other Items
The following are covered in brief. please fer to the video for specifics.
New Camera Presets Coming?
[09:14] Jonathan Yap, who has worked on various code contributions for the viewer including, most recently, graphics presets, is working on a new project, which appears to be updating the viewer’s camera presets.
Music Stream Autoplay
[16:45-28:09] A lengthy discussion takes place on music autoplay within the official viewer, and whether or not it should be enabled by default.
Having it enabled is seen a off-putting to new users, as it means they can be confronted with loud music playing over their system almost from the moment they log-in, with no apparent way to turn it off. This is seen as possibly causing some to log-off in frustration
Having it disabled by default is seen as breaking the shared experience in regions where the creator has specifically included music streaming as a part of the environment
The compromise is potentially for the default volume on media to be reduced.
(Note, this discussion also drags on between 29:45-33:50, after the above agreement being reached.)
Click-to-Walk
[28:45] In a similar vein, a request was made to disable click-to-walk, as it has been observed that new users get confused when they find their avatar apparently moving when they haven’t touched their keyboard. A JIRA on this has been requested.
Group Chat Issues and Group Notice Deliveries
[34:59] Group chat lag become more noticeable over the holiday period. However, the Lab ran a restart of the back-end group chat servers, and this appeared to resolve the majority of issues. If specific groups are still experiencing issues, JIRAs are requested.
[36:49] There are reports that the problem of group notices not always getting through is getting worse. So people don’t get the notice, others get them twice, etc. A JIRA, BUG-40824, has been raised on issues with off-line receipts of group notices as well.
As an aside to this, a fix is in progress t ensure that off-line messages, which may not always get delivered at the next log-in, will be delivered.
Environment Maps, Shiny, Projectors and More
[42:29-end-of-meeting] The end of the meeting centres on a convoluted discussion on the environment map used for the sky, shiny / glossiness, etc. In sort, there is a request for region holders / creators to be able to replace the environment map with a texture of their own choosing. On the plus side, among other things, this could allow things like easier simulation of reflections using projectors. on the negative side, again among other things, it could break a lot of existing content.
Changes to the environment map, providing they can be shown to have specific benefits and do not break existing content, have not been ruled out. However, a specific proposal is really required.
On Friday, January 13th, Alina Lyvette released version 3.3.1 of the Lumiya Android client for Second Life and OpenSim.
The release builds on the 3.3 update, which added Voice capabilities to Lumiya, by providing additional audio controls for Voice together with Bluetooth headset support, which are combined in a single easy-to-use UI addition. As well as this, the release includes a number of bugfixes.
The audio controls can be displayed any time that Voice is enabled and about to be used – see my Lumiya 3.3 review for details on how to enable Voice in Lumiya.
With voice enabled, tap on the telephone handset icon as you would to launch a Voice conversation. When the microphone bar is display on your screen either in local chat or as a result of someone accepting your Voice IM request, tap anywhere on the bar except the microphone icon or the X, and the audio controls will be displayed.
Lumiya Voice audio controls
These comprise three elements:
And overall volume slider
A toggle button to activate your device’s external speaker
A toggle button to direct audio through your Bluetooth headset.
Bluetooth Headsets
Note that for Bluetooth connectivity to work, you will also need to update to the latest Lumiya Voice plug-in app and, obviously,have a Bluetooth headset pair with the device being used to run Lumiya. Once paired and the headset is active, Lumiya will automatically route incoming audio to the headset when you establish a voice call. Should you wish to place the incoming audio on your device’s speaker (and back), use the buttons on the Lumiya audio controls, described above.
Bug Fixes and Minor Improvements
The bug fixes and smaller improvements with this release comprise:
A fix for some texture uploads to fail.
A fix to prevent camera position being reset when exiting 3D view.
Region restart messages and other alerts will now display correctly.
Objects will be automatically rezzed under land group when possible.
Feedback
Adding Bluetooth support is an obvious step now Lumiya supports Voice, and while I was unable to test it myself (the only Bluetooth earpiece I have is a good decade old and has lain in a drawer for most of that time, and so unsurprisingly didn’t work when allowed to see light of day), the process appears simple enough.
A number of people have asked me about Lumiya and Bento. As I noted in my last Lumiya review, Alina is working on it, and probably the fairest time frame to put on it is that it will be released when it is ready 🙂 .
The Content Creation User Group has re-formed out of the Bento User Group, and is held at the Hippotropolis Campfire Circle. Imp costumes entirely optional 😀 .
The following notes are taken from the Content Creation User Group meeting, held on Thursday January 12th, 2017 at 1:00pm SLT at the the Hippotropolis Campfire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are available on the Content Creation User Group wiki page.
Core Topics
Bento request from Troy Linden.
Supplemental animations that run alongside the main animation (e.g., flapping wings while walking).
Possible future project – applying baked textures to mesh avatars.
Bento Request From Troy Linden
Troy Linden is preparing a presentation on Project Bento for an upcoming Second Life meeting within Linden Lab in which he plans to review the project, the interactions with content creators, the benefits this brought to the project, etc. In particular, he would like to demonstrate Bento content people are making and impress on LL’s executives how the project has been received, and how things might be followed-up.
To help with this, he is requesting that anyone with glamour shots of Bento avatars, etc., videos of avatars and Bento items to contact him via IM to discuss and / or send him what they have (troy-at-lindenlab.com).
Supplemental Animations
Introduced in 2013, llSetAnimationOverride() is one of a series of animation commands keyed directly into the server’s animation states, allowing for faster, smoother animation state changes than with AO systems using the older llPlayAnimation() command. However, llSetAnimation() only allows one animation to be played at a time for any given state, and this can lead to conflicts when trying to run custom animations as well (see BUG-41048 . An example of this is trying to use llSetAnimationOverride() to walk whilst using an animation to flap wings (below), which causes while the walk, set by llSetAnimationOverride(), to freeze in favour of running the wings flapping, as they are also seen as a locomotion animation.
Vir has identified two possible courses of action to deal with this. The first would be to extend llSetAnimationOverride() to allow “supplemental” animations to run alongside the animation states keyed by llSetAnimationOverride(), effectively allowing them to play together. The other would be to provide a means for people to define their own custom animation states (with associated animations) which the simulator would be able to recognise and handle alongside the existing animations states, rather than having the associated animation conflict with the default animation states.
No decision has been made on which route to take, and Vir is putting together a proposal on approaches, which he’ll put forward at a future meeting.
Applying Baked Textures to Mesh Avatars
This would allow the skin and clothing layers (skin, tattoo, under shirt, shirt, etc., “wearables”) to be directly applied to mesh avatars. In theory, this could be done, and could make it easier to do things like match skins between, say a mesh body and a non-mesh head without having to use applier systems. It could in theory even reduce the complexity of mesh avatars, which currently have to be made up of multiple layers (the so-called “onion meshes”).
A further benefit would be for non-human avatars a well. Providing the same UV is used across all elements of an avatar, it could allow creators to offer different pelts / skins for their animal / creature avatars and, if they make their UV maps available to other creators, allow them to produce things like additional skins.
However, there are problems in proceeding this way.The baking service is capped at a limit of 512×512 texture resolution, which would mean a loss of detail trying to “stretch” such textures over a mesh avatar, which would result in the ability potentially being ignored in favour of using the current “onion mesh” and appliers approach. It might also mean that wearable layers would be used in non-standard ways (e.g. using a “skirt” layer to apply a skin), which could lead to user confusion (“why am I using a skirt to wear a skin?”) – although this could be overcome by adding further wearable types specific for use with avatar meshes to the system.
An alternative would be to increase the texture resolution for the baking service to 1024×1024. While not entirely ruled out, it does carry with it a set of unknowns as well – what would be the back-end resource hit, could it lead to an uptick in texture trashing issues in the viewer, etc.).
Baking Textures on In-World Mesh and prim Surfaces
Part of the above discussion overlapped with the idea of allowing textures to be baked on arbitrary meshes (thus allowing for compositing, etc).
Vir noted that this would be a far more complex project due to the nature of the baking service, and thus would likely not be considered as a part of making changes to how system wearables might be applied to mesh avatars. However, he is interested in seeing feature requests on how this might be done and the benefits it would bring to SL, and a related JIRA – BUG-7486 – is in the process of being re-opened for comments along these lines.
Other Items
The latest version of Avastar is support of Bento is still undergoing testing. Those using it report it is behaving well, so hopefully a realise won’t be too far off.
On Sunday, January 8th, the Alchemy team released a beta version of Alchemy 5.0.0, the first update to the viewer to include support for Project Bento and Avatar Complexity (although no Graphics Presets).
As well as Bento support, version 5.0.0.40120 includes several updates specifically aimed at those with estate management responsibilities, plus a range of bug fixes and improvements from both Linden Lab and the Alchemy Team. In addition, this release includes work that is ongoing to reorganise the UI.
The following is intended to be a general overview of the more visible updates to Alchemy 5.0.0, and a summary of some of the bug fixes.
Project Bento
As almost everyone in SL must be by now aware, Project Bento introduces an enhanced avatar skeleton offering greatly improved support for mesh avatars and rigged mesh attachments. It also includes a set of new attachment points to work with the new joints, although the overall limit of the number of attachments you can wear at any one time remains 38 (including HUDs).
Most of all of this work is entirely under-the-hood. However, there are two additions to the avatar right-click context menu for both your own and other avatars: Reset Skeleton and Reset Skeleton And Animations which should be noted. In Alchemy 5.0.0, they can be found in the Appearance sub-menu of the right-click avatar context menu.
They have been added because sometimes, when changing between one mesh avatar and another, the basic SL avatar can become deformed, resulting in it looking squished, stretched, caught between two looks, or something else.
The reset skeleton options should “fix” your own or other avatars which appear distorted in your view after changing looks / shape – note both options only affect your view of the avatar in question, it does not affect how others may see the same avatar
The problem is generally the result of race conditions when the avatar’s appearance is being updated, and both of these buttons are intended to correct the problem – the option to reset animations as well is intended to fix deformations which may be due to animations also kicking-in incorrectly / at the wrong time.
Further information on Bento (if needed) can be found via the following links:
To be honest, I thought this had been part of Alchemy already, but looking through my past reviews and Alchemy’s release notes, I can’t find evidence of it being mentioned, and the 4.0.0.37571 release doesn’t include the Avatar Complexity options. Anyway, assuming I’m not going bonkers and thus repeating myself, here’s a rapid breakdown – please refer to my Avatar Complexity release article for in-depth info, if required.
, Avatar Complexity (aka Jelly Dolls), is in short a means to reduce the rendering load placed on your computer in having to render all the avatars around you in detail. Instead, you can set a rendering limit (aka Maximum Complexity) in the viewer. Any avatar exceeding this limit won’t be rendered in full – unless you opt otherwise – but will instead be rendered as a solid colour (aka Jelly Doll).
The revised Preferences > Graphics tab, including the Maximum Complexity slider. Setting this to high values will render avatars which may place additional rendering load on your computer, slowing your SL experience, to be fully rendered. Lowering it will cause such avatars to be rendered as solid colours, reducing their render load on your system
With Alchemy, this means that The Preferences > Graphics tab adopts the official viewer’s approach, displaying frequently used options within it, and moving the more advanced options to a separate Advanced Graphics Preferences floater.
The newer Advanced Graphics Settings floater (accessed via the Advanced Settings…. button in the Preferences > Graphics tab
Avatar Complexity includes some additional capabilities / options
Every time you change your appearance, and thus your avatar complexity, your current complexity value will be briefly displayed in the top right corner of the viewer window
You can display information on your own and other avatar’s complexity by going to the Advanced menu (CTRL-ALT-D to display it, if required) and selecting Performance Tools > Show Avatar Complexity Information
Your own avatar will always be fully rendered in your own view
Maximum Complexity has a No Limit setting. It is not recommended you use this. If you wish to avoid seeing the vast majority of avatars around you as Jelly Dolls, set the slider to a high value. Setting it to No Limit can leave you vulnerable to graphics crashers.
Use the avatar right-click context menu and the Visibility options to select how another avatar is rendered during your current log-in session
You can also alter how you see other avatars around you without altering your Maximum complexity setting. To this, right-click on an avatar to display the context menu. Go to Visibility to display the sub-menu. This has three options:
Render Normally – will render the avatar in accordance with your Maximum Complexity setting
Render Fully – will render them fully, no matter what your complexity setting
Do Not Render – will render them as a grey 3D imposter, no matter what your complexity setting.
Not that Render Fully and Do not Render only apply to your current session. If you re-log the avatar in question will once again be rendered in accordance with your Maximum Complexity settings.
There are no planned deployments for the week. However, all servers on the three RC regions will be subject to a rolling restart. This is in accordance with the Lab’s new policy of restarting channels every fortnight, whether or not there is an associated deployment. As the Main (SLS) channel underwent a restart on Tuesday, January third, server on this channel were not restarted this week.
SL Viewer
Project Alex Ivy
The 64-bit versions of the official viewer arrived in project viewer form on Tuesday, January 10th, under the code name Project Alex Ivy – which I take to be a reference to 64 (LXIV being 64 in Roman numerals, hence aLeX IVy).
The viewer, version 5.1.0.501863, has been built using the newly updated and upgraded libraries and build process the Lab has been putting together, which will also be used for 32-bit Windows builds. Thus, the project viewer is available in three flavours:
64-bit Mac
64-bit Windows
32-bit Windows.
There is no Linux viewer as yet, but the Lab has indicated it is their intention to provide one, although TPVs and open-source contributors are likely to still be asked to help with its ongoing support.
Additionally, the following points, as specified in the release notes, should be underlined (although please ensure you read the release notes in full if you intend to try this viewer:
The Mac build has several known limitations:
There is currently no Mac Havok build,so pathfinding paths cannot be visualised, and it may not be possible to upload mesh assets.
Video media using QuickTime does not play.
The 64-bit version will not run on Windows 10 systems with Intel HD 2000/3000 GPUs and may not run on other systems that do not have GPUs explicitly supporting Windows 10.
These shortfalls will be addressed as the viewer progresses through the project and release candidate phases to release status in the next weeks / months. Once released, it will signal the end of the 32-bit MAC version of the viewer (and possibly the 32-bit Linux version). The Windows version will continue to be available as a 32-bit build as well as having the new 64-build available.
Also, note that this viewer doesn’t include any functional updates / changes to the existing viewer.
Remaining Viewers Pipelines
Outside of the 64-bit project viewer, the various viewer pipelines remain as my last SL project update:
Current Release version: 5.0.0.321958, dated December 1st, promoted December 5th – formerly the Project Bento RC viewer
Maintenance RC viewer, version 5.0.1.322513, dated December 21st – some 42 fixes and improvements + Bento support
360-degree snapshot project viewer, version 4.1.3.321712, dated November 23rd – ability to take 360-degree panoramic images – hands-on review
Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Monday Outage
On Monday, January 9th, many users were hit with significant issues, with many finding themselves unable to log-in, or being disconnected from the simulators and unable to log back in. On Tuesday, January 10th, April Linden from the Ops team posted another of her excellent post-mortem blog posts on what happened, and I recommend it as a worthwhile and informative read.
In essence a failure within a third-party provider used by the Lab failed to trigger the expected automatic switch-over of connections for all users accessing Second Life through that provider. As a result, those users were disconnected from the service, and due to the volume of people trying to re-connect, couple (I assume with those simply trying to log in, unaware of problems) generated a backlog, forcing the Lab to bring additional log-in servers on-line.
Once again, April does an excellent job in explaining things – revealing more of the complexities of SL in the process (which, as I’ve oft said in the past, goes well beyond just the simulator servers), and also offers apologies for the Monday problems.
Inara Pey: Living in a Modemworld 