SL15B: Meet the Lindens: Grumpity and Oz summary

Grumipty (l) and Oz Linden at SL15B with Saffia Widdershins
Meet the Lindens is now a regular part of the Second Life anniversary landscape.

Over the course of the week of the Second Life anniversary celebrations, it gives Second Life users the chance to find out more about the people working at Linden Lab, find out about projects and plans, and the work being carried out on Second Life and Sansar, ask questions about matters of interest / concern to them.

For Meet the Lindens 2018, Saffia Widdershins sat down with six members of the Second Life team, as well as with Linden Lab CEO Ebbe Altberg:

 Table of Contents
  • Kiera and Patch Linden.
  • Oz and Grumpity Linden.
  • Xiola and Brett Linden.

This article is part of a set of summaries for the five sessions, and focuses on the conversation with Grumpity Linden and Oz Linden. Please note that it is not intended as a full transcript of the given session; because some topics came up more than once through the week, I have tried to focus each summary on subjects that were answered in the greatest detail within each individual session.

Use the links in the table contents to jump to topics of interest or any of the other sessions in this series. Note that audio extracts are included with each summary; these have been edited to remove pauses, repetitions, etc., with care taken to maintain the overall context of comments and answers.

All of the sessions were recorded as a part of the overall video record for the SL15B celebrations by SL4Live. For completeness, the video of each session has been embedded at the end of each summary. The timestamps provided here and in the other summary articles will open the relevant video in a separate browser tab, so you can here the question and reply as given during the conversations.

About Oz and Grumpity Linden

Oz Linden

  • Is the Technical Director for Second Life.
  • Previously worked in the telecommunication arena, notably with voice over IP systems (VOIP), where he managed a number of open-source projects.
  • Moved to Linden Lab in 2010 as a result of looking for something “more fun” to do.
    • Initially responsibility was to manage the viewer open-source project and rebuild what had become a fractious relationship with TPVs.
    • Role expanded over time to encompass more and more of the engineering side of Second Life.
  • As work on Sansar started to progress in earnest, he pro-actively campaigned within the Lab for his current role.
  • As part of this he took time to structure his engineering team around staff would wanted to stay with SL and remain engaged with it, rather than getting involved in Sansar.
    • He describes his team as some of the best people he’s worked with, and the work itself “a lot of fun”.
  • Work involves working with the operations team and others to ensure SL constantly evolves without (as far as is possible) breaking anything – a process he refers to and rebuilding the railway from a moving train.

Oz describes the more interesting part of his job being that of discovery:

Actually, the best part about it is that nearly every feature request or bug report that we get, teaches me something about the product that I didn’t know before, or about how people are using it, that I didn’t know before. A big part of my motivation as an engineering has been to build things that people will use, and to see the tremendous breadth and depth of the different ways people use Second Life and the different ways it is a part of their complete lives is just endlessly reinforcing. I am just constantly validated by how passionately people care about what we do and how engaged they are and how creative they are with using it.

Oz Linden on his love of Second Life and its user base

Grumpity Linden

  • Is the Director of Product for Second Life, enjoying what she and Oz jokingly refer to as a “symbiotic relationship”.
  • Actually started with the Lab in 2009, while working for The Product Engine, a company providing end-to-end consulting and software development services, and which supports viewer development at the Lab.
    • Her role was initially related to Viewer 2, which The Product Engine was not responsible for designing (that was 80/20 Studio), but was responsible for helping to develop and support.
    • Prior to working at The Product Engine, Grumpity worked in the oil and gas industry, and has a background in psychology and computer science.
  • Became a “full-time Linden” in 2014. Now manages the Second Life Product team, which involves:
    • Coordinating the various teams involved in bringing features and updates to Second Life (e.g. Engineering and QA), liaising with legal, financial and compliance to ensure features and capabilities meet any specific requirements in those areas, etc.
    • This work can also involve looking at specifics within various elements of the overall SL product, such as UI design and layout, etc.
  • She refers to herself, Oz and Patch Linden as the “hydra” or troika, responsible for the development and direction of all aspects of Second Life.

Bakes on Mesh

