Category: SL User Group Meetings

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

Posted on by Inara Pey

Soul2Soul River; Inara Pey, February 2018, on FlickrSoul2Soul River – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • The Main (SLS) channel was updated on Tuesday, March 27th, to server release 18#18.03.14.513292, containing the new server capabilities (see below).
  • At the time of writing, the Release Candidate channels were all TBD regarding potential deployments. This report will be updated if the deployment thread provides further information on the RC channels.

New Capabilities

The new capabilities in 18#18.03.14.513292 for the Main (SLS) channel is the first part of a set of server and viewer updates.

  • The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
  • The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.

Updates to the viewer incorporating these changes will be made available by the lab in the near future.

SL Viewer

  • The Maintenance RC viewer updated to version 5.1.3.513630 on Friday, March 23rd.
  • The Media Update RC viewer updated to version 5.1.3.513644, on Tuesday, March 27th.

The remainder of the pipeline remains as:

  • Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
  • 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.

In Brief

First Name / Last Name Changes

This is still a long way off from being implemented, however, Oz Linden confirmed llDetectedName() will return the current name for an avatar, no matter what the change. However, it may take some time for it to change everywhere due to caches.

More on the return of last names and name changes, please refer to The return of Second Life Last Names – update with audio.

SL Messaging Layer

Simon Linden is looking into the Second Life messaging layer, which may be the problem behind a lot of “lag” issues. “There’s actually a number of small improvements I want to make, but I’m being careful to do them one at a time and have real data showing it gets better,” he said in providing an update on the work.

Friendship Offers Failing

Some are experiencing Friendship offers failing, even when the offer is accepted – see BUG-215977. According to Simon Linden, this might require a server-side update to fully correct.

Region Crossings

Simon Linden has been looking at vehicle region crossings alongside of  Joe Magarac (animats) testing with the viewer (See Firestorm JIRA FIRE-21915, BUG-214653, this SL Forum thread, this Google document, and my update here for more).

Part of the issue, a previously noted, is viewer / simulator communications. If these are suffering latency or packet loss, then things can get rough with vehicle region crossing very quickly. This is something Joe has been trying to compensate for by introducing a script that turns off physics and freezes the vehicle when received by a new region until it can confirm the associated avatar data has arrived.

Unfortunately, excising the viewer from region crossing data handling would be difficult, as it has to be involved to move and change its primary connection for an avatar. It would take a major protocol change to remove the viewer from the region crossing loop and separate connection hand-off from crossings. Further, if such a protocol change were to be made, it would require more work to support both new and old until enough viewers get updated.

Mainland Price Restructuring

While the Lab does not issue numbers, Oz Linden indicated at the Simulator User Group meeting that since the Mainland Price Restructuring, “mainland ownership is up quite significantly.”

2018 SL UG updates #12/2: CCUG summary

Posted on by Inara Pey
A rally of (Animesh) raptors on Aditi

The following notes are primarily taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, March 22nd, 2018 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

There is no video to accompany this update, notes are taken from my own audio recording of the meeting.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures on avatar meshes.
  • An intended follow-on project to actually support baking textures onto avatar mesh surfaces (and potentially other mesh objects as well). This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

It is important to note that this project is still in its preliminary stages. Any release of a project viewer (see below) doesn’t mark the end of the project, but rather the start of initial testing and an opportunity for creators to have input into the project.

Project Viewer

  • QA testing revealed a number of bugs which need to be addressed before the project viewer reaches public consumption.

EEP and Atmospheric Shaders Work

Environment Enhancement Project (EEP) Summary

A set of environmental enhancements, including:

  • The ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level.
  • New environment asset types (Sky, Water, Days – the latter comprising multiple Sky and Water) that can be stored in inventory and traded through the Marketplace / exchanged with others.
  • Experience-based environment functions
  • An extended day cycle (e.g a 24/7 cycle) and extended environmental parameters.

