Month: January 2018

2018 Sansar Product Meetings week #3 – with audio

Posted on by Inara Pey
Sneaking a peep at Anu Amun’s new steampunk experience

The following notes are taken from the Sansar Product Meetings held at 4:00pm PST on the afternoon of Friday, January 19th, 2018. These Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat, and there is currently no set agenda. The official meeting notes are published in the week following each pair of meetings, while venues change each week, and are listed in the Meet-up Announcements. and the Sansar Atlas events section.

Ebbe Altberg and Paul  (aka Pierre), Alex and Nyx Linden from the Sansar product team joined meeting host Jennifer for the event. Audio extracts from the meeting are included below for reference to key points in the discussions. Note that some subjects were discussed at different points in the meeting, and so some of the audio extracts here represent a concatenation of the different points at which a particular topic may have been discussed.

Web Atlas – Concurrency Indicators

The Web Atlas has been updated with a new search category – Popularity – and concurrency indicator. When selected from the sort drop-down menu (see below), the Popularity option orders the listed experiences in a tab by current real-time use,  so those with avatars actually visiting them will be listed first.

In addition, those experiences with avatars in them have a concurrency indicator in the top left corner of their thumbnail image. This is a near real-time indicator that the experience is in use at the time it is seen in the Atlas.

Web Atlas: popularity in the sort drop-down (circled), and the concurrency indicators (arrowed) available for all experiences with avatars in them on all tabs. Note the relatively low number of “active” experience in this image may appear low as it was captured at 10:40am UK time on a Saturday morning, a typical time for low concurrency numbers for VWs

The popularity search option and the concurrency indicator will be added to the client Atlas, possibly as an update in week #4. Both present a first step in presenting users with more information on popular experiences and in helping them locate spaces which have a “social” presence in Sansar.

Sansar Store Tags

It is now possible for creators to tag items when creating Sansar Store listings, and the Store Guidelines have been updated to reflect this.

January Release

The January 2018 release, referred to internally at the Lab as “Release 17” (the Fashion release having been Release 16), is primarily code / performance focused. In particular this update includes:

  • Bug fixes.
  • Performance improvements – for example, the amount of data sent to the client for avatar and dynamic object animations has been reduced by some 60%, which will hopefully make things more fluid for users in busy experiences.
  • An experience loading progress bar has been coded, although the scene loading page has yet to be revised to show it, and it is hoped this will be in Release 17, or deployed shortly thereafter.

User Sign-up / On-Boarding Process

The Sansar product team believe the current sign-up / on-boarding process for Sansar (see here for the basics) is too complex. It is hoped that a more streamlined sign-up process will form the nucleus of the February 2018 release, and that these updates, together with the Atlas popularity ratings / indicators, will make it easier for incoming users to sign-up and start finding experiences where they can meet and interact with other Sansar users.

Under discussion at the Lab is whether or not to create a dedicated “on-boarding” experience towards which incoming new users could be directed following sign-up, rather than just leaving them to find their way around the Atlas. This would not be part of the February release, and could be more of an exercise in testing which route  – via sign-up and then Atlas, or sign-up and “learning / tutorial” experience – is preferred by in-coming users / helps improve retention levels among new users.

Should Sansar have “on boarding” experiences akin to SL’s Social and Learning islands (shown above)? If so, should they be split between “general / consumer” users, and “content creator users”? How would such learning centres, as part of a sign-up / on-boarding process sit with experience creators providing their own gateways to their experiences? These are some of the questions the Lab is asking itself

One issue with providing any “centralised” on-boarding experience is how will it sit with user-created experiences? Part of the idea with Sansar is not to have a central / main “gateway” into the platform (as is the case with Second Life), but to allow experience creators to develop their own gateways directly to their own experiences (e.g. through a dedicated web presence, a corporate website, or via Facebook or Twitter, etc.). So, how do any on-boarding experiences supplied by the Lab fit with these routes of access?

Should a user signing-up to Sansar through a specific experience gateway be “diverted” to a Lab-created learning experience and then dropped into the experience they were signing-up to join? If so, how exactly should that work? Should they simply be dropped into the experience they were expecting, and be left to work it out for themselves / complete any tutorial options provided by the experience creator?

