As always, please refer to the server deployment thread for the latest updates.
- On Tuesday, April 17th, 2018, the Main (SLS) channel was updated with server maintenance package 18#18.03.29.513939, previously deployed to the RC channels and containing internal fixes.
- On Wednesday, April 18th, 2018, the major RC channels, BlueSteel, Magnum and LeTigre should all be updated with the same server maintenance package 18#18.04.09.514272, containing internal fixes and a fix for BUG-214702.
With the exception Animesh project viewer (see below), there have been no updates to the current SL viewers thus far in week #16, leaving the pipelines as follows:
- Current Release version 220.127.116.113644, dated March 27, promoted April 13 – formerly the media update RC – NEW
- Release channel cohorts:
- Love Me Render RC viewer, version 18.104.22.1684437, April 13.
- Ouzo Maintenance RC, version 22.214.171.1244434, April 13.
- Project viewers:
- Bakes on Mesh project viewer, version 126.96.36.1993936, March 30
- 360 snapshot viewer, version 188.8.131.523006, March 6 (this version can have significant rendering issues, see my hands-on update).
- Linux Spur viewer, version 184.108.40.2069906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
- Obsolete platform viewer, version 220.127.116.110847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.
Animesh Project Viewer Update
The Animesh project viewer updated on Monday, April 16th. Version 18.104.22.1684468 brings the viewer to parity with the current release viewer. In addition this viewer has revised streaming cost/land impact formula for Animesh objects, which are also reflected in ARC (avatar rendering cost) calculations for Animesh items.
In summary, the updates are:
- Animesh attachment limit = 1: only one Animesh object can be attached to an avatar at a time. This is unchanged from the original estimates.
- Triangle Count Limit = 100,000: an animesh object (linkset) can have at most 100k triangles, where the count is based on the estimated size of the largest LOD (normally this is the high LOD). This includes all mesh triangles, static or rigged.
- Land Impact: streaming cost = 15.0 + 1.5 * ktris + cost of non rigged prims: for a rigged mesh prim in an animesh linkset, the streaming cost will be 0.0015 * effective_tri_count – that is, 1.5 per thousand triangles. The value for effective_tri_count is derived from the estimated triangle count of the various LODs in the prim as follows:
- High LOD: all of the estimated triangle count included in the effective_tri_count.
- Medium LOD, Low LOD and Lowest LOD: the allowed number of triangles can be up to ½ of the LOD above, or 64, whichever is larger (i.e. Medium can be up to ½ of High, or 64, whichever is larger). If there are more triangles than this limit, that excess will be added to the effective_tri_count.
See Vir’s explanation in the Animesh updated limits and cost formulas forum thread for a complete explanation of these limits and how they have been arrived at.
An important point to note is that these formulas only apply to Animesh; there is a second, and longer-term project – ARCTan – a re-evaluation of all object and avatar rendering costs (and which may see further changes to Animesh calaculations). It is hoped that overall, ARCTan will improve viewer-side performance and provide creators with positive incentives to build more performant content.
You can find out more on ARTan in this blog post and this blog post in this blog.
Viewer Texture Cache
As noted in several of my TPV Developer meeting updates, Linden Lab are trying to improve viewer caching – starting with the texture cache. Commenting on the work, Oz Linden said, “We’re experimenting with a number of different changes. Some that you might think (I did) would make things better turned out not to, but we’re making progress.” It’s not clear if / when any project viewer utilising any new texture caching capability will be available for general use.
LlRequestUserKey and LlName2Key
The Lab has released two new LSL functions: llRequestUserKey and llNameToKey, both of which are in connection to the upcoming return of Last Names (see this blog post and this blog post for more):
- Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
- It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
- Note that agent being searched for with this function does not need to be signed on to Second Life.
- See the llRequestRequestUserKey wiki page for more.
- Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
- If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
- Uses a different mechanism to look up agent information to the older llKey2Name().
- See the llName2Key wiki page for more.