The following notes are taken from the TPV developer meeting of Friday August 15th. A video of the meeting, provided by Chakat Northspring is included below. This report represents an overview of items discussed at the meeting which are liable to have the broadest interest among users. Timestamps are given against items and paragraphs for ease of referencing what was said within the video for those who wish to listen to the entire conversation on a given subject.
Note that subjects are not necessarily presented chronologically when compared to the video, but has been grouped under common headings.
My thanks, as always, to North for her recording of the meeting and linking to this blog post.
SL Viewers
[00:30] There have been few visible changes with the RC and project viewers this week. The library refresh viewer and the experimental log-in viewer remain unchanged, and while the Experience Keys project viewer has been updated, this has yet to appear in the Alternate viewers wiki page.
Oculus DK2 and Project Viewer Updates
[00:50] The lab has received around half-a-dozen of the Oculus Rift DK2 headsets, and so it is anticipated that further work will be progressing with the project viewer, and updates will be emerging over time. As noted in week 32, there are some substantial differences between the DK1 headset and the DK2, which currently make the project viewer largely incompatible with the newer headset.
Texture Statistics Logging
[19:15] With the roll-out of the 3.7.7 the Lab unfortunately broke the texutre stats reporting debug option LogTextureDownloadsToSimulator. As this is off by default (set to False) it has not been noticed by most users. However, the recommendation is that users do not set this option to True, as it will cause the viewer to immediately crash on start-up, at the next attempt to run it. This issue is common to all viewers using all code releases subsequent to 3.7.7 as well.
Viewer Build Process
[40:24] The Lab is shortly going to commence the process of upgrading the tool chain they use in the viewer build process (e.g. switch to Visual Studio 2013 for Windows and Xcode 5 for Mac) and switching over to the new version of autobuild. This work may also eventually help pave the ay for 64-bit builds of the official viewer. However, this is not currently the focus of the changes, as no decision has made as yet within the Lab on producing 64-bit builds of the viewer; the current aim of these changes is to improve the overall viewer build process.
[47:23] There are two points of note here. The first is that the new autobuild process includes changes which self-compilers must adhere to if they are using it, and details are available on a wiki page. The second is that it is probable that Windows viewers built using Visual Studio 2013 will not run on Windows XP. The Lab has already dropped Windows XP support, which is as much as it will currently say in terms of future viewers built using the new tool chain running on XP.
Group Chat
[02:00] The work on group chat has temporarily halted due to those working on it either being on vacation or working on other projects. Given this, and with a degree of ironic timing, there have been increasing reports of group chat issues over the last several days, including one chat server apparently becoming completely non-responsive.
It’s not clear to the Lab as to what may be causing the problems, but they have been noted. In the meantime, informal advice is that if your group chat is consistently failing, to contact support, provide them with the information on your group (name, etc.), and the issues you’re having, and request the chat server is restarted.
Texture and Mesh Over HTTP
[05:30] As a part of Monty Linden’s continuing work on HTTP, the Lab has started experimenting with how textures and mesh are fetched via HTTP. The work is currently very preliminary, and is aimed at improving the overall reliability of fetching over HTTP.
specifically, the Lab is looking to move texture and mesh fetching to a content delivery network (CDN). The work is currently proof-of-concept, currently using the same CDN as used with avatar bakes (although this may change). If successful, this approach will see texture and mesh fetching bypass the simulator entirely, being routed between the viewer and asset servers via the CDN, thus removing the simulator as a possible bottleneck.
The next stage of the work is to establish test regions on Aditi which will be used for testing the approach with different viewers (currently, no viewer-side update is required with the new approach, although if the project does progress as hoped, there will likely eventually be viewer-side updates) and with larger numbers of users to present better load testing situations.
[10:54] An eventual hope is that should this approach prove successful and reliable, it and the deployment of HTTP pipelining will allow the Lab to retire the use of UDP texture fetching (much as they did with avatar bakes), although this is liable to be some way into the future, and is dependent upon the HTTP approach(es) all working an anticipated.
Avatar Height Offset Proposal
[26:57] As reported in my week 25 updates, a proposal for delivering a better z-offset height adjustment capability than is currently provided through the official “hover” option, was forwarded to the Lab (see also SUN-38) at the end of June.
This has been percolating through the Lab’s thought processes for the last few weeks, with generally positive noises being made towards something being done to revisit and improve avatar height offset issues.
The Lab hopes to be able to develop something that will address the problem in a way that is conceptually easy for users to grasp, and which will allow viewer developers to present a simple means by which users can adjust their height offset through the viewer.
Updates made through any viewer-side mechanism will be sent to the simulator to become a part of the avatar appearance packet sent to all viewers connected to the region, thus presenting a consistent view of the avatar to everyone around it. As noted below, there are several levels of complexity involved in this due to the way in which the z-offset might be used.
One thing that will not happen with any new solution is that any manual adjustments made to an avatar’s height offset will not be persistent across log-in sessions from the simulator’s perspective. This likely means that to ensure manually applied offsets can be re-applied at the next log-in, TPVs may provide a means of storing them viewer-side, and the lab is not opposed to them doing so.
A Side Note on Height Offsets
One of the odd features of the present system is that an avatar’s z-offset can be affected in a number of ways. Rigged mesh items, for example, can be uploaded with a defined z-offset, and we’re all familiar with how scripted attachments might adjust an avatars height when wearing them (the familiar “bounce” as the avatar moves up and down).
Which height offset ultimately affects an avatar depends on the order in which things are worn. Essentially, the last item with any form of z-offset parameter that is worn is the one for which the height offset is applied to the avatar’s appearance packet by the baking server in order to adjust the avatar’s vertical position.
A problem here is that when several items with their own height offsets are included in an outfit, the order in which they are worn by the avatar (using the wear or add outfits options) is entirely random; thus there is no way to predict which item may be the last worn and its offset applied. Therefore, part of the Lab’s approach to allowing manual adjustments to the z-offset will ensure that it is always the last offset value applied to the avatar’s appearance packet, and thus the one that gets used.
As a broader part of this work, once the Lab is in a position to start it, is that the Lab hope to be able to look into some of these issues of how and when an avatar’s height offset is affected, with the aim of hopefully – if it can be done – making them work in a somewhat more predictable manner.
Inara Pey: Living in a Modemworld 
CDN for textures and mesh sound great, I hope it will eliminate, or at least greatly reduce, the inordinate time required to load them at very busy sims such as product fairs & other events.
LikeLike