Day: April 17, 2018

2018 SL UG updates #16/1: Simulator User Group

Posted on by Inara Pey

La Virevolte; Inara Pey, March 2018, on FlickrLa Virevolte – blog post

Server Deployments

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.

SL Viewer

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 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC – NEW
  • Release channel cohorts:
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, 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 3.7.28.300847, 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 5.1.4.514468 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):

  • llRequestUserKey:
    • 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.
  • llName2Key:
    • 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.

Kokua: new faces, the future and release 5.1.3.43129/43130

Posted on by Inara Pey

In March I reported that Chorazin Allen, had joined the Kokua viewer development team. He volunteered after Nicky Perian’s decision to step back from day-to-day management of the project, announced in October 2017 to allow him to enjoy more of his retirement, failed to elicit hoped-for volunteers to take over the general management of the project.

Chorazin, although he modestly describes his C++ coding skills as “rusty” (causing him to initially hold back from volunteering sooner), has considerable experience in project management, software development and build experience coupled with many years of experience of in-world LSL scripting and working with RLV/RLVa.

Since joining Kokua, he has been getting familiar with the rest of the Kokua team, and together they have been working on updates to the Second Life viewer to bring it up to parity with the current Linden Lab code base, including full integration with the Alex Ivy 64-bit code. I’ve been tracking these updates – made through the projects Sourceforge pages, rather than being “official” releases, for the past few weeks via my Current Viewer Releases page and my weekly viewer release summaries.

Kokua: The Future

On April 15th, this work reached a point where the team were ready to resume making formal Kokua releases, and to publish a blog post outlining the viewer’s future development. I strongly urge all Kokua users to read this post in full, and am only bullet-pointing the key elements here:

  • Until such time as an OpenSim developer can join the project, Kokua will only be actively maintained for use with Second Life.
  • Kokua for Second Life will be developed as a 64-bit bit viewer only, offering both RLV and non-RLV variants.
    • The Windows and Mac versions will be actively maintained, based on Linden Lab’s  Alex Ivy 64-bit code base.
    • Effort will also be put towards a 64-bit Linux flavour of the viewer based on the Lab’s Alex Ivy code. However, this will doubtless be dependent on the Lab’s broader attempts to work with the Linux community to develop a 64-bit Linux viewer.
  • In keeping with a request from Linden Lab, the major version numbers for Kokua releases will reflect the Lab code base release they are based on. So, for example Kokua 5.1.3.xxxxx indicates it is based on the Lab’s 5.1.3 code base.
  • Legacy 32-bit versions of Kokua will remain available via the download page, but will not be actively maintained.
  • The Kokua group within Second Life is the preferred medium for user-to-user support and will also be used for group notices about new versions or other significant developments. All other channels of outward  communication (IRC, Twitter, etc), have been discontinued.
  • The Kokua wiki will continue to be used for viewer release notes (as seen in the viewer when a new version is launched) and for the summary of current versions and download sites.
  • The preferred method of inward  communication to the team is via a ticket raised in Sourceforge against the Kokua Project.

Kokua 5.1.3.43129/43130

The formal release the release of Kokua’s Alex Ivy based 64-bit viewer for Windows and Mac, offers the viewer in both RLV (5.1.3.129) and non-RLV (5.1.3.43130) variants on both platforms. It brings with it a full parity with the Second Life viewer up to and including (at the time of writing) the current official release viewer, 5.1.3.51364, formerly the Media Update RC viewer. The RLV version of the viewer also gains parity with RLV 2.9.23.0.

Performance Feedback Capabilities

The core element of the updates made by the Kokua team comprise new performance and information feedback capabilities, including the ability to report on changes in the number of scripts in a region, changes in the server channel with changes of region.

All of the new settings can be found in two new Preferences tabs: Preferences > Kokua > Performance 1 and Preferences > Kokua  > Performance 2:

  • Performance 1 deals with notifications on entering a new region and agent (avatar) and script notifications, which must be enabled on a group basis – agent and / or script notifications, and then individual options within group set as required.
  • Performance 2 provides notifications on Frame Timing and Basic Performance.

In addition, it should be noted that:

  • Performance 2 also includes a check box to display the information from these features either as a notification in the top right of the viewer window and in chat history, or have them only displayed in chat history.
  • All of the options have default values which are intended to be representative of fairly average performance. If you aren’t familiar with what they do, it is probably preferable that you don’t randomly enabling them, as you could end up  swamped in notifications and feedback.
  • It is important to not that any changes made relate what is reported by the viewer and when – changing these values does not change actual simulator performance.
The new Preferences > Kukua Performance 1 tab, allowing users to set notifications for region, agent (avatar) and script notifications.

Some of these options mirror similar capabilities found in other TPVs – such as reporting a change in the server channel when moving between regions; others may be of more benefit to region holders and their estate managers than they are for general consumption. The idea with them is not to simply turn everything on, but to select those options which might be of specific interest.

For example, while knowing how many avatars (agents) are in a region might be of use to some users when hopping about Second Life, information on how the physics  simulation is performing or on overall timing information within a region, together with the active object count and script count is only likely to be of interest to those managing a region. Similarly, enabling the Physics time section of the frame monitoring options in the Performance 2 tab could help creators monitor vehicle performance during testing (e.g. on region crossings.

The new Preferences > Kokua > Performance 2 tab, providing Frame Timing and Basic Performance notifications

For a more rounded examination on how these options might be used, please refer to the Kokua release notes, which provide a range of examples of now the tabs might be used. It should also be notes that general “real-time” monitoring of the options provided can also be done via the Statistics (CTRL-SHIFT-1) and Scene Load Statistics (CTRl-SHIFT-2) floaters. Finally, those particularly interested in learning more about the viewer’s statistics reporting abilities and on tuning viewer performance should refer to the Viewer Statistics wiki page, and the Viewer Performance Knowledge Base article respectively.

Feedback

While the lack of OpenSim maintenance for Kokua – at least until such time as an OpenSim developer volunteers to work with the team, as noted – will probably be lamented in some quarters, the “return” of mainstream release announcements of Kokua, together with information how the viewer’s development will proceed into the foreseeable future is to be welcomed.

That Kokua is only being maintained on Windows 64-bit might cause frustration for some. However, given that systems capable of running 64-bit Windows (e.g. supplied with more that 4Gb of RAM) are far more prevalent on the marketplace; ergo, the decision to focus the team’s limited resources on providing support for the one flavour of Windows  makes sense.

It’s hard to judge how well the two new Performance tabs will be utilised. Aso noted, for the likes of those engaged in region management, or scripting, they could potentially be very useful. For others, the tabs might rarely see the light of day. But that’s what TPVs are about – providing choice for users.

I’ve not had an opportunity to run Kokus 5.1.3 hard, having only spent part of a morning bouncing around SL with it. However, in that time I found it to be (as usual) robust and providing frame rates and general experience with the official viewer and – on a frame rate basis – somewhat above that managed by Firestorm on the basis of very rough-and-ready “like for like” testing across some of my preferred regions where things like agent numbers., etc tend to remain constant.

Additional Links