Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, May 5th
This summary is generally published on 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.
Note that test viewers, preview / beta viewers / nightly builds are not recorded in these summaries.
Official LL Viewers
Current Release version 5.1.3.513644, dated March 27th, promoted April 13th – formerly the Media Update RC.
Kokua updated to versions 5.1.3.43237 (RLV) and 5.1.3.43238 (No RLV) on May 6th. This release includes a Linux flavour built using LL’s Alex Ivy code base and Kokua’s Linux libraries – release notes.
V1-style
Cool VL viewer stable branch updated to version 1.26.22.4 on May 5th – release notes.
Viewer support has been a subject of frustration among SL users who prefer to use Linux (around 1%-1.5% of the total SL user base) over the lack of official support for the operating system.
As I reported at the time, in 2015 and due to a lack of Linux expertise, Linden Lab pulled back from active Linux viewer development in favour of seeking support from the open-source community in order to maintain a Linux version of the viewer (see here for more). More recently, the Lab has been looking to provide a means to build a Linux flavour of the viewer, based on their Alex Ivy 64-bit code base and libraries, but not distribute or build all the various dependencies required for the viewer, instead leaving this to TPVs to do as part of providing their own support for Linux users (see here for more), although this is taking time to happen.
In the meantime, on May 6th, 2018, the Kokua team released the first third-party viewer for Linux based on Lab Lab’s 64-bit Alex Ivy code base, although built using Kokua’s own Linux libraries.
Kokua release 5.1.3.43237 (RLV) and Kokua release 5.1.3.43238 (no RLV) are are supplied in Windows, Mac and Linux flavours. In addition, and as is to be expected, both are built using the latest LL release code base (SL 5.1.3) while the RLV version is at parity with RLV release 2.9.23.0.
The viewer is currently available for download on the Kokua website for those who wish to try it – just scroll down to the RLV 64 bit (active development) or the NORLV 64 bit (active development) sections of the download page for the version you’d prefer to use.
If you are a Linux user and opt to download the viewer, please do take the time to report any issues you find with it via the Kokua Issue Tracker at Sourceforge, as refinement and enhancement of the Linux flavour of the viewer is dependent on the Linux community, perhaps more so than the Mac and Windows flavours (which each have the advantage of larger user bases and more chances of issues being more widely identified and reported).
It should be noted that the Linux flavours of the viewers does come with a warning:
Some areas of the Linux release are still being worked on, however we believe that enough is working and well enough to share this with a wider audience to help us squash any remaining gremlins.
However, the news that there is now an up-to-date 64-bit Linux viewer available for download which is based on the Lab’s current code-base should hopefully come as good news for Linux users.
The was no deployment or restart for the Main (SLS) channel on Tuesday, May 1st. The channel remains on server maintenance package 18#18.04.13.514504, containing internal fixes and a fix for BUG-214702.
On Wednesday, May 2nd, the simulator release candidate channels should be updated as follows:
Magnum and LeTigre should receive server maintenance package 18#18.04.30.515008, which includes updates to simulator communication protocols aimed at improving region crossings and teleports, deployed for the last week to a number of selected regions on Blake Sea via the Snack RC channel.
LlRequestUserKey and LlName2Key
The Lab has released two new LSL functions: llRequestUserKey and llNameToKey, both of which are in connection to the upcoming return of Last Names (see this blog post and this blog post for more):
llRequestUserKey:
Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
Note that agent being searched for with this function does not need to be signed on to Second Life.
Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
Uses a different mechanism to look up agent information to the older llKey2Name().
Bakes on Mesh project viewer, version 5.1.3.513936, dated March 30th.
360 snapshot viewer, version 5.1.3.513006, dated March 6th (this version can have significant rendering issues, see my hand-on update).
Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November 2017 – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
Environment Enhancement Project (EEP)
Rider Linden re-confirmed that while EEP will allow different Windlight settings at altitude above a region / parcel, the zones will be set at 1000 metre intervals (1,000, 2,000, 3,000 and 4,000) and set by the simulator – they will not be user-configurable as can be done with Firestorm (viewer-side only). His hope is also to have scripted per-agent Windlight settings as part of the initial deployment of EEP; however, this is TBC.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, April 29th
This summary is generally published on 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.
Note that test viewers, preview / beta viewers / nightly builds are not recorded in these summaries.
Official LL Viewers
Current Release version 5.1.3.513644, dated March 27th, promoted April 13th – formerly the Media Update RC.
The majority of these notes are taken from the TPV Developer meeting held on Friday, April 27th 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.
Once again, this was a short meeting, but one with extended periods of silence; hence some of the gaps in the time stamps below. There’s also a conversation on the forthcoming Bid A Linden Bald event, as part of the Relay Rockers annual
SL Viewer
[0:07-0:36] The Love Me Render RC viewer updated to version 5.1.4.514788 on Wednesday, April 25th, 2018, and the Ouzo Maintenance RC updated to version 5.1.4.514802 on Friday, April 27th. Both of these RC viewers have had “significantly higher” crash rates than the default viewer, so the Lab will be watching to see what happens with the two updates, and with the crash rate for either is reduced as a result of their release.
Otherwise the viewer pipelines remain as:
Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
Bakes on Mesh project viewer, version 5.1.3.513936, March 30.
360 snapshot viewer, version 5.1.3.513006, March 6 (this version can have significant rendering issues, see my hand-on update).
Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7. This viewer will remain available for as long as reasonable, but will not be updated with new features or bug fixes.
[0:39-1:24] The 360 snapshot viewer remains “on hold”, receiving updates to maintain parity with release viewer, but otherwise not receiving any significant work on its key features at this point in time. Work will resume in the future as the specialist resources become available. Both the Animesh and Bakes on Mesh viewers are referred to in the meeting as being “close to coming over to Agni”, although this only hold true for the Animesh project viewer, as the Bakes On Mesh viewer should work on the Main grid already (albeit with the Bake Service’s current 512×512 texture support, as the support for 1024×1024 textures has yet to be deployed).
Viewer Texture Cache Work
[1:46-2:14] The Lab continues to work on the viewer texture cache, and it is hoped that the latest attempt will lead to a “big improvement” in how textures are handled. Currently this code is not available for public consumption, but the hope is that there will be a project viewer with the code available “pretty soon”.
Updated Estate Management Tools
[19:30-20:10] Work is again progressing on enhancing the Estate Management tools in the viewer (e.g. refining ban list management capabilities, etc.). It is hoped that a project viewer will be emerging in the next few weeks. The viewer updates themselves are largely done, and things are awaiting server-side support.
The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
Scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.
Current Status
[11:39-12:38] Rider Linden has been engaged in some other work for most of the past month, but is now largely back working on the project. It is now a focus for the Lab going forward, with the hope that Rider will not be diverted into other work at EEP’s expense. Some test regions for EEP are also being prepared on Aditi.
Other Items
Testing Viewer Options and the Shared Experience
[5:00-5:45] TPVs sometimes introduce features and options which might be considered as breaking the “shared experience”. The question was therefore asked if allowing people to test / play with new rendering options – as developed by a TPV rather than Linden Lab – might be considered as breaking the shared experience. Oz Linden offered a response which provided some guidance on similar kinds of updates:
I think the best I can give you in terms of a general answer is if it’s the sort of thing that’s going to cause a merchant to include a note card with a product that says, “to see this product correctly, you have to run this viewer with that option turned on”, that’s a sign you’re breaking the shared experience … On the other hand, if you want to experiment with something that you’re then going to contribute upstream [i.e. to the Lab for inclusion in the base viewer code (which is used by all TPVs)] that’s a different problem altogether.
Catznip Displacement Maps Experiements
The question itself was prompted by Kitty Barnett of Catznip, who is working on using displacement maps in the viewer, as well as some other normal mapping tweaks.
Displacement maps, currently being experimented with by Kitty Barnett, can add further depth to surfaces. For example: top left – a prim wall with a brick texture; top right: a prim wall with a texture and normal map applied, as we’re used to seeing in Second Life – some depth is added to the cement grouting between the bricks etc. Bottom centre: the same prim wall with the same texture added, but now using a displacement map: note the greater apparent depth between bricks and cement grouting, etc (highlighted). However, such a capability will have a Land Impact cost.
It would seem that if successful, this work will be contributed to Linden Lab for evaluation and consideration. It’s important to note that Catznip’s work is in the early stages, more work is required on level of detail impact / modelling / potential Land Impact costs, etc., for which Catznip may look to the Lab for assistance.
[6:26-6:46] In the meantime, Oz Linden reiterated that, quite aside of the Environmental Enhancement Project (EPP – see above), the Lab is working on a number of other environmental (render-side) improvements. Previous discussions on rendering improvements have indicated that Graham Linden is already working on a series of environment updates alongside the EEP work being carried out by Rider Linden, which appears to include support for Godrays, potential pre-baking of some environment effects, etc. It’s not clear from Oz’s comments whether he is referring to this work, or something further downstream.
Natty Linden’s Marketplace Job Ad
[16:37-17:00] Natty Linden posted a Marketplace listing for a job at Linden Lab. While offering a little fun, the listing has a serious edge: there is an open Marketplace web developer post at present. As such, Natty’s listing is a further way of reaching those already engaged in Second Life who may have the requisite skills sets, who live in the right location and who may be interested in joining the Lab (which frequently does employ Second Life users – as seen with the likes of Patch Linden, Xiola Linden, and Rider Linden, to name but three of the more well-known resident hires made by the Lab over the years, and who work in different areas within the SL team).
The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, April 26th, 2018 at 13:00 SLT. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Animesh Project
Project Summary
The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.
Server-Side Updates
Vir believes the Lab is pretty close to a final set of Animesh updates for the server side of things. These include support for the Animesh updated limits and cost formulas, and it is expected that QA will be starting soon on the code in readiness for clearing it for deployment to the Main grid, Agni.
Joint Offset Constraints
One of the reasons the Lab is discussing constraining joint offset is an Animesh bear developed for testing purposes (and which can be found on the Aditi Animesh test regions) which sits some 75 metres off the ground, that’s due to a bad offset being set within the mesh and used with the mPelvis bone, which comes into play when the mesh isn’t being animated.
The bear itself was created as the SL10B wearable avatar, and so demonstrates what can happen with existing wearable content with such errors (which would not become apparent while the mesh is become worn, as the avatar tends to always be in a state of animation) is converted for use as Animesh.
Constraining the distance joints can be offset (say to 5 metres) offers one means of preventing this kind of problem; however, it is recognised that doing so could break existing content – such as the very tall avatar models that are available. Therefore the Lab is considering this an other, more complex options – such as doing something with the bounding box.
Animation Playback Issues
Some are still having Animation playback issues with Animesh objects, notably on initial rezzing or following a region crossing. The advice is it increase the number of animation updates being sent out.
Land Impact
There is some potential confusion with the land impact reports on the mesh uploader and when calculated for an Animesh object when in-world. The uploader calculates the LI for a mesh based on it being a static object. It is only when the object is toggled to Animesh in-world that the revised formulas for LI and complexity are used. This has in turn lead to issues for creators trying to determine what the likely weightings are going to be for their models prior to update.
There have also been some reports that on conversion, models not obeying the new LOD requirements defined as part of the within the new formula suffer heavy penalties when converted to Animesh.
Rigged Mesh Level of Detail / Bounding Box Issues
Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box (see BUG-214736). Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.
Graham Linden has been investigating this issue, and now has some updates for the viewer (yet to be integrated with the Animesh project viewer) which should help with this issue and encourage those creator who have, deliberately or accidentally, gaining an advantage from the issue to offers balanced LOD models for their content.
Bakes On Mesh
Project Summary
Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.
This work does not include normal or specular map support, as these are not part of the existing baking service.
Completing the work to implement three more tattoo slots of the Bake Service: skirt tattoo, hair tattoo and eyes tattoo. These are designed to extend the tattoo to the same set of slots as for the underwear and clothing layers, and hopefully make the available slots far more flexible in potential use when applying baked textures to worn mesh.
Continuing to work on the skirt layer stacking issue.
The basic functionality of taking system wearable layers and applying them to mesh faces is viewed as working. However, as per my previous Content Creation meeting notes, there is still a lot to be decided on how to progress Bakes on Mesh, particularly in reference to Bakes on Mesh and the applier market, and the overall convenience of Bakes on Mesh for applying textures to worn mesh faces, compared to “ease” of using applier systems for consumers.
Internal discussions about some of the ideas raised around this – such as being able to inject textures into the Bake Service via script – are still be discussed within the Lab as a result of the concerns raised at the previous CCUG.
Bakes and UV Maps / Spaces
Bakes on Mesh has generated a lot of discussion on the effectiveness of custom UV maps and the Baking Service – UV maps being the thing that take was are essentially 2D textures and “wrap” them around a mesh object. In brief:
The system avatar has a set of pre-defined UV spaces associated with it. These are used by many of the mesh body makers, and so using system clothing layers via the Bake Service should work on these. Mesh heads tend to be different, and so issues can occur trying to apply skins, etc., to them.
The Lab’s view is that there’s no reason in principle why the baked textures must use the system UV space. So, for example, and providing none of the system avatar layers (such as the skin) are to be visible, it should be possible to use a set of tattoo layers defined in a specific mesh body’s UV space which can then be passed through the Bake Service and applied to a set of mesh faces regardless of the system UV space.
An issue here is that only tattoo layers can be used with custom UVs, as all other layers have “holes” in them designed to reveal the system avatar skin, allow for eyelashes, etc. Therefore, it is not currently possible to re-purpose a shirt layer, for example. Cathy Foil expanded on this, and on the use of system UV space with mesh bodies.
Vir expanded a little on the idea that some of the clothing layers that have more “intelligence” built-in (e.g. alpha masking support), hence why they would not work with custom UVs and it would be necessary to use tattoo layers for the textures and re-name them.
Within the meeting, this led to an extended discussion on UV options – such as the advantage of updating the avatar .LAD file and the viewer appearance editor to allow the use of custom UVs or the system UV space (via an appearance editor check box) over re-purposing tattoo layers.
It’s like that initially, the Lab will lean towards re-purposing tattoo layers, rather than re-working the avatar .LAD and appearance editor, leaving it to body / head creators to offer updated UV maps for those cases where they don’t precisely follow the space UVs.
Next Meeting
There is no CCUG on Thursday, May 3rd due to a conflict with the Lab’s monthly internal meeting. The next CCUG will therefore take place on Thursday, May 1oth, location TBA.
Inara Pey: Living in a Modemworld 