[20:26-21:12]

  • When mesh was introduced, the Lab didn’t see it as being used to create avatar body parts; as it was,the ability to use the extensive system wearables capability (skin, underwear, shirt, etc., layers) became practically redundant.
  • Bakes on Mesh is intended to re-enable the use of system wearables with mesh avatar attachments.
    • It updates the viewer, viewer, the server back-end and the Bake Service itself – providing: support of 1024×1024 sq metre textures – so that wearables held in inventory can be applied directed to mesh bodies and heads.
    • May in time lead to a reduction in the complexity of mesh avatar bodies and heads.
    • Does not (at this time) include adding materials (normal and specular maps) support, as this would require a much bigger update to the Baking Service.
    • Adds five new bake channels to the Bake Service specifically to support mesh body parts (these additional channels will not work with the system avatar).
  • It’s not fully understand what impact Bakes on Mesh will have on the current applier market
    • There is some thought that if implemented correctly, it could supersede the resource intensive (HUDs and scripting) applier market.
    • There are potential limitations with Bakes on Mesh compared to appliers (the lack of materials support being one).
  • Bakes on Mesh is currently available for testing on the Beta (Aditi) grid, and there is a project viewer available for this (version 5.1.6.516270 at the time of writing – Check the Alternate Viewers wiki page for updates).

Note: I provide updates on the Bakes on Mesh project through (generally) weekly Content Creation User Group meeting updates.

Animesh

[23:13-27:05]

  • A project to provide the means to animate rigged mesh objects using the avatar skeleton, in whole or in part.
    • Will allow independently moveable pets / creatures, animated scenery features and attachments using the skeleton and scripted animations.
    • Creations should be far more natural in movement and far less resource-intensive than current means of animating in-world objects.
  • Requires server and viewer updates.
  • Currently in development testing. At the time of writing:
    • Animesh is supported on all RC channels.
    • The project viewer (version 6.0.0.516979 at the time of writing) is available via the Alternate Viewers wiki page.
  • Until Animesh at least reaches viewer release candidate status, creators are asked not to sell Animesh projects because work is still ongoing, and it is still regarded as experimental.
Animesh dancing bears courtesy of Alexa Linden

Note: I provide updates on the Animesh project through (generally) weekly Content Creation User Group meeting updates.

Rendering Updates and EEP

[1:07:07-1:09:52]

  • Graham Linden from the rendering team, who had moved to Sansar, is now back as part of Second Life engineering team.
  • There have already been updates to the viewer’s rendering engine through the  Love Me Render viewer and more to come.
  • The Environment Enhancement Project (EEP) includes rendering updates to allow some new atmospheric effects and volumetric lighting effects.
  • EEP will also allow for different windlight settings at defined altitudes (ground up to 1,000m; 1,000 and above; 2,000 and above; 3,000 and above).
  • There is also a project in progress to revamp the texture caching system, which should result in faster rendering of scenes.

Note: I provide updates on the EEP work through (generally) weekly Content Creation User Group meeting updates.

Second Life Mobile Solution / SL in a Web Browser

[55:34-58:52] (mobile) and [1:00:27-1:02:10] (browser).

  • The potential for some kind of mobile solution for Second Life is being discussed.
  • One idea might be to provide a “companion” app, which could be used “between” desktop sessions.
  • Another idea is to provide an entirely standalone experience presenting all of Second Life to a user.
    • This might be something to prototype and see if it encourages user growth.
    • There are some significant challenges to providing such a standalone experience of this kind.
  • There are questions around what type of mobile device should be addressed? cellphone, phablet, tablet, etc., some of which might be better suited (due to large screen real estate) than others.
  • There have been streaming solutions  – the defunct SL GO from OnLive; the Bright Canopy product offered through Frame, for example. These also have challenges, notably cost to users.
    • While streaming costs are coming down, it is not felt that they have yet reached a point where they would be attractive to a large number of users.
    • When prices do reach a point where they could be acceptable to a reasonable portion of the Ls user base, the Lab may well provide a solution.
  • The Lab has also in the past experimented with streaming SL to a browser (e.g. the Pelican project).
  • Browser-based SL access is essentially streaming, so if the Lab were to support a streaming option, browser-based access would be a part of this.

Different Region Sizes and the Cloud

[1h04m42s-1:06:55]

  • Not something that can be offered at present: the 256 sq metre size is too deeply baked into the SL infrastructure.
  • It is potentially something the Lab would like to offer, and might be something that could be developed once transition to the cloud has been made and product opportunities examined.

Transitioning to the Cloud

Second Life will be transitioning to the cloud for the next year or so. Credit: Linden Lab / Amazon Web Services Inc.

