The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, September 23rd. The video of that meeting is embedded at the end of this update, and references to it are indicated through the use of time stamps in the paragraphs below. My thanks as always to North for recording and providing it.
This is not intended to be a transcript of the entire meeting, which featured discussions of some situations specific to individual region rather than SL as a whole. However, key discussion points have hopefully been highlighted.
There was no update on the Main (SLS) channel on Tuesday, September 20th. On Wednesday, September 21st, all three RC channels should receive the same new server maintenance package, containing further “minor internal changes”.
VLC and Project Bento RC Viewer Updates
On Tuesday, September 20th The VLC media plug-in viewer updated to version 126.96.36.1999856, while the Project Bento RC viewer updated to version 188.8.131.529893 on Thursday, September 22nd. In both cases, the updates were primarily intended to bring the viewers to parity with the de facto release viewer code base.
It is hopes the VLC media plug-in viewer will be promoted to the de facto release status in week #39 (week commencing Monday, September 26th).
Clarifications was given at the TPV meeting that the 64-bit version of the official viewer will be Windows, Mac and Linux, with the 32-bit version of windows continuing, Mac and Linux moving purely to 64-bit. Active development of the 64-bit viewer is expected to resume in week #39, with the intention of getting the viewer out and available sooner rather than later.
Autobuild, Public Sources and Viewer Building
Part of the 64-bit viewer work involves viewer build infrastructure changes. These include updates to how public sources should be built and to the viewer Autobuild process. In particular, these updates allow the viewer library files to all be built using the same compiler switches regardless of build system. The wiki documentation for viewer builds will be updated to reflect these changes, and there may be a presentation on things at the next TPV Developer meeting. There is a separate file for controlling the compiler switches, so if TPVs and self-compilers wish to build their viewer with different compiler settings, they can swap this file with their own.
As per the Lab’s recent blog post, all official viewer versions older than 4.0.5 have been blocked from accessing Second Life. Users on such viewers will be required to update their viewer to a more recent version. This has been done to encourage users to keep up with the numerous changes and improvements being made to the viewer.
That same blog post indicated that the Lab are discontinuing support for Windows Vista and for Mac OSX versions below 10.9. The Lab is doings its best to maintain back compatibility wherever it can, but where the underlying technology loses support, etc., then it is not possible for the Lab to continue maintaining support either (the more recent versions of CEF, for example, do not work on Windows Vista).
The recent changes to the viewer code are said to be significantly reducing the crash rate for the official viewer, and it is hoped this will continue with further improvements to the code and through the coming availability of 64-bit versions of the viewer.
Avatar and Object Rendering Investigations
[12:12] Vir Linden is starting to work on a new project (concurrent with Bento) involving digging into avatar and object rendering, and land impact. The work is due to an accumulation of issues raised concerning rendering costs by users, and the investigations at this point are focused on what might be improved and what cannot be (due to issues like backwards compatibility) .
This will involve taking “a bunch” of representative / problem cases, and try to take a set of carefully defined measurements of what the real impact is during rendering on a wide range of systems. It is hoped this will allow the Lab to adjust the formulas used to make a reasonable generalisation in the rendering cost of things, and whether or not objects are being reasonably accounted for in those calculations. At this point in time, it is not a given that anything will chance – simply because it has been a long while since the Lab took a similar “deep dive” into rendering, but there is a “good possibility” changes will result from the investigations.
Avatar Rendering Calculations
[14:54] Avatar rendering calculations were expanded upon by Oz in terms of what happens now, and what the intent was behind things.
The viewer, providing it is using LL’s code unchanged, sends to the simulator a report on what it believes is the rendering cost of all the avatars it can “see” in a region. The simulator then averages the reports from the various viewers, with heuristics to remove excessive values at either end of the scale, back to everyone in the region.
Right now, the viewer decides how to render each avatar it its view purely on its own per-avatar calculation, using the full dataset for each avatar. However, by using the average value calculated by the simulator, it should be possible for the viewer to start making decisions on whether or not to render avatars in a field of view based on that average (compared with its own Max Complexity setting), without having to wait for the full data on each avatar to be received. The viewer-side code to allow this has yet to be written and implemented, but may form a future project.
[18:34] The other aspect of avatar complexity calculations is that the viewer sends to the simulator a single bit of information for each avatar it can “see”, on whether or not the avatar is rendered as a Jelly Doll. The Simulator then counts how many viewers are reporting on each avatar, and how many of those are rendering that avatar as a Jelly Doll. This information fed back to that avatar roughly once a minute to generate the pop-up notification we see in the top right corner of the viewer window.
Due to the nature of the system, the updates can be delayed, or include out-of-date information. For example: data on avatars who have left a region isn’t immediately discarded by the viewer, but is held for a certain amount of time. Similarly, when changing outfits, you get an immediate update on your complexity (as it is a local calculation), but the number of those who are not rendering you fully is delayed by around 90 seconds while your updated appearance is sent to other viewers and they respond to the simulator with their information on whether they are rendering you fully or as a Jelly Doll, and the simulator feeds that information back to you.
[25:15] As noted in my Avatar Complexity updates, the complexity value assigned to an avatar can differ by up to 2K in value between those looking at the avatar. There are a number of reasons for this, including differences in the rendering capabilities of the systems viewing an avatar, and level of detail seen / distance. While it is not a high priority, the Lab is considering tuning how complexity is calculated (such as removing the LOD / distance factors from the calculations).
There are two significant bug reports for issues with the current viewer-side avatar complexity calculations:
- BUG-37642 – an avatars complexity value can double or triple following a teleport or relog without changing its outfit. This appears to be triggered by certain outfits / attachments.
- BUG-37631 – wearing a rigged mesh with any amount of transparency applied to it results in a 4 times higher complexity value. This appears to be due to x4 multiplier used in the Mesh/Rendering Weight calculation for an alpha being applied to the entire avatar complexity calculation, rather than just the vertices using the transparency.
BUG-37692 – llRezObject() and llRezAtRoot()
[39:30] BUG-37692 has been raised at a number of recent UG meetings, and is seen to be causing a wide range of issues, notably for weapon systems used in combat environments. The Lab does not currently have a response for the issue, which will be looked at during the next triage period, on Monday, September 26th.