There’s also the question of how deep does any on-boarding experience have to go – can things be made easier to understand through the client itself – keeping the UI straightforward, offering on-screen indicators for controller buttons options when required, etc?

Mentors / Greeters

A suggest was made to have a “learning welcome” space where volunteer “Sansar ambassadors” (akin to Second Life mentors) can spend time helping new arrivals gain familiarity with using the Sansar client – the atlas, settings, walking, running, chatting in text, IMing, etc.

In response, Ebbe noted that – contrary to anecdotal views in Second Life – having mentors (either at their own welcome environments or those at the various Community Gateways in operation around Second Life) does not actually lead to any greater levels of retention among new users than the self-teach environments that have been presented to incoming users over the years. However, the is a willingness to experience with methods – with the use of AI-driven NPCs or the provision of some kind of “learning HUD” also being mentioned as possible options to help new users.

Events

Pierre reiterated his comments from the previous Product Meeting, that additional tools to help creators / users mount and promote their own experiences will be appearing in the very near future. This is again seen as a component in helping to drive user interest in Sansar.

Avatar and Fashion

Currently, the Sansar avatar is not – outside of the head / face – customisable other than with clothing and accessories. As recorded in my 2018 week #2 notes, there are plans to enhance the degree of customisation available within the avatar, starting with the head, and then with work on the body. This led to concerns on how additional avatar customisation capabilities might impact clothing design. Animator and creator Medhue Simoni in particular laid out his concerns in a video on the matter, which apparently became the subject of discussion at the first Sansar Fashion Product Meeting (which I was unable to attend), with it being indicated that the Lab’s Fashion Team had watched the video, taken note of the concerns raised etc.

As the avatar is enhanced, there may well be a need for clothing designers to go back and re-rig clothing created outside of Marvelous Designer (MD), although it should be possible to re-simulate MD clothing over a changed avatar body shape once this capability has been enabled with Sansar.

In the short-term for Fashion, there will be an update to fix the UV issues people are experiencing with MD, wherein the export to Sansar is using a different UV space to the export to other formats. However, the avatar customisations capabilities will be added gradually over a longer period of time.

To help compensate for the avatar updates, requests have been made for a deformer mechanism to be added to Sansar to allow rigged mesh clothing to more easily adjust to the avatar shape (and changes to it – think Fitmesh is Second Life as a broad idea), while potentially avoiding the need for clothing to be supplied in a range of sizes. This may not be so easy to introduce.

However, and whether it will be possible to implement or not is still unknown, the Lab is trying to determine if, where different clothing sizes are required, the platform itself can auto-generate different default sizes rather than the designer having to upload them all (e.g. if a designer uploaded an item in a “standard medium” size, the “standard large” and “standard small” sizes would be auto-generated from it).

One of the things the Lab wants to do is keep the fashion creation flow relatively straightforward, and avoid placing too many requirements on designers. They are therefore keen to avoid things like morph-based solutions and blend shapes (thus negating designers having to implement a whole series of body morphs into their designs or having to run through some conversion process to handle blend shapes, etc.).

Continue reading “2018 Sansar Product Meetings week #3 – with audio” →

Lost in Thor’s Land in Second Life

Posted on by Inara Pey

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land – click on any image for full size

Land of Thor is a huge setting designed by Thor (Anaadi Resident), who recently extended an invitation for Caitlyn and I to visit. Located on a Full region, it is one of the first places we’ve visited to make use of the additional 10K Land Impact allocation available to Full private region owners who wish to raise their overall total from 20K to 30K – and the additional allocation has been put to extensive use!

“The region is very loosely based on Norse Mythology,” Thor informed me when offering the invitation, “and has a lot of interesting places to discover.” Which, as it turned out, was something of an understatement!

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land

The land itself, bathed in sunlight under a cold-looking blue sky and surrounded by tall, rugged peaks with flanks cloaked in fir trees, certainly has a Nordic feel – on arrival I was reaching for a woolly jumper. Roughly divided into four parts by river channels, the land is a curious set of contrasts, with each part named for one of the nine realms of Norse mythology.

