There are no planned deployments for the opening week of 2018. There are currently no DRTSIM projects on Aditi (the beta grid) awaiting promotion to the Main grid, however, there may be new RC deployments for week #2 (commencing Monday, January 8th).
SL Viewer Updates
There have been no SL viewer updates over the holiday period. This leaves the viewer pipeline as per the end of 2017:
Current Release version 5.0.9.329906, dated November 17th, promoted November 29th – formerly the “Martini” Maintenance RC
Release channel cohorts:
Nalewka Maintenance viewer version 5.0.10.330123, December 21st.
Wolfpack viewer, version 5.0.10.330113, December 20th.
Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11th.
Voice RC viewer, version 5.0.10.330039, December 12th.
Project viewers:
Project Render Viewer version 5.1.0.511446, December 18th.
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.
TPV Updates
The following third-party viewers updated over the holiday period:
Cool VL viewer updated to version 1.26.20.40 (stable), and 1.26.21.6 (experimental).
Catznip updated to version R12 on January 2nd, 2018 – see my overview for more.
My weekly viewer release summaries will resume from week #2, 2018.
SL Feature Summit
The next Second Life “feature summit” when potential projects and major updates for SL are considered / reviewed, is due to take place in February 2018. These meetings are generally held around every 6 months.
Monday, January 1st, 2018 saw the long-await release of Catnzip R12 – the release coming a little over a years since the last update – and slightly earlier than planned, thanks to the auto-update!
As one might expect, this update brings a large number of user-facing updates, which are quite comprehensively documented in the accompanying release notes, and rings Catznip up to parity with the current LL released viewer code base 5.0.9. It is currently only available for Windows, in 32-bit and 64-bit versions, the latter conforming to the Lab’s Alex Ivy 64-bit build.
Given the depth of the release notes, I’m providing an overviews of just some of the updates here:
Quick Preferences updates.
Inventory Management improvements.
Chat / group chat updates.
For the rest of the changes, please refer to the release notes.
Quick Preferences Updates
Main Quick Preferences Panel
The main Quick Preference panel sees a number of small updates and improvements:
The short cut CTRL-SHIFT-P no longer conflicts with Print Selected Object Info (the latter now ALT-SHIFT-P).
The panel can now be minimised via a button (item 1 in the image below)
The Other Section of avatar rendering now includes a button to open the Exceptions panel for listing exceptions to your avatar rendering settings (item 2 in the image below)
The worn items tab button (item 3 in the image below) now displays a tab with button to display sort options for the items listed in it (item 4 in the image).
The revised Catznip Quick Preferences
Quick Inventory
We all use HUDS – HUDS for AOs, HUDs for mesh bodies, HUDs for mesh heads, HUDs for appliers, etc.). However, wearing the all, all the time not only clutters the viewer’s window, it actually eats texture memory. We also have certain things we like to wear all the time. However, even if you dump all of your HUDs into a single folder in inventory, finding the one you want can be a pain.
Catznip R12 helps ease some of this pain through the provision of a Quick Inventory function. Used via Quick Preferences, this can afford faster, cleaner access to your HUDs, etc. To use it:
Create a folder anywhere in your inventory (if you don’t already have one ready to go).
Drag and drop your HUDs an bits (or links to them ) into it.
Open Quick Prefs and click on the inventory button (item 1 in the image below).
Click on the Folder <click to select> button (item 2 in the image below) to open a folder picker.
Click on the folder with your HUDs and bits to select it.
The contents of the folder will be displayed in the inventory tab of Quick Preferences each time it is opened, allowing you to easily Wear / Add items from it (right-hand picture in the image below).
The folder can be changed at any time by clicking on the folder button in the inventory tab.
Quick Preferences: Quick Inventory
Inventory Management
Inventory management updates make up the core of the R12 changes, and these come in a number of improvements, from how you chose to receive goods purchased in-world in your inventory or passed to you by others, through searching inventory to where boxed items are unpacked and stored in your inventory.
Accepting In-World Purchases and Inventory Offers
With Catznip R12 you can now designate where the items you purchase in-world or are given by others, are stored within your inventory. So, for example, you could opt to receive all your in-world purchases in a folder you call “Shopping Bag”, any demos you grab in a folder called “Demos”, anything your offered by friends in “From Friends”, and so on. How you organise things is entirely up to you. This means both the Pay and Buy floaters in Catznip R12, together with the Accept Inventory floater now offer you the ability to select where incoming items are going to be stored in your inventory.
Catznio R12’s options to select where items you buy / receive go in your inventory
The options should be fairly self-explanatory. Check Accept in and the remaining options are activated. The drop-down will display a list of folders you have opted to allow incoming items to be delivered (show in the image on the right), the browse button allows an alternative to you list of folders in the drop-down to be selected, and the spanner button allows you to establish your list of destination folders. The roadmap of these various options is shown below.
What the options do. Note they are available in both the expanded floater view (centre) and the collapsed view (left)
Not only can you select the folders into which you want incoming purchases to go, you can also set Catznip R12 to dynamically create new folders in which to place incoming items. This means, for example, that if you got to a big shopping event at one location, you can set the viewer to deliver all the demo you obtain / items you purchase into folders define by – say – the month in which you got them, and the location where they were obtained.
So, for example, if in April you go to shopping event X on region YYYY, and grab a load of demos, and then later in the month go to event A on region BBBB and grab more demos, you can have them delivered to sub-folders in your “Demos” folder, respectively labelled “April 2017 YYYY” and “April 2017 BBBB” – both of which are dynamically created by Catznip as they are needed. So even if you don’t get around to trying them for days after your visit, you can quickly and easily locate the demo items without have for fiddle around searching for folders and objects.
The panel for setting folders into which incoming purchases can be received, and the option for setting dynamically created sub-folders within that folder
Each week through the year, I try to get to as many in-world and other meetings held by the Lab to keep an eye on technical developments and updates which are in the works for the viewer and the simulator, relaying the notable items via my SL project updates. As such, I thought it might be interesting to look back at some of the technical changes and updates have come our way in 2017.
Visible Projects
The year started with everyone still getting their heads around 2016’s Project Bento, which reached release status at the end of that year, bringing with it a much extended avatar skeleton with masses of new bones allowing a range of new animations and opportunities for more diverse avatar looks that used bone animations rather than resource-heavy options such as alpha flipping and so on.
Thus, 2017 – or at least the early part of it at least – saw many Bento releases hitting Second Life, from animal avatars through to Bento-enabled avatar mesh heads and hands which offer a greater range of expressions and natural motions, natural jaw and mouth movements to go with Voice or with text chat, and so on. Given the interest in Bento, I offered a behind-the-scenes look at the project from a personal perspective, having been an observer of the work from the initial closed development work all the way through the open beta to release.
I eventually made the move to a Bento head in September 2017, after extensive fiddling with demos from all the major makers, with (r) Lelutka proving to be the best in terms of maintaining much of my “original” (aka “2010 onwards”) look (l), as I played with the demo model & test skin)
The Bento project gave rise to several potential follow-on projects, of which the three most popular among creators at the Bento / Content Creation meetings were: supplemental animations, to allow smooth interaction between animations as a result of conflicts arising between the extended bone groups (currently on hold), animated mesh – eventually renamed “Animesh”, and bakes on mesh – with the latter two becoming a particular focus of the in-world Content Creation User Group meetings, together with the Environment Enhancement Project (EEP).
Animesh is 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. It can be used with any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself. During 2017, the focus has been on getting a basic Animesh capability working in Second Life, which by the end of the years saw a project viewer at an advanced stage of development. 2018 should see this move to RC status, and the project as a whole move to release. A potential follow-on project may then see the capability extended to allow more in the way of NPC creation through Animesh.
Animesh allows you to take rigged mesh objects, add animations and controlling scripts to them, associate them with an avatar skeleton, and have them run in-world without the need for any supervising viewer / client
Bakes on Mesh extends 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 (but does not include normal or specular support). Once this initial work has been completed, an intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
Environment Enhancement Project is a set of updates to Windlight settings, etc. These include the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type 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.
While 2017 didn’t see the deployment of many high-profile user-facing projects, it did see a considerable amount of back-end work take place, not all of which was necessarily user-visible, and some of which also affected the viewer. In summary this work included:
A complete overhaul of the simulator code build process, including upgrading the Linux OS for the simulator servers – the first of such rounds of OS update.
Moving most of the remaining SL asset (inventory items) handling from UDP messaging through the simulators to HTTP delivery via the CDN.
Changing how multiple, repeat teleport requests made via scripted HUDs were handled to reduce the impact such requests have on region performance.
The start of a project to revise the complexity calculations (in-world objects and Avatar Rendering Complexity) to make them more accurate / stable and reflective of the true cost of rendering items – this work is still ongoing.
Continuing work to eliminate exploits use to crash regions and to make the simulator code generally more robust, trying to curb illicit content copying, etc.
The Viewer
Much of 2017’s focus on the viewer was directed at moving it to 64-bit for Windows (whilst also maintaining a 32-bit version as well) and for Mac OS X. Started in 2016, with a significant overhaul of the viewer build process and its associated libraries, the first project viewer release for the 64-bit viewer – code-named Alex Ivy (aLeX IVy = LXIV = 64) – arrived in early January, with work continuing throughout the year to refine the viewer, work out issues in the build process, and move the project towards release status – which should now happen in early 2018.
The 360-snapshot viewer received an overdue update which, while suffering from pro resolution issues, did streamline the production of 360-images. This was the only update to the viewer in 2017, leaving it as project viewer status. More work will be forthcoming in 2018.
The revised snapshot floater in the July 2017 360-snapshot project viewer
The Lab also restated their desire to continue with Linux, by offering a Debian build of the viewer – but only with the help ogf the Linux community.
Other updates for the viewer in 2017 included custom folders for uploads, the launch of a new release candidate branch of the viewer specifically to manage fixes and updates to the viewer’s rendering pipe, the first pass at improving region / estate ban lists for estate owners, the viewer’s avatar rendering options (right-click context menu and Preferences > Graphics) were improved to allow users to better define how avatars around them are defined. New region / parcel access controls were introduced and a WORN tab was (finally) added to the inventory floater. There was also the ongoing series of Maintenance RC releases throughout the year, aimed specifically at fixing bugs and issues, which in 2017 gained their own code-name series, each one being named for an alcoholic beverage.
Other Updates and Changes
A new Second Life Community Platform officially launched on Tuesday, March 14th, 2017. You can read my overview of the platform here.
Places Pages officially launched after a beta run, and continued to be refined.
You can follow my updates on SL technical developments and updates through the likes of my weekly SL project updates and weekly viewer release summaries (which also cover TPV releases).
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, December 24th
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.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change.
Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models
The following notes are primarily taken from the Content Creation User Group meeting, held on Thursday, December 21st, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.
Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. However, the first part of the meeting is absent the video, so I’ve included two audio extracts of salient points raised, taken from my own audio recording of the meeting. Where the video is referenced, time stamps to the specific point of the video are provided in the text – click on them to open the video in a separate browser tab at that point.
Animesh (Animated Mesh)
“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “Animesh”.
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.
In short, an Animesh object:
Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory (Contents tab of the Build floater) required for it to animate itself.
Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
Can use many existing animations.
However Animated objects will not (initially):
Have an avatar shape associated with them
Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
Use the avatar baking service
Will not support its own attachments in the initial release.
These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).
Animation Playback issues: as highlighted at the December 14th meeting, animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This had been considered a viewer issue, but could equally be a simulator / viewer race condition wherein the viewer is receiving animation information before it knows what to do with it (and so is ignoring it). Vir is still looking into this.
Object Selection issues: this isn’t just an Animesh issue per se. Historically, selecting multiple animated objects (or an avatar) so they are displayed as wire frames has been handled “extremely inefficiently”, impacting local frame rates. A fix is in hand for this, and will be in the next update of the Animesh project viewer.
Animesh Release ETA and Limits
There is still no indication of a release date for Animesh. Work still to be completed / carried out includes:
It is worth repeating (again) that the current limits of tri count, LI, and number of attachments are purely for the purposes of performance testing, they are not the “final” limits for Animesh, some of which will hopefully be somewhat more relaxed / reflective of server / viewer capabilities when scaling Animesh use within a region.
The initial tri count limit (again, set for testing purposes only) was increased from 20K to 50K with the current project viewer release (version 5.0.10.330058, at the time of writing). As noted in my week #50 update, this increase had been requested for some time – although it appeared to be wanted more for testing proposed Animesh products, rather than testing the basic Animesh capabilities. Zooby’s has since issued a video of one such new product, involving both a wearable cat avatar, and which is also intended to support the avatar being used as an in-world Animesh object, once Animesh is released.
Animesh Use Cases
The focus for Animesh among creators thus far has been for avatars (NPCs), and creatures, pets and things like mechanoids (both free-roaming and wearable). However, there is potential for Animesh to be used for landscaping as well: tree boughs / grass moving in the wind, water features, etc., and the Lab is interested in discovering how much appetite there is among creators to use Animesh in this way, particularly when it comes to profiling performance and limits.
Skeleton Use and Bone Naming Convention / Parenting
An extensive discussion on using the skeleton bones.
[0:00-10:36] When talking in terms of unique Animesh objects, the skeleton can be re-purposed to suit the need, and not all the bones need to be animated. So, for example, in a grouping of plants, the leg, arm, wing, and tail bones could be used to animate individual plants (in principle, individual finger bones could be used).
As with any use of the skeleton, the important aspects are preserving the recognised bone naming and parenting hierarchy (although it is possible to constrain bones / bone groups for specific uses within Blender, then map this back to the SL skeleton, but it requires care and attention with a thorough understanding of the SL avatar).
This is where Animesh is attachments such as hair is of an advantage over hair that simply uses with avatar’s own skeleton. With the latter, the available bones are limited without potentially impacting the ability to wear animated hair with a Bento head (although there are “spare” ear and eye bones which could potentially be used to create an animated ponytail or pigtails).
Using a separate range of bones in Animesh hair offers greater flexibility – but then the issue becomes keeping the animations in the Animesh hair in sync with the movements of the avatar wearing it.
“Dropping” Animesh / Mesh
[11:50-15:31] Worn mesh cannot be simply “dropped” in-world. It has to be detached to inventory and then rezzed in-world from there. This has been seen as limited with Animesh pets, etc., where ideally people might want to pick a pet up and carry it and then put it down again (drop it). Making it possible to drop mesh is seen by the Lab as “kind of a hassle to do”, but it’s not currently clear how big or small a hassle it might be, as it would involve additional land impact calculations, physics updates, etc., none of which were given support when mesh was introduced. Thus, it could require an extensive simulator-side overhaul.
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. The project is in two phases:
The current work to update the baking service to support 1024×1024 textures.
An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.
This work does not include normal or specular map support, as these are not part of the existing baking service.
Current Progress
Viewer work has paused while some back-end baking service issues are resolved.
Other Items
How the Lab looks at Features
One oft-phrased point-of-view is that the Lab “only” think about features being used in a certain way – and this has at times been voiced for Animesh. Speaking at the meeting, Oz Linden sought to dispel this idea, pointing to the diverse ways capabilities are frequently used in SL.
Mesh Uploader
[18:15-22:44] Cost calculation issues: discussion on mesh upload costs noted in the viewer. These have long been an issues, where costs can alter due to the same model being automatically decimated differently with each upload, etc. These are most likely the result of errors in the calculations framework, and they are something the Lab is aware of, and might be the result of the removal of the SLM file from the uploader, which caused problems of its own. Those who wish to test whether the cost calculation issue is reduced by using the SLM file can do so by setting the MeshImportUseSLM debug to True.
[23:32-24:22] Mesh object names: Vir reminded people due to a limitation with Collada .DAE files mesh objects for upload via the official viewer cannot currently have spaces in their names. However, the Lab will be adopting the Firestorm work-around for this by allowing the use of underscores in object file names.
Bone Offsets
[26:44-29:18] Bone offsets: Vir points to an issue he encountered with an avatar model using a 75m offset for the mPelvis bone which, every time the offset was calculated, would cause the object to vanish from his screen until Reset Skeleton was used. This prompted the question whether should bone offsets have a constraint of bone offsets – such as no more than 5 metres, as is the case when offsetting using animations.
SL Viewer
The Wolfpack RC viewer (containing no functional changes to the current release viewer) updated to version 5.0.10.330113 on Wednesday Novermber 20th, 2017.
Nalewka Maintenance RC updated to version 5.0.10.330123 on Thursday, December 21st, 2017.
These likely mark the last viewer updates for 2017, leaving the rest of the viewer pipeline as follows:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
There are no planned deployments for week #51. This will leave the grid running on server release 17#17.12.01.511131 (link to SLS summary page). However, given the RC channels have not been restarted in the last two weeks, there may be a rolling restart for all three RC channels on Wednesday, December 20th.
SL Viewer
The Nalewka Maintenance RC viewer updated to version 5.0.10.330111 on Tuesday, December 19th. This adds a further 11 fixes and updates to the viewer since the initial release of the viewer RC.
The Project Render Viewer updated to version 5.1.0.511446 on Monday, December 18.
The Alex Ivy 64-bit RC may also get an update during the week. However, at the moment the remainder of the SL viewer pipeline remains as per the end of week #50:
Current Release version 5.0.9.329906, dated November 17, promoted November 29th – formerly the “Martini” Maintenance RC – No Change
Release channel cohorts:
Alex Ivy 64-bit viewer, version 5.1.0.511248, December 11.
Voice RC viewer, version 5.0.10.330039, December 12.
Wolfpack viewer, version 5.1.0.3300001, November 30.
Inara Pey: Living in a Modemworld 