Server Deployments
Wednesday November 14th saw the same code deployed to all three RC regions in preparation for the US Thanksgiving week code freeze (see below). This primarily brought all three RCs to the same code level, release-wise and fixed a bug discovered in week 45.
There will be no rolling restarts in week 47 (week commencing Monday 19th November) due to the code freeze.
SL Viewer Update
The beta viewer rolled to the last of the 3.4.2 releases on Thursday November 15th, with the release of 3.4.2266995. Providing the crash statistics remain good (they were very positive for the first 24 hours), it will be going to the production (release) viewer QA in week 47 and should result in the release of a new version of the viewer shortly after the Thanksgiving weekend.
This beta contains a lot of updates and improvements, as well as a wide range of fixes for issues encountered with earlier releases up to and including the previous beta release, 3.4.2.266708, issued on November 8th. For a comprehensive list of changes, please refer to the release notes.
At the same time, the development viewer rolled to 3.4.3.267061, marking a further update of the development viewer to the 3.4.3 code, which should be appearing in the next release of the beta viewer. This include the new viewer-side code for the HTTP texture fetch project developed by Monty Linden as a part of the Shining Project improvements.
As the holiday period is approaching, viewer releases will be slowing down, but the aim remains to try to clear the backlog of waiting merges and updates by the New Year with a view to resuming their more usual cycle of releasing a development / beta update around every three weeks. Once things are back on track, LL will be looking more closely once again at the question of disabling tcmalloc completely within the viewer.
Code Change Freezes
The official dates for code change freezes during the upcoming holiday periods currently stand at:
- Week 47 – Monday 19th November through to Sunday 25th November
- Week 51 – Monday 17th December through Sunday 23rd December
- Week 52 – Monday 24th December through Sunday 30th December.
No status has yet been given for the New Year week (Monday 31st December through Sunday 6th January 2013.
Avatar Baking
On Friday 16th November, Nyx Linden provided a brief update on the Avatar Baking project, which again forms a part of the Shining project improvements to Second Life. In short:
- The viewer code is starting to look stable. However, merging the new code into the existing viewer code is liable to be somewhat more “painful” (Nyx’s term) than had been hoped
- Work is progressing on the server-side elements (the composite baking server), with the code reaching a point where avatar texture can be generated server-side
- Currently, the plan is to continue working on both sides of the equation, with the aim of ensuring the new code is successfully merged into the viewer development branch, and then offering it in a “very alpha” form to TPVs so that they can start merging it into their code and assist with testing. As this happens, one or two regions on the beta (Aditi) grid will be set-up to allow testing on the new service.
There is still no time frame for the appearance of the viewer code in the development branch or any test regions on Aditi, but in Nyx’s view, both are liable to be on the horizon “pretty soon”. Overall, the plan still remains to have at least a two month period from when the code is made available for testing purposes through to the official implementation of the new service.
Interest List Demonstration and Weirdness
The focus of this project is to optimise the data being sent to the viewer, information already cached on the viewer and the manner in which that data is used in order to ensure it is used more efficiently so that things rez both faster and in a more orderly manner than is currently the case.
This work is being undertaken by Andrew Linden in a number of stages, the first being to clean-up the code related to information sent to the viewer from the simulator relating to objects in the camera’s viewing range such that only objects actually in the camera frame are updated (if updates are required) and that objects outside of the current camera frame are not updated, thus reducing the amount of data both the server and the viewer need to process, which should lead to performance improvements.
It is possible to visualise the update process using a viewer debug setting (Develop > Show Info > Show Updates to objects or Ctrl+Alt+Shift+U) to show object updates being received by the viewer. This shows updates in three colours: red, which indicates the viewer is receiving a “full” update on the object (generally because it is being “seen” / is within draw distance) for the first time; blue, which indicates the viewer already has data on the object and is receiving “terse” updates relating to changes in the object’s appearance / position relative to the viewer’s camera position; and green, which indicates the object has been deleted / remove from the camera view, and updates are about to cease.
On the 15th November, Andrew used this debug setting, together with a set of scripted “bouncing” cubes to demonstrate his improvements to this update process. Observers were asked to focus their camera on the cubes, which were initially static and had no coloured data stream associated with them. The cubes were then set bouncing, which generated a stream of blue “terse” updates, indicating the motion of the cubes in the viewer was being updated. However, when observers angled their camera to view the space above the cubes (so the cubes were not directly in their world view), the update stream ceased – indicating the viewer was no longer receiving update data for the cubes.
This may seem a small change, but it does dramatically decrease the amount of information the viewer has to process relating to in-world objects, and should result in performance improvements within the viewer. In the future, further work will be undertaken to enhance the interest list code even further – such as prioritising the order in which objects in the world view are actually rezzed, so that items closest to the camera view are rezzed first, etc.
HUD Issues
Following the demonstration, however, some people started noticing an odd issue: they could right-click on the centre of their screen and reveal a prim attachment belonging to someone else’s HUD. Chieron Tenk was the first to raise the issue, although Ana Stubbs also quickly reported the same problem.
After initial confusion, investigation revealed it was possible for anyone to find they had random prims from other people’s HUDs appearing on their screen, simply by attaching a HUD or a prim to their own screen. Concerns were further raised when it appeared that events might be able to be triggered if the prim was touchable.
The issue appears to be tied to changes made to the interest list code on the test region, and is obviously going to be the subject of further investigation on the Lab’s part prior to the interest list project being carried forward.
Inara Pey: Living in a Modemworld 
…do i get this right, that interest list update basically means that moving objects only move on your screen while you directly look at them?
…that is going to break so much scripted content…
LikeLike
It means that superfluous updates for the motion, etc., of objects which are outside your field of view are still being calculated server-side, they’re just not being sent to your viewer when the system calculates the object is outside of your field of view. When the object moves back into your field of view (by you camming back onto it for example), the interest list code recognises this and immediately resumes sending updates to the viewer once more, starting with where the object is “now” relative to your world view.
As everything is still being calculated server-side, there’s no reason for these changes to break any content. Well, outside of the current HUD peculiarity.
LikeLike
As All with LL tech, one never knows!
See the failure of path finding (who ever asked for that in 1st place!)
Worst is that is not LL that is learning with mistakes, but other commercial grids that are moving slowly but steadly into the future!
And only when in world you see the frustation of users, due to lag, to sims being restarted without worning, 2 or 3 times daily, one understands why many old residents are moving away and none of the new ones stay for long!
LikeLike
Where are regions being restarted “2 or 3 times daily”? The majority of regions undergo one restart a week on a Tuesday or Wednesday) unless something unforseen happens during the update deployment or the region owner punches the restart button. While there are at times mishaps which require additional restarts during a deployment, these are not as frequent as we sometimes imagine – they merely stick in the memory a lot more persistently, causing us to forget all the deployments which go smoothly in between mishaps.
As to whoever asked for pathfinding – well, quite a lot of people. Pathfinding has its heritage in a form of “AI” tools which LL were developing several years ago and then ceased (to much grumbling from users at the time). Since that time, people have prodded LL on-and-off for such “AI” capabilities, which could be used to great effect across the grid.
Where pathfinding went “wrong” was not so much that “no one wanted” it, but that in the way that the Lab deployed it – which appears to have been somewhat “arse backwards” and which was certainly very negatively communicated. With the latter, the Lab made absolutely no effort to reach out to the user community as a whole to keep them informed as to what was going on through the deployment process, with the result that the message ended up in the hands of the community itself. Because of this, and despite the best efforts of even those with a high level of technical understanding about SL, the message ended up being badly mangled, giving rise to a huge amount of negative misinformation to get into widespread circulation – a lot of which still appears to be the entrenched view among a good many users even today.
As to “moving into the future” – technically, there is plenty of that happening in SL. As these weekly reports demonstrate, there is a lot coming down the pipe. Individually, the changes coming may not include a huge “wow” factor, but collectively, they could – should, hopefully – do much to significantly improve the look, feel and operation of SL.
Certainly, there are problems LL need to address on the non-technical front; tier is a major (and complicated) issue which has to be addressed at some point. Retention issues need to be revisited (again, no easy matter – and the reasons people don’t “stick” with SL are often far from being technical in nature), and – frankly, they do need to look again at how the message about Second Life is managed when it comes to their own users (the situation with pathfinding being a case in point: LL surrendered the message with the result that misunderstanding and misinformation were given free reign to spread across the grid).
LikeLike