This work involves simulator and viewer changes, and includes some infrastructure updates.

Current status: Rider Linden is working on some internal fixes for EEP which should hopefully move it closer to public visibility, and there is some more infrastructure work to be done.

Atmospheric Shaders Work

A project to revamp the viewer’s atmospheric shaders and rendering.

Current status: Graham Linden indicated “good stuff” is in the works, but nothing he can publicly report on as yet.

Animesh Project

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.
  • Will not initially include the notion of a body shape (see below).

Resources

Current Progress

Vir continues to work on performance profiles, and is “pretty close” to having something for Land Impact, with a formula under evacuation. Among the changes, this formula calculates scaling differently, and Vir notes there are a number of corner cases which need to be dealt with. The tri count cap will also be finalised alongside the updated LI formula.

Rigged Mesh Level of Detail / Bounding Box Issues

Beq Janus has reported on issues with rigged mesh LOD issues related to the avatar bounding box. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar Bounding Box. Some creators, deliberately or otherwise, force the bounding box to be far larger than is required, which then creates problems

For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily (see BUG-214736 for more).

Vir Linden agreed that this is a problem, and that forcing abnormally large avatar bounding boxes is undesirable. In some places, the Lab tries to use the rigged mesh wireframe as the basis for the bounding box, which is seen as a little more robust as it is looking directly at the triangle data, rather than working off of the avatar itself – and this is the approach being considered with Animesh to avoid similar issues with Animesh rigged mesh failing to correctly LOD in the viewer – however, so believe the use of such static data is “meaningless”.

JIRA “Accepted” Status

The “Accepted” status on the JIRA still causes some confusion. In brief:

  • For BUG reports, Accepted tends to mean the Lab have imported the report for evaluation / agree to there being a bug and will look to fix the issue. When it is addressed is dependent on a number of factors (e.g. severity of the issue).
  • For feature requests, Accepted means the Lab is sufficiently interested in the idea to want to track it. It does not mean the idea will be implemented, either in whole or in part. Whether it is implemented in whole or in part again depends on a number of factors (how it sits within the current workflow, whether or not it is related to work being carried out and can be added to it; whether it is something which might be implemented alongside of upcoming work; whether it is better to hold off until it and other ideas like it can be implemented together as a project, etc.).

Return of Last Names

The last portion of the meeting focused on the recent blog post from Linden Lab indicating Last Names would be returning to Second Life. Given the level of interest in this project, I’ve written a separate update on this section of the discussion. See:  The return of Second Life Last Names – update with audio.

In Brief

  • Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

    Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette). Graham Linden indicated that this is something the Lab plans to fix, but the work has yet to be scheduled.

  • Switching mesh asset on the same prim root: this used to be supported via script, but was removed due to people using it to create flipbook style animations which could adversely affect performance. It’s been suggested that it could offer an alternative to performance-impacting alpha swapping on meshes; however, the Lab’s view is that while alpha swapping is performance impacting, switching entire mesh assets would still be more of a performance hit, as the latter requires all of the geometry data associated with the mesh to be rebuilt every time.

Second Life: Last Names update with audio

Posted on by Inara Pey

Update, April 21st, 2018: at the April 20th Town Hall meeting with Ebbe Altberg, it was indicated that the new first name / last name system might be a Premium only benefit, or that if generally available to all users, that Premium account holders will have some advantage in using the capability over Basic account holders. Please refer to the audio of Grumpity Linden’s comments from that event appended at the end of this article.   

Update, March 28th, 2018: further information was provided at the Web User Group meeting on this date. This information has been appended to the end of this article. 

Following the Lab’s announcement that last names will be returning to Second Life  later in 2018 (see my post here), Oz and  Patch Linden have been providing further details on the change.

Patch has been commenting on the forum thread related to this topic (and the Lab’s 15th anniversary blog post in general), starting here, and I’ve also quoted him below.

