Mojo Linden, the Lab’s new Engineering VP discusses SL at TPVD meeting

Andrew Kertesz

Linden Lab’s new Vice President of Engineering, Mojo Linden (aka Andrew Kertesz) dropped into the Third party Viewer Developer meeting on Friday, September 17th, both to say a few words and field some questions. These notes offer a summary of his  comments, together with some audio extracts.

When reading / listening to the following please note:

  • The bullet points within the topics are designed to help provide context to the audio.
  • Unlike my usual approach, I have not attempted to group comments by topic per se, but have ordered things as they were discussed through the TPVD meeting, so that the notes and audio extracts here do parallel the video recording of the TPV meeting, which is embedded at the end of this piece.
  • The audio extracts have been edited to remove pauses, repetitions, etc., and to remove break-in comments from others at the meeting. However, in doing this, every attempt has been made to maintain the actual context and meaning of Mojo’s comments.

Mojo’s Background

  • Mojo started his career at Microsoft, spending over 16 years working on a variety of products and services: Visual Studio, the DirectX API, XBox development (technology and game development). This also saw him help establish the Forza Motorsport Studio and work on a lot of the major Microsoft games like Halo.
  • Joined a former CTO for XBox at IGT (International Game Technology), a company producing slot machines, where he worked in a highly regulated software environment.
  • Moved on to Double Down, another gambling / gaming group, where he worked on mobile apps.
  • Thereafter moved to Level Ex, a company specialising in making games specifically aimed helping doctors face the chellenges of modern medical practice.
  • Developed a significant interest in virtual worlds and virtual spaces, which led him to join Linden Lab.

On performance and General Improvements

Mojo Linden

Following his comments about working on DirectX APIs, Mojo was asked if enhancing the viewer’s rendering capabilities would be a focus for him in terms of determining projects at the Lab, and also responding to comments about the value of working to fix issues and properly polish features and capabilities, rather than trying to push “big” new features.

  • As he was unclear on all the the Lab’s preferences regarding mentioning specific projects and times lines, was understandably cautious about talking in detail about specific projects.
  • Having had exposure to graphics APIs has an interest in improving rendering in Second Life.
  • However, has a broader interest in improving overall performance, which he sees as much a part of the platform’s feature set as any new features.
  • Agrees with the view that many users would prefer to see fixes and improvements to current capabilities rather than a massive push for new shiny features, and notes that the Lab is looking to “delight” its user community.
  • Acknowledges the point-of-view that functionality isn’t always delivered in a manner users were expecting it to work and that capabilities can be delivered / added, but then fail to receive the degree of polish that would make them more fully usable.
  • Indicated that LL have been discussing different lighting models  – and in doing so mentioned he has been made fully aware of the expectation among many users that whatever is introduced does not “break” existing content, etc.
  • Recognises that SL has a lot of users with a deep understanding of the platform, and is already thinking on ways that could be leveraged to help expand the platform and give practical improvements.
  • In this latter regard, he realises that TPVs have done a lot of work in the area of performance for themselves, and is keen to explore how this work can be better leveraged.

About Avatars, Complexity and Performance

  • Recognises that unbounded avatars with high complexity are not good for performance.
  • Questioned whether it is better to throw controls and options at users for them to deal with performance issues they hit, or whether it would be better for the viewer to deal with matters more inherently, based on the user’s system.
    • An example of this might be the viewer being able to more intuitive handle very complex avatars though automated imposter, etc., based on the capabilities of the system being used to run the viewer, etc.
  • During the discussion, Vir gave a brief recap on project ARCTan (the work to realign complexity calculations, starting with avatars), and Mojo questioned whether the user community is offering potential solutions (Beq Janus and Elizabeth Jarvinen (polysail) have been looking extensively at the question of avatar meshes – see my CCUG / TVPD meeting notes for more on this).
  • Is aware of the issues of avatar customisation, and is open to hearing back from those who directly face the issues new users have with their avatar looks, etc., on what might be done to improve things.

(My apologies for the sound balance in the extract below – the recording software went slightly wonky during the mid-point of recording the meeting, and attempts to re-balance after the fact didn’t exactly work…)