The main landing point sit on the largest of these four parts: a huge table of rock occupying the north-west quadrant of the region. Sitting beneath a humped shoulder of rock from which rises Asgard, legendary home to the Æsir tribe of gods. Facing south, the landing point looks out over much lower-lying lands. A switchback path curls down to these lowlands from a slightly lower shelf of rock reached via stone steps, while a great waterfall plunges from a cleft in the great plateau.

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land

Like its namesake, Asgard is surrounded in part by a (albeit low) wall, while smooth path of smooth stone snakes up to it from the west, where sits Yggdrasil, the mythical tree that connects the nine worlds in Norse cosmology. Travel north from the tree, and then west along the cliff edge of the plateau, and you’ll come by way of a grassy trail through avenues of trees leading east, to where a great stone arch spans a deep chasm, offering visitors a way to reach Alfheim (or Álfheimr, “Land Of The Elves” or “Elfland”). This is another highland area, rich in tall grass and where time seems to have stood still, sitting among low, pointed peaks of rock.

Below these northern heights sits Midgard, home of the humans in Old Norse, and for the region, the location of a modern-looking settlement broadly split into three parts: an open-air entertainments area sitting at the foot of the high cliffs of Asgard / the main landing point and separated from the rest of the town via a narrow channel. South of this, and straddling a small natural harbour, sits the rest of the town. Many of the houses are raised on stout wooden stilts, several of them brightly coloured, and fishing boats are tied-up at wharves, marking this as a working town, rather than a holiday setting. A large house – that of the mayor? – sits slightly elevated and a little separated from the rest, occupies the south-east corner of the land, and all of the houses are open to the public.

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land

But this is not all; sitting under the plateau of Asgard, and reached via teleporter (look for the carved stone disks located around the region) or – for those keen of eye – via a hidden entrance curtained by water – is Helheim. Traditionally the abode of Hel, daughter of Loki, in this instance it is a place of winding tunnels and chambers. Easy to find one’s way into, but perhaps not so easy to find a way back out.

Helheim is sometimes linked with Niflheim (“land of Mist or “world of the darkness”), which is one of the locations only reached via the teleport system. Like its namesake, this a place of ice and snow – and home to another great castle-like hall, this one equipped as a club.  Also accessed via the teleport system are Jotunheim (or Jötunheimr, the land of the Giants) and Svartalfheim.

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land

For Land of Thor, Jotunheim is presented as an oriental / Japanese environment, although at least one giant is present near the landing point. Cobbled paths run through the landscape here, linking points of interest, which include an interpretation of FLW’s Fallingwater, and floating islands reached via ropes bridges, as well as a pagoda rising from a nearby peak – also reached via rope bridge.

In Norse mythology, Svartalfheim is the home of the svartálfar (“dark elves”). Here, and while dark (being underwater), it has more of a sci-fi / post-apocalyptic feel to it, with a particular emphasis on a certain sci-fi franchise. It can also be reached without teleporting – for those travelling far enough through Helheim’s tunnels.

Thor's Land; Inara Pey, January 2018, on Flickr Thor’s Land

Even with all this description, I’m still only scratching the surface of Thor’s Land. There are paths to be explored, trails to follow, houses and castles to be examined, hidden walkways to be found, dragons to be ridden – and places to simply set and relax. There’s obviously a lot to photograph as well, for those so minded, and the region has a dedicated Fickr group to which images can be submitted.

Eclectic, eye-catching, detailed, and surprising, Land of Thor makes for an engrossing and worthwhile visit.

SLurl Details

  • Land of Thor main landing point (Mirrors Edge, rated: Adult)

2018 SL UG updates #3/2: Content Creation User Group

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

The following notes are primarily taken from the Content Creation User Group meeting, held on  Thursday, January 18th, 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 for this meeting, as Medhue missed the first 30-ish minutes. Audio extracts are supplied instead, where relevant.

Animesh (Animated Mesh)

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.

However Animated objects will not (initially):

  • Have an avatar shape associated with them
  • Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
  • Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
  • Use the avatar baking service
  • Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Resources

Viewer Update