Oz Linden took time to address questions on the subject at the Content Creation User Group (CCUG) meeting on Thursday, March 22nd.

The following is a summary of what has been said thus far, predominantly using Oz Linden’s comments at the CCUG meeting. I’ve attempted to summarise the key points as series of short topics, and have included audio extracts of Oz’s comments with each topic.

Note that the audio extracts draw together related comments voiced at different points in the session, as Oz addressed questions. I hope that presenting them in this way, rather than just chronologically as they came up at the meeting, helps to present a clearer picture of what is being planned.

In General

As the original blog post indicated, the return of last names will be coming later in 2018 – not in the immediate future. There are some back-end changes to SL which need to be made before last names can make a return, so it would seem like “later in 2018” users might be read as “late 2018”.

That is not something that we’re going to be able to deliver real quickly. Don’t look for it in the next few weeks. But it is on the road map for this year, and we’ll try to make it better than the very end of the year, but there are a couple of things that have to get fixed on the back-end before that can work.

Oz Linden, CCUG meeting, March 22nd, 2018

With the introduction of this system, Agent IDs will become the primary means of link names to avatars. As noted below, this means that those scripting items which require avatar details, and who don’t use Agent IDs might want to start thinking about revising their scripts to do so.

In Summary

  • The plan is to allow people to change their first and last name whenever they wish.
  • As with the “old” system, users will be able to choose whatever first name they like, then select their last name from a pre-set list of available names.
    • The list of last names will be routinely refreshed.
    • The Lab is considering accepting suggestions from users.
  • Once a name combination has been created, it is forever tied to that avatar, it cannot be used by anyone else, even if the “owner” later changes their name, or their account is deactivated.
  • Previous names will be retained by the system, so:
    • If you can remember someone’s previous name, you can search on that and get their current name.
    • Users will be able to switch back to previous names they have used, as well as select new names as the list changes.
  • Unicode will not be supported when entering a first name.
  • The first name / last name capability will not replace Display Names1.

This has no effect on display names and largely I do not anticipate we will change how display names work. If anything, it somewhat sunsets the need for them.

Patch Linden, March 22nd, forum thread

  • There will be a fee associated with changing your name (which has still to be determined).
    • The fee is liable to be “large enough” to prevent people simply constantly changing name just to use the “good names” up.

  • Advice from the Lab to scripters:
    • Given this change is coming, scripters who have a need to same avatar details should start to consider doing so by Agent ID, not first name / last name.
    • The Lab will most likely provide an API for resolving first name / last name into a valid Agent ID.

In the forum thread, Patch also reiterates the uniqueness of first name / last name combinations, as noted above.

No hiding of names. First name and surname combos will have to be unique like they are today. A couple of other questions that came up – no re-use of retired names, once a name has been used, it belongs to that account forever. We keep a transnational name change history. Only standard English characters will be permitted.

Patch Linden, March 22nd, forum thread.

I’ll have more on the return of Last Names as information becomes available, mostly like much nearer the time the feature is ready to deploy. In the meantime, Patch may post further information on the forum thread, so it might be worth keeping and eye on that.

Update From the Web User Group, March 28th, 2018

  • “Original / legacy” last names will not be re-opened for use.
  • New users joining Second Life will still be given the automatic “last name” of “Resident”, but have the option of changing if they wish.
  • The fee for name changes has not been announced, however, at this point the indication is that the fee will be in fiat currency (i.e. US dollars) not Linden Dollars.

Update From the Town Hall Meeting, April 20th, 2018

  • Intimation that the name change capability might be a Premium-only benefit.
  • Indication that if available to Premium and Basic, Premium members will have an (at the time of reporting) unspecified advantage over Basic account holders.

  1. Oz indicated that Display Names will not be replaced due to the work involved in removing the functionality. It’s also worth noting that – depending on the fee levied for name changes – people  who have multiple characters associated with their avatar for role-play, etc., and so frequently change their name, might find using Display Names remains more convenient / cost-effective means of doing so once the first name / last name capability is deployed.

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

