SL project updates 42/1: server, viewer

Tavana Island; Inara Pey, October 2017, on FlickrTavana Islandblog post

Server Deployments for Week #42

As always, please refer to the server release thread for updates and the latest news.

  • On Tuesday, October 17th, the Main (SLS) received the server maintenance package,  17#, 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, #, also comprising internal fixes.

Neither of these updates should have user-visible changes.

SL Viewer

The former Maintenance RC viewer, version, was promoted to de facto release status on Friday October 13th., and a new Maintenance RC viewer, version was released. SL viewer pipeline remains unchanged from week #41:

  • Release channel cohorts:
    • Voice RC viewer, version, dated September 1.
    • Wolfpack RC viewer,version, 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, dated September 5.
  • Project viewers:
  • Obsolete platform viewer version, 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.



SL project updates 41/2: Content Creation User Group

People gather for the Content Creation User Group meeting, October 12th, 2017

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”.

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.

  • 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).

Viewer Progress

[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.

Root Positioning

[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.

Quick Questions

  • Land Impact:
    • [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.

Continue reading “SL project updates 41/2: Content Creation User Group”

SL project updates 41/1: server, viewer

Oh Deer, Heavenly Waters; Inara Pey, October 2017, on FlickrOh Deerblog post

Server Deployments for Week #41

As always, please refer to the server release thread for updates and the latest news.

  • On Tuesday, October 10th, the Main (SLS) received the server maintenance package previously deployed to the RC channels.  17#, intended to address the unintended returns issue of two weeks ago – see The Return of the Living Objects: A Pre-Halloween Horror Story for more.
  • On Wednesday, October 11th, the RC channels should be updated as follows:
    • BlueSteel and LeTigre should be updated with a new server maintenance package, 17#, containing internal fixes
    • Magnum should also receive a new server maintenance package, 17#, also containing internal fixes.

Neither of the RC updates should have user-visible changes.

SL Viewer

There have been no viewer updates thus far this week, leaving the pipelines as follows:

  • Current Release version, dated August 9th, promoted August 23rd – formerly the Maintenance RC
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Voice RC viewer, version, dated September 29.
    • Maintenance RC viewer, version, dated September 22nd.
    • Wolfpack RC viewer,version, dated September 22nd – 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, dated September 1st
  • Project viewers:
  • Obsolete platform viewer version, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Touch, Camming, Experiences, Avatars and Feedback

Note: the following is not indicative that the Lab is considering behavioural changes in Second Life at this time. The topics were simply raised with a view to generating discussion and feedback.

There are a lot of things  we can do in a region which might not always be in the spirit of what is intended by the region owner, particularly if the region is designed for a specific purpose, such as an experience or game. We can, for example, cam ahead, seek out secrets, identify traps or hazards and find ways to avoid them. We can also reach across a region to touch things when perhaps it would be better if we could only do so up close.

There are various ways to limit some of this – scripts can be used to limit touch, as can RLV, for example. But for things like experiences and games, it might be better if the region owner had the option to perhaps enforce limits on how far away from their avatars people can cam or touch.

However, this has to be balanced against those situations where camera and “long-distance” touch can be essential. Shopping at a crowded event, for example can be made much less of a fight against crowds and lag by using Area Search, the camera, and far touch to obtain specific items (even flycamming and far touch can make shopping a lot easier in any situation). Ergo, there’s a risk that imposing limits on either could have a more detrimental effect on people’s willingness to shop in popular locations.

Given that crowds themselves are a problem, would it be worthwhile limiting the number of avatars seen within a region in some way? Perhaps a limit set through the estate controls, or by some method within the viewer such that avatars / imposters beyond a certain radius aren’t rendered / have updates ignored by the Interest List until they come within the specified distance – just like people can move in and out of view in a real crowd.

Again, how something like this might work – should it really be a control at estate level, or would it be better as an option users could tweak (which would get my vote) – would have to be thought through in detail. Particularly given we already do have some control over the rendering, at least, of the avatars around us through various methods (e.g. render friends only, derender selected avatars, CTRL-ALT-SHIFT-4, avatar rendering, etc.); while although each of them might not be perfect, they can give flexibility of control to individual users.

As noted, the Lab aren’t planning any changes specific to any of the above  – but by throwing questions out and listening to feedback, concerns, alternative ideas, they are perhaps pulling ideas and thoughts into the melting pot on how SL might be refined and offer better controls and means to improve people’s individual and joint experiences.

SL project updates 40/2: TPVD Meeting; e-mail verification

Mitsumi-Town in Tokyo; Inara Pey, September 2017, on FlickrMitsumi-Town in Tokyoblog post

The majority of these notes are taken from the TPV Developer meeting held on Friday, October 6th 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. time stamps in the text below will open the video in a separate tab for ease for reference to the relevant points of discussion in the meeting.

The meeting was chaired by Rider Linden, who was filling in for Oz, and was somewhat foreshortened.

SL Viewer

There were no updates to the current crop of official viewers during the week, leaving the pipeline as:

  • Current Release version, dated August 9th, promoted August 23rd – formerly the Maintenance RC
  • Release channel cohorts:
    • Voice RC viewer, version on Friday, September 29th
    • Maintenance RC viewer, version, dated September 22nd.
    • Wolfpack RC viewer,version, dated September 22nd – 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, dated September 1st
  • Project viewers:
  • Obsolete platform viewer version, dated May 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Quick notes:

  • [4:35-4:52] Work is continuing to fix the texture crashes in the 64-bit Alex Ivy RC.
  • [5:25-5:40] There is a reference to Voice changes, however, the question is non-specific, and it is unclear if it refers to the current Voice RC (updated at the end of week #39) or to further updates, the question is deferred to Oz (who is directly involved in the Voice project).

E-mail Verification

[2:56-4:00] As noted in part 1 of this week’s report, the Main channel deployment saw an update to IMs-to-e-mail as part of the Lab’s move to only handling verified e-mail addresses.

The sending / forwarding of messages to unverified addresses is not blocked – as yet. However, once a viewer-side changed has been deployed, accounts with unverified emails will no longer be able to request that IMs be forwarded to e-mail; attempts to enable the viewer-side setting will fail, and result in a message advising the account holder to verify their e-mail address.

Potential Interest List Change

[15:52-18:40] (with a lengthy silence)] There is a potential simhost change to the Interest List under discussion at the Lab. This will in essence reduce some of the aggressive culling of updates from objects behind an avatar (particularly useful in the case of light sources, moving objects, etc). If it goes ahead, this update could also benefit the 360-snapshot viewer.

Other Items


Estate Tools Update

[6:07-10:40 (ish) and 13:10-14:20] There is a lengthy on-off exchange, in Voice and text (with some long pauses in both) regarding the Estate Tools updates in the viewer. In short: updates to the estate ban lists (see BUG-8883 and BUG-40676 as examples of requested changes), have resumed. however, as Alexa Linden, who is running this project, was unavailable for the meeting, no detailed update was possible.

Viewer Build Issue

[10:50-12:00] There is “progress” in fixing an incorrect viewer build update involving a change to the Cmake files which results in a forced rebuild of the Windows version of the viewer (the “-z0” issue).

In-world Posing

[20:48-end of meeting] NiranV Dean has been experimenting with a means of in-world posing an avatar through the viewer (e.g. for things like photography), which would be visible to the person posing their avatar (as it would require server-side support to be visible in all viewers). There may be interest from the Lab in accepting as a proposal / contribution, if the details of what is required can be agreed between the Lab and Niran.

There were concerns among those attending the meeting (and raised largely in text) on what Niran is trying to achieve and how it might related to content ripping. If nothing else, the conversation underlines the need for a clearly thought-out proposal outlining the idea, its purpose, how it might be implemented, potential issues which will need to be considered and addressed, etc., rather than requesting people “try” the idea and give feedback.

Date of Next Meeting

The next Third-Party Viewer Developer meeting will not be until Friday, November 3rd, 2017.