Materials Processing
As reported in part 2 of this update, the release viewer was updated on June 27th with a release containing a number of updates and fixes, including some for materials, such as occlusion culling is less effective than it should be, especially with regards to very large objects; light function sampling being incorrect in advanced lighting model and the legacy Shiny options being overly strong in deferred rendering. The initial fixes for these issues are considered important for TPVs to pick-up when integrating materials into their viewers, while follow-up releases (such as the new 3.6.1277824 beta viewer released on June 25th, being viewed as slightly less important at this time.
The latest stats the Lab has on viewers show that some 30% of users are currently running with the Advanced Lighting Model option (ALM – otherwise known as deferred rendering), and are thus able to see materials in use in-world, although the stats also appear to indicate that up to 75% of the user base have hardware capable of running with ALM enabled, “with reasonable performance” in terms of frame rates (e.g. an average somewhat above 10 fps). However, given that fps is a highly subjective measure and somewhat dependent on a range of external factors (such as how many other avatars are in the region with you, whether you are moving around a lot or not, etc), the “YMMV” rule comes into play.
The Lab has already carried out a fair amount of performance tuning with ALM, and at the TPV Developer meeting on Friday June 28th, Oz Linden reported that further work is going on in this area, which will include some profiling of the shaders in order to try to further improve performance.
Currently, and as previously reported in these pages, the Cool VL viewer experimental branch and the Black Dragon 2.2.3 beta both provide materials processing capabilities.
Viewer Release Process and Viewer Updates
The expectation is now that the new viewer release process will come into effect during week 28 (week commencing Monday 8th July). The process is actually ready to go, but as with the server-side of things, the 4th July no change window means that the process cannot be implemented in week 27.
Vivox Update
Once the new process is running, the Vivox update is likely to be one of the first items to go to a viewer release candidate. This update should greatly improve Voice quality within SL. A further Vivox update is liable to follow this at some point.
Interest List Improvements
The viewer-side interest list updates are coming, although the viewer repro has yet to be made public, although again it is anticipated that a project or beta viewer with the updates will be made available after the holiday period, and TPVs will be able to obtain the code.
Viewer Settings
The Lab is moving to eliminate the use of viewer settings files based on channel name. This means that in future, a single SETTINGS.XML file will be used for all versions of an SL viewer which is installed. The code for this is moving towards the release channel of the SL viewer, and the hope is that it will prevent issues of confusion when settings appear to be “wiped out” when using multiple versions of the viewer (e.g. such as moving between the SL release viewer and the SL development viewer and back a few months ago resulted in people’s toolbar buttons “vanishing” from the release viewer).
Server-side Baking / Appearance
Deployment / Enabling
As indicated in Nyx Linden’s e-mail / in-world note, the plan remains to start enabling the SSB/A server capability on or around July 9th. There is a possibility this might slip by a week due to the Independence Day holiday code freeze which is in place for week 27.
Commenting on the state of the project at the TPV Developer meeting, Oz Linden said, “We’re in the home stretch now, and we really, really mean it,” to which Nyx Linden again urged all users who have not done so to update their viewers to a viewer / version which has SSB/A support enabled.
Pile-on Test
There will be a final SSB/A pile-on test on Tuesday July 2nd.
Viewer News
As noted in my Server-side Baking / Appearance updates, a further viewer-side update is anticipated after the server code has been enabled (post 3.5.1 viewer code). Commenting on this at the TPV Developer meeting, Nyx Linden said, “It’s still under active development. We haven’t started our stabilisation pass yet; there’s still a couple of small features we’re going to be adding and bugs we’re going to be fixing. So it’s not getting ready for release yet … The source is available for pre-merges, but it’s not ready for release.”
The Lab is planning on monitoring the number of viewers connecting to SL which are SSB/A capable – both LL viewers and TPVs. This will be part of a new reporting system the Lab is looking to introduce, and will let the Lab track where things stand on SSB/A.
Issues Update
The server-side fix for SUN-74 (the skin/eye/hairbase corruption issue which may affect people running non-SSB/A capable viewers on SSB/A regions when wearing Modifiable versions of the named items) has yet to be merged-in with the server-side trunk code. The code will now be deployed after the week 27 code freeze, although the Aditi SUN test regions have been updated to allow testing of the fix there.
Issues have been reported with upper body bake fails / blurred layers affecting two users on the closed-beta SSB/A test regions (see SUN-94, Tazzie Tuque bakefail on Testylvania Sandbox and SUN-88, Blurry upper body on SSA-regions), which are under investigation.
Local Rebakes (CTRL+ALT+R) have been reported as “no longer working” as a result of SSB/A updates. This is actually incorrect. Local rebakes will still work when required both during and after the SSB/A deployment, should they be required.
HTTP Work
Monty Linden reports that he has been working on mesh and HTTP (which he has previously referred to mesh as “shotgunning” the network in terms of the number of connections it demands. The first part of his work in addressing this will involve two server releases, which will be followed by a project viewer release – all of which constitutes a major mesh update, although much of it will be “under the hood” improvements, rather than being anything with major UI visibility.
Other Items
Cache Issues
SL cache issues are not a new problem. There are many and varied issues with the caching system which the Lab itself acknowledges. “[Part of] the problem is that every time we introduce a new object, someone decides that this is an excellent opportunity to investigate new caching schemes,” Monty Linden said at the TPV Developer meeting, “Every single one of them has been a custom job to some extent, and none of them are actually implemented reliably.”
However, this is not to say that clearing cache is a de facto fix for all ills one encounters within SL. For example, it is unlikely to help with issues of “lag”. This is a common misunderstanding at large events such as fashion shows, where models can be told to “clear cache and relog” prior to a show in order to “improve performance” – whereas the reality is, by clearing their cache, they are actually degrading performance by forcing their viewer to request completely fresh data on the region they are in – as is everyone else around them who has done the same.
That said, there are also times when clearing cache does appear to be the only means by which some issues can be cleared – such as inventory load failures, for example. This is why some TPVs recommend a “clean install”, because very often users will upgrade and find their inventory will not load and blame it on the newer version of the viewer they have just updated to, and then roll back to a previous version.
A further problem with things like inventory load failures is that there doesn’t seem to be any common root cause or issues. Someone with 25K of items in their inventory can never experience a failure, whereas someone else with 25K in their inventory find it routinely fails to load – which may be related to something like network issues impacting the inventory load process or may be related to other issues.
Commenting on the general state of caching, Oz Linden said, “Maybe what we as a group [LL and TPVs] should figure out a way to do is to create a project to work out what the problems with the caching are and fix them.”
Quite when and if such a project forms remains to be seen, however, there was strong support for such an initiative from the TPVs attending the meeting.
Video courtesy of Chakat Northspring.
Inara Pey: Living in a Modemworld 
With all the changes, all the different servers supplying objects via HTTP, it’s likely time to look closely at caching. With much bigger hard drives, there’s also a need to look at how the code deals with a very large cache.
I don’t know what some of the figures in the stats window mean, when it comes to measuring cache effectiveness, but is a big cache, such as is available in Firestorm, really a good idea?
LikeLike