Posted on by Inara Pey

Sanctuary; Inara Pey, February 2018, on FlickrSanctuary – blog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • There was no deployment / restart to the Main (SLS) channel on Tuesday, March 6th, leaving it on server maintenance package 18#18.02.12.512536.
  • The main RC channel should be updated as follows on Wednesday, March 21st:
    • The BlueSteel RC should receive a new server maintenance package. 18#18.03.17.513365 is said to comprise “internal fixes”.
    • The LeTigre and Magnum regions should receive a new server maintenance package. 18#18.03.14.513292, comprising internal fixes, additional logging to help diagnose an issue with in-world HTTP servers returning HTTP 503 (BUG-214702); add two new capabilities: one to request IMs that were delivered to the requesting agent while the agent was off-line; one to request the most up to date list of abuse report categories.

New Capabilities

The new capabilities in 18#18.03.14.513292 for Magnum and LeTigre are the first part of a set of server an viewer updates.

  • The new IM cap is to overcome of off-line IMs failing to be delivered when a user logs in. Currently, these are delivered via UDP, whether or not the viewer is ready to receive them. With the new capability (once grid-wide and implemented within the viewer), the viewer will request off-line IMs, which the server will package and deliver to the viewer via HTTP.
  • The new abuse report cap will replace the need for the viewer to have AR categories hard-coded into it. Once fully deployed, and a viewer update released, it will mean the view will request the current list of AR categories from the server when starting up, making the management of the list easier, and hopefully reducing the number of ARs filed under outdated categories.

SL Viewer Updates

There have been no updates to the current selection of official viewer at the start of the week, leaving the pipelines as follows:

  • Current Release version 5.1.2.512803, dated February 23rd, promoted March 1st – formerly the Nalewka Maintenance RC.
  • Release channel cohorts
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 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 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Region Crossings

As noted over the last few weeks, user Joe Magarac (animats) has been digging into region crossings, particularly looking at the issue of avatars getting unseated from vehicles (See Firestorm JIRA FIRE-21915, this SL Forum thread, and this Google document, plus my last update here for more).

His latest approach involves adding a script to a vehicle effectively turns off physics and freezes the vehicle when received by a new region until it can confirm the associated avatar data has arrived (using llGetObjectDetails (avatar, [OBJECT_ROOT]) to check for the presence of avatars). On confirming the avatars are present, the script check the vehicle is allowed to resume.

“The typical freeze time is 40-120ms in addition to the regular region crossing delay, so you barely notice.” Joe told me in discussing the approach, which he has now made available to those wishing to test it using a simple motorbike build. “For double region crossings, the vehicle should slow down, although not by too much. I’ve also tried the same script in aircraft, and it seems to work.”

Joe continued, “Right now, I want to see if it ever fails. Issues are logged to an external server, so I can see what’s going on. I’d also love to get some of the SL motorcycle clubs involved in testing , so I’m giving out these test bikes. However, if anyone wants to test the script with their own vehicles, they can contact me for a copy, and I’ll be happy to work with them.”

Again, this workaround isn’t intended to solve all region crossing issues (e.g. it won’t stop “rubber banding” or address motion prediction – which the Lab sees as probably too aggressive), but it should help with full or partial avatar unsits; so those interested in given it a go are welcome to drop Joe a line.

Other Items

SL Messaging Layer

“I’m looking at the messaging layer; that seems to be the problem behind a lot of laggy things,” Simon Linden stated during the SUG meeting, revealing some of his recent work.

“There’s been a lot of learning. That code is complicated and there’s actually a lot of wisdom written into it, but I’ve found it doesn’t really do the best things when packet loss increases. The most basic thing I’ve found is that the estimated times based on pings used for time-outs can grow too fast: like on a 100ms connection, it can jump up to using 5-10 seconds. There’s a balancing act between resending data, and thinking it needs tons of time to get there.