On Making Changes and Bringing New Users to the Platform

  • (Alexa Linden pointed out that Mojo has been through the avatar selection / customisation and experiencing its pinch-points, and since joining the Lab has been spending time in-world exploring.)
  • In terms of changes and improvements, Mojo is very aware that users can be resistant to change, particularly around things like the UI, where muscle memory plays a big role and people are simply unwilling to learn how to do things differently.
    • Alexa noted that Lindens are not immune to this, and the push-to-talk change in the current RC viewer has resulted in much internal grumbling about having to change behaviour.
  • He is very aware that the viewer has to address (broadly speaking at least) two different audiences: those who simply want to come aboard Second Life and grip to grips with the basics, and those who are more experienced in using the platform and want to carry out more advanced activities.
  • In this, he (again) recognises the value of TPVs and the commitment of the user base as a whole to Second Life and its growth, and so is interested in exploring opportunities for his own engagement with assorted parties via meetings and other possible forums of exchange / engagement. As such, he intends to drop into things like the TPVD meetings as often as he can – particularly if there is specific news to announce.

For completeness, here’s the video of the TPVD Developer meeting with Mojo’s input:

2021 CCUG and TPV Developer meetings week #37 summary

A Touch of Scotland – Bluebell Coast – blog post

The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, September 16th 2021 at 13:00 SLT, and the TPV Developer’s meeting of Friday, September 17th.

With the meetings once again falling on the same week, and with the degree of overlap in content between the two, core discussion points from both have been combined into this one summary. The TPV meeting was also recorded by Pantera Północy, and her video is embedded at the end of this article, for those wishing to refer directly to that meeting.

Meeting Details

  • CCUG meetings are held on alternate Thursdays each month (generally the 1st and 3rd Thursday, subject to the vagaries of month length), with dates available via the SL Public Calendar. The venue for the CCUG is the Hippotropolis camp fire.
  • TPV Developer meetings are generally held on alternate Fridays each month, although dates are not currently listed in the SL Public Calendar. The venue for meetings is at the Hippotropolis Theatre.
  • Both meetings are currently chaired by Vir Linden, and are led using Voice, although attendees can use either Voice or text to provide input / feedback (with text generally being the preferred medium).

SL Viewer

[TPVD Video: 1:08-5:52]

Simplifying the Viewer Pipelines

LL have have hit a bottleneck in current viewer development, Essentially, projects are tending to push multiple viewers internally for testing and QA work, creating a backlog; plus there are currently multiple RC and project viewers in flight. To this end, work has started to try to merge various viewer development tracks together and combine them into more “composite” offerings where this makes sense. This has been done with the two Maintenance RCs (see below), and if successful, will pave the way for other viewer project merges in the future.

Viewer Updates

  • Maintenance RC viewer  was issued on Thursday, September 16th.
    • As noted above, this viewer combines the former Grappa and Happy Hour RC viewers into a single viewer.
    • This RC also now makes Push to Talk with Voice the default behaviour. To change this, open Me → Preferences → Controls, then scroll down to Sound and Media, then click Primary Control for Toggle Voice and finally press Middle Mouse Button (MMB) for legacy behaviour.
    • However, these is a issue with this (see: BUG-231212 “[Maint G+H] Toggle speak on/off when I press button conflicts with key binding Controls”), which LL plans to address via a hotfix.
  • The Simplified Cache viewer updated to version on Friday, September 17th.

Remaining Viewer Pipeline

The rest of the official viewer pipelines remain unchanged from the start of the week:

  • Release viewer: version version, formerly the CEF Update RC viewer, issued July 24 and promoted August 10th.
  • Release channel cohorts:
    • Simplified Cache RC viewer, version, dated August 9th.
  • Project viewers:
    • 360 Snapshot project viewer, version, issued September 3rd.
    • Performance Floater project viewer, version, issued September 2nd.
    • Mesh Optimizer project viewer, version, issued September 1st.
    • Legacy Profiles viewer, version, dated October 26th, 2020.
    • Copy / Paste viewer, version, dated December 9th, 2019.

General Viewer Notes

  • LL are specifically looking for feedback on the 360° Snapshot project viewer and the Performance Floater viewer ahead of these being moved forward.

Mojo Linden

[TPVD Video: 6:22 onwards, interspersed with other discussions]

Mojo Linden, AKA Andrew Kertesz, the Lab’s new VP of Engineering, attended the TPV Developer meeting.  After giving a run-down of his career, he spoke about Second Life and responded to questions and feedback from those at the meeting.

Rather than cover his comments here – where it may only be read by those specifically interested in matters relating to the viewer / the CCUG meeting – I have attempted to offer a summary of his comments, with audio, and written context for his feedback based on the questions from those at the TPVD meeting. See: Mojo Linden, the Lab’s new Engineering VP discusses SL at TPVD meeting.

Avatar Discussions

