SL projects week 46/1: server, projects and general news

Server Deployments – Week 46

Deployments for the week are progressing as planned.

Main Channel

The main channel received the code which had been running on the Magnum RC channel as well as some updates.

This now means that the server-side Group Services code to improve the loading and editing of very large groups (10K+ members) is active right across the main grid – see the section on Group Services below for further information.

This roll-out restored functionality within the Estate Tools which allows region physics to be put in a condition of limited functionality, which is sometimes useful in dealing with issues and problems within a region. The capability was disabled around the time of the mesh roll-out, and has now been restored with this release. This caused some minor inconvenience on some regions (at least one), where the option has been enabled at some point, with the result that following their restart, objects within the region(s) were not functioning correctly. However, this was corrected without major incident.

Main channel release notes.

Release Candidates

Wednesday 13th November will see all three Release Candidate channel receive the same update package, including the BUG-166 update, which means that linksets with bounding boxes larger than 64m (in any dimension) are prevented from being rezzed if doing so will cause the object to collide with an avatar excluding the object owner.

Release notes:  Magnum, BlueSteel, LeTirgre.

Week 47 Deployments and Christmas Run-up

There will be no server roll-outs in week 47 (week commencing Monday 19th November) due to the forthcoming Thanksgiving weekend in the United States. There will be deployments between Thanksgiving and Christmas, but it currently looks as if these may be limited to a couple of weeks during that period according to Simon Linden (details on the likely number pending), and there will as usual be no releases over the Christmas / New Year period.

Interest List and Object Caching

Andrew Linden reports that the first phase of this work is drawing to a conclusion, and he is planning on having a possible demonstration of the capability on the beta (Aditi) grid on Thursday 15th November, most likely during the Bet Server User Group meeting.

The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.

Interest lists and object rezzing: initial srver code updates almost ready

Andrew reports that general performance on object rezzing should be improved, although the overall sorting element of the code (ensuring objects closer to an avatar’s camera position rez sooner than those further away) isn’t currently as rigorous as it could be. However, the server and viewer do now interact better, so less information is sent to the viewer relating to in-world items which are not visible within the current camera view for the viewer.

Commenting on demonstrating the capability when speaking at the Simulator User Group meeting on Tuesday 13th November, Andrew acknowledged that it may be difficult to achieve on Aditi, which is a relatively static environment (improvements will hopefully be more noticeable on regions where there is a lot of movement and activity); however, anyone interested in this work may want to try attending the Beta Server Group meeting on the 15th November, in case a demo is provided.

Currently, this represents the fist pass in Interest list improvements, and one which is liable to be heading to an RC channel in the near future – it does not require any specific viewer updates to work -, and Andrew expects to be building on this work in the future.

Group Services

As mentioned above, Baker Linden’s Group Services HTTP code is now available across the main grid. As there was some confusion evidenced on Plurk yesterday, here’s a quick re-cap on what this means:

  • The new code allows for improved loading of membership lists of very large groups, together with improved reliability in editing such groups (i.e. assigning roles, removing people, etc.), by the group moderators
  • The code requires a viewer update. At the time of writing, this is available with the official Second Life beta viewer (3.4.2.266708+), and the code will be filtering into the majority of popular TPVs as they update (and currently appears to be available in Zen (3.4.2.2+) and Niran’s Viewer (2.0.3.2262+) and Cool VL (1.26.4.38), all of which successfully loaded large group lists for me)
  • Until such time as the viewer-side code has been incorporated into TPVs, the “old” method of loading group lists into the viewer will still be available. However, viewers using the “old” method (a protocol referred to as UDP) will have group loading capped at 10K members. This means:
    • That for groups with 10K or fewer members, there will be no change regardless as to whether the viewer is using HTTP or UDP
    • But for groups large than 10K, viewers running the UDP code will be unable to load the group until such time as they have been updated to the new code
  • The code will not lead to any improvements in group chat reliability, and is not aimed at improving group chat.

Materials Processing and Avatar Baking

No news on either of these, beyond what has been previously reported in these pages. Materials processing has a test region on Aditi, but there is no timeline on when a project viewer is to be made available. For an overview of the initial capabilities for material processing, please see my project update here, and remember that the capabilities will be applicable to prims and mesh, but not directly to avatars or system layer clothing.

Avatar Baking is progressing, but without any significant update at this time, please refer to my last detailed update on this project for information.

Mesh Importer Fix

