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.
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).
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.”
Linden Lab have launched, somewhat unexpectedly, a new project viewer, called CHUI. While sounding like a character from Star Wars (CHU-EE, geddit? *Ahem*. Sorry), it stands for Communications Hub User Interface. The blog post states:
With so many ways for users to communicate with one another in Second Life, there are quite a few communications tools in the Viewer. To make it easier to find, learn and use these tools, today we released a project Viewer that introduces CHUI (Communications Hub User Interface). In addition to bringing most of these communications tools “under one roof,” CHUI also introduces some new and improved features.
Among the listed features are:
The Conversation Log: providing you have enabled the option to save chat and IM logs to your computer, this allows you to open the entire history of a conversation with another user held in the past 30 days directly in your viewer, or review off-line IMs received from both friends and non-friends
Expanded conference calls: with CHUI it is possible to add people to a conference call after it’s started, or add someone to an existing one-on-one IM session
The ability to easily move your voice connection between open conversations including nearby chat, private IM, conference chat or group chat. Click the “add voice” button on any conversation to move your voice connection to that conversation. Click the “hang up” button and your voice connection is returned to nearby chat.
The ability to access chat preferences in a single click from the Conversation window
Change the volume of a single person’s voice by simply clicking on that person’s speaking icon in the Conversations window
A multi-line chat entry box which expands as you type.
CHUI Conversation Log
These features primarily found in two floaters: Conversations Log and a revised Conversations floater. The Conversations Log window lists all recent and past conversations, allowing them to be to scrolled through and opened for reading. As I’ve only jut started using the project viewer, I’ve actually not investigated this in-depth. Clicking on a listed conversation will open in the Conversations floater, and the Conversation Log contains two buttons for sorting the listed conversations (by name, by date, etc.), and a gear cog button for access various options – start an IM, enter a voice call, view profile, etc., for a selected conversation in the list.
For those who use TPVs with tabbed IM capabilities, the revised Conversations floater will look remarkably familiar, bringing as it does local chat and all IM conversations into a single floater panel. Any conversations in the Conversation Loge will also open here as well.
The Conversations floater
The panel includes a number of buttons. These again allow conversation to be sorted, closed individually, etc., and also include a number of additional options:
Add someone else to an existing IM conversation, and establish a conference call. This will open the Choose Resident Floater, allowing you to pick a friend, someone nearby or search for someone.
Start a Voice conversation with a person or hang-up from a Voice conversation (the icon will change on the button, depending on the status of the call)
Open the Choose Resident floater to select someone with whom to start an IM or Voice conversation.
Break-out any conversation into its own floater.
The Conversations floater can also be compacted down into one of three sizes, using the left / right double chevron arrows. These help reduce the amount of space the floater takes up on your screen when not actively in use. It can be expanded either using these buttons or using the right-pointing arrows next to the names in the conversations list.
The three compact views of the Conversations floater
Overall, this is a significant attempt to centralise in-world communications, and there are some nice features here, particularly in the extended Voice options.
For Linden Lab, this is very much experimental, as noted in the blog post itself, and they are asking for people’s feedback on the features:
We’ve been testing CHUI inside Linden Lab for some time, but any major redesign requires a lot of people using it to make it as smooth and useful as it can be. This is where you come in.
Please think about these questions as you use the CHUI project viewer:
Are the new features useful?
Do the functions you commonly use seem more streamlined, or do they require more clicks than before?
Are all of the functions, both old and new, easy to find?
We’ll ask you to complete a survey in approximately one week to gather your thoughts on these questions.
There is a publicly accessible JIRA (https://jira.secondlife.com/browse/chuibug) available for the viewer, and if you do try it out and find a bug, LL request you report it there.
Also tucked away in the blog post is news that blocked users and objects can now be viewed from within the People floater, rather than via a separate menu option, and can also be unblocked from here via the right-click context menu.
After hopes that the latest beta version of the viewer would prove stable enough for things to start flowing again, it turns out that its crash rate is hovering around the 14% mark, with Oz reporting that a substantial portion of the crashes, which still appear to be related to memory problems, occurring as users exit the viewer. While these may go unnoticed by users, LL still want to bring the rate down to something closer to the release viewer (which is currently 10%).
As such, further candidate version of the beta viewer is being built, which should be released on Monday 22nd October with the hope that the changes being made will do just that. However, it is fair to say that the level of optimism within the Lab that this will be the case is currently low. Until the problem is resolved, further releases of code for projects are likely to remain blocked.
This issue is now the primary delay in moving a number of projects forward, including the Baker Linden’s Group Service project, Monty Linden’s HTTP texture project, updates for the Steam link-up and a host of other internal and contributed elements.
Mesh Deformer
A revised version of Darien Caldwell’s proposed addition for arbitrary shapes in the mesh uploader for us with the deformer
Darien Caldwell has been continuing to work on getting the deformer to work with arbitrary human shapes, and has some success. She has also ben working to refine the new options on the mesh uploader to cater for custom shapes, indenting the options to make it clear that they are a part of the Deform to Avatar Shape check box item (see right). Also, and while awaiting feedback from LL, she has moved the option to export an avatar shape as an XML file from a sub-menu on the Develop Menu (DEVELOP -> AVATAR -> APPEARANCE TO XML) to the Advanced Menu on her version of the Mesh Deformer project viewer.
However, as she comments on the JIRA (STORM-1716) for the deformer, there is also a problem.
Essentially, there are certain sliders (eleven in all) associated with armature bone length, which already deform mesh without using the deformer (see her JIRA comment for the full list of sliders). When these are adjusted to create a custom shape for making mesh items, problems arise because they are then deformed by both the viewer and the deformer, leading to odd results under certain situations.
The issue appears most pronounced when working on individual body elements, such as the upper body (as defined by SL) when using a custom shape (such as when creating a jacket). However, in a “full body” mesh, the problem is somewhat less pronounced.
Deformation issue: on the left, an “upper body” flesh-tome mesh (analogous to, say, a jacket) built to a custom shape is worn on that custom shape (in black). Note the mis-match. On the right, the same mesh, but combined with lower body elements applied to the same custom avatar shape. A much closer fit
As the sliders are placed closer to their default values, the issues become less and less pronounced. Darien had suspected this might be an issue, but until she started working with shapes other than the default, she had no way of determining if a problem existed. She has also a nagging concern that a small adjustment made to the deformer code itself might be having an unforeseen impact. However, from his own understanding as to how the deformer works and when discussing the matter at a delayed OpenDev meeting on Thursday 18th October, Oz Linden agreed this was unlikely to be the case.
When using custom shapes with the “problem” armatures set closer to their defaults, the problem is still present in “upper body” meshes (l) but is somewhat less pronounced, and again is barely noticeable on a “full body” mesh (r)
Currently, and assuming I’m understanding the matter correctly, the “fix” for this problem seems to be to define a custom avatar shape in SL, then adjust the eleven “problem” sliders to their default values prior to exporting the shape data to an XML file which is used shape to create the required mesh items (body, clothing). Once the finished items has been uploaded to SL, it can be worn with the shape and the desired settings for the eleven affected sliders can then be restored with the result that the mesh should deform as expected.
Darien will be carrying out further tests on the issue prior to offering her version of the deformer for wider use.
HTTP Libraries
As a result of beta viewer issues, it’ll be a while before everyone benefits from faster texture rezzing – but work continues on related services
While the viewer side of the new texture fetch library is blocked from going further than a project viewer at the moment, Monty Linden has resumed work on the server-side of things. Commenting on this at the TPV/Dev meeting on Friday 19th October, Monty had this to say, “I’ve been working on server-side work … and as part of the next part of the HTTP work, there will be a server change, grid change. sim OS change. And I just want to let everyone know that at some point we’re going to have to put up some beta servers on the beta grid and start some testing … It will be an interesting change to the services.”
This work is related to the number of connection an agent can have open to a given service – essentially the development of a “fairness policy” with regards to service connections. The changes and the policy itself are liable to be fairly dynamic as they come into effect and LL monitor use and potential abuse and start to focus down on ensuring a reasonable balance is met. This will require extensive testing from TPVs to ensure their viewers are handling the new services correctly, whether they can operate within the policy in terms of number of retries or back-offs on a failed connection, etc., and whether they need to limit the number of connections users can manually open (where this is the case).
Other Bits
Viewer and FMOD
No major news on this since reporting it in week 41. It is still LL’s intention to do something about it, however no resource has been allocated to it as yet – with emphasis on the “yet” from Oz Linden. One of the hold-ups here is (again) the ongoing problems with the beta viewer, which require resources and effort to resolve.
Mountain Lion Support
The the TPV/Dev meeting on Friday 19th October, Oz reported that the Lab were making “great strides” on updating their Mac support for OSX 10.8 Mountain Lion, including gatekeeper support, and that the information should be available “quite shortly”.
64-bit Builds of the Official Viewer
The subject of 64-bit one that frequently arises in relation to the official viewer, particularly when mentions is made of memory leaks and the like, and it comes up not only among users. Remarking on it in the TPV/Dev meeting, Oz Linden said, “It is a bullet we have not yet decided to bite, but at some point we’re going to have to.”
He went on to point out that LL are already approaching a point where they’ll have to build OSX versions of the viewer in both 32-, and 64-bit, and that, “At some point the cost/benefit will tip the other way.” As such, he stated that any help LL can get from TPV developers in getting the code “64-bit clean”, etc., would be welcomed. In the meantime LAA support for the viewer has been merged into the development viewer (viewer dev) and is locked behind the current issues with the beta viewer.
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.
Inara Pey: Living in a Modemworld 