The following notes are taken from the TPV Developer meeting held on Friday November 22nd. A video, courtesy of Northspring, can be found at the end of this report. The numbers in braces after each heading (where given) denote the time stamp at which the topic can be listened-to in the video.
No Change Windows
As has been previously noted in this blog, week 48 (commencing Monday November 25th) is code freeze / no change window due to it being Thanksgiving in the United States. This means there was be not server deployments during the week and there will be no viewer release channel updates for the week.
The Christmas code freeze / no change window is scheduled to run from Monday December 16th through until Wednesday January 1st. This most likely means that once the code freeze comes into effect, there will be no major server updates until the 2nd week of 2014 (commencing Monday January 6th, 2014), and viewer updates may be likewise.
Both the Thanksgiving and Christmas no change windows effectively mean there are only two full weeks left in 2013 in which server deployments and major viewer updates are liable to be made. However, it is possible both periods could see project viewer updates appearing. This is because any project viewer which may be available will have limited use (only those particularly interested in using / testing it are liable to run it), and so minor updates, etc., to such viewers are not seen as being potentially problematic in terms of support issues.
As note in part 2 of this week’s report, the release viewer was updated using the GPU table updates release candidate, leaving just the Project Interesting RC in that channel.
There are upcoming RCs in the pipe awaiting release, including an updated version of the Google Breakpad viewer and another maintenance viewer RC, while the Project Interesting viewer is to update an update as well. However, as week 48 (commencing Monday 25th November) is a code freeze week for Thanksgiving, it is unlikely there will be any releases in the viewer release channel during the week.
Fitted Mesh Viewer
A number of JIRA have been filed in relation to the Fitted Mesh project viewer, and are receiving attention within Linden Lab. “We’re getting the repairs together,” Oz Linden reported to those attending the TPV Developer meeting, “And when we’ve got enough of them together to do a release with, that have been tested, then we’ll do an update to that one.”
Avatar Skeleton Files
The Fitted Mesh viewer actually contains a small number of actual code changes; the majority of the changes lay within the avatar skeleton and its associated filed (e.g. Avatar_skeleton.XML / avatar_lad.XML). This has led to speculation that other viewers can update relatively simply by using the revised avatar skeleton files. Responding to this, Oz said:
Ideally that’s true, but it turns out not to be quite completely true. It turned out that there were some code bugs that the new skeleton and weighting exposed. So there are actually some changes that will be beyond that. That is some code [to be changed].
“Adding bones exposed some limitations,” Nyx added.
One of the code fixes which is in progress appears to deal with the issue of how garments weighted to use the new skeleton appear in viewers which do not have the updates, as demonstrated in my preview article on the Fitted Mesh viewer, and shown below.
Time Frame for Formal Release
While the Fitted Mesh project viewer may well see one or more updates before the end of the year, there are no plans to progress it to a release candidate status before the start of the New Year (again, the no change windows would preclude that, at least in part).
Even with the changes now being made, the number of code changes within the viewer is “very, very small”, so when the code is in a position where the Lab is comfortable with TPVs taking it and merging it into their repositories, it should not create major issues. One thing that is not clear at this time is whether merging and incorporating the Fitted Mesh changes will be dependent upon merging other code releases coming out of the Lab, such as the Sunshine / AIS v3 code and the Project Interesting code.
Project Sunshine / AIS v23 Updates
Nyx Linden reports that the Sunshine / AIS v3 updates are going “really well”, and the Lab is focused on cleaning up the last few bugs of which they are aware, and it is hoped that the code will be ready for QA and then a project viewer soon, possibly prior to the December no change window coming into force. If the viewer does make it to a project release prior to that happening, Nyx will likely hold it over until early January.
In the meantime, the Lab is still keen to get started on more extensive load testing for the new inventory service, AIS v3, using the Sunshinetest regions (1-4) on Aditi. They’d preferably like the assistance of TPVs with this, the latter having been given access to the code a couple of weeks ago so that they could start work merging it into test versions of their viewers for this purpose.
Firestorm released a version of their viewer with the new Sunshine / AIS v3 code updates to their Beta testers in week 47, although this has yet to have the legacy baking code added back into it for the OpenSim version of Firestorm. The team is approaching this cautiously, as there is a need to try to isolate the code used in the legacy avatar baking process (which is still used on OpenSim) so that it does not interfere with / get altered by future merges with code from Linden Lab. Once this has been done, Firestorm plan to make the code available to other TPVs so that they do not have the same headache when faced with trying to reintegrate the legacy baking code into their viewers.
Both Firestorm and Kokua (the latter having integrated the Sunshine / AIS v3 changes into a test viewer at the start of November) have indicated they are now in a position to assist with any load tests. The hope is that this will take place during December.
One of the reasons the Lab is keen to get the load testing underway is so that any remaining issues with the server-side code can be identified, investigated and fixed prior to the code being deployed on any RCs on the main grid. Any initial deployment of the server code on the main grid would likely be handled “pretty quietly”, simply because it wouldn’t be exposed to any viewers that did not have the necessary updates.
“It is currently still in QA,” Monty Linden reported in reference to his current work with HTTP 1.1 changes within the viewer. while no bugs have so far been found with the new code itself, he did reveal that the work has uncovered “quite a few bugs in mesh in general”, which are being filed internally. Currently, it is predicated that the QA round is unlikely to finish before Tuesday December 3rd, so and project viewer will not be appearing until after that date.
In addition to QA testing not finding any bugs within Monty’s code, all the numbers coming out of the performance aspects of the testing are described as “equal or better than past history”.
In the interim, Monty is continuing to lay the foundations for HTTP pipelining. As indicated in my last update on his work, he’s been going through the third-party libraries and their repositories which are used in the viewer builds and updating them. This has led him into a number of “interesting” discoveries as a result of tracking through all of the repository dependencies, etc., and identifying the various package mismatches and unnecessary libraries which are being packaged with the viewer (noticeably in the Linux version of the viewer), as well as one or two libraries which are not being packaged when they should be, as well as the use of multiple versions of the same library (e.g. 3 different version of Boost, 3 or 4 different versions of zlib, etc.).
Oz added that a “wide range” of the problems relating to the use and packing of third-party libraries is being documented with the aim of putting together a project to get the issues cleaned-up, although this is unlikely to happen in 2013.
As a part of this work, Monty has requested TPVs contact him directly with issues they have found with the libraries so that he can also take a look at anything he may have missed which they’ve seen as he continues with the work.
We’re all probably familiar with Simon Linden’s proof-of-concept work with the Leap Motion device at the start of 2013. Leap Motion have now approached Linden Lab with a desire to see the control fully integrated into the viewer, and the Lab is looking to develop a project which involves Leap Motion and third-party viewer / open-source developers to make this happen. See my report on this here.
There are some sporadic reports of an issue when using the latest updates to voice with the viewer. The problem has been particularly reported by users on the latest Firestorm 4.5.1 beta and 64-bit Windows alpha release, although the issue has been reproduced on the official viewer, and takes the form of the speaker’s voice shuttering in what has been described as a “Max Headroom type” manner when listened to by others.
The issue appears to affect those using the latest version of Firestorm / the official viewer to speak and listeners using an older viewer / voice version, suggesting there is a conflict between the newer and older voice software elements (SLvoice plugin), although this has yet to be thoroughly tested and confirmed. Another problem is that the issue doesn’t appear to affect everyone, so pinning down the exact cause may take time and may require assistance from Vivox, although the suggestion is that it is some kind of buffering / backwards compatibility issue. There has been a previous JIRA on the matter of stuttering, BUG-3616 (Grid wide voice stutter issue), which Alexa linden has now re-opened.
Windows 64-bit Viewers
Singularity release a 64-bit Windows version of their viewer on November 14th/16th, and it has met with some surprising results, as reported by Latif Khalifa. The first was that when presented with an equal opportunity to download either the 32-bit or 64-bit Windows versions of the viewer, some 60% on the initial 20,000 downloads were for the 64-bit version. Even allowing of the degree of self-selection which may be occurring (e.g. those who are more adventurous and having higher-spec machines being more pre-disposed toward getting the “latest and greatest” version of a viewer), the Singularity numbers suggest that there is a significant portion of the SL community now running on 64-bit versions of Windows who will naturally opt for a 64-bit version of the viewer regardless as to any other limitations inherent in their hardware (age, etc.).
Also, and as with Firestorm, the crash rate for the 64-bit Windows version of Singularity has been significantly lower than that of the 32-bit bit version (although it has already been noted that people running the 32-bit version of a viewer on 64-bit Windows tend to also have lower crash rates).
One of the reasons for this is down to the 64-bit operating system being able to address more memory and PCs running 64-bit versions tend to come with more memory; however, it does suggest the people on 32-bit versions of Window and with very limited memory (2 GB) are possibly encountering more memory issues than has previously been considered.
Speaking for the Firestorm team, Jessica Lyon reported that the feedback on the Firestorm Windows 64-bit version has been overwhelmingly positive. The Lab is continuing to watch the 64-bit developments with interest.
64-bit Havok and OS-specific Crash Reports
There is currently no news on when a 64-bit version of the Havok library may become available. With regards to the crash reports, which TPVs are keen to see, the Lab is still working on building their reporting system, and Oz is still pushing to get the necessary breakdowns incorporated into the reports.
With thanks to North for the video.