Second Life™ Viewer 3.6.8 (282367) Oct 14 is a hot fix release for an ATI driver incompatibility problem. The Release Candidates will be getting updated with this change too.
Richard Linden says the project is coming to an end and viewer side source code is out. TPV Dev’s are looking at it. The changes have NOT been through QA and are NOT ready for release. But, at least TPV Dev’s can see what they will need to handle. More eyes mean more bugs found and more brains thinking mean more solutions and improvements.
While building the coming Interest List release the Lindens were focused on things not rendering but still having a presence in the physics engine. Sever changes at this point are significant. The viewer is a preliminary version without significant change.
Prior to this change the server was in control of what you see, what in your avatar’s field of view got rendered. Imagine trying to maintain a list of what your avatar can see and keep you viewer informed fast enough to render things in the correct order while flying. That takes lots of communication.
Richard is telling us that now the viewer is in charge of tracking what we can see. So, what the server does when you TP some place is send you the close and big stuff first. Then it will send everything else… (yes the whole region.). But I think they are sending only the parametric information. That means you would be getting the cube’s dimensions, deforms, and list of textures. But, I am guessing the textures are not sent at this time. With a mesh we probably get the parametric info without the vertex list or textures.
Then the viewer will decide what is has and does not have in cache and start making request for things as it decides what it needs to render.
Another server side change is that when you have not been in a region before, the server just sends everything. I am guessing it still uses the closest-biggest priority. But, it does not wait for the individual texture, vertex list, and materials requests. It just starts sending them.
As for items that are reused throughout Second Life™, I am guessing they are so few per region it is faster to send everything than process the list of what you do and don’t have in cache.
Under the hood is work on the metrics system… the system that reports what the server is spending its time on. The system is improved and better integrated with the viewer’s Fast Timers (Ctrl-Shift-9). This doesn’t do much for users but will give the Lab and TPV Dev’s information for future optimizations.
Since the viewer is learning to handle the Interest List the new metric system is going to help third party developers make changes to Interest List processing to improve performance. They will have a measure of how significant their changes are in affecting render time via the new metrics.
Richard says the team thinks they have all the viewer render fails fixed. They have an edge case where they use too much memory. They are working on that now. Since over use of memory can lead to texture thrashing experiencing thrashing should see less of that.
Soon we will see updates to the Wiki describing the new Interest List process.
The Interest List process is a complex mix of the server and viewer updating the render process. There are currently problems with keeping scripted and sound emitting items updated. Richard says they have done little to resolve some of those issues. So, doors that close behind you may still appear to be open. However, the server will update the physics engine, so you can’t walk through it. But, the viewer looses track of the door state.
Oz Linden discussed when we might be seeing the viewer that takes advantage of the server side Interest List changes. There is no clear answer. The time needed is dependent on how well the viewer is working and how much time the metrics say is being saved. The thinking is that information factors into priorities along with other viewer changes, improvements, and new items that are currently in the viewer pipeline. So, best estimate is: weeks.
The Lab’s goal is to release viewers on two-week intervals. But, they are deliberately avoiding schedules for RC’s. They plan to use objective data, like viewer crash rates. Also, the more subjective priority of the importance of the viewer changes/fixes and which features or fixes are most important to get out.
That set of criteria makes it nearly impossible to estimate which RC will make it out ahead of other RC’s.
They did break their two-week guideline for the ATI fix release. It became a priority because ATI users updating to the latest ATI driver were effectively blocked from using SL. So, that is an example of a fix’s priority superceding guidelines.
Firestorm is nearing a release. Jessica Lyon says the Interest List changes are a significant amount of code. Attempting to add in the Interest List changes would set back the release date of the next viewer. So, between what I hear in the TPV meeting and what Jessica has pointed to on the Firestorm blog, it looks like the next release of Firestorm is some time away, like early December or early January. I think the Firestorm team and I are both guessing about whether the Interest List changes will be in that release or not. Whether they are or not, the viewer will work with SL as the servers are maintaining both the old and new Interest List behaviors.
Viewers that can use the new process send a flag that says ‘use new process’. Those that cannot don’t send the flag or set it false. The server responds based on the flag.
The current work on HTTP is sitting waiting on QA resources. Once the updates make it through QA there will be a server and viewer release as RC’s.
Monty Linden has already started work on the next phase of HTTP, which has to do with cURL, which is a library of functions that use URL’s as data connection points for moving data with ID/password and encryption decryption in flexible ways. I use it with PHP for credit card verification and other financial transactions in web sites I build. I’m not sure how SL makes use of it. All I get is Monty plans to make it better.
Nyx Linden says Inventory API’s have changed and the code is now accessible to developers. The Sunshine test regions in ADITI have the new code running. This is about new Inventory API’s targeted at resolving bake fail issued caused by inventory problems.
This too is stuck waiting for QA. Baker is getting test regions up on ADITI.
There is some concern about rogue viewers being able to circumvent Group Ban. I think that is mostly from people not understanding how Group Ban works, or may be I don’t understand the expected exploit.
The server does the banning. A viewer sends the command to ban. But, it has to come from a group owner or officer with banning privileges. Once the server receives the ban order I don’t see how the ban can be circumvented by the avatar that is banned.
There is the problem that once someone has accessed the group chat, banning them from the group does not cut off their current chat privilege. The group member and privilege system and the chat backend do not communicate after the initial validation. Since they have already cleared the chat backend security check, it allows them to continue chatting.
The SL viewer is going ban and eject in one operation. If I understand correctly neither of those operations will revoke the avatar’s current chat privilege in the group chat system. That means they can continue to chat until they logout or crash. A group moderator has to mute the problem maker, which tells the group chat servers to stop their chat. Even then they can continue listening until they end the session.
I expect the viewer will eventually handle all these steps in one click.
While a spammer or troublemaker being able to listen in is not ideal, this group ban will be way better than what we have now.