Not much new news so far this week. We did learn a bit more about how the Materials System may be implemented.
Content & Mesh Meeting Aug 2012
Materials
Q: Will there be any veiwer settings requirements to see materials? such as lighting and shadows on. ac14 Hutson
A: I suppose Hutsom is asking will there be any visual settings dependencies. For instance having to have Lighting & Shadows on before you can turn on Sun/Moon shadows is a dependency.
A: Geenz Spad: Lighting & Shadows will be required, *however* you can disable the shadows part by setting that setting to “None”.
Update Note 2014-04-10:The Photo Tools are not part of the Firestorm Viewer and do not need to be installed.
I saw these tools mentioned on Hamlet’s New World Notes in an article titled: Want to Take Great SL Images? Get Mr. Weaver’s Phototools! These are tools made for the Firestorm Viewer (Firestorm 4.1.1 (28744) Jul 9 2012 21:43:46 (Firestorm-Release)). The tools will only work with the default skins.
Mayfair – Not the default settings
This is an interesting addition to Firestorm. It is a rational and logical arrangement of the controls by William (paperwork) Weaver that affects how the viewer renders with world. If you are a photographer this is going to be a way handy tool. All the settings that affect the render appearance are in a single panel consisting of 6 tabs. Some of the controls open other panels, but basically it is one new panel, but what a handy panel.
First… there will be no MetaReality podcasts until September 24th, due to RL problems and RL work load. So, I doubt we will see an update on the Mesh Defomer before then. 🙁
SL Support
If you use a Third Party Viewer (TPV), Second Life™ support can be really annoying. There are viewer problems and server side problems. If it is a server side problem, it really doesn’t matter which viewer you are using. Support should help out and get the problem fixed regardless of the viewer being used. That idea is taking root at the Lab.
Scripting-Server UG August 2012
Now that the MAJORITY of viewers in use are TPV’s, this problem is a significant pain. A process is starting to change that and hopefully reduce the problem. BUT… and this is a big butt… er but… first level support people have a hard time figuring out what are viewer and server side problems. So, some work is going into developing processes to help them decide.
To understand what is happening and what to expect one has to understand the problems support people face. One problem is the Lab’s support people are not trained in how to use or help with TPV’s. That would drive the support training costs and time requirements beyond anything reasonable. If only some TPV’s were supported to reduce cost and time required, there would be a load of drama about which viewers were selected. So, that means an all or nothing approach. It is going to come down on the nothing side.
Baker Linden got us some new information this week in the Server-Scripting UG on the fix for Large Group Editing Problems.
For the last two months he has been trying to solve the problem of getting large data sets to transfer reliably via the current API (application programming interface) running over UDP (an Internet protocol – think of it as a spoken language), which is the protocol all viewers use now to get group member lists. It is when that UDP transfer fails that people have problems with group member lists failing to load. Those failures also create some simulator side issues that degrade performance.
Large Groups – Image by: KittyKat3756 – Flickr
The practical limit for use with UDP is a member list of about 10,000 members. Any group larger will not reliably download. On some connections even the smaller 10k list will have problems. Sometimes larger lists will download. Sometimes they won’t. Baker has optimized the SQL query that pulls the list and eliminated as many timing problems as possible. I get the impression that several SQL tricks were tried, like breaking up queries and batching group of members for transfer were tried. But, in the end it simply is not going to work. So, the new API is going to use HTTP for the transfer. Eventually the UDP service tube for group member lists will be eliminated.
Just after I got my article out on Bandwidth and SVC-8124I heard that there will be no promotions from the release channels to the main channel. This means the fix for SVC-8124 will NOT roll to the main channel next week.
There is a problem with permissions. See: SVC-8177 – There is different behavior between the RC channels and the main channel involving permissions, objects loose modify permissions. This is going to prevent any roll to the main channel.
The Bandwidth problem will continue for another week. I’ll have to see how they handle the fixes to the release channels next week to know how this is going to work. But… the Lindens tried several fixes, I think for 8177, and they failed. I think the result is they are rolling back the release channels to unwind the 8177 fixes and get a main channel version with a 8124 fix running on the main trunk code. With any luck they can get the 8124 code in and they will make it through the RC QA.
