Some of the notes in this update are taken from the TPV Developer meeting held on Friday, July 1st. The video of that meeting is embedded at the end of this update, and references to it are indicated through the use of time stamps in the paragraphs below (note that there were some extended pauses in the meeting where there was no discussion, hence some of the time gaps evident between time stamps, where given). My thanks as always to North for recording and providing it.
Server Deployments – Recap
- On Tuesday, June 28th, the Main (SLS) channel received the same server maintenance package previously deployed to the RC channels, comprising minor internal changes and Tool Tip/Constant text fixes.
- On Wednesday, June 29th, all three RC channels received the same new server maintenance package, comprising the following fixes:
- BUG-11836 Increase max animation size – animation files up to 250Kb can now be uploaded
- BUG-6035 (non-public) LSL email registration (for receiving email from outside the region) can break without automatic recovery.
Deployments for Week #27
There will only be one deployment in week #27 (commencing Monday, July 4th), this will be to the Main (SLS) channel, promoting the current RC channel package, which due to Monday being a holiday in the United States, will take place on Wednesday, July 6th, rather than Tuesday, July, 5th.
The Bento project viewer updated to version 184.108.40.2067134, on Thursday June 30th. This update includes small tweaks to the avatar skeleton file, but no structural changes, and provides fixes for:
- missing string for left pec, right pec attachments
- issues with system eyelashes
- vertical flicker with some mesh avatars.
Visual Outfits Browser Project Viewer
[03:22] The Visual Outfits Browser (VOB) project viewer updated to version 220.127.116.116422 on July 1st. This could be the last iteration of the viewer as a project release prior to it being promoted to a release candidate status, which might be as early as week #27, pending the outcome of fixes for a couple of issues.
Oculus Rift Project Viewer
[04:19] A new Windows build for the Oculus Rift project viewer, version 18.104.22.1687313 was released on July 1st (reported as being with the Labs QA team during the TPV Developer meeting) – see my update article for more.
It is expected that over the fullness of time, this viewer will progress through project and RC releases and be merged into the main viewer. The Lab currently has no plans to maintain it as a separate viewer channel.
Note that this viewer is still specific to the Oculus Rift. Support for the HTC Vive in Second Life is something the Lab “would like to be able to do”, but this viewer does not expressly support the Vive as well. If and / or when the Lab might offer Vive support in SL, and how far that support might go (e.g. will it include support for using the Vive’s room sensors with SL) is an open question at this point is time.
Inventory Messaging Viewer Promotion
[00:28] It appears the inventory messaging viewer, version 22.214.171.1245555, is “almost certain” to be promoted to de facto release status on Tuesday, July 5th.
This viewer eliminates deprecated and unused UDP inventory messaging mechanisms from the viewer, replacing them with the current AIS mechanisms. The promotion of this viewer to de facto release status marking the start of a countdown towards the removal of the corresponding back-end support for these old UDP operations, which will most likely take place some time in Q4 of 2016 (final dates TBD at this time).
When it happens, it means than any viewers still reliant on the UDP mechanisms for inventory operations – such as the Lab’s Obsolete Platforms viewer (version 126.96.36.1990847) will no longer work.
Maintenance RC Viewer
[03:02] The Maintenance RC viewer, version 188.8.131.526883 at the time of writing, is also doing well in its cohort, and is expected to be promoted “not to far” behind the messaging viewer – so most likely around mid-July, unless anything happens, given the Lab generally likes to leave 2 weeks between viewer promotions.
Project VLC Media Plugin Viewer
[36:23] It is hoped this project viewer (currently version 184.108.40.2066258, dated June 15th) should move to release candidate status in week #27. Again, this will be for Windows only, replacing the QuickTime media plugin for the Windows viewer with one based on LibVLC. The Mac viewer will be updated to use LibVLC when the 64-bit version is released.
There have been some issues with this viewer recognising .MOV files in comparison with playing files in a web browser or a VLC client (see BUG-20024), It is believed that this is due to be down to the number of different .MOV formats the VLC plug-in in the viewer can recognise (.MOV essentially has multiple flavours) when compared to other means to play these files.
[44:56] In general terms, the Lab plan to make further media handling improvements with the 64-bit versions of the viewer, unless something significant comes up with diverts resources.
There have also been some questions over licensing of media in .MOV format, commenting on this, Oz said:
[39::08] We believe our viewer is not going to be violating any licensing terms, and you [TPV developers] will have to make your own judgements about what your viewers are and are not allowed to do. I’m afraid Linden Lab cannot be in the position of providing advice on that.
[15:42] Work is continuing on the 64-bit versions of the Windows and Mac viewers., with Oz again re-iterating that when ready, the Lab will provide the Windows viewer in 32-bit and 64-bit flavours and the Mac versions as 64-bit only (as do most TPVs who support 64-bit). Linux will also be provided as 64-bit only, although this isn’t a focus for the first release of the 64-bit versions, unless the Lab receive suitable Linux contributions to help them along.
The Lab has been heavily focused on server-side infrastructure updates for the past several weeks or more. This work diverts attention away from new features implementation, etc,.,, and is largely invisible to users. However, commenting on the work during the Simulator User Group meeting on Tuesday, June 28th, Oz Linden expressed a belief that the current work, once completed, should reduce the time and pain involved for the Lab in implementing routine security updates to their servers.
[19:54] The Lab is currently porting the simulators to a new version of their server operating system. As a part of this work, it is hoped that some of the performance analysis tools will be updated. If so, they may allow for a more in-depth look at some of the issues occurring with regions crossings beyond the expected causes (e.g. multiple avatars crossing simultaneously, avatars making a crossing with a high number of active scripts, etc.).
[23:53] The discussion on region crossings and physics weight / script issues prompted Oz to issue a reminder that the Lab frequently examines historical limits within Second Life and looking at the means of increasing them.
One of our ongoing activities that we try to pick up every now and then and iterate on, is to look for limits, the values for which were set a long time ago, and which maybe we have headroom to increase now … and we’re sort-of doing that all the time; it’s not a high priority activity, it’s the sort of thing we get to when we’ve got a few minutes … and sometimes we put out some tests where we really allow something to be bigger, and see whether it’s causing problems, and we decide whether or not to do it.
If you are frequently encountering, or if your support process is frequently encountering limits that seem as though it might be good to increase them, I’d be more than happy to entertain those suggestions.
However, because of issues such as region crossings, increasing script memory limits are unlikely to be something that will be considered.
Parcel Resource limits vs. Throttling
[26:25] Although slightly removed from raising limits, one oft-repeated request has been to limit the amount of resources a single parcel in a region can use at the expense of other parcels in the same region.
Acknowledging that this is potentially a fair request, Oz went on to comment that at the moment, the Lab is preferring to focus looking at particular calls people make which are particularly “heavyweight” for the simulator to handle, and attempting to throttle those calls (e.g. limiting the number of scripts allowing in objects / attachments), or adding additional sleep time to things that are resource intensive. So it would be more likely the Lab would attempt to analyse what is going on, and then determining whether further throttling against specific calls, etc.
Parcel Windlight Coming SoonTM?
Back in December 2015, Oz indicated that he hoped the Lab would, in the (then) near(ish) future be able to put a project together on improved environment settings, including the potential for officially supported (i.e. server-side) parcel windlight capabilities. Commenting on work following behind Project Bento during the Simulator User Group meeting on Tuesday, June 28th, Oz indicated that the Lab has, “got a nice new feature coming for landowners.”
He refused to be drawn on exactly what it might be, but in response to a question from Whirly Fizzle, he confirmed that parcel owners as will as region owners will be able to take advantage of it, adding sparks to the speculation that the new feature will be environment / windlight improvements such asserver-side parcel windlight support.
Texture Memory Support
[11:00 (text) / 12:59 (voice)] Texture memory support can be something of an issue. the official viewer currently supports 512Mb, while some 64-bit viewers supporting larger amounts (Firestorm 64-bit supports 1024 Mb, for example). Kokua developer Hurana Ugajin is working to try to extend stable support to 4 Gb or 64-bit viewers. While not opposed to accepting contributions which support higher texture memory limits, Oz noted:
My understanding – and this is not my area – is that the difficult parts of supporting more texture memory is correctly detecting how much you can get away with using on any given card before you start having problems. And we have a lot of problems with many cards … especially lower end ones if we try to use more … And we no longer have a mechanism for conditionalising [a viewer’s graphics settings] based on what the name of the car seems to be, and we’re not putting one back.
He went on to say he would be delighted to work with anyone wishing to contribute suitable code (based on the official viewer’s code base), but they should be aware that they’ll be subjected to some “pretty brutal QA”. He also noted that he’d be OK with a manual setting by which users could adjust the texture memory limit within their viewer, “if and only if, when it fails, it makes it clear that’s what the problem is, and you have to go do something about it.”