Tag: Shining Project

Avatar Baking: “and the clock has started!”

Posted on by Inara Pey

Update, April 6th, 2013: Please also see my updated status report.

The new avatar baking project took a step closer on December 14th, as LL started to release more in the way of technical details on the project and launched a project viewer.

Avatar bake fail
Avatar bake fail

Code-named Project Sunshine, and a part of the Shining Project, this work is aimed at improving avatar baking and at eliminate bake fail issues.

The project represents a sizeable change in how Second Life works, and as such will take time to fully implement, requiring extensive changes to the viewer itself – something which Nyx Linden has previously referred to as, “Some pretty scary viewer re-architecting”, as well as a good part of the back-end services – hence why it has taken so long for the project to mature. Because of the degree of changes taking place, Linden Lab have consistently promised, via Oz Linden, that TPV developers would some eight weeks notice prior to any initial deployment of the new service in order for them to ensure they can integrate the required viewer-side code changes, test them, and ensure they can support the new service.

Speaking at the TPV Developer meeting on Friday 14th December, Oz reiterated the 8-week lead time before adding, “Today begins the clock! … You get at least two months from now before we begin rolling server-side baking out to the main grid, at least beyond a test region or two.” So while the precise timescale as to when the new baking service will start to appear on the main (Agni) grid remains open, TPVs can now start to engage in the project, a step which itself brings it one step closer to reaching the grid.

A Quick Recap: How It Is and How It Will Be

Currently, avatar baking is essentially driven from the viewer. In summary (and without drilling too much into detail), this means that when a system layer outfit or item of clothing is changed (including alpha layers), the updates are applied locally in the user’s viewer. They are then uploaded to the server the user is connected to, which then passes the updates out to the other viewers connected to it, so that other users get to see the change as well. This process has several points of potential failure: communications between the viewer and the server may be interrupted, for example, with the result that the server doesn’t receive all the information pertaining to an outfit change, with the result that  – again as just one example – the user sees their avatar perfectly fine, but others see the avatar as blurred / grey. In some instances, the process can fail such that while the user sees their avatar wearing the desired outfit, other see the same avatar still wearing the “old” outfit.

The new service will hopefully eliminate these issues by moving much of the emphasis for the baking process from the viewer to a new “Texture Compositing Service”. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example. However, the new compositing service will take over most the donkey-work and handle the majority of avatar baking data and communications (excluding prim-based attachments).

As with many of the new services being introduced into Second Life by LL, the new baking service will be HTTP driven (the current system is UDP protocol based) which should have an additional benefit of speeding up the entire avatar load process when logging-in to SL and in fetching textures.

How the entire process should work can be summarised as follows:

  • The new service will use the Current Outfit folder as its viewer-side driver. This means that in order to use the service a viewer must have the Current Outfit folder properly implemented
  • When a rebake request is due (e.g. after a user has finished editing their appearance) the viewer sends a message to the baking service essentially asking it to look at the contents of the viewer’s Current Outfit folder and then return an updated appearance based on the contents of that folder
  • At the same time as the data is returned to the user’s viewer, it is also sent to the simulator to which the user’s viewer is connected, so that the simulator can send the appearance information to all other viewers connected to it.

To further TPV developers understand the new system and answer their questions,  Nyx Linden dropped by the TPV developer meeting on Friday 14th December. Note that what follows is an overview of Nyx’s discussion from the point-of-view of providing digestible information on the new service for “general” users, rather than a in-depth review of the full technicalities of the system and Q&A session.

Nyx linden discusses server-side baking at the TPV Developer meeting, Friday 14th December
Nyx linden discusses server-side baking at the TPV Developer meeting, Friday 14th December

Please use the page numbers below to continue reading this article

Pages: 1 2

SL project news week 48/1: server and beta, viewer, maps and memory

Posted on by Inara Pey

Server Deployments

After indications from LL that there may not be a Main channel deployment on Tuesday 27th November, restart commenced as the deployment made to the RC channels last week went ahead as per the usual schedule.

Wednesday 28th November should see the three main RC channels updated as follows:

  • BlueSteel and LeTigre: should receive a maint-server project.  There are a few new flags for the LSL function llGetObjectDetails(), but the most important changes are some fixes for physics and mesh-based crash modes – see the server release notes
  • Magnum should receive the say package, with additional stability improvement changes – see the Magnum server release notes.

