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.
On Thursday, August 20th, the Alchemy team released version 3.8.2.36473 of their viewer in the first of their promised monthly updates.
This release brings the viewer to par with the Lab’s 3.8.2 code base – which means Viewer-Managed Marketplace support. Also, and interestingly, the windows version of the viewer is now built using Visual Studio 2015 (this will generate a VS2015 Redistributable message as a part of the installation process as core elements required for the viewer to run are installed).
Also with this release – and the Alchemy team are calling it a release, rather than a “beta”, as with recent updates – is support for up to 2 gigabytes of texture memory; improvements to the build floater and right-click context menu option; some tweaks to Preferences; and the arrival of OpenSimulator support as well.
So, as a quick look at the main updates.
Alchemy now has VMM support
The SL VMM support offers the expected Marketplace Listings panel, found under the Me menu.
I admittedly did not play with it extensively (i.e. I didn’t attempt to create an entirely new listing, as I don’t have anything not already listed via VMM), but everything did appear to be working quite happily while I poked at updating listings, etc.
In Preferences, the Sound and Media tab gets two new sub-tabs. The first of these is for media, and entitled Sounds; it also includes a toggle for enabling / disabling audio stream notifications.
The second sub-tab is called Voice, and does exactly what it says on the label: provides access to the Voice options.
A minor update to the Setup tab sees the Use Built-in Browser option re-labelled to be more generic in recognition of OpenSimulator support (“in-world” rather than “Second Life”).
A new tab in Preferences, called Grids, provides access to the viewer’s grid manager for adding OpenSimulator grid details, which can then appear on the log-in / splash screen grid selection. By default, both the SL main (Agni) and beta (Aditi) grids are listed, and adding further grids is the usual case of adding the appropriate URI, with the Grid Manager set to recognise the more popular destinations.
Alchemy 3.8.2 brings with it OpenSimulator support
In testing I found everything working as expected, and I had no issues adding Kitely and logging-in. In addition to the new grid options, the OpenSim updates also include both hypergrid support, and support for OpenSim variable regions.
The build tool updates come in two parts. The first is an expanded build sub-menu available from the right-click context menu, which now includes the various script-related options (recompile, reset, set running, etc). The second is the addition of a check box to the build floater itself to automatically synchronise settings (repeats, offsets, etc), between materials layers on an object / object face.
Alchemy 3.8.2 brings with it expanded build options in the right-click context menu, and the ability to synchronise materials on an object / object face
All told a tidy update in which the OpenSimulator support could be very welcome. As always, for full information on updates, any known issues, etc., please refer directly to the release notes.
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.
Quick Graphics project viewer version 3.8.4.304433, release on August 21st – provides the new Avatar complexity options to assist with viewer performance when rendering avatars in busy locations, and the new graphics preset capabilities for setting, saving and restoring graphic settings for use in difference environments / circumstances (download and release notes).
Alchemy updated to version 3.8.2.36473 on August 20th – core updates: OpenSimulator Support, Build tools improvements (incl. VS 2015 for Windows), parity with LL 3.8.2 code base; support for up to 2 gigabytes of texture memory – release notes.
Firestorm updated to version 4.7.3.47323 on August 18th – core updates: parity with LL 3.8.2 code base; VVM support; attachment fixes; Experiences support; Layer Limits and much more – release notes – review notes.
UKanDo updated to version 3.8.3.28132 on August 18th – core changes: parity wit the LL 3.8.3.304115 and RLV 2.9.12 releases – release notes
The following notes are primarily taken from the TPV Developer (TPVD) meeting held on Friday, August 21st, 2015. A video of the meeting is included at the end of this report, with any time stamps in the following text referring to it. My thanks as always to North for the recording and providing it for embedding.
Server Deployments – Recap
There was a single server maintenance package deployed during the week, which was delivered to the BlueSteel RC on Wednesday, August 19th. This was intended to provide fixes for items and folders getting mixed up. however, this was subsequently rolled back on Thursday, August 20th.
Viewer Updates
Project Quick Graphics
On Friday, August 21st, the long-awaited Avatar Complexity / graphics presets viewer arrived in project viewer form. Version 3.8.4.304433 is being referred to as “Project Quick Graphics”. I provided an initial look at this viewer in pre-release, but I now have an updated overview available.
The Quick Graphics project viewer offers the means to create your own sets of graphics presets you can quickly swap between according to needs / circumstance. It also include the new Avatar Complexity capabilities – see my overview for more information
As noted in that report, the Avatar Complexity default you get is based on the rendering performance of your system. however, this might be adjusted by the Lab during the time the viewer is available at a project status.
Other Viewers
[02:00] An update to the Oculus Rift viewer is still anticipated, although this has tended to be pre-empted by other things, and may be again.
There have been no other viewer updates since the promotion of the Maintenance viewer on Tuesday, August 18th, as reported in part 1 of this update.
[23:35] The will, at some point be an experimental viewer build, which should lead to a project viewer in the future, using the FMod Studio for audio.
HTTP Work
[08;00] Rider Linden has been engaged in further HTTP work, specifically aimed at the viewer with the intent of reducing the paradigms for how HTTP should be used within the viewer from 4 to a single, consistent approach. He has most recently been engaged in aligning recent HTTP updates made to the viewer with his own work.
[19:36] The Lab is still looking for move more asset types from delivery using UDP via the simulator to delivery using HTTP via the CDN, but this is pending the completion of Rider’s HTTP work. Overall, the view is that there is no reason why any asset that goes to the viewer should be cached and delivered via the CDN.
Inventory Improvements
[10:48] The lab is continuing to investigate causes of inventory issues with the intention of reducing them. In particular, they are considering server-side enforcement on how inventory should be organised.
The idea is not to prevent how people organise their inventories, but rather to ensure things that simply should not happen under normal use, but which have been shown to lead to inventory losses when they do occur, are no longer possible. Examples of this include a user’s inventory gaining more than one Trash folder, or the system allowing folders to be created without an associated system ID, and so on. The most effective way of achieving this is through server-side rules enforcement.
While the Lab is not ready to start implementing such changes as yet – they are still investigating, as noted – these changes are part of an overall goal to migrate all inventory operations over to AIS (Advanced Inventory System) and then to deprecate older inventory code – all of which will involve changes to the viewer. This means that as this work progresses, viewers not supporting the AIS v3 code will no longer be able to perform inventory operations.
Server-side Validation
[16:40] Commenting on issue of validation of uploads in general, Oz Linden said:
I would like to add validation for more things that get uploaded [but] of course there’s always the backward compatibility problem, people complaining that once upon a time I could upload this, and now I can’t…
However, he went on to say that there is a case for not limiting validation of uploads purely to the viewer, as is currently the case:
There’s nothing wrong with also checking in the viewer, but if it’s not the model we expect to be true of the world, there should be validation on the server because we have a lot of third-party viewers … So we really can’t count on the viewer to get it right, there are too many of them. And if nothing else, some things that can cause crashes that might be deliberately put into viewers … that might cause crashes in other people’s’ viewers, and that’s not good. So we have to try to protect against that.
The best place to put that protection, if we can do it, is to put it one the server-side, if we can do it. So there are lots of things that, over time, we may add checking of things, as they are uploaded, on the server, and we may reject uploaded things, and we may reject uploaded things that are inappropriate.
How quickly we will be able to do that will probably vary with what the upload type is and what time we have between doing dazzling new features; but if we find something related to some dazzling new feature we can add some checks to, we might do that.
Avatar Complexity (aka Jelly Babies) is now available in the Quick Graphics project viewer
Update:See BUG-9962 for issues relating to avatars becoming stick as Jelly Babies when using Avatar complexity.
On Friday, August 21st, the Lab issued their Project Quick Graphics project viewer. Version 3.8.4.304433 brings with it the much-anticipated Avatar Complexity and graphics presets capabilities, both of which are intended to assist in improving viewer performance for those on lower-specification computers.
I provided an overview of the viewer while it was still in an early version, so this is offered as a further update.
Avatar Complexity introduces a new slider to the viewer which can be used to set a level above which avatars requiring a lot of processing will appear as a solid colour (including their attachments), giving them the nickname ” Jelly Babies” after the sweet (candy) of the same name.
As avatars can often be the single biggest impact on the viewer in terms of rendering, particularly in crowded places, using this slider is intended to greatly reduce the load placed on a system compared to having to render them in detail, allowing users to adjust the setting according to circumstance – the setting can be increased, rendering more avatars as solid colours in crowded regions, and turned down for quieter spaces. At the same time, there’s also the ability to set how individual avatars are rendered on-the-fly during the current log-in session.
The Avatar Complexity slider in Preferences > Graphics > Advanced Graphics Preferences (l) and the new format of information displayed when Advanced > Performance Tools > Show Avatar Complexity Information is enabled (r)
The Avatar Complexity slider can be found on the Advanced Graphics floater (Preferences > Graphics > Advanced Settings…), The values run from 19,999 to 300,000, above which it switches to No Limit, meaning all avatars in your field of view will fully render, with the default based on the rendering performance of your system. As noted in my last piece on this, the values used by this slider are based on those previously used to determine Avatar Draw Weight / Avatar Render Cost.
It is possible to see the render complexity of all avatars in your field of view (including your own) by enabling Advanced > Performance Tools > Show Avatar Complexity. This displays a series of figures above avatar heads which is updated in real-time. The one likely to be of interest to most users is at the top: the actual render complexity value. This should remain fairly constant, allowing for how people might change their appearance by adding / removing items and changing their appearance.
The viewer also generates information messages in the upper right corner related to Avatar Complexity. One is displayed each time you change your own avatar’s appearance and impact your own rendering complexity. The second acts as an indicator for when you’re over the limit of “too many” of the avatars around you, and are being rendered as a Jelly Baby.
The viewer displays notifications when you (l) make a change to your own avatar which impacts its render complexity; (b) if your avatar is largely rendered as a Jelly Baby by others
A further element of Avatar Complexity is the ability to selectively alter how individual avatars are rendered on-the-fly. This is achieved via the right-click Avatar context menu, which includes three new options:
The right-click avatar context menu has options to allow you to define how you want specific avatars to render during the current session
Render normally – the avatar will render as defined by the Avatar Complexity setting. If the avatar’s complexity is lower than the setting in the viewer, it will render correctly; if it is higher, it will render as a Jelly Baby
Always Render Fully – does exactly what it says – the avatar will always be fully rendered, regardless of it exceeding your set complexity limit
Do Not Render – renders the avatar as a Jelly Baby (or even not at all save for name tag if already very easy to render) regardless of your Avatar Complexity setting. Note that this setting does not persist across log-ins (so if you re-log, those avatars you’ve used it against will render normally), and it will not block the ability to read their local chat or receive their IMs, etc.
There are a couple of final points worth mentioning with Avatar Complexity. The first is that it is not a replacement for Avatar Imposters, but can be used alongside it. The second is that with this project viewer release, the colours of Jelly Babied avatars has been muted when compared to test versions of the viewer, making them a lot easier on the eye (the image at the top of this article shows the former, more vivid colours).
Graphics Presets (see STORM-2082) allows users to create, save and use their own graphics presets, each designed to meet a specific requirement, and which can be quickly switched between with the overall aim of helping with viewer performance.
For example, one preset may have all the performance hitting items (shadows, projectors, etc.) turned on / up for times when the overall quality and depth of detail in a scene is important for taking photos, another may have them dialled-down for crowded places, and a third might have them adjusted further for “indoor” use (so draw distance is greatly reduced, sky and terrain details are set to low, water reflections turned off, etc.).
The viewer includes the means to create and save sets of graphics presets which can be quickly loaded according to need / circumstance to help maintain a viewer’s performance
Once a preset has been set-up, using the revised Advanced Graphics Preference panel, it can be uniquely saved, and then applied at will using the either via Preferences > Graphics > Load Preset, or more directly by the Graphic Presets icon located in the top right of the viewer.
When the mouse is hovered over this icon (shown right), a list of all saved presets is displayed, a tick appearing alongside the one currently being used. Clicking on any other preset will immediately apply it.
In addition, this panel also has a button which will open the viewer’s graphics settings in Preferences.
As noted in my previous article on these updates, the Advanced Graphics Preferences panel has been seen as less-than-optimal due to its size; the Lab have acknowledged the feedback, but have not made any significant changes to the layout as yet with this project viewer release. Whether they do or not may depend on feedback they receive directly from users, and what they feel can be done to improve clear deficiencies.
The ability to create and save graphics presets is a welcome addition to the viewer – these are not the same as backing-up and restoring viewer settings as seen in other viewers, but do provide a fast and efficient way to adjust graphics settings according to situation, if needs be.
Avatar Complexity is liable to be an interesting addition to the viewer. While there is a risk of seeing a return of ADW / ARC drama, it also provides the means for people to accurately judge the impact their avatar might be having on others – and their own, given their avatar must be rendered by their own computer as well – SL experience. It also potentially offers content creators to better understand how the use of mesh and textures can impact other people’s SL experience, allowing them to further improve their products.
Those wishing to try the viewer for themselves can find it here. Keep in mind, that is it s project viewer, prone to possible bugs and to further changes from the Lab, and issues should be reported via the JIRA.
There was no main channel roll on Tuesday, August 18th. The LeTigre and Magnum release candidate channel will also remain as they are for week #34.
The BlueSteel release channel received a new server maintenance package on Wednesday, August 19th, which includes internal improvements for inventory performance.
Commenting on the changes rolling to BlueSteel, at the simulator User Group meeting on Tuesday, August 18th, Simon Linden said:
If you notice anything on the Bluesteel RC channel after the roll, please file a jira on it with all the info you can about time and place and what happened … these changes aren’t about per[mission]s, I believe, but items and folders getting mixed up … Someone dug deep into the inventory system and identified some problems and tried to fix them.
The mention of permissions in his description of the update was the result of a question on whether the update would correct “perms bypassing”, which he addressed directly:
I know there’s been some talk about permission issues but from what we can tell, there are no _new_ permission problems. The best advice I can give is that you have to be extra careful about changing permissions in inventory (or in an object inventory) and then transferring it before it gets rezzed. And what I mean by “be extra careful” is, “don’t do that.”
There is a possible conflict if you change permissions while in inventory, and then pass it (without rezzing) to someone else. In that case, the “next owner” permissions can conflict with what you tried to set, so the result may not be what you expect. That’s been around forever and is often the reason people end up making copyable objects that they want “no-copy”.
SL Viewer Updates
On Tuesday, August 18th, the Lab promoted the summer Maintenance RC viewer, version 3.8.3.304115 as the de facto release viewer. This viewer includes over 50 maintenance fixes and update – please refer to the release notes for details.
The anticipated arrival of the Avatar Complexity / Graphics Presets project viewer in week #33 failed to occur, so perhaps it will arrive later in week #34.
Inara Pey: Living in a Modemworld 