“It really goes bad if a ping packet or the reply gets lost. SL just uses the same time-out for each retry – that’s another part that could be smarter.”

Defining this as an “interesting” part of the code, he’s reasonably certain it could be doing things better – and in doing so, could also help with region crossings and overall updates.

He also noted that also the SL bandwidth code is broken. This appears largely due to the volume of traffic going over the HTTP caps and via the CDN(s), which isn’t counted. “So I’m pretty sure we clog up a narrow pipeline more than we should,” he added.

2018 SL UG updates #11/2: TPVD meeting with Ebbe Altberg

Posted on by Inara Pey

Realm Of Light; Inara Pey, February 2018, on Flickr Realm Of Light – blog post

Update: the 43-bit viewer KDU issues has been updated based on feedback from Ansariel Hiller.

The following notes are taken from the TPV Developer meeting held on Friday, March 16th 2018. A video of the TPVD meeting is embedded below, my thanks as always to North for recording and providing it. Time stamps in the text below will open the video in a new tab at the relevant point of discussion.

This meeting was somewhat extended  – lasting 1 hour 30 minutes – as a result of the presence of Ebbe Altberg, Linden Lab’s CEO, who commented on some of the item of discussion that came up at his session at VWBPE 2018 (see my notes and transcript here), as well as more broadly discussing Second Life and Sansar.

SL Viewers

[0:17-2:20] There have been no further updates to the current release, RC and project viewers in week #11, leaving the pipeline as follows:

  • Current Release version 5.1.2.512803, dated February 23, promoted March 1 – formerly the Nalewka Maintenance RC – No change
  • 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.

General Notes

  • The Media Update RC viewer is unlikely to be promoted to release status in the immediate future, as it has some Windows 7 update issues which need to be resolved.
  • The Love Me Render viewer is making good progress, although it also has the Windows 7 problem.
    • [7:30-8:30] This viewer also has a KDU issue which can cause the 32-bit version of the viewer to crash when uploading textures larger than 512×512. One workaround for this until fix is obtained – depending on how long that takes – is for an older version of KDU to be used for 32-bit viewer versions.
  • Despite the issues with it (see my update here), the 360-snapshot project viewer is not getting a lot of attention.
  • Animesh project viewer is getting close to a possible RC release and the Animesh project close to a move to the main grid.
  • The Bakes on Mesh viewer has cleared LL’s QA, so a Bakes on Mesh project viewer for use on Aditi should be appearing soon.

New Viewer Caps

[3:51-7:04] The lab is introducing two new viewer caps they’d like TPVs to adopt quickly:

  • One will be used when the viewer first logs-in to read all of the deferred IMs received while the user was off-line, which are being moved from UDP delivery to HTTP in an attempt to overcome issues of off-line IMs failing to show.
  • The second is to read the correct set of abuse report categories from the server, so only valid categories are displayed within the viewer, allowing users to more correctly file ARs, rather than using invalid categories held viewer-side.

 

General Discussion with Ebbe

Highlights only – refer to the video for the full discussion.

Economic Model

[9:20-14:35]

  • The Lab is looking to try to pivot the SL economic model away from a heavy reliance on land fees, and then in time hopefully reduce the cost of land.
  • This will see a shift from land to revenue generation through fees in other areas.
  • The Lab cannot simply drop land fees and raise fees elsewhere, the two have to be balanced, so while the Lab is hoping to “aggressively” tackle pivoting revenue generation, they will also be cautious in making changes.
    • The hope of reducing land fees can be seen in the reduction in Mainland fees.
    • [10:50 via Oz and Linden] The Mainland price reduction has already seen a significant uptick in interest for abandoned Mainland, with support being “overwhelmed” with requests.
  • There is currently nothing planned for Private region fees, simply because the Lab has to be cautious around revenue.
    • It might be a case of (a) fee increase(s) elsewhere first, followed after a time by consideration of what can be done with Private region fees.
    • It is however, something the Lab would like to do.
    • The steps must be measured not only to safeguard LL’s revenue stream, but also so as not to upset the SL economy.
    • For this reason, the Lab will take a little time to measure the Mainland restructuring before they make other changes, so that they can more accurately measure cause and effect between different types of change.
  • These ideas were also discussed that the VWBPE session with Ebbe – see my transcript notes (with audio from that session) for more.

