Category: SL User Group Meetings

SL projects update: week 40 / 1

Posted on by Inara Pey

Update 3rd October: The RC roll-outs were somewhat different than indicated by Simon. Magnum apparently received the back-end configuration work for new and future hardware, and BlueSteel received the maintenance update. The Group Services code & maintenance release was targeted at LeTigre, however a showstopper issue means that these regions are now in a state of flux. A comment from Oskar Linden reads: “LeTigre regions exhibited issues that necessitated a rollback. The regions were rolled forward and are on the same code that is on BlueSteel. Affected regions are getting a simstate rollback” . 

Server Deploys

There was no main channel roll-out this week, as expected, following the cancellation of last week’s RC channel deploys.

Wednesday 3rd October will see the three RC channel deploys originally planned for last week:

  • Back-end configuration work designed to help SL run better on new and future hardware – this should be deployed to BlueSteel
  • A maintenance release, which includes has Baker Linden’s Group Services project – this will be deployed to Magnum
  • The third is described by Simon Linden as being, “Very similar to what we have today, with a fix for some future compatibility coming down the pipe. It’s nothing really exciting, but required so things won’t break.” – this should be deployed to LeTigre.

The order of the releases is not clear at the time of writing, and is based on Simon Linden’s comments at the Simulator User Group.Confirmation / updates to the plan should be made available via the Server Deployment thread in the forums.

SL Viewer Releases

Things remain slow due to on-going crash / possible memory leak issues, as reported in my last mini-update.

Group Services Project

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. The project viewer for this is already available (for Windows, Linux and OSX.). It had been hoped that the viewer code might reach a 3.4.2 beta release during this week, however due to continuing issues with the current beta viewer code, this now seems unlikely.

The initial server code for this will be deployed to the Magnum RC channel, as mentioned above, on Wednesday 3rd October.

Materials Processing

The final feature set for the first release of materials processing is now more-or-less complete, and it should hopefully be announced nearer the time for beta testing. A number of regions on Aditi have been prepared for beta testing, and details on these will be released when the initial project viewer is ready for release.

Options to be used by Normal and Specular Maps, which will need to be provisioned in the Build floater

The initial feature set will include the ability to set parameters (rotation, offset, etc.), for normal and specular maps as well as diffuse (texture) maps. Oz originally hinted this was the aim a few weeks ago, although Geenz indicated it was only hoped these capabilities would be included, rather than it being definite at that time. This means that the build floater for the project viewer will be somewhat different from most people who build are familiar with, as it must include a number of additional options (see right). However, what is being considered is not a complete rebuild of the Build floater.

Commenting on this aspect of the work at the Content Creators’ Improvement Informal User Group, Oz Linden said, “We’ve got a strawman design in internal review… will have a version to look at soon, I think.”

The design has had input from a number of builders. Some of these are from within LL, some of them users, and will probably be left unchanged until further experience is gained in its use. Whether this means the viewer remaining unchanged between the beta programme and the release of materials processing on Agni, or whether changes are made between the beta and the release, remains to be seen. As Oz went on to comment, “It’s a very difficult problem, and we tried to meet three sometimes-conflicting goals: do what needs to be done; keep things familiar; make the things you have to change better in the process. I think we did pretty well…”

Obviously, TPVs will have access to the build UI code once it is available in LL’s accessible repositories, and they’ll doubtless look at the code in terms of how best to integrate it into the look and feel of their own viewers.

There are still no firm dates for the project in terms of beta commencement, etc., but Oz reiterated that the project will follow the familiar course, with an Aditi beta, followed by a release to one of the RC channels on Agni, prior to an eventual full roll-out.

Related Links

With thanks to JayR for the simulator UG meeting transcript.

SL viewer and project mini-update

Posted on by Inara Pey

A couple of items came up at the Open Dev meeting held last night (Thursday 27th September) which are worth pushing out by way of updates to my SL Projects Update from earlier in the week.

Beta Viewer

