Category: SL User Group Meetings

SL project news: week 44/4: server and viewer news

Posted on by Inara Pey

Quick Links

Server Deployments, Week 44

There was some confusion on the server channel deployments this week. As reported earlier this week, roll-outs were put back by a day due to issues within LL. This meant that the main channel deployment did not occur until Wednesday 31st October, and the RC channels on Thursday 1st November.

There was further confusion as the main channel had been scheduled to receive the code which had been on BlueSteel and Magnum, but it instead received code which had been on BlueSteel some two weeks ago, and caused some confusion on the Server Deployment forum discussion for the week.

Other than being 24 hours late, the RC releases were more-or-less as planned and previously documented:

  • BlueSteel received the Havok updates deployed to LeTigre, complete with the lHTTPRequest header “fix”
  • Magnum has the Group Services code from Baker Linden for handling the editing and managing of large in-world group lists. The code includes some fixes to problems found in the Snack RC deployment of the Group Services code (again, see part 2 of this report)
  • LeTigre received further updates for the Havok deployment, etc.

In addition, Magnum received a fix for the Estate Tools debug capability to disable collisions. When enabled, the option freezes all physical objects in a region in place and prevents avatars colliding with objects. As such, it is primarily a useful tool when trying to sort-out performance issues or locate and remove unwanted objects (although in the latter case, any TPV with Area Search included can achieve the same result. The option has been broken for some time, and the code deployed to Magnum should fix it.

Also on Magnum, Qie Niangao reported issues which may – or may not – be linked to previously encountered problems with llsensor(). However, it is not clear as to how widespread this might be.

Deployments for Week 45

As they currently stand, the plans for Week 45 (commencing Monday 5th November) are:

  • Tuesday 6th: the Main Channel should get the code currently running on Bluesteel and LeTigre  – so this will be the Havok updates, etc
  • Wedneday 7th:
    • Magnum should get fixes and updates to the code currently running there (including the Group Services code)
    • LeTigre and Bluesteel should get the next bug fix server in the pipeline, which includes the code currently on Magnum, and more.
  • Further details will be available as the release notes are issued

Threaded Region Crossings

This has been a project which has been going on for some time now, with Lindens working on it quietly in the background. As it hasn’t been openly mentioned in User Groups for some time, it had led some commentators to believe the project was no longer being worked on. However, as I’ve commented in these pages (and more recently quoted Baker Linden as commenting on it), the work has been progressing, and may now be nearing the time when it will see greater light of day. As a part of this, it looks like there might be a call for volunteers to participate in a “pile-on” test in the near future, specifically to test whether the new code is easing region crossing issues and generally leading to an improvement.

Avatar Baking

Avatar bake fail

Questions about server-side baking are a common occurrence at OpenDev and TPV meetings.

Currently (and as all too often indicated in these reports!) work is progressing on both sides of the equation within LL, but there is currently little of major impact to report. The emphasis has been on the viewer code (which will be used as the basis for the new Texture Compositing server the Lab will be implementing.

However, it remains that are still  no ETAs on the availability of either the viewer code or the server. The plan, however, remains that TPVs should receive around 2 months notice as to the availability of code for merging into test viewers. Given this, it remains highly unlikely that there will be visible progress with the project before the start of 2013.

Please use the page numbers below to continue reading

Pages: 1 2

SL Project news week 44/3: mesh deformer

Posted on by Inara Pey

Testing is continuing with the latest release of the Mesh Deformer project viewer, which can be used to deform mesh items to either default or custom human shapes. While the pool of test items remains small, people appear to be testing using their own creations, with at least some feedback being given to the JIRA (STORM-1716), which remains open to comment. If you are testing the deformer using the latest project viewer, please be sure to provide feedback on your results – be they with default shapes or custom shapes – to the JIRA.

Some problems with breast fittings might be down to an incompatibility between Avastar and the viewer, which is currently being corrected

Most of the results obtained to date appear to be satisfactory, although some issues still remain with custom shapes. Darien Caldwell, working with Gaia Clary, has identified one issue which exists specifically with the Avastar add-in for Blender co-produced by Gaia.

Avastar is a Blender add-on for Second Life mesh creators and animators which provides a wide range of capabilities, including (for mesh creation): SL shape import into Blender, SL shape sliders support, support for attachment bones, and so on.

The issue has been that Avastar’s sliders have been based on a scale of 1-100, whereas the viewer’s sliders operate on a scale of 0-100 , leading to some scale miscalculations within Avastar which in turn have led to issues with mesh fitting over body parts such as breasts. According to Darien Caldwell, she and Gaia now have this “pretty well nailed” and an update to correct Avastar will apparently be out shortly (Update: please see Magus Freston’s comments at the end of this article).

This still leaves the broader deformation issue, as reported recently, which is still being looked into, and awaiting some feedback from Qarl.

Other issues outside of these which have arisen with the deformer have been largely the result of unrealistic expectations – that it will, for example, mimic facial morphs or hand movements closely or some changes to feet. However, in these situations, it is important to remember that the deformer was never developed to deal with these, as it works off the avatar’s bone structure, and facial features and hands don not have any bone structure within the avatar associated with them.

Time Frame for the Deformer

While progress with the deformer continues to look good, there remains no ETA as to when the code will appear in the release version of the official SL viewer.

The major reason for this is the ongoing problems with the Beta release channel for the viewer (of which more in the next update for this week!). As it stands, the deformer is positioned roughly at the back of the queue of releases which are being held as LL work to resolve the current crash issues with the Beta viewer. This means that, at least until the Beta issues are resolved, there is no official ETA for the deformer code reaching the release viewer. However, the latest revisions are starting to be incorporated into some TPVs.

In the meantime, and if you have been testing the project viewer, please remember to give feedback via the JIRA.

Performance Concern

While it is not actually an issue with the deformer per se, commenting at the Content Creation User Group on Monday 29th October, Siana Gearz highlighted a potential problem with mesh clothing utilising the deformer and avatar physics.

The concern is that the deformer uses the same morph-based schema as is used by the avatar physics system. This means that the GPU has to do a lot of additional calculations for the polygons in an item of mesh clothing to simulate movement (such as “bouncing boobs”) when avatar physics are in use. This obviously leads to a performance hit. So long as the polygon count in clothing is kept low, the impact is minimal, but the concern is that clothing build using high polygon counts to provide detail could have a larger impact on the viewer.

One possible way for this to be avoided, should it become an issue, is for clothing makers to optimise their mesh clothing with lower poly counts – and the forthcoming materials processing capabilities should go a long way towards helping with this.

Related Links

SL projects news week 44/2: server, group services, mesh and more

Posted on by Inara Pey

Quick Links

Server Updates

Deployments this week are being delayed some 24 hours, which means the main channel deployment will not take place until Wednesday 31st October, and the RX channels on Thursday November 1st. This has led to concerns that the main channel deployment / restarts may impact any Halloween events taking place across the grid on Wednesday 31st. Simon Linden promised to raise the concerns at an internal LL meeting taking place later on the 30th October, however, at the time of writing, the Grid Status page reports that the deployment will go ahead, starting at 05:00 SLT on the 31st.

In the meantime, the deployments for the week remain largely as previously indicated:

  • The main channel should receive the code currently on BlueSteel and Magnum. As mentioned above, the code has no externally visible changes but has some system level adjustments – release notes
  • LeTigre will receive a further update for the code currently running on it, which will include a number of bug fixes and pathfinding updates – release notes
  • On Friday 26th October, Simon Linden indicated to me that Magnum should be receiving the code planned for week 43 (the llSensor() problem has been fixed) which will include Baker Linden’s Group Services code currently on Snack, however, as of the Simulator User Group meeting on the 30th October, the final release notes for Magnum had yet to be published, so the update may still be in a state of flux
  • BlueSteel should get the same code as is on LeTigre.

Interest List

Andrew Linden has fixed a bug wherein some child prims in linkset fail to rez and he has carried out further work on performance issue he reported last time. This turned out to be an issue with the code which caused the simulator to send a full update of everything within view to the viewer each time an avatar within visual range moved. Understandably, on  crowded regions, this led to performance issues.

The code is in the process of being revised to ensure it only calls for “terse” updates to be sent to the viewer, which will help ensure more relevant information is sent to viewers when updating, which should reduce the performance hits.

Group Services

Baker Linden, speaking at the Simulator User Group on Tuesday 29th October, said that the server-side code for this project, which should improve the load times and editing abilities for very large group lists, seems to be working “moderately well” since the deployment to the Snack RC channel last week. However, some bugs have been found, Commenting on these, Baker explained that, “The group name, description, and other things don’t load right now on the Snack RCs.” However, the bugs have been investigated and fixes found, which should be merged into the code ahead of the planned deployments on Thursday November 1st. The fixes have also been tested on Aditi, where they’ve been found to induce a slight lag on group loading.

For the time being, testing this now code continues to require a dedicated SL project viewer (available for Windows, Mac and Linux), until such time as issues with the SL beta viewer code can be fixed and merges with viewer project code resumed / made available to TPV for integration.

Avatar Baking

Work is still progressing, Nyx Linden confirmed, talking at the content Creation User Group on Monday 28th October. How far down the road the work is, is unclear. The server-side of things will apparently be using the code being developed for the viewer, and it is this which is the focus of attention for the present, as has been the case for some time.In talking to TPV developers on the subject the last time the matter came up, Oz Linden confirmed LL’s plan is still to give TPVs “at least” 2 months (eight weeks) notice prior to anything being rolled out for testing, in order to give TPVs sufficient time to incorporate the code into project viewers of their own and assist with the overall testing.

SL Issues

Mesh Alpha Issue

Theresa Tennyson demonstrates the skinned mesh / alpha issue

Also during the Content Creation meeting, a problem with alpha textures as applied to worn skinned meshes was brought up. Theresa Tennyson demonstrated the issue during the meeting, which somewhat resembles the old invisiprim  / alpha issue.

Siana Gearz suggested two possible causes for the issue, “[The] first is that rigged mesh transparent surfaces appear to be drawn before prim transparent surfaces. [The] second issue is that the shader apparently writes depth for whole fragment, not just for relatively in transparent pixels.”

Nyx Linden requested a JIRA item be raised for the issue, again highlighting the problem with the recent JIRA changes, in that outside of those with access privileges to the new system, no-one could actually confirm if a JIRA had already been raised.

ETA 31st October: Seems a public JIRA on the matter is available – see MartinRJ’s comments which follow this article. Many thanks, Martin!

With thanks to Theresa Tennyson for the Simulator UG meeting transcript

SL project news week 44/1: viewer updates

Posted on by Inara Pey

A quick start-of-week update on the status of releases with the offical SL viewer. News on specific projects (Mesh, deformer, interest lists, etc.) to follow in the week.

Beta and Development Viewers

The beta viewer situation remains in review, with the latest release – 3.4.1.266251, released on the 24th October – still available for download. Crash rates remain the major issue to unblocking matters and getting things moving again.

In the meantime, an updated development viewer (3.4.1.266120) was released on the 25th October, but otherwise things remain largely unchanged, and as stated above, project related viewer releases remain blocked. Expect further updates to be reported later in the week.

FMOD

The aim remains for LL to use FMODex within viewer builds following FMOD’s decision to discontinue making core FMOD libraries available for builds see JIRA OPEN-150). However, the issue is not currently a priority within LL due to other matters (such as resolving beta viewer crashes and unblocking the release pipe).

OpenAL has again be suggested as an alternative to FMODex; however, commenting on this, Oz Linden again repeated that, “I don’t think it very likely that we’re going to use OpenAL.” In the meantime FMODex is in use within the Singularity viewer, and that code has recently been ported into Firestorm, where it is currently being worked on.

CHUI

The Communications Hub User Interface project viewer launched last week. As I reported at the time, this is an attempt by LL to re-centralise communications within the viewer, and has both good and bad points to it.

The fully expanded Conversations floater in the CHUI project viewer

As might be expected with an initial pass of a project viewer, CHUI has generated extensive feedback from testers as to issues and problems both large and small. These very much reflect the fact that CHUI is still in its nascent stages, and that further work will be going into it to both iron-out bugs and improve performance / capabilities. A survey on the project viewer is due to be made available this week, whether this goes ahead based on the level of feedback currently being generated through the JIRA (which has been reasonably high from those testing the new functionality almost feature by feature), remains to be seen.

SL project news: week 43/4: server updates

Posted on by Inara Pey

Week 43 Deployments

Main Channel

Tuesday October 23rd saw an update to the main channel which should have minimal impact on things, the changes having previously been on the Magnum RC channel. LL have been monitoring the deployment and have seen no adverse impacts.

BlueSteel RC

The BlueSteel RC channel received a further update to the current server maintenance project aimed at general stability improvement.

LeTigre

LeTigre is currently the focus of the server modernisation project, and as such received further updates to the deployment of Havok 2012.1. This means that mesh vehicles will continue to be unable to cross from LeTigre into regions running on other server channels for the time being.

As previously reported in part one of this week’s project news, LeTigre contains an updated cURL library which may cause problems for services using an external website for frequent data updates. The issue affects llHTTPRequest.

Essentially, the problem is that until now, the cURL library used by LL uses an explicit call to ensure data being returned from an external web service (such as information relating to the health status of breedable animals) is “fresh” data, rather than anything which may have been cached along the way. As such, specific functionality hasn’t previously been required within LSL to ensure this is the case.

However, The new cURL library deployed to LeTigre no longer attached the explicit call (technically a Pragma: no-cache header) to outgoing requests. This means that information being returned as a result of a call to an external service may in fact come from data cached along the way (such as from an intermediary server). Obviously, receiving “old” data would not be good for things like breedables, which could end up dying.

To overcome this, LL have added a new flag to the llHTTPRequest function to achieve the same result as used to be achieved via the old cURL library attaching the Pragma no cache “request”. In the meantime, anyone with breedables or other services which rely upon frequently updated data from an external web service have been advised to test their products on LeTigre.

Magnum RC

The Magnum RC channel was to have received a series of bug fixes, together with Baker Linden’s code for large Group Services. However, a showstopper issue was discovered with llSensor(). As a result, the release was rolled back and replaced with the BlueSteel deployment.

Also to have been included with this release is a new capability allowing the simulator to report information about script permissions granted to objects within a region. This capability requires an update to the viewer in order to be used (the code for which is currently held-up due to the beta viewer issues). Once the viewer code has been released, the new capability will allow users to list all items in a region to which they’ve granted permissions (such as items which have been granted animate permissions) and, if required, revoke them.

Please use the page numbers below to continue reading this article

Pages: 1 2

SL project news week 43/3: viewer status updates

Posted on by Inara Pey

SL Beta Viewer

A new Beta version of the beta viewer was release on the 24/25th, (3.4.1.266251), which has more-or-less the same visible changes as the previous release, except that tcmalloc has been re-enabled as LL seek to determine whether stability issues have been improved or not. However, given the high crash rates experienced with the previous release, Oz Linden is requesting people take time out to give the beta a run. Speaking at the OpenDev meeting on Thursday 25th October, he said, “Run the beta viewer a lot. We think this one will be good, but it takes a lot of usage to find that out and things won’t get unstuck until we do.”

Tcmalloc has been re-enabled with the latest beta release, and this probably means that those using cloud storage such as Microsoft Skydrive and others (such as Cloud Drive – see FIRE-7520 – are liable to encounter issues using it.

The intent at LL still appears to be the complete disabling of Tcmalloc from the viewer code, however, the attempts to do so to date have only met with partial success – the “fix” for MS Skydrive, for example, apparently only worked for some instances, not all.

Commenting on the situation at the OpenDev meeting, Oz said that efforts to completely disable tcmalloc are “taking too long”. As a result, and to prevent work with tcmalloc from adversely affecting attempts to stabilise the viewer, the decision has been taken to move the work on tcmalloc to a separate branch of the viewer code for the time being, with efforts on the beta branch focusing on stability.

In the meantime, code releases remain blocked, pending confirmation the beta release has improved on previous crash rates (which were around 14%).

Mesh Deformer Viewer

As reported in part 2 of this week’s project news, a new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. In addition, Darien Caldwell has made updates to the SL wiki page on the avatar shape XML format which are related to the project.

The updated shape selection options for mesh clothing and human shapes in the mesh upload floater, as seen in the latest version of the Mesh Deformer project viewer

The current thinking is at present that the latest version of the viewer requires wider testing, so if you are involved in mesh clothing / shape creation (humanoid shapes, remember), then you might want to download the viewer and try it yourself. Commenting on the JIRA (STORM-1716), Darien notes:

If people could provide feedback on the use of the custom base shape part specifically, that would be great.

Keep in mind the potential bone length problems outlined above: do these affect your creations negatively when used with custom base shapes?

And is the potential workaround of setting bone lengths to the defaults a problem for your workflow?

Those and any other issues, please post. Thanks 

Initial feedback from those who have tried the viewer have been largely positive, although the issue with custom shapes and certain sliders, as previously reported in these pages (and on the JIRA) remain. Darien has been looking a little deeper into the latter issue, which affects a total of eleven shape sliders, and seems to have found the potential cause:

“The bone length deformation seems to be performed in the function LLRiggedVolume::update(). The deformer is doing its processing before this is reached, and when creating the custom base shape, it’s never run on that custom base shape. So the bone length deformations aren’t included.”

Instead, the current  deformer code assumes that all joints in a shape have the same scale, and that the scale is uniform in all axes. This is fine for a standard shape, but doesn’t work so well with custom shape forms, and wouldn’t work were scaled bones within avatar shapes ever to come about. The solution for this issue is unclear; the current plan is for Darien to write-up her findings for LL, so that someone there can look into the code as well.

The problem: bone length deformation is performed outside of the deformer code, which in turn appears to assume that all shapes use the same, uniform scale for joints. When working with a default shape, neither of these issues present themselves in obvious ways. When working with custom shapes, however, the problems become very evident. In this image a tall, then shape is use to generate an upper body mesh (flesh toned). When uploaded and applied to the shape itself (shown in black), the discrepancies become clear. Had the mesh been correctly deformed according to the shape data, it should more closely match the original shape

Group Services Project Viewer

Baker Linden’s server-side Group Services code for handling very large in-world groups was rolled out to four regions on the main grid on the 25th October, as reported here. However, due to the issues with the beta viewer code as reported above, testing of the new code requires the Group Service project viewer. If you do manage any group(s) with more than 10K members, you may wish to download the project viewer and give things a test on the nominated regions (see link above).

The viewer is available in Windows, Linux and Mac flavours.

Related Links