JIRA SH-3055 records a  problem with the official viewer’s mesh uploader which has been affecting people over the course of the year. The fix for this, released as a project viewer (3.4.2.266471, available for Windows, Linux and Mac OS) on November 5th, is still available for those experiencing uploader issues, although it is in the pipeline to be merged with the beta viewer now that crash issues seem to have been resolved. Bear in mind that – as Runitai states in his JIRA comment, the viewer is a pre-beat project version, and may include other bugs and problems. While reports on the JIRA seem to point to it being relatively stable, caution should still be taken if attempting to use it as a primary viewer.

Related Links

SL project news week 45/2: server news, viewer updates Steaming ahead, and surprises

Week 45 Deployments

The deployments schedule for this week (Tuesday 6th and Wednesday 7th November) went ahead as planned, namely:

  • Tuesday 6th: the Main Channel received get the code currently running on BlueSteel and LeTigre – release notes
  • Wedneday 7th:
    • Magnum received get fixes and updates to the code currently running there (including the Group Services code) – release notes
    • LeTigre and BlueSteel should get the next bug fix server in the pipeline, which includes the code currently on Magnum, and more – release notes (BS) and release notes (LT)

The main channel deployment now means that all regions are running on the same version of Havok with the exception of Magnum regions, which should be getting the update in week 46 (see below).

LeTigre and BlueSteel both have an additional “feature”: Linksets which have bounding boxes larger than 64m (in any dimension) are prevented from being rezzed if rezzing would cause the object to collide with an avatar excluding the object owner (BUG-166).

In addition, both LeTigre and BlueSteel include the following oft-requested bug fixes:

  • Script Time in the Statistics Bar now correctly shows 0ms when scripts are disabled in the sim (BUG-311)
  • Script error messages now include information about the object’s root prim, when certain operations fail due to the object’s pathfinding setting (PATHBUG-198).

A crash bug was also found in the Magnum code, and this has received attention, with the fix due to go out next week.

Week 46 Deployments

Things are gradually slowing down in preparation for the Thanksgiving code release freeze which will see a suspension of code deployments during the Thanksgiving week later in November. As it stands, the following roll-outs are planned for week 46 (week commencing Monday 12th November):

  • Main channel: should receive the code currently running on Magnum (including Baker Linden’s Group Services code – see later in this article)
  • Magnum: should receive the code currently running on BlueSteel and LeTigre, which will mean the entire main grid is now running the same version of Havok
  • BlueSteel, LeTigre and Magnum should also get the same additional updates (details yet to be specified).

Beta Viewer Update – Steaming Ahead with Project Code Merges

As indicated in Part 1 of this report, the crash issues impacting the beta viewer code have been resolved, and LL have been engaged in merging-up code into the beta and paving the way for the first of the 3.4.2 beta releases. These were always intended to have the code from some of the major SL projects which impacted the viewer, including Baker Linden’s Group Services code and Monty Linden’s HTTP texture fetch code.

The first 3.4.2 beta viewer was release on Thursday 8th November (3.4.2.266708), which includes a range of updates from the Lab as well as a number of contributed updates and improvements (see the release notes), although precisely which of the LL project elements are in the release isn’t obvious from the release notes themselves – the removal of JIRA numbers from the release note entries makes identifying updates, features and fixes that much harder, even though the JIRA items themselves are still open for public viewing.

One element that is clearly in the latest beta viewer release is the code for the steam link-up, as evidenced by the arrival of the new splash screen which I first reported on back in August 2012 – complete with a promotional piece for the Lab’s Pattern’s game.

Continue reading “SL project news week 45/2: server news, viewer updates Steaming ahead, and surprises”

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

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 43/3: viewer status updates

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

New Group Services code now live on Agni

Large group loading: a familiar problem

The Group Services project is an attempt to improve the management and editing of large SL groups by replacing the current UDP-based service (which has capacity issues with the size of group lists it can comfortably handle) with a new HTTP-based service.

Oskar Linden has announced that the new code for handling large groups is now live on four regions on the main grid. His announcement reads in part:

These fixes were released to Magnum this morning, but then we found issues in llSensor() that required us to remove the code from a channel as large as Magnum. We have a very small qa channel called the Snack RC Channel that we put the changes on.

 – https://wiki.secondlife.com/wiki/Release_Notes/Second_Life_RC_Snack/12

You will need to be  a member of the group Second Life Beta to access them. You can join that group here: http://world.secondlife.com/group/19657888-576f-83e9-2580-7c3da7c0e4ca

