This is the news from the Third Party Viewer Developers Meeting. There is always lots of interesting new information that comes out in these meetings. The first thing Oz Linden went over were the RC Viewers currently out.
RC SL Share
Merov Linden talked about SL Share. Oz Linden translated for him as Merov’s voice was distorted beyond understanding.
I gathered that the SL Share feature is mostly implemented server side. The Facebook login tokens are not kept in the viewer. So, third party developers would not see the Facebook information… But… one does type an ID and password for the account into the viewer to set up the connection. So, is that safe?
I’ll have to look and see how this is actually working. For now I think it may be similar to how SL Search works, where a web page is opened as a panel in the viewer. While you are appearing to type in the viewer, you are typing into a web page. I suspect SL Share is something similar with the account connection setup.
Once the connection is established, future posts from the viewer are passed to the SL server, which has the tokens, for it to pass the post along to Facebook. So, the viewer would never actually be connecting to Facebook.
Strawberry Singh has her video up on using SL Share. It is pretty good. She mentions the problems she has already run into with Facebook not liking her avatar only account. See: Second Life Facebook Share.
Her experience leads me to think Facebook may be using connections from the Linden server to ID avatar accounts and force them to connect to real user accounts. It is Facebook’s financial mode to sell real people information to their real customers. Having non-real accounts that cannot be connected to traceable people degrades the quality of their marketing information. So, it would seem to be to their financial advantage to cull those accounts out.
This viewer could release in week 40, but probably won’t… but it is a strong contender. Oz says lots of people are downloading the viewer and using it. So, it is racking up lots of test hours. Merov says the crash rates and other metrics are looking good.
The Lindens will be meeting in week 40 to decide which RC to promote. So, it has a decent chance.
There is no connection between this Facebook feature and your SL Feed. The Lab is not currently planning to link Facebook and the SL Feed. Oz thinks that might be possible, but it would have to be a TPV that does it.
This is an effort to improve crash reporting. This version will do as much crash reporting preparation work as possible at viewer startup rather than trying to do it all at crash time.
Oz says this RC is not likely to promote soon. The Lindens are working with tuning the information they are gathering. This is a process of looking at what they are getting from their Breakpad configuration/setup and what information they need. Then seeing what they can change to pick up missing pieces.
The big feature in this release is the request TP feature.
This RC has lots of bug fixes. Plus there is more stuff coming right behind this candidate. These fixes were stacking up and getting them out faster was a major motivation for implementing the new viewer release pipeline.
Animation Influencing Interface
This change is NOT about changing the basic animation system. That fundamental change is not likely for some time. The interface change being considered is about how the viewer works with animations. The viewer would gain more abilities so things like the Firestorm Bridge would not be needed. What the Bridges does now, the viewer would be able to do, making the Bridge unnecessary.
Oz and the Lab have not made much progress on the project. The people Oz needs for this are busy with other things.
Oz thinks they may be able to get the viewer some scripting ability to allow it to influence animations. If I understand what we are trying for here, this would give the scripters some interface points like we see in RLV enabled viewers. Along with Advanced Experience Tools this would allow game developers in SL more control over the experience.
Oz says there is an Interest List viewer in the wings. It just has not been able to make it through internal QA. People are still working on it. So, we will see it some day. Real Soon Now™…
Oz has been expecting this viewer to make it into RC pipeline for 4 or so weeks now.
Baker Linden thinks he is close to having the Group Bans working and the viewer side of the effort complete.
There is no point releasing until it works well and doesn’t crash. So, for now it is cycling through QA testing and revisions.
Clean up work on the server side is still in progress. There is also viewer side work in progress. Eventually this polish code for server and viewer will make it out.
The current work is in changing Inventory API’s. A new set of API’s are being implemented. The old ones will remain in place, giving two sets of API’s that can be used. I would guess that at some point the older API’s would be depreciated.
The idea is the current API’s tend to be lower level and require several API calls to accomplish a task. The new Inventory API’s will do more and require fewer calls to the servers. That would make them more efficient, reduce bandwidth, and increase reliability.
The bake fails people are seeing now are mostly related to inventory problems. As Monty improves the HTTP connection to SL and with these new SSA API’s we should see reduced the inventory problems. Hopefully eliminating most of those problems causing bake fail.
Server side changes are in place for a viewer update. That viewer update is about ready to go to QA. There are technical changes coming to curl, I think Monty was hard to understand and I only have so much patience.
There is a discussion going on about wireless connections to SL. See: SSB via T-Mobile cellphone.
Advanced Lighting Model needs to be enabled to see the new Materials Features. So, the big question for many of us is who can see materials? Plus, there is the reverse question, how many people are building with materials?
So, who can see it and how much is there to see?
About 33% of all regions now have one or more materials-enhanced-thing in the region. From release time to now to 1/3 adoption is way faster than when mesh was adopted.
The number of avatars wearing materials enhanced items is much less. Oz did not give us a number. I think this adoption number will reflect a composite of several things. System clothes cannot use materials. Only mesh clothing items can use materials. So, this would be a matter of how many people are wearing mesh that also have materials applied. If 100% of mesh clothes had materials it could still be a small number.
The people that have class 3 and above video cards that the Lab believes can support ALM that have ALM enabled is 20%, one in five.
Oz filtered out those with class 1 and 2 cards that have ALM enabled. Which he describes as a spectacularly bad idea. Those cards can’t support ALM. So, eliminating those makes the numbers clean for figuring out how many that can display ALM have it disabled, 80%.
The numbers are from all viewers (yes, including TPV’s) that report statistics.
Currently Firestorm and Singularity disable ALM by default. The Lab is asking they reconsider that choice. Because those with class 5 cards get better performance if they have ALM enabled.
Those with class 4 cards and below take some performance hit, with lower level cards taking more of a hit. The hit with class four cards is small. But, small doesn’t really tell us whether that is an acceptable hit or even how much it is.
So, how do you know which class video card you have? Navigate to the file gpu_table.txt, which you will find in: C:\Program Files\SecondLifeViewer (on 32 bit systems) or C:\Program Files (86x)\SecondLifeViewer (on 64 bit systems). This is a text file. You can open it with any text editor, but do not save the file, unless you know you can save it as a plain text file. Do not change the file unless you can maintain the data format. On Windows it is better to use Wordpad over Notepad.
The table has names followed by some numbers. The first number is the class value. Seatch for your card name and model number. The columns don’t line up well on my screen, which may make it look to some like some cards are missing a class number. They aren’t, its just funky columns.
An Nvidia GTX560 M (laptop) is a class 3 card. An Nvidia GTX 560 (desktop) is a class 5 card. Nvidia 240 to 280 cards are class 4.
Comments with in the file explain what the classes mean:
- – Defaults to low graphics settings. No shaders on by default
- – Defaults to mid graphics settings. Basic shaders on by default
- – Defaults to high graphics settings. Atmospherics on by default.
- – Same as 2, but with lighting and shadows enabled.
- – Same as 3, but with ambient occlusion enabled.
- – Same as 4, but with shadows set to “Sun/Moon+Projectors.”
Obviously these comments are a bit out of date as we now have more than 5 graphics settings for the viewer. But, having 7 classes to match the viewer settings is probably unnecessary.
From the information given by the comments you can tell what type of card the viewer thinks yours is without opening the file. The default settings the viewer uses gives it away.
Jessica Lyon pointed out there is disagreement between the Lab and TPV Dev’s between what is meant by ‘small hit’ or reasonable performance (10 FPS – Oz). Oz suggests we get away from adjectives and start using numbers, as this would allow people to decide for their self. I have gotten by with as little as 8 FPS. I prefer 25 FPS and above. For Oculus to work well I suspect we are going to need something closer to 60 if not 120 FPS… there is a challenge.
The use of numbers over adjectives is difficult as the viewer stats TPV Dev’s used to get went away when the Lab’s stats systems changed over to the new one. Oz is working to get the useful reports back and provide them to the dev’s. That will include performance data by viewer brand and have breakdowns by hardware.
The result will be the ability to provide meaningful data that shows the range of performance with specific graphics cards and possibly CPU’s. Third party developers will be able to better say what advantages or disadvantages certain hardware, graphics cards, and settings have on performance for their viewer.
There is the problem of what might be considered a reference scene. We all know various regions provide better and worse frame rates. Also, the number of avatars and activity decide how crucial frame rate is. At a meeting with lots of avatars sitting around a frame rate of 5 FPS is not much of a problem. When dancing a rate of 20+/- is about the lowest that works well. Anything slower is a bit disappointing. In a combat game rates below 30 FPS are annoying. Players that can run 60 FPS in combat areas have a huge advantage.
Oz is working to get some reasonably well controlled experiments in place so that the Lab can do more standardized testing. You may have noticed that Inara provides an FPS at something like 3,000m elevation as one measure of performance. That pretty much eliminates region variation. I often use Pooly or Furball for measuring performance for comparison.
He is also asking dev’s to suggest what would be useful for people trying to understand what is restricting performance on their system. We have Fast Timers (Ctrl-Shift-9). But, that is for dev’s and far too hard to explain to casual users. Most people look at it and the information they take away is just that it is complex and get no clue as to what to tweak on their system.
Something like Fast Timers that shows what the system is doing is needed but for users. Something that provides useable information and advises which settings can be tweaked for better performance. If it can show the change when settings are tweaked, it would be great. If it can do it in real time, even better.
This is not a simple project. But, I suspect we will see something come from it, eventually. I, at least, hope so.