2018 SL project updates 3/2: Content Creation User Group

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.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.

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.

Advertisements

SL Linux viewer to help bridge the gap

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

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

Lab posts on their 64-bit viewer and plans

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.

 

2018 SL project updates 3/1

La virevolte; Inara Pey, December 2017, on FlickrLa virevolteblog post

Server Deployments

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

  • On Tuesday, January 16th, 2018 the Main (SLS) channel was updated with the server maintenance package deployed to the RC channels in week #2.maintenance package  18.01.08.511751 comprises internal fixes.
  • Speaking at the Simulator User Group meeting on Tuesday, January 16th, Simon Linden indicated that the next RC deployment should be in week #4 (commencing Monday, 22nd January.

SL Viewer

The Alex Ivy 64-bit viewer, version 5.1.0.511732, dated January 9th, 2018, was promoted to de facto release status on Tuesday, January 16th, 2018. All other viewer in the pipelines remain unchanged at this point in time, although the Voice and Nalewka RC will be updated in due course for parity with the Alex Ivy code base. This means the viewer pipeline currently reads as follows:

  • Current Release version 5.1.0.511732, dated January 9th – formerly the Alex Ivy Maintenance RC
  • Release channel cohorts:
    • Nalewka Maintenance viewer version 5.0.10.330173, January 10, 2018.
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

  • Simon Linden is working on a new feature – due to go to Aditi (the beta grid) for testing soon – but will not be drawn on specifics at this point in time.
  • Joe Magarac (animats) has been digging into the viewer code handling region crossings in an attempt to improve avatar handing  when seated on objects and looking at the “partial unsit”issue (when the avatar becomes visual detached from a vehicle on a region crossing, but acts as if still attached (e.g. appearing seated, with any attempt to stand causing a viewer crash. He’s documented his work on a Firestorm JIRA (see FIRE-21915). Commenting on the work, Oz Linden indicates that if Joe would like to submit the change to the Lab (via the Second Life JIRA) the Lab would be interested in working with him to further improve agent  / object handling during region crossings.

 

Ivy Falls in Second Life

Ivy Falls; Inara Pey, January 2018, on FlickrIvy Falls – click on any image for full size

Miro Collas tapped me about taking a visit to Ivy Falls, an Adult rated Full region open (in part) to visitors to enjoy, explore and photograph, so we hopped over on a Sunday evening for a look around.

“It is a sim I built and share with my friend Rekka,” Kere Delcon says of the region, Rekka being Rekka Berchot. He continues, “Our private homes are on the north side of the land, but the rest is open and free for all to explore and use. Fair warning, though! It’s an adult playground designed for adults only to enjoy.” Ivy Falls is gay-friendly, and the Adult warning appears to reference the hints of BDSM which can be found in the region – nothing that is in any way blatant, but which can be found indoors in places.

Ivy Falls; Inara Pey, January 2018, on FlickrIvy Falls

Our visit began high above the majority of the land, atop a table of rock rising from near the centre of the region – although at the time of our visit, there was no set landing point. Not only does this offer a vantage point from which to survey the rest of the land and the surrounding mountains, it also provides an introduction to the region via a noticeboard, which  offers a general welcome and a few notices on visiting – particularly in reference to the private homes on the north side of the region.

There are two means for getting off of this plateau (not including jumping – flying is disabled by default): a teleport pad or a via a hang glider. The former is located by the welcome sign, and offers a quick route to any one of the major locations in the region. The hang glider can be obtained from the west end of the plateau (an empty glider will auto-rez as the previous one is used) and is fun to fly. use the arrow keys for banking or increasing / decreasing your speed, and the page keys to climb / descend, and simply stand when you are close to the ground.

Ivy Falls; Inara Pey, January 2018, on FlickrIvy Falls

The major locations open to visitors comprise the aforementioned lighthouse, a bar, a bath house / gym complex with a terrace before them, complete with a playable game of chess; a nearby bar and beach (with beach cabins, which have their own teleport option), a sauna a little more out in the wilds, a camp site, and a pier where sailing and rowing boats are moored. All of these destinations are within easy walking distance of one another across the south extent of the region, with the beach, cabins and pier to the west,  and the sauna up in the rock uplands to the east.

Most of the southern side of the land resembles a small resort town, nestled under craggy shoulders of sheer rock faces. This is the home of the elevated terrace and gym / bath house facilities (indoors and out), together with a small club house looking out over the snow-covered terrace. Beneath this, to the west, and linking it with the beach and pier, is a small commercial parade, with various businesses including a cosy café, a studio, a gentlemen’s hairdressers, the bar (through the door and downstairs), and what appears to be a gallery awaiting occupation. With cobbled paving and a small outdoor seating area with gazebo, fire pit and fountain, this part of the region is watched over by the red-roofed lighthouse.

Ivy Falls; Inara Pey, January 2018, on FlickrIvy Falls

It’s well worth exploring this side of the region carefully, as there are numerous footpaths winding their way around it. Some – such as the one leading under a rock arch to the beach on the west shore, may be obvious to the eye, other – such as those leading off the trail to the sauna – perhaps less so. The later in particular offer an excuse for a walk, and when followed reveal one or two more points of interest.

The private residences, as noted, are on the north side of the region, and physically separated from the rest of the land by a lake served by two channels of water – all of which are currently frozen in the winter setting. When exploring, it can be tempting to slip across the ice and continue wanderings on that northern shore – so please do keep in mind Kere’s request to respect the privacy of the residents there, and stay away from that side of the region unless invited.

Ivy Falls; Inara Pey, January 2018, on FlickrIvy Falls

Set in a perpetual winter evening’s light, this iteration of Ivy Falls makes for a pleasant visit with plenty of opportunities for the Second Life photographer, either using the default windlight or under assorted daytime settings – I opted to take some of mine under a morning setting.

SLurl Details