The Animesh project viewer updated on Thursday, January 18th to version 5.1.1.511908. This includes a merge up to the Alex Ivy viewer code base, and so is only available for Windows (32-bit and 64-bit) and Mac OS X (64.bit). A number of updates are also included with the viewer:

  • Reduced lag when zooming in and out on some models.
  • Improved rendering performance when preview wireframes are displayed.
  • Some diagnostic updates and performance fixes.
  • In mesh upload, allow underscores in joint names to substitute for spaces.

Performance Profiling / Animesh Limits

As promised in the week #2 meeting, a region has been set-up on Aditi for public Animesh performance profiling which has a tri cap that can be varied (called Animesh XL), allowing it to be set higher than the 50K limit found on the other Animesh regions on Aditi. The Lab has internal regions set-up for performance profiling as well.

There has been a request for a triangle count and/or skeleton count per square metre limit, rather than the triangle count and land impact limits the Lab are currently experimenting with. Vir concedes that this may give a similar result to the Lab’s approach with tri count and LI, but also notes that people are already pushing tri counts to the limit, and he’d rather have something that helps push towards more optimised content creation. He also notes that tri count isn’t the only potential performance impact  – texture use, for example can also have an impact – so it’s a case of finding the right balance and ensuring that balance uses figures which are easy for creators / users to grasp.

The tri count limit is per object / linkset for Animesh, and is something of an approximation based data specifying the size of an object, in order to avoid having the simulator having to carry out all the triangle count calculations (and possibly impacting simulator performance). The resultant figure does under-estimate of the actual number of triangles within an object / linkset – but not, Vir believes, by a huge amount.

One issue around performance is avatar attachments, which don’t directly count towards region limits in the same way as things like LI, but which can still have an impact on performance (as can be seen with avatars wearing a lot of high-poly mesh attachments). However, re-working how attachments are handled specifically for Animesh is considered problematic, and unlikely to be re-worked (and so is being handled by a straightforward cap on how many Animesh attachments can be worn at one time – initially 1 for testing purposes) .

Animation Playback Issues

It’s been noted that animations already running on an Animesh object don’t necessarily play for those entering the region where they are running, or update correctly when camming to them for the first time. This appears to be a race condition, with the viewer receiving information on the animation before it has rendered the object being animated, resulting in the animation being ignored. Vir is confident that now the cause has been found, the issue can be fixed.

There is also an issue related to the Interest List where an Animesh object in a neighbouring region fails to update (animate), even when in your field of view and draw distance.

Both of these issues are still being investigated.

There is a claim that animations fail to play when an Animesh object is attached directly from inventory. This is something that isn’t being seen by the Lab, and which might be down to code within the animation script itself, or could be an issue. Vir has requested a JIRA specifying the problem and how to reproduce it.

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.
  • 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.

Current Progress

Vir believes Anchor Linden has resolved the issues around getting the appearance service updates out.

Other Items

Screen Release Estate and Multiple Monitors

The Second Life viewer is constrained to the window / screen on which it is being used: however many floaters and panels a user opens, they can only be displayed in the one window / screen, which can quickly become crowded. This had led to various suggestions on how the issue of screen real estate use might be improved, including:

  • Making floaters and panels so they can be displayed outside of the main viewer window. Firestorm actually developed a proof-of-concept model for this several years ago. However, it was just an experiment, and the overall functionality was limited. The idea was thrown open to allow viewer developers to work on the idea, but the complexity of the work meant it was never carried forward.
  • Altering Second Life so that more than one viewer session can be run from the same account at the same time: the idea here being that a use with multiple monitors could log into SL with their account, position the viewer on one screen, then log in again with the same account, and have that viewer instance on a second monitor – so they could use one for all their chat and inventory floaters, while have a clear in-world view on the other. This would require extensive changes to the back-end of SL, and so is potentially even more complicated than making the viewer floaters work outside of the main viewer window.

Next CCUG Meeting

Due to various conflicts, it appears that the next CCUG meeting will not be until Thursday, February 16th, 2018. However, as this has yet to be confirmed, the best thing for the next 2-3 weeks is to monitor the CCUG wiki page for updates and meeting notifications.