As usual there is a forum thread for the week’s server deployments.

Viewer News

Release Viewer

The 3.4.2 viewer code finally reached the release (production) version of the LL viewer with the release of 3.4.2.267137 on Monday 26th November, which I briefly reviewed here.

Beta Viewer

The beta viewer, now cleared of the crash issue bottleneck, moved rapidly through the 3.4.2 code base prior to Thanksgiving in the US, as previously reported in the news updates, and then reached 3.4.3 with the surprise release of 3.4.3.267135 during Thanksgiving week, after it had been indicated there would be no viewer releases during the week due to decreased support staff availability during the long weekend period. As reported last week, this release includes the first phase of Monty Linden’s HTTP texture fetch project, which should see people experiencing significantly faster texture rezzing when in-world.

CHUI Viewer

The CHUI – the Communications Hub User Interface – project viewer is due to go through another couple of iterations before moving towards a development / beta viewer code merge. There has already been one update since the project viewer, which is aimed at improving the capabilities and reliability of in-world text and Voice conversations, first appeared.

CHUI: potentially a couple more iterations to come

While he has not followed the project first-hand, Oz Linden believes CHUI to be nearing a “feature complete” status. The advice is that if you haven’t tried it out and wish to give feedback, now is the time to do so.

Mesh Deformer

Nalates Urriah provides an update on some of the ongoing work around the mesh deformer. In the meantime, speaking at the Open Development User Group meeting on Monday the 26th November, Oz linden responded to a question from White Rabbit as to what garments are still required for testing by saying, “That’s a great question. I’m setting up a meeting with the people responsible for avatars to try to get a proper acceptance test defined for both that and STORM-1800.” STORM-1800 relates to the vertex weights of the default avatar character mesh.

While Oz didn’t specify a date for the meeting, those with a direct interest in either supplying mesh clothing for testing or in the JIRA should be hearing from him in the near future on the meeting details.

Continue reading “SL project news week 48/1: server and beta, viewer, maps and memory” →

SL projects update week 42 / 1

Posted on by Inara Pey

Server Updates

The main channel deployment took place as planned on Tuesday 16th October. As previously indicated, this was the code deployed to the BlueSteel RC channel in week 41 (essentially an improved database query that should help with the back-end system load).

Of the Release Candidate channels, these are due to be updated on Wednesday 17th October as follows:

  • Magnum – will not receive an update, but will continue to run with the code deployed in week 41, probably in the same configuration
  • BlueSteel – will get code that’s almost the same as the main channel, with some OS-level configuration changes that shouldn’t be visible to anyone
  • LeTigre – will be getting a minor update to the Havok library which is mostly about getting our servers to build under Visual Studio 2010 on Windows and autobuild on Linux.

The LeTigre update will use “slightly newer” versions of the Havok libraries, so concerns were raised at the Server  / Sim meeting on Tuesday 16th October as to whether this may lead to a resumption of the problem with mesh vehicles being unable to travel between regions running different versions of Havok.Andrew Linden confirmed this might well be the case for mesh vehicles moving between LeTigre regions and other regions following the deployment.

To help reduce issues with situations like this arise, it was suggested that areas such as the Blake Sea regions are either removed from the RC channels, or placed on the same channel. While this would not solve the problem grid-wide, it would reduce the impact somewhat for people using mesh vehicles in these regions. A query was put to the LL deployment team on this by Andrew Linden, and they  agreed to try to make the Blake Sea regions more homogenous by ensuring they are all on the same channel.

SL Viewer

A further stability test build for the beta viewer was made on Friday October 12th, and reached the download page on Tuesday 16th (3.4.1.265898 – release notes) after being cleared by QA. This should be the last stability test release and should see the OK for code merges to resume. Merges and release priorities are still being looked at, and speaking at the Open Dev meeting on Monday 15th October, Oz indicated that there are “a few open source contributions in the pipeline that are in the mix”, as well as the anticipated LL merges such as the Steam code, Monty Linden’s HTTP library updates, Baker Linden’s Group Services project code, Apple OSX Mountain Lion support (including gatekeeper compatibility), etc.

