The following notes are taken from the TPV Developer meeting held on Friday, November 17th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.
SL Viewer
[0:50-2:22] The Alex Ivy 64-bit RC viewer, version 5.1.0.510354, has been holding up “really well” in its release cohort, although there is a start-up / benchmark crash the Lab has had difficulty reproducing, but for which they now believe they can fix in the next update, which should appear after the US Thanksgiving break (Thursday November 23rd – Sunday November 26th, 2017). If the crash is shown to be fixed, then the viewer should hopefully be in a position to move to release status in December.
[2:25-2:43] Vixox is still working on a race condition in the Voice RC viewer, version 5.0.8.328552 at the time of writing, and the Lab is hoping for an update on that either in parallel with or shortly after the Alex Ivy update.
[2:46-2:59] The current “Martini” Maintenance RC viewer updated to version 5.0.9.329906 on Friday, November 17th.
[3:00-3:28] An update to the 360 snapshot project viewer, version 5.1.0.506743 at the time of writing, is in progress, which should greatly improve image quality. If possible, this update might appear ahead of the US Thanksgiving break.
Rendering Project Viewer
[5:15-5:52] A new project viewer – Project Render, version 5.1.0.510604, dated November 14th, 2017, is available for Windows (32-bit and 64-bit) and Mac OS X. This viewer includes several fixes to the Rendering pipeline, and comes with a request that all issues are reported via JIRA.
The viewer is now built from the Alex Ivy (64-bit) branch (hence no Linux version), and all known issues for the Alex Ivy Viewer apply to it. It is intended to provide / address:
- Improvement to mesh LOD calculation (account for CTRL+0).
- Agents that render as jelly dolls should have their attachments render at 0 LoD to prevent loading higher LoD complexity in memory thus deterring crashes -> debug setting RenderAutoMuteByteLimit has to be > default of 0 for this feature.
- Bug: Mesh avatar deforms constantly – was due to bounding box / LOD swaps.
- Bug: Some mesh turned invisible when camera is moved – was caused by fix for MAINT-6125.
- Bug: Setting one avatar to “Do not render” causes all avatars to become impostors.
Viewer Development Focus
Linux Viewer
[3:32-4:52 and 15:28-15:46] Currently, the Lab is aiming to get 32-bit and 64-bit Windows builds on the current viewers, together with 64-bit only Mac builds.
Once this has been done, the Lab will try again to get a 64-bit Linux build of the viewer, with the overall goal being to change the Linux build over to a Debian package without the additional libraries, allowing TPVs to add the dependencies they require for their flavour of Linux build. However, the Lab will be looking for help from TPVs and open-source developers in getting this done.
If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.
General Focus
[10:10-14:35] In general, the Lab will be focusing more on current hardware (see resource usage tools, below) and operating systems over older / outdated hardware and operating system flavours. So for Windows, for example, while the Lab is not dropping support for 32-bit systems, the recommendation is that those who can upgrade to support Windows 64-bit (and particularly Windows 10 64-bit) should do so. If nothing else, this should substantially reduce viewer crash rates, particularly when used 64-bit versions of the viewer (e.g. fewer out-of-memory crashes).
Resource Usage tools
Note the following elements are discussed between 6:16-10:08 and then from 19:52-49:10.
VRAM and Texture Information
Chalice Yao has proposed a feature to the Firestorm team to allow users better understand the resources they are using, both through their avatar’s VRAM usage and the VRAM (triangles and vertices) for any selected object (see FIRE-21793).
Textures are a significant issue because of the widespread use of 1024×1024 textures on multiple faces of items at 4 MB a texture, whether needed or not (do buttons on a jacket really need 102×1024 textures?). This can lead to avatars using VRAM in the gigabyte ranges – simply because there is no incentive in place for creators to optimise their use of textures. so, offering a means by which users can see and understand their resource usage might encourage creators to start thinking in terms of optimising their use of the textures.
Overall, Oz is in favour of the idea, noting that it could be a good fit with the Lab’s own work in trying to make the render cost calculations for avatars and objects more accurate (allowing for the variances in handling information inherent within different types of graphics cards with different capabilities one to another). In addition, the Lab has been working on an experimental viewer which radically re-organises the texture cache to make it simpler, but this has yet to work (this includes the previously mentioned idea of storing textures already decoded).
The discussion (a fair part of which is in text) also covers the upcoming Bakes on Mesh work (see my CCUG meeting notes), the benefits of supplying users with pertinent information vs. the problems of witch-hunts, providing the means for people to be better educated and to make more informed decisions, how any additional information should be displayed etc.
Hide All Objects Outside of A Parcel
BUG-5671 outlines another idea related to data handling / viewer resource usage: offering parcel owners a setting that would effectively prevent the simulator from downloading information about objects outside of their own parcel. This would reduce simulator load, bandwidth use and mean the viewer doesn’t have to manage object data and rendering for items the parcel owner doesn’t want to see when with their parcel (although it also means their view would be reduced to looked out over “empty” land).
The feature request has been accepted by the Lab – but when or how it, or something like it, may be implemented – if it is implemented at all – has yet to be considered.
BUG-5671 another demonstration of the important difference between a JIRA being Accepted compared with being implemented. JIRAs can be Accepted for a number of reasons, but does not automatically mean it will be implemented. Reasons JIRAs might be Accepted include: it explain an issue the Lab may want to address at some point; or because it might offer a means to resolve part of a larger issue or group of issues the Lab might want to address, again at some point in the future.
RenderVolumeLODFactor
Mixed with the above discussions (again in text) is a debate on RendeVolumeLODFactor settings, with some viewers (e.g. Firestorm) defaulting to higher values than the official viewer, and the impact this may (or may not have) on content creators.
Certainly, high-end LOD settings are detrimental to viewer performance, but whether enforcing a lower LOD setting would encourage content creators to optimise their designs is questionable: “recommendations” for very high LOD settings (often much higher than the defaults used by any viewer) have been a factor in content creation for a very long time, with some creators even foregoing the use of lower LOD models (so it because an “all or nothing ” approach). As such, a more effective means of preventing this might be to penalise creators who fail to provide proper medium and low LOD versions of their creations, something the Lab is considering.
This conversation (largely in text) continues on to alpha blending / masking, etc.
Other Items
Inventory UDP Messaging Deprecation
[16:14-17:30] A reminder that the Lab is working to deprecate all / most of the UDP inventory messaging. The viewer side of this work will be appearing in a public branch “pretty soon”. Once the viewer-side code is released, the Lab will look to remove server-side support, most likely early in 2018.It is hoped this will resolve a number of issues with inventory reliability, which is one of the driving reasons for carrying out the work. It also means that any active viewers still using the UDP inventory handling routes should be making the move to HTTP in order to remain functional vis-a-vis inventory.
Holiday No-Change Windows
- [18:10-18:52] There will be no “risky” / major updates / changes for week #47 (commencing Monday, November 20th) due to it being Thanksgiving in the United States. Server-side deployments for the week will be limited in scope.
- [19:05-19:26] The Lab’s Operations Team has yet to finalised the official No Change window for the Christmas / New Year period, but the Lab as a whole is shut down for holidays Friday, December 22nd, 2017, and re-opens on Tuesday, January 2nd, 2018, so a No Change window will be in force at least during the Christmas week.
TPV Updates
- Alchemy updated to version 5.0.7.41341 on November 14th, with a focus on bug fixes
- Cool VL viewer Stable branch updated to version 1.26.20.37 and the Experimental branch to version 1.26.21.3, both on November 18th – change log for both
- MetaChat for iOS updated to version 1.1.3.1 on November 16th.
Next TPVD Meeting
The next TPVD meeting will be on Friday, December 15th, 2017.
Inara Pey: Living in a Modemworld 