SL project news: week 42 / 2: viewer, mesh, shining and more

SL Viewer

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.

3 thoughts on “SL project news: week 42 / 2: viewer, mesh, shining and more

  1. What ever happened to the gaming/experience tools, no one has said anything about this amazing new feature coming to SL since… well… year ago. I guess it’s pushed so far back by the current viewer troubles that it’s not on the same page anymore.

    Like

    1. If you mean the advanced content creation tools, they are already out and available, as they are all server-side but we’re waiting on the permissions system to be updated to make full use of them. I’ll ask about what is going on with that next week.

      Part of the problem is so much is going on that it’s easy to lose track. I’ve mentioned mylti-threading region crossings a few times recently, but other commentators had thought that project was sleeping as nothing had been asked / mentioned of it of late, yet up it pops again this week (see the Teleport Timeout bit on Page 2) as something which is still being tinkered with, but does have the Linden “Coming Soon” (TM) associated with it, as it has yet to reach Aditi or a Release Channel 🙂

      Like

Comments are closed.