The beta release ((3.4.1.265134) made available on September 24th is still suffering from high crash rates. Whether these are related to memory leaks or not is currently unclear, as the Lab is apparently having trouble reproducing specific causes of crashes. It is believed that tcmalloc is no longer a part of the code. As a result of the investigations, the planned frequent deploys of 3.4.1 beta releases as specified by Oz last week has been delayed. This is liable to have a knock-on effect with planning for the 3.4.2 beta releases as well, although 3.4.2 continues to roll to the development branch, with 3.4.2.265141, released on the 25th September being the current development build at the time of writing.

Mesh Deformer

Following the release of version 3.4.1.265139 on September 25th, the Mesh Deformer project viewer updated to 3.4.1.265192 on September 26th. This version has the normals calculation disabled, as it conflicted with how Blender creates sharp edges and would cause the deformer to split the edge. In addition, it appears from comments made at the Open Dev meeting that meshes uploaded prior to this version will not deform unless worn with a mesh uploaded using this version, which is intentional.

There have been further contributions to the test clothing at Hippotropolis, and Nalates Uirriah commented that some creators are placing free copies of clothing for testing up on the SL Marketplace for people to use in tests. Oz requested that anyone doing this to please explicitly state the version number of the project viewer they used to upload the mesh clothing.

At the moment, and based on contributions received, Oz is hoping to arrange for a new series of tests to be run to test the overall functionality for the deformer as it stands. Again, if you do wish to contribute clothing (uploaded using the current version of the project viewer), please refer to Oz’s original request on the subject.

Avatar Baking

Bake fail: a familiar problem for many

Avatar baking is progressing, although there is still no time-frame for any project viewer or roll-out of code on the server-side.

Currently, work is being undertaken to move the viewer’s baking code to its own library, which will be used with the new server-side baking service as well. Thus the same code will be used when changing your appearance locally, and to send your updated appearance out via the new baking service, once it has received the updates from your viewer. This aim of this work is to further eliminate some of the errors which can occur as a result of the current baking process being reliant upon viewer-side hardware, drivers, etc., wherein the same inputs can lead to different results when using different hardware.

One of the biggest benefits of this work will be removing the burden of texture caching from the simulators. With the new system, avatar texture caching will essentially be a global service: the Texture Compositing service becomes a single point-of call for avatar texture information, instead of a simulator having to contact the simulator a visiting avatar was originally baked on in order to obtain texture data.

This not only means that texture caching will be removed from the simulators once the new service is up and running smoothly, it could pave the way for other benefits as well, as Oz mentioned in the meeting, “In theory at least, that lets us introduce persistent connections and pipelined requests (don’t know if that will be in the first version or not), which could enormously speed up getting the bakes when you enter a crowded area.”

Plans for the project remain aimed towards providing TPV developers with as much advanced warning as possible prior to the new service being enabled on the main grid (Oz has been aiming at around two months’ notice), to give them time to incorporate the viewer-side code changes and assist with testing the new service. When the server-side code is ready, a project viewer will be released, and a series of regions on Aditi (the beta grid) will be updated to use the new service for testing purposes.

I have a more explicit explanation of the core aims of the new avatar baking service available in an overview of the Shining project.

Related Links

SL projects update, September 26th

Posted on by Inara Pey
Update 28th September: Please also refer to an update post on some of the projects / news given here.

SL Viewer Status Updates

Linden Lab have been working hard on a range of viewer-related issues, notably crash rates and memory leaks, which have slowed the viewer update a release process up over the last few weeks. In terms of memory leaks, tcmalloc has been identified as the culprit, with Linden Lab deciding that dropping it is “probably a good idea”, according to Oz (tcmalloc has previously been implicated in crashes linked to the use of things like Microsoft’s Skydrive). There have also been an issues with LL’s statistics system which have meant that the viewer hasn’t necessarily been accurately tracked in terms of crash rates, etc.

Beta Releases

As it stands, LL hope to have the blocks on the various code merges removed during this week, which should see a rapid series of beta releases coming down the pipe. This work commenced with an initial 3.4.1 beta release (3.4.1.265134) emerging on September 24th. It will be followed by around three or so additional and rapid 3.4.1 build iterations aimed at confirming the viewer’s stability and at replacing various fixes which had previously been removed from the viewer code while trying to identify the causes for the viewer crashing / suffering memory leaks. It is expected that each of these iterations will be on the beta release build channel for a couple of days, prior to being replaced. Following these there will be a series of project updates, the first of which gatekeeper compliance project, which is also targeted for a 3.4.1 release build.

Project-related Releases

Once the stability of the beta viewer has been confirmed, it is anticipated that project-related code will be merged into the viewer, most likely starting with 3.4.2 builds. Among the releases planned for 3.4.2 is Monty Linden’s HTTP Library Services and Baker Linden’s Group Services code. These are currently targeted to reach the beta build channel in week 40 (week commencing Monday October 5th).

These releases will at some point include the Steam updates currently in a Development branch as well, which might in turn mean that Second Life could be ready to appear on Steam in the very near future, once these updates have reached a release version of the viewer.

Account creation prompt: heading for the beta viewer

Group Services Project

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. The project viewer for this is already available (for Windows, Linux and OSX.), however, as mentioned above, the current plan is to get this into the 3.4.2 build stream alongside the HTTP textures project, possibly in week 40.

Originally, the server code for this project was due to have been rolled to the RC channels during week 38, (week commencing September 17th), but the channel deploys were postponed after QA issues were found. As a consequence, the roll-out was due to take place on Wednesday 26th September, but has again been postponed.

There has been some confusion as to the aim of this project, with some people believing it is focused on fixing group chat issues such as  lag and chat failing to start. This is not the case at all; as stated above, the project is aimed at improving the management and editing of large groups (10K+) through the use of a new HTTP service.

HTTP Library Services

As indicated above, the first phase of this work, covering a new texture fetch service, should be appearing in a 3.4.2 beta release of the viewer in the near future.

HTTP Libraries project viewer: improved texture loading and rezzing

Please use the page numbers below left to continue reading this article

Pages: 1 2

Pathfinding: summary update

Posted on by Inara Pey

Linden Lab has been quietly working on pathfinding, clearing a range of bugs, updating the supporting documentation (some of which is still a work-in-progress) and providing more information for users aimed at clearing up misconceptions / misunderstandings. The following is a quick update on recent activities.

Lorca Linden’s FAQ

On September 18th, Lorca Linden posted a Pathfinding FAQ to the Second Life Server branch of the technology forum. While perhaps not the most high profile place in which to post the information, the FAQ nevertheless addresses a number of core issues related to pathfinding and makes a valuable read for anyone interested in using pathfinding or who wishes to understand more about pathfinding in general, rather than relying on hearsay.

One of the major misconceptions which is perhaps missing from the FAQ is that disabling pathfinding in a region will somehow “improve performance”.  In fact,m the only thing disabling pathfinding for a region does is to prevent pathfinding characters from operating; the underpinning Havok engine remains unchanged, and no Havok functionality related specifically to pathfinding is “turned off” in any way. So if there are no pathfinding characters being used within a region, disabling pathfinding will not improve the region’s performance, and any apparent improvement which may be noted is more than likely a placebo effect.

Pathfinding Tools In The Viewer

The latest release version of the SL viewer (3.3.4.264911) now includes the pathfinding tools, as do a number of TPVs, some of which I reported upon a while back, and which have since been joined by Firestorm (4.2.2.29837+); while Singularity (1.7.1+) also now provides some of the viewer-side tools / options associated with pathfinding.

Updates list of viewers monitored on this blog  which provide pathfinding support (click to enlarge)

Documentation-wise, work has been put in on cleaning up the existing wiki pages (although some are still somewhat out-of-date or difficult to follow as they presume a certain level of understanding). An updated list of pathfinding wiki documentation and related resources which I’ve previously published in the blog can be found in Related Links, below.

While there is still ongoing work in relation to a number of pathfinding bugs, the arrival of the pathfinding tools into the SL release viewer theoretically marks the point at which pathfinding might be considered “fully released” (as previously indicated by Lorca Linden). As such, it would be beneficial for Linden Lab to provide a formal blog post on the subject, including links to relevant resources such as those listed below in order to make the information more readily apparent to SL users, regardless as to how well (or otherwise) LL believe their blog is read.

Related Links

Upcoming SL projects update

Posted on by Inara Pey

There is a lot going on in terms of projects and development work in Second Life. The following is a further update on a number of key projects I’ve been following and reporting upon through the pages of this blog.

Group Services Project

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. The project viewer for this is already available (for Windows, Linux and OSX.), as I reported last week.

This week sees the server-side code rolled-out to all three RC channels (Magnum, LeTigre and BlueSteel), allowing the project viewer to be tested in handling very large groups (significantly larger than are available on Aditi). Note that those running viewers without the new code on any RC region will be unaffected, as they will continue to access the current UDP service.

There are still no timescales as to how long the testing of the service will last (“It’ll take as long as it takes,” Baker commented recently), or when the viewer code will progress beyond the project viewer. However, a number of things should be noted in reference to the eventual roll-out:

  • The viewer code is not being made back-compatible with V1 code by the Lab. Therefore, TPV developers using the V1 code base will have to backport the code themselves in order to use the new service
  • The initial HTTP service roll-out does not include any data compression. This means there will still be some delay in downloading member lists for very large groups with tens of thousands of members
  • Once the new service is rolled-out, which service is used is entirely transparent to the user. If a viewer with the new code is running on a region which has the server-side HTTP service, it will connect to that service. If it is on a region using the older UDP service, it will connect to that service instead
  • Once the HTTP service is fully deployed, viewers which do not implement the viewer-side code will still be able to access groups with member lists up to 10K in size via the UDP service until such time as it is switched off (which will not occur for some time after the HTTP service has been rolled-out). However, attempts to access groups with lists larger than 10K will fail.

Interest Lists and Object Caching

It’s been a while since I’ve reported on Interest Lists Object Caching, which forms a part of the Shining Project.

To recap: when you enter a region at the moment, your viewer receives a huge amount of information on what requires updating, much of it relating to things you can’t even see from your position in the region. This information is received in no particular order, with the familiar result that things appear to rez in your view in a totally random order. Not only that, but the chances are that if you’ve previously visited the region, much of the information being sent to your viewer is already locally cached – but is being ignored. The focus of this project is to both optimise the data being sent to the viewer and the information already cached on the viewer with the aim of significantly improving object rezzing times in terms of speed and order (so objects closer to you rez before those further away, for examples).

Object caching and interest list changes: easing the pain of random rezzing

Andrew Linden had hoped the project would be going to QA this week ready for roll-out to one or more RC channels in the near future, but some last-minute problems popped-up and have delayed things until he can get them sorted out. In the meantime, the code has been deployed to a number of regions on Aditi, and Andrew plans to, “Try to throw a pile of test avatars at it to stress it out. Later this week.” No viewer-side changes are associated with this work.

Materials Processing

Work continues on the project to bring materials processing to Second Life. Last week, it appeared as if the new materials – normal and specular maps – would have their own rotation and positioning options independent of any texture (diffuse) map. This week, it appears that this is the hoped for situation, but the matter is still open to question – which goes to show how fluid the project is.

The new capabilities require changes to the rendering pipeline, and details have been released on some of what this entails.

In order to work, normal and specular maps require what is referred to as per-pixel lighting (as noted in the original blog post on the subject). As such, there has been a debate on whether it would be better to develop a per-pixel lighting framework within the viewer, or work to make the current deferred rendering system more accessible to per-pixel lighting capabilities. As the latter approach will allow getting materials processing working within SL sooner than would otherwise be the case, it has been decided to go that route. Thus work is focused on making the current lighting system more configurable and able to better handle a broad range of material types (metallic, matte, plastic, etc.), together with adding support for both per-object and per material shading differences.

However, a dedicated per-pixel lighting framework does offer advantages of its own, and as such is being considered as a possible future extension to the project, which may be implemented at some point down the road. One such advantage is that could potentially be run in a non-deferred mode, which might lightening the load on older graphics systems.

Please use the page numbers below to continue reading

Pages: 1 2

Belated avatar baking service update

Posted on by Inara Pey

The server-side elements of the new avatar baking service (part of the Shining Project) continue to progress, alongside what Nyx Linden has referred to as, “Some pretty scary viewer re-architecting” which is being undertaken by the Lab in order to try to isolate some of the avatar baking aspects from the rest of the viewer code base. As such, he’s anticipating the eventual code merge to be “fairly significant” when it does happen, although at the time of commenting (the last TPV/Dev meeting, September 7th), the code was not in a condition where it could be used by any of the TPVs.

Bake fail: a familiar problem for many

Overall, the viewer elements of the project are the priority, with the aim remaining to get the viewer code completed first, and to make it available to TPVs so that test viewers can be built. This is likely to happen before the code is ready for any formal release, the aim being to allow TPV devs to carry out test merges and to let LL know anything else has been broken as a result of the changes made to the code in order for the new service to work.

Once the code is available for testing both within the viewer and on test regions on Aditi, Nyx will be looking for “as many people as possible to pile-on” and test the code in order to see how the service works and how it may break, so that  by the time the viewer code is merged for release purposes, it will be as robust as possible.

Test Avatars

To assist with the work, Nyx is also looking for volunteers willing to take part in the initial round of testing using avatars wearing multi-layer outfits (e.g. outfits combining undershirt, shirt and jacket layers, etc; outfits using multiple elements of the same layer; outfits with system skirts and glitch pants, outfits using alpha and/or tattoo layers, and so on). Anyone interested in joining-in the testing should contact Nyx via e-mail or by sending him an in-world notecard, specifying the avatar name and details of the outfit itself. When volunteering, bear in mind that:

  • The outfit must be a Viewer 3 outfit, and your viewer must support the Current Outfits folder (which is used to drive the new service from the viewer end)
  • Testing will be on Aditi, and as such, the avatar and outfit must be available on Aditi. If necessary, you may need to update your Aditi inventory to make the outfit available.

Going Forward

The plan is still to have the new code support both the “current” method of avatar baking  and the new baking service, until such time as the new service is fully deployed. This means that if a user is in a region that does not make use of the new baking service, avatar baking will continue to be handled using the viewer-side mechanism. However, if the user is on a region that utilises the new baking service, avatar baking will be handled through that, with a flag set via the region capabilities being used to distinguish whether or not the new service is available.

There is still no definitive time frame for the project because of the complexity involved in both developing the viewer code (which is currently using a branch of the SL development viewer, but will obviously be moved to whatever code release is current) and with the development of the new server-side service. As such, it is still liable to be at least another month or so before the code is ready for significant testing on Aditi.

Related Links

This is a little overdue due to problems earlier in the week accessing the recording of the TPV/Dev meeting (which I was unable to attend in person). Thanks to Oz for sorting the problem out, allowing me to catch-up on overdue updates on this and JIRA matters etc.