The four Snack test regions are:

Currently, the viewer-side code required to use the new service is only available in a project viewer, which is available as follows:

The viewer side code, as I’ve been reporting in these page, is currently being held-up from more widespread use by crash issues impacting the SL beta viewer code. As such, TPV developers are being encouraged not to merge the code for the above project viewers with their own development viewer code for the time being.

In the meantime, if you manage a large in-world group with more than 10K members, you may wish to download your relevant flavour of the project viewer and try-out the new code on the nominated regions.

Related Links

SL projects update week 41 / 1

Server Deploys

The main channel today received the same maintenance release made last week to BlueSteel (and which was used to help fix the LeTigre problems). speaking at the Server / Simulator User Group, Simon Linden described the deployment as, “A very minor change … from one of the RCs. It’s really not any functional change but was needed to go grid-wide before another one goes into RC.”

Following week 40’s issues with LeTigre, the three primary Release Candidate channels will be getting updated as follows:

  • Magnum, which has code to help sims run better on new hardware,  will be getting the same change that went to the main channel
  • BlueSteel and LeTigre will get the same update, which is described as “pretty minor but important”, being a back-end query optimisation designed to assist with database loads.

Currently, the prim accounting issue is still being worked on, which affecting scheduling what will be available in deployments. Passing comment on how deployment packages are put together, Simon explained that, as a rule, bug fixes tend to be put together as far as possible, prior to going to QA and then to an RC channel. He went on to say that what goes into other releases can be variable, “There’s a judgement call on how much gets bundled together, and a bunch of things go into the decision, like how overloaded the QA guys are, how many other things are trying to get to RC, risks of one part blocking it (like now), stuff like that”. In the meantime, LL are actively looking at ways to both prevent a recurrence of this problem and to improve the RC channel deployments as a whole.

SL Viewer

The promised new beta release (3.4.1.265642) reached the release point on Monday October 8th. This release sees tcmalloc disabled once more,  but otherwise appears to be the same code as the previous beta. It is intended to be a further stability testing / confirmation release, and as such will remain available for the next couple of days as Linden Lab gather data on its performance.Tcmalloc has been disabled, rather than removed, as it has apparently been useful in helping to trace issues within the viewer code, and LL wished to retain the ability to re-enable it in case they needed to re-enable it to help identify problems within the viewer in future.

Assuming this release proves stable, and assuming that plans outlined by Oz Linden have not undergone significant change, it should clear the way for the unblocking of various code merges that have been awaiting the stability / memory leak issue to be resolved. As previously reported, the precise order in which code merges will be made / released is unclear, but Linden Lab have a significant amount of updates waiting in the wings, including Steam support changes, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), and more.

Steam updates – one of the viewer merges waiting to be released

Under the original plans for the beta viewer, project viewer code was to start merging into the viewer with the 3.4.2 release code. As there was no OpenDev meeting on Monday 8th October, it is assumed this is still the case, however, the precise order of the merges is due for discussion this week within the Lab, and a clearer indication of the order may be available by the Thursday OpenDev meeting, and will be given in part 2 of this report, if that is the case.

Group Services Project

Due to the problems experienced with the leTigre deployment in week 40, Baker Linden’s Group Services code did not receive a proper deployment to a Release Channel. It is not due to be released this week, but should be in an RC deployment aimed at week 42, although as it has been bundled with the LeTigre deployment which had problems, this may be delayed further while the prim accounting error is looked into.

It is currently unclear as to whether the delay with the RC roll-out will influence when the Group Service viewer code (currently available in a dedicated project viewer) will be merged into the development  / beta branches of the SL viewer code; again more should be known on this following Thursday’s OpenDev meeting.

Materials Processing

Continues to progress, with little to report at this time. The feature set for the initial release still has yet to be published, and the wiki page for materials processing is due for further update. Concerns were raised over one statement relating to the use of colour, to whit:

Color a solid color for the surface; not used if a Texture is also specified.”

The concern was that whereas it is currently possible to specify both a texture and a colour for a given object or object face, the wiki implies that under material processing, it will become either / or. However, this appears to be an error in the wiki, and both options will remain available.

Linkability Bug

As reported in my last update, and while not strictly a project, the bug which is currently allowing prims to be linked over distances greater than 54m has been investigated, and a fix is expected to be rolled-out to the RC channels for this in week 42.