SL Linux viewer to help bridge the gap

Posted on by Inara Pey

As noted in my recent article on the promotion of the Lab’s Alex Ivy 64-bit viewer to release status, there is currently no official 64-bit support for Linux at this time.

It is hoped with will change: the Lab is establishing a viewer build environment to build a Debian version of the viewer with the various specialist libraries required by the various flavours of Linux. The hope being that this, with contributions from the open-source community, will provide a means for the Linux flavour of the viewer to continue, with viewer developers adding the specific libraries they may need as required.

It’s not clear how long it will take for all of this to mature, and for a Debian version of the viewer to appear. In the meantime, it means that as the Lab baseline their viewer build process on Alex Ivy, and existing project and release candidate viewers are updated to the Alex Ivy code, they will cease having Linux versions. This can already be seen with the 360 snapshot viewer, the project render viewer, and the Nalewka RC at the time of writing (versions 5.1.0.506743, 5.1.1.511873, and 5.1.1.511871 respectively), none of which have a Linux flavour of the viewer. As the remaining project and RC viewers currently in the pipeline are updated with the new code case, they will also be without a Linux version for the time being.

To help compensate for this, on Thursday, January 18th, 2018, the Lab release the Linux Spur release candidate viewer, version 5.0.9.329906.  Dated November 17th, 2017, this viewer is in fact the Martini RC viewer which was promoted to release status on  November 29th, 2017 – the latest viewer to be promoted to release status prior to Alex Ivy being promoted.

While it is not explicitly stated in the release notes, it is unlikely this version of the viewer will be updated with bug fixes, updates, etc., but will be offered until such time as a Linux viewer using the 64-bit libraries is made available.  As such, it may offer a means for SL viewer users on Linux wishing to continue using that viewer, rather than a TPV flavour of Linux.

Obviously, those TPVs providing their own Linux flavour of the viewer are free to continue to do so.

Dreamer’s Feelings in Second Life

Posted on by Inara Pey
Dreamer’s Feelings

Dreamer’s Feelings is the title of a collaborative 2D and 3D art installation by Maddy (Magda Schmidtzau) and CioTToLiNa Xue, which opened at Trésor de l’Art on January 10th, 2018.

The installation is located in a sky gallery, reached via teleport from ground level – which instructions for the best viewing experience can also be found. Those who find the preferred windlight – Ambient Dark – a little to dim to see, might prefer setting their viewer to midnight. Do, however, take note of the need to have Advanced Lighting Model (ALM) enabled. Shadows are not required, so this shouldn’t be too much of a performance hit for most people – however, as the exhibition does use projectors, it is essentially ALM is turned on (if not on by default in your viewer) in order to fully appreciate the installation. Once any adjustments to the viewer have been made, the installation proper can be reached via one of two red teleport discs.

Dreamer’s Feelings

“Dreamer’s Feelings,” the artists note, Is a dreamlike narration through happy feelings.” And so it is visitors travel through a series of halls wreathed within the darkness of night, each offering scenes of colour and expression in which certain motifs – notably that of music  – can be found.

Starting from an illuminated pool, the display halls rise step-like, separated one from the next by steps or ghost-like art which stands almost glass-like across entrances or glides like smoke across them (again, it is essential that ALM is enabled to fully appreciate the scenes).  In the first hall, hands rise from the watery surface, lights playing over them and they surround a guitar. Close by, two more arms rise from the water, fingers entwined as lovers might hold hands, while images are projected  on the marble-like walls.

Dreamer’s Feelings

From this starting point, the remaining halls rise to surround the pool almost entirely, each one offering a mix of 2D art (Maddy) and 3D art and sculptures (Maddy and CioTToLiNa), with some of the motifs freely represented in either format. Directly above the pool float four spheres containing Figures of an angel, who  – in three at least – appears to be keeping watch on things.

With the dark environment settings, the projected lights and images drifting around and through the sets, the repeated motifs, this installation has the feel of travelling through a dream – but whether it is your own dream or someone else’s is up to you to decide. Whichever you chose, the art by both Maddy and CioTToLiNa is engaging wnough to warrent  visit to Dreammer’s Feelings and spending time wandering through the halls.