Kelly Linden reports fixing SVC-7870 (Edit Linked Parts isn’t returning creator/owner), but given the current backlog, it may be a while before this makes it through to a beta  / release viewer.

Avatar Baking

The aim of this work (Project Sunshine) is to improve issues around avatar baking and to eliminate bake fail issues. It will primarily focus on moving the emphasis for the baking process from the viewer to a new Texture Compositing server. The viewer will retain some elements involved in avatar baking – the actual baking of the avatar shape (i.e. shape values and IDs) will still take place on the viewer side, for example.

As of Monday 15th October, no major news. Commenting at the Content Creation / Mesh Import meeting, Nyx Linden said, “Still plugging along at it :). It’s a complex project with many moving pieces, we’ll let you know when there are updates, and I will definitely be asking for beta testers here when we’re ready for feedback”.

Interest Lists and Object Caching

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: ironing-out the bugs, wherever they are

Andrew Linden continues to iron-out the bugs in the interests lists project, including one in the main viewer codebase wherein after crossing a region boundary the connection to the region you were just in will get reset after about 60 seconds. This is impacting the interest lists work and requires resolving, so Andrew is currently focused on trying to sort it out. A problem has also been reported with objects rezzing in the test regions on Aditi (e.g. Ahern) when moving through them in a vehicle, and will be looked into.

Pathfinding

A question was raised at the Content Creation / Mesh Import meeting on the 15th October as to why a 1-prim pathfinding character  has a land impact of 15. The reason for this is due to the increase physics load on the character. As previously covered, while this may seem harsh, it actually means that characters with a much higher prim count will also have a land impact of 15 (for example, a 30-prim character will still only have a land impact of 15), unless other factors (such as streaming cost) come into effect.

There are a couple of other issues with pathfinding characters which are being (or are about to be) looking at:

  • A bug whereby copies of single-prim characters only have a land impact of one (not 15). This problem is being addressed under PATHBUG-194.
  • A problem wherebypathfinding characters suddenly appear to “fly away” when adjusting your camera position, almost as if they are suffering from lag, and then reappearing there they should actually be (I gather this tends to happen when looking at a pathfinding character, which is following a set path then turning the camera away and then back again). Andrew Linden believes the problem is related to interest list updates, and will be looking into it.

Mesh

The patch to enhance the mesh uploader when dealing with rigged mesh items was discussed at the Content Creation Mesh Import group meeting on October 15th, with Nyx expressing interest in the idea, and agreeing with a suggestion that the patch needs to be formally submitted to LL’s bit bucket repo applied to a cloned version of the development viewer, supported by a JIRA outlining the patch and with a link to the repro.

Mesh uploda enhancement: suggested that it is submitted as a patch to LL

SH-3055 is a bug relating to mesh uploads which has been around for a while, but which appears to be affecting more people of late. With it, mesh uploads fail without any error message or warning on clicking CALCULATE or UPLOAD on the mesh upload floater. The issue is hard to track down (or even reproduce) as it doesn’t occur with any consistency. Either the upload works, or it simply sits as if waiting for something – whether it is waiting for data to be returned by the server, or whether it is receiving information and failing to action upon it.

Darien Caldwell and Nicky Dasmijn have been working with a debug viewer in an attempt to pin the problem down, but so far without success. One school of thought they are pursuing is that it is a problem with the viewer’s cURL wrapper (which is also thought to have been responsible for the recent crash issues being experienced in the beta viewer). The thinking behind this is that the problem appeared to come about with the introduction of a multi-threaded cURL in v3.2.5 of the viewer – with 3.2.4 having exhibited no major issues with uploading.Nyx Linden has stated he’ll take the problem to the team work on cURL to see if they can identify anything.

Materials Processing

No further updates. When talking to Geenz Spad and Oz Linden on Tuesday 16th October, Geenz could only say, “There’s not much to really report on materials for the time being unfortunately, but when there is something I’ll be more than happy to tell everyone.” Oz then added, “We’ll do more than tell you – we’ll give you something to play with :-)”.

Network Pile-on Test Update

Commenting on the thread for the pile-on test, Oskar Linden said: “All of the tests passed and the code will be going to RC next week. Thank you all for your help!”

With thanks to Baz deSantis for information on the Sim / server Group meeting.

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