[1:13:15-1:21:50]

  • [1:13:15-1:16:25] Why?
    • Second Life is currently limited to around four or five server types.
    • All of the servers (simulator and back-end services like the Bake Service, inventory service, group management services, log-in services, etc.,) then have to be maintained in the Lab’s own data centre (located in Arizona), incurring ongoing maintenance and running cost
    • As server models get older, they require replacing with more recent models.
      • This requires a lot of time and effort invested in testing different classes of server, assessing performance, determining which types will properly manage Second Life simulator loads, etc., and qualifying them for use before purchasing them in bulk.
    • The Lab recently reached a point where some of their current server types are due to be replaced, requiring another round of evaluation and certification of new server types.
    • However, today, cloud services such as Google and Amazon mean it is not necessary to go through the assessment / testing / procurement / provisioning / maintenance loop with a dedicated server farm – the companies who offer cloud services have already done all this.
      • It therefore makes sense for the Lab to leverage such companies and simply rent the servers they require.
      • It also means the Lab could potentially have a much broader pool of servers from which they can chose to run different simulator product types.

  • [1:16:28-1:18:13] Flexibility:
    • Using cloud services with data centres in multiple locations across the world may make it possible to locate regions closer to their primary audience (e.g. servers used by those in South America could be hosted in South America rather than Arizona).

  • [1:18:14-1:21:50] Progress:
    • Not as fast as some might hope, but is being made.
    • Some Lab staff now have their inventory served via the cloud.
    • It is likely the current deployment route of using release candidate channels to test new simulator releases will continue; however, what form this will take is still TBD.
    • The use of RC channels for server deployments will likely continue after the transition, but may be altered to suit the new environment
    • In fact, the RC process may actually be changed outside of the move to the cloud as things evolve, if there is a need to make it more effective.
      • This is because given the many ways users make use of SL outside of the Lab’s expectations, there is no way to test for every potential for issues or breakage ahead of a release. Hence the need for some sort of gradual exposure to new simulator releases: so things can be rolled back if something goes awry.
    • Similarly, while there will likely be changes to how rolling restarts are handled, they will still happen after the transition to the cloud.

Other Topics

About Project Viewers

[27:06-28:12] Project viewers are used with new features and / or capabilities which are still in development or are considered experimental.

  • These features / capabilities are not finalised, and maybe subject to change (and may cause possible breakage of content).
  • For this reason, they should not be used for the development of content intended for commercial resale.
  • Products for commercial resale should only be produced using release candidate viewers or, preferably, the actual release version of a viewer containing new capabilities.

Providing a Dynamic User Interface for the Viewer

[29:28-33:30] It has often been requested that LL implement a means to move viewer floaters outside of the main viewer window (e.g. have them as object on a second computer screen). Firestorm came up with a basic concept in 2014 – initially promoted within an April Fools joke, but actually with some conceptual substance.

  • This is on the “interesting ideas” list at the Lab, where some thought has been given to how it might be achieved, but there is no actual project at present.
  • It is possible that at some point the Lab may investigate at least a proof of concept study to see how it might work.
  • One issue with the idea is that the current toolset used internally by the Lab for their own UI is that it isn’t designed to handle “free-floating” elements outside of the viewer window, so this would have to be re-worked for the Lab to successfully put ideas to the test internally.

The Lab’s Relationship with TPVs

[35:53-40:05] It is believed the Lab has a positive relationship with Firestorm and other TPVs.

  • Firestorm are of inestimable help in acting as a first line of support / investigation of viewer and simulator issues, simply because of their own support team and problem triaging approach, and the number of users they have.
  • The Lab also accepts contributions from Firestorm and other TPVs, as and where they fit with the Lab’s development of the official viewer.

Mac / OpenGL Contingency Planning

[42:29-44:03] Linden Lab is committed to continuing to support Mac users, but not decision on which course of action to take has been made .

  • It is felt that there is still plenty of time to make a decision on which course of action to take.
  • The Lab would like to complete current projects relating to the rendering engine before making a final decision on future support for Mac users.
  • Many employed at the Lab use Macs, so it is a problem that will be solved.

Support for VR Headsets

[1:09:57-1:11:54] At this point in time the performance of the rendering system isn’t good enough to support VR headsets, which require sustained, high frames rates. The Lab hope that they can improve performance, and this coupled with improvements with VR hardware (and a reduction in its cost) might in the future make it worthwhile having another go.