Sansar

[15:39-18:36] A general overview of Sansar – which is still is  Creator Beta – including the drive this year to gain an audience for Sansar, plus improvements to the VR aspect of the platform. Most of this is covered in my weekly Sansar updates. For Ebbe in particular, the Sansar team is at a point where he feels comfortable pivoting attention away from that platform and back to Second Life, including spending more time in-world.

Sansar and SL

[18:38-22:09]

  • A re-iteration that Sansar was never intended to be a replacement for Second Life.
  • Both products now have completely separate teams working on them
    • At VWBPE 2018, Ebbe indicated that the core SL team – engineering, development, operations, support – is “close to” 100 in number.
  • There is an area of overlap between the two products, but there are also very clear differentiators.
  • Proof that Sansar isn’t a replacement for Sl is the level and speed with which LL has continued to invest in SL (overhauling the viewer and simulator build mechanisms, bringing more performance and stability to the platform) and to add new capabilities (Bento, Animesh, Bakes on Mesh, EEP, rendering enhancements, etc.).

Moving SL to the Cloud

[22:09-32:00]

  • Progress is being made.
  • Experimental regions have been run in the cloud, and they worked.
    • There are a lot of functional limitations that must be addressed before regions users can access can be run in the cloud.
    • The regions did achieve a reasonably high concurrency level (precise number not given).
  • Much of what SL does natively – dynamically spinning-up a new set  of inventory management servers or a new set of log-in services, etc. – is similar in nature to a lot of what cloud service providers do, so a lot of the back-end work involved in moving to the cloud is taking what the Lab have, and adapting it to run within the infrastructure of the cloud.
  • It is a massive engineering undertaking that will take time.
  • Once completed, it is hoped operating SL in the cloud will allow LL to offer benefits to users, which might potentially include:
    • Reduced costs for regions that are spun-down and stored to disk when no-one is using them, should this be explored for Second Life
    • Ability for simulators and services to be more geographically based (e.g. simulators used largely by an audience in South America could be hosted in facilities in South America)
    • Ability to potentially have a broader cross-section of land product based on server types, with a broader range of performance / pricing.
  • It is hoped that, for the most part, users won’t be aware of services being switched from the Lab’s dedicated infrastructure to running within a cloud infrastructure
    • Some non-user facing services are already running in the cloud.
    • The work will be done progressively, and not a “flipping of the switch” for “everything”.
    • There is not end-date for the work. The Lab is approaching it as aggressively as possible, but there are a lot of technical hurdles to be cleared along the way, some of which will only become apparent as attempt are made to shift things and put them into production via the cloud.
    • To deal with potential issues / hurdles, it is possible that further ahead, there is a simulator RC channel “in the cloud”, while others are still running on the Lab’s own infrastructure.
  • Also see Ebbe’s comments from VWBPE 2018.

Upcoming New User Experience

[1:01:23-1:07:11] The Product Team is doing a lot of work with the new user flow, and are getting close to where they can start experimenting with ideas.

Part of this work involves a themed learning island reached via a new user clicking a themed ad which takes them to a themed landing page on the SL website, where they can sign-up, obtain an avatar in keeping with the theme, and are delivered to a learning island that also follows the theme.

This approach will be tested alongside the current on-boarding routes.

