The Viewer Release Process and Viewer News
There are currently five viewer release candidates sitting in the viewer release channel. These are:
- CHUI updates
- Cocoa updates for the Mac version of the viewer
- Google Breakpad updates (fixes and updates to improve the level of crash reporting from the viewer)
- Maintenance viewer updates
- Snowstorm updates (third-party contributions to the viewer)
As the first release candidate has now become the de facto viewer release (the Vivox updates, see part one of this report), all of the remaining release candidates are undergoing rebuilds using the “new” release viewer code base, and this is expected to be completed in week 33.
The current number of release candidates is considered to be atypical of the process, and reflects the fact that there is a backlog of viewer updates to be cleared. Once this has happened, it is anticipated that the number of release candidates within the viewer release channel will fall. In the meantime, it means we could be seeing new viewer releases (i.e. release candidates being promoted to the de facto release viewer) at the rate of one a week, depending upon how well individual RCs perform in user testing, until such time as the number of RC viewers becomes more manageable.
Installing Multiple Release Candidate Viewers & the Auto-updater
By default, release candidate viewers are intended to install / be installed into the same location as the de facto release viewer. Therefore, if you wish to run multiple RC viewers, you must install them manually into separate folders.
However, there is a problem in installing multiple RC viewer under windows, whereby the last location used to install a viewer is recorded by the installer (presumably as a registry setting), and the auto-updater will automatically use that location to install any update. So, if you manually install “Release Candidate B” into its own folder, and then receive an update for “Release Candidate A” (already installed on your PC) via the auto-updater, it will be installed into the folder containing “Release Candidate B”, overwriting it. This may even happen if the auto-updater is “disabled” within viewer preferences (see here for notes on how to avoid this).
At least one JIRA (non-public BUG-3522) has been raised against this issue. However, while LL are still investigating the problem, if it lies within the installer itself, it may not be addressed as there is an unwillingness at the Lab to get deeply involved in the mechanics of the installer.
Viewer Downgrades
There have been reports of the auto-updater mechanism forcing people to downgrade their installed viewer to an earlier release. While it “shouldn’t happen”, and may have been fixed, anyone who does experience the problem when auto-updating a viewer is asked to raise a bug report with as much information as possible on what happened (i.e. version being run before the update, version running after the update, date of update, etc.).
Making the Viewer Management System Available to TPVs
The Lab is experimenting with making the viewer management system available to TPVs if they wish to make use of it. This will mean that TPVs will have to port the code for use in their own viewer / environments, but it could help them with automating viewer updates if they don’t already have such a mechanism in place. One of the potential benefits of this for those TPVs following the Lab’s lead is that, as a result of changes also being made to the Lab’s reporting mechanisms, they will be able to receive a range of stats reports on their viewers directly from the Lab.
Settings.xml Changes
The current Snowstorm release candidate includes a change to how the settings.xml file works (the file which controls your viewer settings). This change will only affect those who have more than one Linden Lab viewer installed on the same computer (for example, someone who has the release viewer, a beta viewer and several project viewers installed), and will see all of the installed LL viewers using the same settings.xml file, rather than each creating a separate version of the file. This should prevent issues where the settings from one LL viewer are incorrectly applied to another, as can sometimes occur at present.
Interest List News
As noted in earlier parts of this report, Andrew Linden has wrapped-up his current work on interest lists. However, the project viewer for some of the work still has yet to appear, and is apparently still encountering problems getting through LL’s QA process. The code has been “real close” to being ready for release in some form on a number of occasions before getting kicked back for further work. The hope is that it will appear as a project viewer – or possibly a beta or release candidate – “soon”.
Server-side Appearance Update
Number-crunching has been continuing with the current deployment of SSA on Magnum and LeTigre and Nyx Linden reports that it is still all looking “pretty good”.
Further to Simon Linden’s comments at the Server Beta meeting on Thursday August 8th, Nyx confirmed that no additional regions will be SSA enabled in week 33, but that grid-wide enabling could occur in week 34 (week commencing Monday August 19th).
In terms of the back-end updates which Simon also mentioned, Nyx gave further information on the work:
We are going to be rolling-out some changes to the back-end servers, the ones that are actually doing the baking. You shouldn’t see much difference, but there were a couple of scenarios where the viewer would have to re-try requests when it shouldn’t have to. So we’re trying to get that cleaned-up before we roll-out to the whole grid.
Again, just to emphasise: the changes Nyx is talking about are to the dedicated server-side appearance servers, not to the simulator servers, so there will be nothing in the deployment notice in week 33 relating to the work.
SSA Viewer Updates
Nyx reports that the next set of viewer-side changes will be available for TPVs soon; he’s currently waiting a further merge-up with viewer release. He also indicated the Lab is getting close to having a “pretty good set” of the new inventory functionality (AIS updates – see part one of my week 30 report), which will see Current Outfit Folder communications between the server and the viewer handled as capabilities within the service, rather than relying on UDP messaging (a possible point of failure). While the code is not yet ready for public testing or TPV integration and has yet to pass LL’s own QA, he is hoping to get the code to an external repository so that TPVs can at least start looking at it.
HTTP Update
Monty Linden has been carrying out further performance testing on his mesh related HTTP work. “It looks good,” he informed the TPV Developer meeting on Friday August 9th, “The goal with this one isn’t so much performance improvements, but much better connection behaviour. Generally, I’m getting the same mesh throughput with one-quarter of the number of connections [eight as opposed to the original 32]”.
He still hopes that his work will emerge in a project viewer before the end of August, although this is not certain. In the meantime, the associated server-side changes are ready to be QA’d, although there is also no date as to when they will be incorporated into a deployment package.
Other Items
Animation Overriders
A complicated series of questions were asked at the TPV Developer meeting as to whether Kelly Linden’s work on adding server-side LSL AO capabilities might at some point herald the arrival of a client-based AO capability within the LL viewer (such as implementing an API which would allow the viewer to utilise the new LSL capabilities).
It’s not clear whether this has been considered within the Lab, and Oz indicated he would check on what the plans (if any) are for the new capabilities going forward, given that the Lab is trying to “make AO work better” (which doesn’t necessarily mean they are trying to make all existing AO systems work better, but rather that there should be a better way to build AO systems), and whether any API might be in anyone’s thinking.
Object and Texture Caching
During the TPV Developer meeting in week 26, the issue of problems within the object / texture caching came up, with Oz suggesting it might be an idea to consider forming an LL / TPV project to look into the issues and determine possible remedies.
While the idea has been taken back to the Lab for consideration, there is a certain reluctance to commit to it on the part of product managers because complex relationship between the viewer’s multiple caches and its core code. Or, as Monty Linden put it, because “there are surprising couplings between cache designs and functional code – it is hairy like a Sasquatch.”
This means the work required in teasing them apart to determine root causes to problems and resolving them could be a long and intensive process, with the end benefits difficult to quantify and qualify from the outset.
A further problem with such a project is gaining consensus on what actually needs to be done in order to fix issues and problems which come to light – a fact demonstrated by the fact that a TPV team looked at caching themselves and could not agree on the best means to handle the issues they uncovered.
Therefore, while such a Lab-led project is not outside the bounds of possibility, it will likely remain at the back of the queue behind other things which can be done within the viewer which are either easier to achieve and / or less likely to generate disagreements as to how they should be handled.
Liquid Mesh Concerns Voiced
Liquid mesh is the brand name for mesh items which (I’ve been informed) is based on the technique first proposed by Redpoly Inventor. It first appeared at the end of 2012 (Nalates Urriah has a review). This technique works by rigging to the avatar’s collision volume rather than the avatar’s skeleton and which, more particularly, uses unsupported bones outside of those recommended for mesh rigging.
While the Lab has repeatedly stated the technique is unsupported and could therefore be adversely affected by future changes to Second Life, concern has been expressed that these warnings are largely invisible to users who purchase mesh items using the technique, and that unless something is done to clarify matters, the Lab could face a huge PR backlash among users should something happen which does end up “breaking” this content.
One way of overcoming the situation would be for the Lab to accept the technique and regard it as supported. Should they decide to continue to regard it as unsupported, views were expressed that they should consider stopping the mesh uploader accepting mesh content which is rigged to unsupported bones – although this also is not without issue.
Nevertheless. the current situation is perceived as being the worst of all possible situations. Whether or not the Lab moves on the matter – and how – remains to been seen, although the indications are that they are unlikely to adopt the technique as a supported capability (although the reasons why were not entered into at the meeting).
Related Links
- TPV Developer meeting video – Chakat Northspring
Inara Pey: Living in a Modemworld 
I think I have a hunch as to why Liquid Mesh is unlikely to be adopted as a supported capability. Two months ago, I asked Oz Linden at the Open Dev UG meeting about the status of the mesh deformer and he pointed clearly to STORM-1716. He also said, and I quote (emphases mine):
To me, this is a strong pointer that the Lab is moving to solve the matter by using an approach that will be one of the following: (i) Qarl’s mesh deformer outright, (ii) an improved version of Qarl’s mesh deformer, (iii) an approach that will do what Qarl’s deformer does, perhaps coded somewhat differently.
At any rate, the deformer we may see from the Lab will be something along the lines of STORM-1716, and NOT Liquid Mesh, which, as Nalates’ review showed, is a sub-optimal solution.
LikeLike
I found the discussions around liquid mesh very interesting. The unspoken takeaway is that the lab will break this functionality, no one really questioned this. Certainly if it is known fact that this rigging method will be broken the lab should disable the ability to use it. One thing I want to comment on though was the contention that designers don’t know or shouldn’t be expected to know about these things. Certainly there are a lot of small time clothing sellers, often working off mesh templates, that don’t understand the rigging one way or another. But Redgrave’s and Angel Red are designers that should be very aware of what is going on. They are not small names. They designers should be at content creation meetings and should have gotten this message. That they release liquid mesh anyway speaks more about the business practice than anything else.
It will also be interesting to see what comes of the discussion on ALM in the materials code reducing performance. There was obviously some contention there.
LikeLike
I admit to not having followed liquid mesh that closely, although I had a poke at Redploy Inventor’s original approach in 2012 to see what it was about. So like you, I found the discussion interesting. I not so sure that the Lab “will” break the functionality per se, rather than they simply won’t care *should* the break the capability somewhere down the road; but it’ll be interesting to see if they take the voiced opinions onboard and do seek to do something.
As to whether designers are aware or not, one of the problems is that, large or small, not every actually attends the in-world meetings or reads the wiki, so there is a chance that people leap before looking / considering. That said, I I do agree that well-established brands and names should perhaps do more to keep an ear to the ground so they are aware of what is going on.
Regarding ALM – I’m drafting a post on materials, etc., which will be covering this. I didn’t include it within this project update as (as Oz indicated) “ALM” covers a multiude of sins / issues, so I want to have something which is focused on the subject (and things like the problems with full bright, glow, etc. & didn’t want to swamp this update with it. Not sure when the piece will be out; I’ll have my hands full for the next couple of days – but it will be coming :).
LikeLike
Personally, I think that anyone who wants to create content for any platform ought to actively seek to learn it’s capabilities, limitations and related developments. Otherwise, they should just forget it.
The way I see it, any.potential PR fiasco should be a risk only for the creators who opted for a stopgap, unsupported method.
But even this can be avoided, IF they are clever. They could just send updated versions of their clothing to their customers when the official deformer rolls out and they’ll pass off as creators who care for their customers. If they don’t do that and choose to start drama instead, they’ll.have my derision, which they’ll richly deserve.
LikeLike
ETA: An “it’s” in my comment above should be “its”. Gotta love smartphones and their autocorrect function.
LikeLike
A typical Nsa way of dealing with the problems, God im so tired of seeing the name of the Lab be put down cause their lack of emphasis with users!
LikeLike
Is there any way of determining before you buy a product if it is using Liquid Mesh? I can easily imagine that a vendor might sell a Liquid Mesh product as Rigged Mesh, even though the product is using Liquid Mesh technology, opting to avoid confusing customers.
LikeLike
Redgrave supply Liquid Mesh under that brand name, so it should be easy to identify in their stores.
Redpoly developed the initial approach, but as I don’t really use mesh clothing, I honestly have no idea if the technique is still used in his retail items (there was a dress using it on sale back in 2012). CheerNo was also mentioned in the TPV Developer meeeting as using the technique, but again, I have absolutely no first-hand experience as to whether they do or what they make.
Hopefully someone who does make use of mesh may be able to provide more information.
LikeLike
Also, by way of Strawberry Singh on Plurk, I found out that Bax has started using liquid mesh. Another brand that should know better.
LikeLike
I am quite well informed about the matter and I have yet to see a proof of LQM going to be killed anytime soon. I have been waiting for a better solution way too long already. LQM is here and it’s working reasonably well for boots and it’s a great convenience for my customers, thus my decision to use it. If LL is ever deciding to kill it, I’ll provide a free update using whatever best alternative method is out there at that time. Of course, LL Employees will say they don’t support it. Collision bones were not supposed to be used in that way and now this falls into their lap unexpectedly and the least they want is taking responsibility for something other than what they absolutely must. But remember, not supporting does not mean wanting to kill.
LikeLike
I don’t know what LQM’s ultimate fate will be. However, given what Oz Linden had said in that Open Dev meeting, to me it seems that the safest bet is the mesh deformer as defined by Qarl.
LikeLike
..which still sits in LL’s drawer after a year+. Does not convince me to wait any longer when there is a solution now. It’s not perfect but better than nothing.
LikeLike
http://strawberrysingh.com/2013/08/11/inventory-meme-liquid-mesh/
Linden Lab must clarify this subject!
LikeLike