The GPU Table Viewer was promoted to main viewer status. So, it is gone from the RC Viewers’ page. This should fix several problems for those with newer video cards. From what I have heard, it may also have created some problems for those with cards that do not meet system requirements. But, there isn’t enough information to know. Reports in the forums are always lame.
The Break Pad Viewer is undergoing updates and doing a better job of error reporting. So, for now you won’t find it on the RC Viewers’ page. It will be back. The Lindens are getting the system figured out. But, they still are figuring out problems. Once this is in place and released it will help the Lab and TPV Dev’s find bugs faster.
Interesting Viewer 188.8.131.523895… yep it is still out there, still getting fixes. I was using it, until Fitted Mesh came out. It does make a difference in render performance.
The Fitted Mesh Viewer 184.108.40.2063899 currently includes the GPU update. I think it excludes the Interesting and Breakpad code, but I’m not sure.
All the RC and Project viewers are getting fixes. But there will not likely be any new RC releases this week as it is a no change window, US Holiday Thanksgiving Nov 28 to Dec 1.
We have another no change window in December from Dec 16 to Jan 1. From past experience I would not expect much to change or update before Jan 6, 2014.
However, during no change windows the Lab allows updates of project viewers. Project viewers are not RC viewers. They are much more like the previous Beta Viewers. Also, they are used by a much smaller number of users. This means an update or possibly two to the Fitted Mesh Viewer are likely before the end of the year. There are some small problems that are being fixed.
HTTP – Nyx Linden is hoping to have a viewer that uses the new HTTP features into QA ‘soonish’. Whether the HTTP Viewer will make it to RC and avoid being caught in a no change window is doubtful. But, certainly expect an RC version from the project during January.
Next the AIS3 Inventory changes will be worked on and load tests tried. That is dependent on the state of Third Party Viewers to some extent. These are the changes that are target the remaining parts of bake fail.
Monty Linden Added information about the HTTP work. The testing is going well and giving them good numbers. But, we probably won’t see much of the project until after the no changes windows pass.
Monty has also been spending time looking at the libraries used with the client (viewer) and server sides of Second Life. Seems there is a lot of old stuff in them that is not used. He is looking at cleaning that up and updating the libraries used to compile viewers.
Collada libraries are proving to be a bit of a problem. I expect this to be a problem for some future mesh uploads as the libraries get updated. But, maybe not.
LEAP Motion reps were at the Third Party Viewer meeting this last Friday (Nov 22). They are interested in getting the Controller integrated into Second Life. The Lab does not have people available that can work with them. But, the Lab does want to support LEAP. So, they are helping the LEAP people find a TPV Dev willing to work with LEAP’s people.
The new voice code is creating problems. A speaker may be unintelligible to listeners when using newer viewers. The speaker cannot hear the problem. The exact trigger for the problem is unclear. But, it appears to be in the Vivox code on the speaker’s side. So, people are running tests and gathering data to forward to the Lab to forward to the Vivox people for them to find and fix the problem.
If you can reliably reproduce the problem, file a bug report in the JIRA with the steps needed to cause the problem.
There is excitement about the 64-bit viewers. Several see them as far better than the current batch of 32-bit viewers. Far less crashes and bugs. But, this thinking from available stats may be miss leading.
Oz has pointed out that from past experience testing viewers, those testing viewers have far less problems with their viewers than the typical users. So, when the exact same viewer moves from RC (previously beta) to the main release the crash rates and error reports increase significantly. Presumably something similar would be true of those choosing to run 64-bit viewers. Thus giving false error rates.
Those wanting to use 64-bit viewers may be more computer tech knowledgeable and have their systems in better shape, thus less problems. This would distort the data and make 64-bit systems look better at first glance.
There is the thing that those using 64-bit operating systems (OS) see fewer crashes. Hard stats say that is a fact. This may simply be because they have more computer memory… cushion for memory leaks and other mistakes. Does anyone think Microsoft made fewer mistakes writing Windows 64-bit code than they did 32-bit code? I doubt that, but may be.
So, the overall picture is 64-bit is better, both OS-wise and viewer-wise. But, don’t expect changing to a 64-bit system/viewer to solve all the problems. There is nothing in 64-bit programming that suddenly makes programmers less error prone.
Jessica Lyon pointed out that most of the bugs found in the Firestorm 32-bit versions can be found in the 64-bit versions. However, the 64-bit version does crash less often.