On Tuesday, October 17th, the Main (SLS) received the server maintenance package, 17#17.10.06.509394, previously deployed to the Magnum RC channel, comprising “internal fixes”
On Wednesday, October 18th, the RC channels should be updated with a new server maintenance package, #188.8.131.529701, also comprising internal fixes.
Neither of these updates should have user-visible changes.
The former Maintenance RC viewer, version 184.108.40.2069115, was promoted to de facto release status on Friday October 13th., and a new Maintenance RC viewer, version 220.127.116.119464 was released. SL viewer pipeline remains unchanged from week #41:
Wolfpack RC viewer,version 18.104.22.1689128, dated September 22 – this viewer is functionally identical to the release viewer, but includes additional back-end logging “to help catch some squirrelly issues”.
Alex Ivy 64-bit viewer, version 22.214.171.1248209, dated September 5.
Obsolete platform viewer version 126.96.36.1990847, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Pathfinding Bug (?)
Pathfinding hasn’t been particularly successful since its introduction. However, with work progressing on animated mesh (Animesh – see my Content Creation User Group updates), there has been renewed interest in using Pathfinding alongside of Animesh. However, it has recently been noted that any call to llCreateCharacter on a Full region causes 8-12% performance loss (Homestead regions do not appear to be affected), regardless of whether the region is actively using Pathfinding or not, and / or whatever else is in the script – see BUG-41385.
This appears to be a recent issue, but it is not clear how widespread it might be, as the issue has thus far only been reported in one estate. However, when it does occur, one character in a region seems to be enough to cause the hit, additional characters don’t cause any significant increase in the loss of performance.
Commenting on the issue at the Simulator User Group, Simon Linden said:
Pathfinding is a big chunk of complex code (that we didn’t write) so I’m sure there’s some significant change between having nothing to do and processing one character. I’ve spent a few days looking into this … Believe me, I’d like to fix it … I’ve tried and couldn’t fix it so far.
On Friday, October 13th, the Lab promoted their “Moonshine” release viewer, version 188.8.131.529115 to de facto release status. This viewer brings some new options to the official viewer, as well as including a range of improvements and bug fixes.
The code name for the viewer is described thus: “Moonshine was originally a slang term used to describe high-proof distilled spirits usually produced illicitly, without government authorisation. In recent years, however, moonshine has been legalized in various countries and has become a term of art. Legal in the United States since 2010, moonshine is defined as ‘clear, unaged whiskey’. This deploy is filled with a jigger of crash fixes, a splash of translation fixes and a kick that will make you say ‘I can’t feel my face any more!'”
In terms of the updates, probably the most visible is the new Worn tab within the Inventory floater. Those who have used third-party viewers like Firestorm will be familiar with this: it presents a list of items your avatar is currently wearing, defined by the folders in which the items are located.
In addition, the scroll zone associated with the inventory floater (and the Marketplace floater) has been improved, and the inventory filter options (My Inventory > Gear menu > Show filters) have two new options:
Created by me, Created by others
Search by Name, Description, Creator, UUID.
The viewer includes the ability to increase the cache size to up to 9.75 GB in size, and cache performance has been improved. This work is all part of on-going viewer infrastructure work, which with this viewer includes changes to reduce the rate at which log-in retries are attempted.
As I’ve reported in my weekly SL project updates, the rate at which these login retries were being carried out could cause a detrimental impact on services when the grid was experiencing issues; it is an update TPVs have been asked to adopt as soon as they can.
Also included in this release as a part of the infrastructure updates is a general clean-up of the log-in code.
In addition to the above, the viewer includes a range of UI behaviour improvements and bug fixes, all of which are listed in the release notes.
I’ve not had the opportunity to use this viewer extensively, but performance-wise and in terms of the length of time I have been using it, the performance easily matches previous releases when running on my main system. In terms of the updates, the increased cache size could prove beneficial to those able to take advantage of it, and who use either an SSD or who can make use of a RAM drive on their system.
Overall, another useful viewer update from the Lab, with a good range of resolved issues and fixed bugs.
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 184.108.40.2069115, dated September 22nd, promoted October 13th – formerly the “Moonshine” Maintenance RC – NEW
The following notes are taken from the Content Creation User Group meeting, held on Thursday, October 12th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. 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 steamed the meeting to You Tube, and his video is embedded at the end of this article, with key points of discussion noted below. Time stamps to the recording are included below, and clicking on any of them will launch the video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.
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”.
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.
Animated objects can be any 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.
It can be an individual object, or a linkset of rigged mesh (e.g. avatar body with linked worn clothing).
A new flag will be added to the viewer, which allows in-world static rigged mesh objects to be converted to Animesh objects (and have an avatar skeleton associated with it).
At this point in time, this is not about adding fully functional, avatar-like non-player characters (NPCs) to Second Life. So Animesh 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
The project may be extended in the future.
It should be possible to use many existing animations with Animesh objects.
It will involve both back-end and viewer-side changes, likely to encompass new LSL commands to trigger and stop animations (held in the object’s contents).
[1:11-3:40] We are now “very close” to seeing a project viewer, test content and test regions appearing. The viewer has been passed by LL’s QA team, the initial test content is being developed (and will be added to, although people can obviously also test their own content) and a total of five regions will be set-up on Aditi (the beta grid) for the purposes of test very soon. Four of these will be arranged in square and be rated Moderate (allowing for comprehensive content testing, including how Animesh is managed on region crossings), the fifth will be separate and rated Adult.
The main hold-up for now is documentation: release notes, wiki documentation, FAQ, etc. When all is ready, there will be a blog post on the project, and the viewer itself will be appearing on the Alternate Viewer wiki page – so those interested in testing Animesh should keep their eyes on both the official blogs and the viewer wiki page.
[4:20-7:20] The most recent work with Animesh has remained focused on aligning the root joint of a skeleton associated with an Animesh to the position of the Animesh object in-world. The problem here is that the skeleton / avatars in SL are oriented along the X-axis; however, some tools (Avastar?) align along the Y-axis.
This means that when applying skeleton (X-axis orientation) with an in-world mesh objects with a Y-axis orientation to make it Animesh, the latter can jump and rotate. Vir had been looking to make changes in the skeleton’s orientation to handle mesh with a Y-axis orientation this. However, it turns out doing so could cause unwanted behavioural changes for scripts handling attachment rotation and positioning. To avoid this, the skeleton orientation will remaining X-axis oriented. Vir hopes that the upcoming testing will allow the settings for linking skeleton to mesh can be further refined to make the conversion from static mesh to Animesh as smooth as possible.
Animesh and Vehicles / Testing vs Release
[9:20-13:20] A view is expressed that Animesh is being “rushed” without sufficient thought being given to its application in vehicle design. This in part perhaps stems from confusion about public testing of Animesh and a release in Animesh. For example, while Bento had an initial “closed” period of develop to lay the ground work, it was followed by a broad and lengthy public period of testing, consultation and enhancement.
As such, the arrival of the project viewer doesn’t mark a move towards “releasing” Animesh – but rather allows more widespread testing of the capability, including its potential use in vehicles and elsewhere. Testing is the point at which the Lab can more fully look to creators for feedback, requests for improvement – and even fleshed-out feature requests etc., which might be considered for folding-in to the current work or for follow-on work once the initial Animesh release has been made.
[15:54-16:29] Overall land impact constraints of Animesh are still TBD (testing will help determine what might be required). However, Vir points out that in terms of individual LI applied to Animesh objects it will initially be focused on a per skeleton basis, not on a per mesh basis (so a linkset of several rigged meshes converted to Animesh will be seen as single object with an LI, not a group of mesh objects, each with an LI).
[37:35-38:34] Couldn’t the Animesh constraint be purely land impact based? possibly, but then attachments would be excluded – as they are with avatars, and the most costly element in terms of performance are avatars; by only using LI as a constraint, then Animesh could become as impactful as avatars with multiple high render cost attachments.
[16:46-17:18] Is Animesh prim objects with an AO? No. Animesh is rigged mesh objects containing scripted animations within them, associated with an avatar skeleton.
[17:22-17:57] If an Animesh has linked skeletons, do animations play across all of them? No – Animesh does not involve linking skeletons. It can comprise multiple rigged mesh objects which are linked to an individual skeleton, which can have animations applied to it.
[18:09-18:30] will the attached mesh also count against the tri count? Yes. There will be a limit, most likely set to 20K when testing starts, but subject to review as testing proceeds.
[26:02-27:35] Short description of how Animesh will work, as covered in some of the bullet points in the project description, above. Includes some discussion of using Animesh with pathfinding.
[30:00-30:35] Is animation movement capped (in terms of moving an individual bone): yes, it is capped at 5 metres, as it always has been for avatars.
[30:41-32:55] Physical properties discussion: Animesh objects will operate like avatars: they well not have physical collisions as a result of animation (e.g. a moving arm on an Animesh will not collide with a passing avatar, for example). However, Animesh objects will have physical properties (based on mesh physics shape), and so can fall, etc.
[47:35-48:08] Will Animesh alter the land impact for existing objects in-world? No. Animesh is a new object property, only applicable to objects intentionally set as Animesh. As such, it will not affect pre-existing content in-world unless said content is converted to Animesh (if it can be).
[48:48-49:58] Will Animesh behave at altitude? There is an issue which sees mesh rigged with software skinning deforms at altitude (starting around 1,000m and getting worse from there). Animesh might suffer the same, but it hasn’t been tested.
[52:47-56:10] The eyes have it – a discussion on automating eye movements on Animesh in a similar manner to avatars. Vir see this more as building-out the NPC-style capabilities with Animesh, which is very much a follow-up to the current project.
[58:18-59:20] Can Animesh work with other mesh? It should; the complex part is liable to be keeping the object’s actual position in sync with its rendered position based on the animations playing, particularly as there won’t be a “sit” equivalent. Vir hopes this is something that will be poked at in testing.
Side notes on Animesh Constraints:
[44:08-45:21] As Vir has previously indicated, all of the constraints in the viewer – when it appears – are for testing purposes, and to provide a means by which things can be tested. For a catch-up on constraints and testing, please refer to my previous CCUG update.
[20:21-20:45] Also, to help with constraints and information, Vir has been updating the viewer’s avatar complexity panel to provide information on triangles, which will also work for Animesh objects.
[22:45-29:08] A feature request has also been submitted for an alternative method of handling land impact and incorporating Animesh – see BUG-139203. This has been left open for comment. However, it is something the Lab is interested in taking a look at.