The core of the CCUG meeting focused on mesh avatars and issues of complexity, performance, usability, etc. Taking the discussion in order:

  • Bakes on Mesh related issues:
    • The left arm/leg asymmetry (to allow things like independent left arm / right arm  tattoos) is seen as incomplete / complex / unworkable (e.g. having to use new channels that are “incompatible” with skin handling compared to the “old” channel, the limited use of the UV map by the left arm / keg (around 10%, etc.). Some have managed their own workarounds to this (e.g. by using the hair channel), but an official fix is seen as preferable. While this is seen as possible, it a) isn’t likely to be seen as a priority item; b) raises concerns over content breakage as a result of further changes.
    • The fact that the alpha wearable does not recognise the new channels introduced with BOM, and so it is possible to end up with the right arm alpha’d as expected, but the left are still visible, which is unwanted. While a Jira has been received to produce a new alpha wearable, this has yet to be implemented.
  • There are reports that people arriving in regions are seeing some avatars with “faces [initially] pasted on the back of their heads”. It is thought (by other users, not the Lab) the primary cause of this is the Lelutka Evo X head using a non-standard UV, and the Bake data arriving in the viewer ahead of the mesh head data (which corrects it).
  • Avatars and performance:
    • As most are aware, a significant hit on performance comes from the fact that mesh avatars are pretty poorly optimised. Beq Janus and Elizabeth Jarvinen (polysail) have been investigating just how hard segmented avatars impact people’s systems, and the results of their work has been summarised by Beq in a couple of technical, but well worth reading blog posts:
    • One suggestion is to implement a means to algorithmically generating the collapsed mesh – or to put it another (simplistic) way: “bake” the entire avatar: body, clothing, attachments, into what would effectively be a composite mesh with fewer faces, limited (or no) body segmentation etc. But exactly how this would be achieved, and what would be required (and exactly how it would work in terms of making on-the-fly changes to attachments, etc.), is unclear.
  • Calls were made to completely replace the SL skeletal rig completely, which lead to a discussion of the flexibility of the rig compared to capabilities found in Unreal Engine and Unity (two engines oft cited as examples of the engine Second Life “should” have). Animator and creator Medhue Simoni questioned the value, pointing out that from a professional standpoint, he finds the SL rig far more capable for avatar creation than the commercial offerings (which is not to say that as capable as it might be, there are not serious issues with the SL rig).
  • The subject of having a new default avatar in SL was raised, with fingers pointing to Patch Linden’s comments at SL18B, which can be found summarised (with a link to the discussion point in the official video) here.
  • The issue with any new avatar system is that it encompasses significant areas of work – the rig, the meshes, the animation system, improved IK, etc.

Two-Factor Authentication

[TPVD Video: 29:46-29:59]

This has been a long-requested capability and something the Lab has been working on for some time.

According to Grumpity Linden we should – with fingers crossed – be seeing some form of announcement on the on Monday, September 20th.

In Brief

  • [CCUG] The Graphics team currently remain primarily focused on drilling down into the data being gathered by the Tracy debugger / system analyser.
  • [CCUG] User Joe Magarac (animats) has been experimenting with better asset loading prioritisation based on screen area. This is something the viewer doesn’t usually do. The video below gives an example of his results (although you might want to turn the sound down a little, if you have speakers on!).

This appears to work well with the cases shown in the video, but as was noted by Animats (and othera) in the meeting:

    • As presented, the code doesn’t currently account for faces using the same texture.
    • Further work is required to account for off-scale meshes that are corrected using prim scale, and with rigged meshes, which don’t report their on-screen size.
  • [TPVD] Some considerable time ago, TPV developer NiranV Dean submitted a contribution to LL for a pose system that propagates avatar poses/animations between viewers for multi-avatar posing. This has been “on hold” for a while, with a promise that discussions should be resumed.
    • Mojo Linden indicated that puppeteering is something the Lab is actually actively discussing / thinking about.
  • [TPVD] Kitty Barnett (Catznip) has been testing scene optimisation through the viewer and has encountered a problem where if a scene is “over optimised”, viewer frame rates collapse until complexity is added back to the scene (such as by enabling shadow rendering).  The precise cause is still TBD, but appears to be related to random OpenGL calls being generated, possibly by the Nvidia GPU, or as a result of a debug setting, or even a flush call being missed, and too much render information being queued at once.
  • [TPVD] Firestorm has been compiling a list of “most wanted” fixes and improvements based on feedback received from their user base by way of feature requests filed with them, questions put to their various language support teams, direct comments, developer experience in handling the viewer code, etc. This is to be submitted to Linden Lab so that they might seen common trends / requests from users.