Mystical Fae Forest – blog post
The notes in this update are taken from the TPV Developer meeting held on Friday, March 10th, 2017. Audio extracts from the core points of the meeting are included.
SL Viewer Pipeline
There have been no further updates to any of the official viewers since part 1 of this week’s updates, leaving the pipelines as:
- Current Release version: 184.108.40.2064126, dated March 3rd, promoted March 6th – formerly a Maintenance RC viewer download page, release notes
- Project viewers:
- Obsolete platform viewer version 220.127.116.110847 dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
A further Maintenance RC viewer is in the offing; expect that soon.
Love Me Render Viewer
The Love Me Render RC viewer containing rendering pipe improvements was withdrawn due to assorted issues, in part justifying the move of rendering fixes to their own viewer branch to prevent them bottlenecking viewer releases (which could have happened if they had been a part of the “regular” Maintenance RC). It will hopefully reappear once the issues prompting its withdrawal have been dealt with.
The Project Alex Ivy 64-bit viewer has a new update currently with the Lab’s QA team. It has “quite a bit of work” in it, and should hopefully appear early in week #11 (week commencing Monday, March 13th). This update will include:
- An open-source wrapper for CEF called Dullahan (link for those who are curious about the etymology of Lab project names) which will replace llCEF, making it easier to render web content through the viewer
- The same versions of Dullahan / CEF and libVLC (audio handling) on both the Windows and Mac builds
- The 64-bit Mac build now uses MacOS Sierra, and will be backwards compatible as far as OSx 10.9 (Xcode 8)
- The 64-bit Windows build still uses Visual Studio 2013, and will support Windows 10, 8 and 7. Vista support is TBC.
360 Snapshot Viewer
New Viewer Management Framework
The next 64-bit update after the one referenced above will include the new viewer update process, which is specifically targeted at Windows users. This will run a process when updating the viewer to check the version of Windows being run (32-bit or 64-bit), and ensure the correct version of the viewer is downloaded and installed. In time, this process will eventually take over producing crash dump data as well.
Some concern was raised over forcing 64-bit users to run 64-bit versions of the viewer if they have found 32-bit versions to be easier (for whatever reason). However, the Lab believes this is unlikely to be the case.
Viewer Build Process
The viewer build process is changing with the arrival of the 64-bit viewer versions. One aspect of this is a new version of autobuild itself. The build process also uses the same compiler switches for building all of the various libraries which go into a viewer build, which are controlled by a new repository. This should smooth the build process and means that for Windows, the process can build either the 64-bit version of the viewer or the 32-bit version, providing the core 64-bit repository is used and depending on how an address size switch is set.
32-Bit Windows Support
There is still a large number of Second Life users running computers with 32-bit windows. As such, the Lab intends to support 32-bit windows for as long as the numbers warrant it / it is practical to do so. However, those on 32-bit versions of the operating system are liable to experience higher crash rates and poorer viewer performance, simply because of the memory limitations inherent in 32-bit Windows.
The next Voice update should be appearing soon, which fixes the left / right orientation of Voice on the Mac. There are still some connection issues to be resolved, but hopefully the viewer will reach LL’s QA team in the next week or so, paving the way for its public appearance.
Abuse Report Categories
Currently, the report categories associate with Abuse Reports (ARs) are currently held in the viewer. This means that any changes made to the categories may not be reflected in all viewers, complicating the Governance Team’s work it triaging incoming reports.
While first mooted in August 2016, the Lab is now looking to make the Abuse Report categories a simulator-side capability downloaded to the viewer (most likely at log-in). This would both make it easier for the Lab to revise the abuse categories (were their ever a need to do so) and, over time, help eliminate the problem of incorrect abuse categories existing in older viewers.
HTTP Asset Fetching
Work is in progress to shift the remaining asset fetching operations away from UDP through the simulator and to HTTP via the Content Delivery Network(s) (CDN) used by the Lab.
- The simulator updates are already on the beta grid (Aditi) for testing (channel DRTSIM-341, which should be grid-wide on Aditi) – see part 1 of this week’s update
- A viewer with the necessary support for asset fetching over HTTP / CDN has now cleared LL’s QA and should appear in project form soon
- This viewer sees the removal of all asset fetching via UDP removed from the viewer’s code
- The viewer also utilises a new Asset Fetch capability, designed to cover all asset types: landmarks gestures, animations, shapes, sounds and wearables (system layer clothing and shapes), as well as texture, avatar appearance and mesh, which are already handled via HTTP / CDN
- Once the simulator support for asset delivery via HTTP / CDN using the new Asset Fetch capability has been deployed to the main grid, and TPVs have had time to adopt the release version of the viewer code, all asset handling via UDP will be removed from the simulator code
- There is no confirmed time frame for the removal of the simulator code, but the target period is July / August 2017
- This removing of asset fetching over UDP will mean anyone using older versions of a viewer reliant on UDP messaging will be unable to receive any asset information
- Testing shows that using HTTP / CDN delivery can significantly improve first time playback of animations and sounds where they are already stored on a local CDN node.
Snapshots to E-mail
As noted in part 1 of this week’s report, sending snapshots to e-mail is currently broken across the grid. However, a viewer patch for the issue has been written, as is being adopted by TPVs as well as the Lab.
A concern raised with snapshots to e-mail, in that they expose the sender’s e-mail address associated with their SL account in the Reply To field (although the sender’s e-mail address used to be exposed in the From field). LL do not plan to change this, so if you are concerned about revealing the e-mail address you associate with Second Life, use this feature with care (once it is working again!).
BUG-20057 Visual Artifacts with ALM enabled on some AMD graphics cards
Anyone encountering this issue should find it fixed with the latest Radeon Crimson Relive 17.3.1 drivers.
Verifying E-mail Addresses
The Lab plans to start implementing sending e-mails only to those account e-mail addresses which have been verified over the next couple of months. The switch-over will be gradual, and will commence with IMs-to-e-mail forwarding and to merchant e-mails from the Marketplace.
Therefore, if you wish to continue receiving information from the Lab via e-mail, it is important you verify your e-mail account – see Important: verifying your e-mail address with Second life in this blog.
The Lab will be running an information campaign via the official blog and a viewer message of the day (MOTD) notice when the switch-over starts.