Category: 2012 Project Updates

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

New Group Services code now live on Agni

Posted on by Inara Pey
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 project news week 43/2: SL viewer, mesh, and materials processing

Posted on by Inara Pey

SL Viewer News

Things are not looking good on the official viewer front. As previously reported, the crash rate for the 3.4.1.265898 beta release was unacceptably high when compared with the current release version.

A new beta candidate  – 3.4.1.266073 – was released late on Monday 20th October. As per usual, it will remain on the beta channel for a couple of days once released in order for LL to get a read on performance and crash rates. Some regression testing has started, with the beta code merged back to the viewer-development pipe, but work is really pending on confirming the beta code is relatively stable.

In the meantime, feature changes to the official viewer remain frozen, and even should the new beta release prove stable enough, it is going to take some time for LL to prioritize all of the pending updates (both their own project work such as the Steam updates, HTTP project, Group Services, etc., and contributed updates), start merging them into the code, testing them, and then releasing updates once more.

With regards to overall viewer stability, A series of crash fixes from Firestorm (officially viewed by Linden Lab as the most stable viewer connecting to SL) have been contributed to LL and are awaiting regression testing in order to confirm their effectiveness with the LL code.

Mesh Deformer

A new version of the Mesh Deformer project viewer appeared over the weekend – 3.4.1.266081, dated October 20th. This has the revisions Darien Caldwell has made to the uploader and custom shapes, although she is still waiting on feedback from Qarl on the matter of the sliders / bone armatures which are deformed by both the viewer and the deformer, as mentioned in part 2 of my week 42 update.

The new version should hopefully include a small bug fix when selecting the Default Male shape (which would act as if the Default female shape were selected).

Materials Processing

Materials processing: using a normal and diffuse (texture) map to generate a 3D effect on an in-world wall – coming to SL in the near future

Speaking at the OpenDev meeting on Monday 22nd October, Oz Linden indicated that the specification for the revised build floater in the viewer – needed to handle picking, rotating and offsetting normal and specular maps in the same way as can be done with textures (diffuse maps) at present.

The specification for the floater has been written in-house at LL, but the work is being undertaken for LL by a third-party viewer developer who volunteered to carry out the required work on LL’s behalf. This work will initially focus on getting a shell for the floater built, as there are a number of things that are being worked on within the viewer with regards to making parameters actually visible on surfaces.

Discussing progress at the Content Creation Improvement Informal User Group on Tuesday 23rd October, Geenz Spad outlined some more of the upcoming capabilities, as defined by the initial release specification document.

“We have normal maps with specular exponent stored in their alpha channel, specular maps will have environment masks stored in their alpha channel [so, for example, mesh won’t require seperate faces in order to have different levels of shininess on different parts of it], and for diffuse maps you’ll be able to select to some limited degree what its alpha represents (currently, none, alpha blending, alpha masking, and emissive mask).” He went on, “There’s a few additional knobs people will be able to mess with as well, such as specular exponent (combines with the normal map’s exponent map in its alpha), specular color (combines with the specular map’s color), and environment intensity (combines with the specular map’s alpha).”

However, custom environment maps – such as used with custom reflections – won’t initially be supported, as has been previously indicated. With the initial release specification now locked – but not currently open to public reading, that will occur nearer the time LL are ready to make a further announcement on materials – any additional functionality is being looked upon as being either for a further release or requiring a programmable system to implement.

Whether there will be further updates to the system remains to be seen, but it appears those involved in the project, both inside and outside of LL are reasonably confident there will be. “Materials is something that you can likely expect to receive several updates over time,” Geenz commented. “It’s something that’ll evolve from a fixed system into something a fair bit more sophisticated eventually.”

Related Links