Interesting tidbits:

  • The lab spent over a year building a “fairly sophisticated” tracking system to gather data on new users and see how they are doing, i order to try to learn more about on-boarding / retention.
  • The Lab’s data / testing suggests new user retention is no better in welcome areas with greeters, than for those without greeters.
  • A test the Lab carried out using a (non-public) browser-based means of accessing Second Life from sign-up (no need to download the viewer) also did not achieve better retention than the “traditional” sign-up and download route.

Other Items

  • [32:10-34:07] Mirrors in SL: the inevitable discussion – and no, mirrors aren’t in Sansar!
  • [34:08-37:08] SL and VR: re-cap of why the VR viewer was dropped from Second Life – unable to maintain the comfort-level VR frame rates (90 fps). Also segues into a discussion of the Sansar / SL Edit mode differences (also see Ebbe’s comments from VWBPE 2018).
    • [37:10-37:40] Sansar benefits to SL: Oz confirms that some of the rendering work with the atmospheric shaders to improve SL’s appearance is leveraging lessons learned with Sansar.
  • [38:35-43:50] Texture caching: the project to improve the viewer’s texture caching is still very active, and once completed, the Lab plain to look at other aspects of how the viewer caches data.
  • [44:17-47:09] Linux Viewer: no real change from my last update.
    • TPV have the same problem as LL re: Linux developers.
    • LL would like to see more from the Linux community get involved.
    • Suggestion is for Linux users to try running the Windows viewer under Wine.
  • [47:10-49:25] OpenGL and GPU/CPU divide: discussion on updating SL’s OpenGL version, which is already under consideration at the Lab. Broadens into a discussion of modifying SL’s rendering capabilities to make more use of more GPU shader capabilities for calculation (rather than being reliant on the CPU), and the risks (to users) this entails (as many SL users don’t use more modern hardware with GPUs capable of taking the load).
  • [51:58-59:58] Community Gateways: Discussion on the Community Gateway programme and attracting users. Includes mention of partners, Place Pages, etc. Ideas raised seen as something that could be put to the SL Marketing team under Brett Linden.
  • [1:12:52-1:14:14] Feature Requests: when filing a Feature Request JIRA, it is better to keep the request focused on a single idea which can be easily digested. Multiple ideas should be submitted via separate JIRAs so that meaning don’t become confused / the JIRA becomes to complicated to understand, etc. Multiple JIRAs around related ideas can also be related via identifier.

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

Posted on by Inara Pey

Kamigami, Pandora Resort Town; Inara Pey, February 2018, on Flickr Kamigami, Pandora Resort – blog post

Server Deployments

As usual, please refer to the server deployment thread for the latest updates.

  • There was no deployment to the Main (SLS) channel on Tuesday, March 13th, leaving it on server version 18#18.02.12.512536. According to the deployment notes, the channel should have been restarted.
  • On Wednesday, March 14th, the main RC channels should be updated as follows:
    • TBC: no deployment to BlueSteel, leaving it on server version 18#18.03.05.513046.
    • LeTigre and Magnum should both receive a new server maintenance package, 18#18.03.12.513258, comprising internal fixes and further simulator logging improvements.

SL Viewer

Updates

  • The Media Update RC viewer updated to version 5.1.3.513038, on Monday, March 12th.
  • A new Maintenance RC viewer was release on Tuesday, March 13th. Version 5.1.3.513234, code-named Ouzo, after the anise-flavoured aperitif. This viewer includes over 50 bug fixes and improvements.

Remaining Pipeline

Besides these two updates the official viewer pipeline remains as follows:

  • Current Release version 5.1.2.512803, dated February 23rd, promoted March 1st – formerly the Nalewka Maintenance RC.
  • Release channel cohorts:
    • Love Me Render RC viewer, version 5.1.3.513005, dated March 2nd.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 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 8th, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Meeting Reminders

  • There is NO Content Creation User Group meeting this week – the next CCUG meeting will be on Thursday, March 22nd at 13:00 SLT.
  • There is no Web User Group meeting this week – the next WUG meeting will be on  Wednesday, March 28th, at 14:00 SLT.