SLurl Details

Second Life: official 64-bit viewer and plans

Posted on by Inara Pey

On Tuesday, January 16th, Linden Lab promoted the Alex Ivy 64-bit viewer (version 5.1.0.511732 at the time of writing). This is a significant release, not so much because of any specific new features (although it does include improvements to media handling), but because it marks a number of important changes to the viewer.

Following the release, which Oz Linden blogged about the viewer and the Lab’s plans around it, on Wednesday, January 17th, 2018, and I’ve highlighted a few points of note from that blog post below – but do please read it in full.

Most notably, this version of the official viewer is built using an updated set of libraries (some of which will be undergoing a further update in the future), and a revised build process. It is currently being made available for download for Mac OS X (64-bit) and Windows (32-bit and 64-bit) – there is no Linux version of this viewer at this time, as explained below.

For Windows users, the most significant update lies with a new viewer executable, the SL_Launcher, which – as Oz explains in his blog post:

Manages the viewer update process, and on Windows also ensures that you’ve got the best build for your system (in the future it may pick up some other responsibilities). For Windows systems, the best build is usually the one that matches your operating system. For example, if you’re running a 64-bit Windows, then you’ll get the 64-bit viewer. If not, then you’ll get the 32-bit viewer.  However, some older video cards are not supported by Windows 10, so the launcher may switch you to the 32-bit build which is compatible for those cards. You won’t have to do anything to make this work – it’s all automatic – if you get an update immediately the first time you run this new viewer, it’s probably switching you to the better build for your system.

Oz also notes that if you have a shortcut to the viewer set-up, you should update it to point to SL_Launcher rather than the viewer .EXE, to avoid issues with running / updating the viewer, and indicates there is a slight bug with both the SL_Launcher and Second Life Viewer processes both show as icons on the OS X Dock, and will be fixed in a future update so that only a single icon is shown.

One of the things the Lab has been tracking with the Alex Ivy viewer is overall performance / stability. It had long be noted that running the 32-bit version of the Windows viewer on 64-bit version of Windows with more than 4 Gb of memory could lead to fewer crashes related to running out of memory. However, with the 64-bit version of the viewer, the Lab have seen further benefits for Windows users, and so are encouraging those who can to switch to using a 64-bit version of their preferred viewer, if one is available (e.g. users still running a 32-bit version of a viewer on a 64-bit version of Windows, or those upgrading their hardware to a system running 64-bit Windows).

Linux will be supported – if there is sufficient input from the open-source / Linux communities

Linux is the notable exception to the Alex Ivy branch of the official viewer, as there is currently no support for the operating system.

Linden Lab halted Linux development work in 2015 for a number of reasons (see here for more), and sought the support of the Linux community (who represent around 1-1.5% for the SL user base) to help maintain the viewer on Linux. More recently, as I’ve reported in a number of my weekly SL project updates (see here for an example),  the Lab has set out new plans for Linux support going forward, With Oz explaining:

We’re reorganising the Linux build so that instead of a tarball, it produces a Debian package you can install with the standard tools, and rather than statically linking all the libraries it will just declare what it needs through the standard package requirements mechanism. We’ll post separately on the opensource-dev mailing list with information on where that project lives and how to contribute to it.

Again, a key aspect of this project will be continued support from the open-source / Linux community to help maintain the Linux viewer going forward, in providing bug fixes, etc., and the Lab providing essential QA and the core build environment, as noted above. This approach is seen as beneficial, as it will remove many of the idiosyncrasies / overheads involved in producing a Linux viewer, such as maintaining multiples libraries associated with the viewer, and instead provide a basic viewer package which can be used by TPVs / Linux users to meet their specific preferences.

Some TPVs have already released versions of their viewers based on the Alex Ivy code, and Firestom’s upcoming release should also, I believe, include a 64-bit version based on Alex Ivy.

And if you’re wondering about the viewer’s name – as Oz explains (and I noted back when the first 64-bit project viewer appeared), Alex Ivy is derived from 64 in Roman numerals: LXIV – aLeX IVy.