2019 Content Creation User Group week #41 summary

Cherishville, August 2019 – blog post

The following notes are taken from my audio recording of the Content Creation User Group (CCUG) meeting, held on Thursday, October 10th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are available on the Content Creation User Group wiki page.

Graphics Team

There are two new Lindens now on the rendering team – Euclid Linden, who has been with the Lab for around a month at the time of writing, and Ptolemy Linden, who has been a Linden for the last couple of weeks, again at the time of writing. Both will be working on various rendering projects which will include the Love Me Render viewer updates and also projects like the Environment Enhancement Project (EEP) – which is considered a priority in order to move that project towards release.

Euclid Linden goes full-on shark-man, while Ptolemy goes a little more conservative with a starter avatar

Viewers

No further updates thus far in the week. The hope is that the Vinsanto Maintenance RC viewer (version 6.3.2.530962 at the time of writing) looks to be in “good shape” for promotion, but currently requires a little more time in its release cohort.

This leaves the official viewer pipelines at the time of the meeting as follows:

  • Current Release version 6.3.1.530559, formerly the Umeshu Maintenance RC viewer, dated, September 5 – No Change.
  • Release channel cohorts:
  • Project viewers:
    • Legacy Profiles viewer, version 6.3.2.530836, September 17. Covers the re-integration of Viewer Profiles.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16.
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November 2017 – 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.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Work is progressing on building a predictive model based on the data LL has been gathering on mesh complexity, frame times, etc.
  • This model will be tested across a wider range of client hardware types and different ranges of settings.
  • The data thus far confirms that geometric complexity plays a large part in performance reduction, but also that there are a lot of other variables in play: rigged meshes are very different in behaviour impact to static meshes; some graphics properties can make a “big difference” in frame time, etc.
  • Details on the impact of textures has yet to be folded into the project.

Project Muscadine

Project Summary

Currently: offering the means to change an Animesh size parameters via LSL.

Current Status

Still largely on hold while ARCTan is being focused on.

Other Items in Brief

  • Mesh Uploader: a couple of points were brought up concerning the mesh uploader:
    • At the time mesh was introduced, materials were no supported; therefore, in the uploader there is code to discard tangent space (which can be used by normal maps). This means normals must be calculated in real time, causing both performance problems and inconsistencies between how normals appear in Second Life and how they appear in the 3D software used to create them. It’s been suggested this issue should be the subject of a Jira.
    • Allowing for the work on ARCTan, some see the uploader unfairly punishing on grounds of size and LI.
      • It what pointed out that a very large mesh that can be complex to render get hit with a high LI and high upload cost, but a very small object  – which may still have tens of thousands of triangles – is not penalised to the same degree, even though it might be as costly to render.
      • The alternative suggested was to have costs based not on LOD boundaries & changes rather than a simple size / LI basis. The idea here being that the cost is more reflective of what is seen and rendered by the viewer, which is seen as “levelling” the playing field (if a small object has a really high LOD tri count, then it would incur higher costs, in theory making creators more conservative in how they construct their models.
      • It was pointed out that in some respects complexity / LODs are already being gamed (e.g. by having one high LOD model then setting the medium and low LOD levels to use the same low poly version of the model for both and avoid costs for a proper mid-level LOD model), and such an approach as suggested might further encourage similar gaming.
      • Vir’s view is that the issue is not really that tied to the uploader per se, but is more in the realm of overall cost calculations (although LOD models obviously impact upload costs). As such, ARCTan is really the first step in trying to deal with these kinds of issues, and may help alleviate some of the perceived imbalance seen with upload costs.
  • Materials and Bakes on Mesh: a request was again put forward for LL to provide materials support for Bakes on Mesh. This is not an easy capability to supply, because:
    • System layers for clothing do not have a means to support any materials properties.
    • The Bake Service has no mechanism for identifying and handling materials properties to ensure they are correctly composited.
    • Thus, in order to support materials, both the system wearables and the Bake Service would require a large-scale overhaul which, given all that is going on right now (e.g. trying to transition services to being provisioned via AWS services), the Lab is unwilling to take on.
  • A request was made to allow 2K textures to be displayed by Second Life under “controlled conditions”, the idea being that a single 2K texture could eliminate the need for multiple smaller textures. The two main problems here are:
    • There is already a propensity for people to use high-res textures across all surfaces, whether required or not on the grounds “higher must be visually better”, so allowing even higher resolution textures to be displayed could exacerbate this.
    • Given there is no real gate keeping on how textures are used in-world once uploaded, how would any “controlled conditions” on the use of certain textures actually be implemented (both technically and from a user understanding perspective)?

Ani’s Gallery: new home, new exhibitions

Ani’s Gallery – Jeremynl, October 2019

In July, I had the opportunity to visit Ani’s Gallery, a new home for the art of Anibrm Jung, and for exhibitions of art by invited artists (see: Art, nature, and stories in Second Life). As is often the way with thing in Second Life, since that time Ani’s Gallery has relocated  – and in the process gained a new look. This being the case, I was delighted to be able to jump back and visit the latest exhibitions currently in progress.

As I have noted in previous reviews of her work, Ani is an award-winning photographer in the physical world who has been active in Second Life since 2006. Based in the Netherlands, she has specialised in photographing nature, many of her images captured from her own garden, and all of them recorded using only natural light, with everything framed directly through the viewfinder, and with no subsequent cropping or image manipulation.

Ani’s Gallery – Anibrm Jung, October 2019

More recently, Ani has broadened the scope of her exhibitions in Second Life to incorporate images taken in-world, and this is very much demonstrated with the portfolio of images she has on display in the Gallery’s lower level. Featuring two dozen images, it is an engaging selection that might be broadly split between landscape images and others more reflective of the art that can be found in Second Life.

In this latter regard, Ani is particularly drawn to the mesh sculptures of Mistero Hifeng, with five of the images representing his work. As an admirer of Mistero’s art, I can understand the attraction: his pieces always encompass a depth of narrative and powerful sense of emotion, and through her framing and composition, Ani adds to both as she presents pieces to be found on Mistero’s own region in a manner that invites further emotional and narrative translation.

Ani’s Gallery – Anibrm Jung, October 2019

Also evident in this particular exhibition is a talent for considered post-processing – something Ani avoids within her real life photography, as noted above. Here, she offers a lightness of touch and eye for balance and tone to present her work in a variety of finishes: watercolour and pen-and-ink; colour and monochrome. In doing so, she adds further depth to an engaging exhibition.

Located on the upper level of the gallery is an display of Second Life photography by Jeremynl. This is largely focused on avatar studies, which can perhaps be split into three groups: those featuring Jeremy on his own, those modelled by Dianna, and those featuring Jeremy and Dianna together. Sitting a little incongruously but nevertheless captivatingly among these are two pieces, each entitled Tree of Life Painting and which, I must confess, particularly held my attention due to the richness of expression each holds.

Ani’s Gallery – Jeremynl, October 2019

Which is not to say Jeremy’s portraiture fails to captivate; far from it. There are stories to be found within his studies, sometimes suggested by their titles – as with Tougher Than the Rest and I will be right here waiting for you, but more often simply by the image itself (particularly as some pieces appear to have all ended up with the same title).

I do confess to being more drawn to the images of Jeremy himself; no disrespect to Dianna (or indeed to Jeremy and Dianna where they appear together), but there is a more natural, less intentionally posed look and feel to several of those of Jeremy on his own – again, take the two pieces noted above, together with Playing and Who’s Got a Lighter?  – that offer an open invitation to frame a story around them.

Ani’s Gallery – Jeremynl, October 2019

Both of these exhibitions make for an engaging visit, and Jeremy’s work will remain on display at Ani’s gallery through until October 30th, 2019.

SLurl Details

More Gentle Breezes in Second Life

Gentle Breezes, October 2019 – click any image for full size

It’s been two years since our first visit to Rosy Highwater’s Gentle Breezes, and while I have a handful of region visits stacking up awaiting write-ups, I’m jumping ahead of some of the newer places we’ve visited (which are either getting a lot of attention right now, or may still be undergoing some further changes) to write about it once again as the colder months start to wrap their fingers around many of us as winter approaches.

Gentle Breezes, October 2019

A homestead region, Gentle Breezes offers a balmy, semi-tropical location of low lying beaches and palm trees backed by hills and temperate trees. Cut by a channel fed by waters tumbling from high falls, the region offers a restful setting where numerous places to watch the tide and the sea birds await visitors who want to spend time relaxing and enjoying their time together.

Gentle Breezes, October 2019

Up on the hills are more places to explore: cottages and cabins, outdoor seating areas, picnic spots, and more. Beaches and uplands are linked by a single path, one that passes between two blocks of rock a short distance from the landing point, wooden boards easing the way up the slope. North of these is a smaller beach facing a small island across a neck of water. Home to a cabin, this little island offer a place to get away from it all even while you’re getting away by visiting Gentle Breezes.

Gentle Breezes, October 2019

Wherever you wander on the region there is something to see or a place to sit and / or cuddle – while for those who fancy, the shallows can be waded and the local wildlife can be observed.

Spending a lot of time writing about Gentle Breezes isn’t really what counts here; the region is easy to visit and explore and offers more than enough to keep visitors engaged while exploring. So if you are missing summer already and want to have a sense of warmth and sunshine and hot sands beneath your feet, Gentle Breezes with all its little beauty spots and touches of detail, could be just the ticket.

Gentle Breezes, October 2019

SLurl Details

2019 Simulator User Group week #41

{PAPPADO}. August 2019 – blog post

Simulator Deployments

Please refer to the server deployment thread for the latest updates.

  • There was no deployment to SLS (main channel) on Tuesday, October 8th.
  • Two RC deployments are scheduled for Wednesday, October 9th:
    • 2019-10-03T01:12:11.531528, comprising:
      • Fixes: BUG-227645 EEP issue; windlight no longer rendering properly.
      • Internal logging changes.
      • Improvements to simulator state saves, which should make rolls smoother.
    • 2019-10-03T01:23:43.531529, comprising the same updates as above, with the addition of the internal script improvements previously deployed and subsequently rolled back.

Script Improvements

For details on the script issues referenced above, please refer to the following blog post from Linden Lab: Parent/Child object Script Communications.

An important point to note with this is that when release 2019-10-03T01:23:43.531529 has been deployed, any scripts that still exhibit the kind of communication issues indicated by the blog post will likely need to be altered by their creator to match the example scripts supplied in the blog post, or at least follow the communications process defined within it.

We’ve also learned a bit more about esoteric scripting behaviour; for example, if an event happens and it’s going to get picked up by multiple handlers, there is NO promises about the order they get it. And with communication or transfers between prims and objects, the big lesson is to make sure everything is ready with “hello” exchanges and confirmations that both sides are ready. It’s like passing a ball – make sure the other side is ready to catch it.

– Simon Linden

SL Viewer

The long-awaited Voice RC, version 6.3.2.531587, was issued on Tuesday, October 8th. Primarily intended to improve voice detection when you’re speaking, this voice includes the following fixes (non-public Jira reports):

  • BUG-227356 [Win] ‘SLVoice.exe’ starts an unexpected cmd window
  • VOICE-56 Voice is cutting out – seems like a threshold is too low
  • SL-11958 viewer-manifest should treat missing files as errors

The remainder of the official viewer pipelines remains as follows

  • Current Release version 6.3.1.530559, formerly the Umeshu Maintenance RC viewer, dated, September 5th – No Change.
  • Release channel cohorts:
  • Project viewers:
    • Legacy Profiles viewer, version 6.3.2.530836, September 17th. Covers the re-integration of Viewer Profiles.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.530473, September 11th.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16th.
  • Linux Spur viewer, version 5.0.9.329906, dated November 17th, 2017 and promoted to release status 29th November 2017 – 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.

 

Survivors of Suicide: Christmas Fair: seeking vendors, sponsors and more

Survivors of Suicide (SOS) is a peer to peer support group within Second Life dedicated to help those who have been impacted by depression, thoughts of suicide, or who have attempted suicide or have lost someone to suicide. The group offers practical support, as well as education and information on dealing with depression, suicide prevention and more.

Founded in December 2008, SOS is the longest running support group of its kind in Second Life, and celebrates its anniversary each year with a special Christmas Fair – and 2019 will be no different; but they need help to make it happen.

In particular the group is seeking:

  • Sponsorships:
    • Land Sponsors: the group would lot to hear from any individual or group willing to provide land on which the 2019 SOS Christmas Fair can be held.
    • Entertainment sponsors: if you have a favourite DJ or Live singer and would like them to appear at the Fair, would you be prepared to book them and pay for their time? If so, SOS would love to hear from you.
    • Photography contest: do you have items you’re willing to offer as prizes in the SOS Christmas Fair photo contest? The group are seeking things like cards, items from photography themed stores, etc., – even L$ amounts for the 5 prize slots in the competition.
    • Raffle items: donations of gift cards, transferable items, etc., for the fair’s closing gala raffle.
  • Entertainment: live singers, cover bands, DJ’s, spoken word artists, dance troupes – all are welcome to donate their time and talent.
  • Vendors / Merchants: SOS would like to have 35-45 vendors and merchants offer their goods at the Fair. Exclusive items are not required (but would be welcome!); all that is asked is that at least one item is offered for sale with 100% of proceeds going to SOS (or multiple items at a lesser percentage each).
  • Celebrity Elves: are you a “known” creator, fashion designer, blogger, etc., and are willing to spend a couple of hours at the Fair as a elf and available for people to take photos of themselves with you? If so, SOS would love to hear from you.
The SOS clubhouse

Full details on all of the above can be obtained from the SOS headquarters  – grab them from the 11th Anniversary Christmas Fair sign board outside of the main clubhouse for details and sign-up forms.

SOS wants to create a safe and fun place for everyone to go to over the holidays if they are feeling a little lonely or in need of some stress relief and we want you to be a part of it. Please stop by SOS and see how you can help make our 11th Anniversary Christmas Fair the absolute best it can be.

– The SOS team

Related Links

A closer look: Second Life viewer & simulator release processes

Part of the official viewer release process (see below for the full diagram). Credit: Linden Lab

Many of us are familiar with the Lab’s approach to viewer and simulator releases – but equally, many only have a passing understanding of what goes on. This was something reinforced to me as a result of in-world conversations I’ve had recently, so I thought I’d reach back to 2013, when I provided a guide to the viewer release process (see: New viewer release process implemented), and use that and some additional notes on simulator releases to try to provide and easy-to-follow overview of how the Lab manages official viewer releases and simulator updates.

The Viewer Release Process

Overview

Note: just to avoid any confusion, please remember these notes only apply to the official Second Life viewer supplied by Linden Lab (and which from the last Lab-derived comment on numbers (late 2016) I have could account for approximately 15%-20% of user usage).

The current viewer release process was introduced in July 2013 as a result of a number of issues occurring in 2012 that combined to produce a severe bottleneck in the Lab’s ability to make timely viewer releases and deploy everything from bug fixes to major new releases.

With it, the Lab can produce multiple versions of the viewer in parallel with one another, some of which may initially follow their own development / testing path independently of other versions, but which can, when they are ready, be tested for their suitability for promotion as the next de facto release viewer through direct monitoring of their performance and through comparison of that performance, one to the next.

The Viewer Release and Integration Process is intended to allow viewers to be better developed tested and prepared for release in parallel. Image credit: Linden Lab

Types of Official Viewer

The process achieves this by allowing viewers to be developed on a rolling basis, defined by project internally, and which eventually appear for public use in one of two “pre-release” versions, as it were: Project viewers and release candidate viewers.

  • Project viewers are generally viewers dedicated to a single new feature, capability or function within the viewer. They are essentially “first look” / experimental viewers designed to expose new features and capabilities (and any new viewer UI that might come with them) to users interested in them, who can then test and provide feedback (including bug reports) to the Lab, allowing the feature or capability to be refined and improved.
  • Release candidate (RC) viewers are viewers considered to be close to the point where they can be promoted as the de facto release viewer.
    • They might be former project viewers that have progress to a point where the Lab is considering formally releasing them, OR they might start as RC viewers in their own right without ever having been a project viewer.
    • It is these RC versions that allow the Lab to gather statistics on the behaviour of individual viewers in order to help determine their suitability for promotion to full release status.

Broadly speaking, whether a viewer starts its public life as a project viewer or a release candidate viewer depends on what it contains. A viewer containing a major new feature – such as Animesh, Bakes on Mesh or EEP, for example – will generally make an initial public appearance as a project viewer for the reasons noted above. Maintenance releases, hot fixes, and things like updates to the viewer rendering system will – in general – tend to appear directly as release candidate viewers.

No viewer ever goes directly from project status to a full release – all project viewers will go by way of progressing first to being a release candidate, then being judged as ready for promotion to full release status.

Where to Find Them and How They are Handled

Both types of viewer appear on the Alternate Viewers Page, but how they are handled is somewhat different – and this is one of the important aspects in understanding them.

  • Project viewers are largely “independent” viewer versions.
    • Users must opt to visit the Alternate Viewers Page and select, download and install one.
    • Each project viewer installs into its own dedicated location (although they share the same settings files and cache locations as the release viewer), so they can be run alongside the release version of the official viewer, if installed.
  • Release candidate viewers are considered as “alternative release viewers”.
    • Release candidates are assigned a “cohort number” the Lab believes will present a reasonable cross-section of users.
      • When a release candidate viewer is made available, the system automatically triggers the viewer update process among randomly selected users on the current official release viewer, moving them to the release candidate.
      • When the cohort number for a release candidate viewer is reached, it is no longer made available for automatic download / installation.
      • Once a user has been selected to receive a release candidate version of a viewer, they will continue to receive updates for that particular RC on a mandatory basis until it is promoted to release status – they will not be selected to receive other RCs (or updates to others RCs) until the RC they have been using in promoted to de facto release status.
      • The reason for doing this is to allow the Lab to monitor the performance of individual viewer release candidates and capture data on things like performance, stability, crash rates, etc. This data, together with bug reports, etc., filed by users is then used to determine an individual RC’s suitability for promotion to release status.
    • Alternatively, users can opt to manually install any RC viewer that interests them directly via the Alternate Viewers Page. Again, by default, any RC viewer installed in this way will overwrite any existing installation of the official release viewer (unless an alternative installation location is provided by the user), and the user will thereafter receive updates for that RC.
    • Note that users who do not wish to have RC viewers installed on their system can, if they wish opt out of the release viewer update loop from within their viewer, as shown below.
Users of the official viewer who do not wish to be involved in testing any release candidate viewers can opt out of the selection / download process by unchecking the Willing to Update to Release Candidates option in Preference. Note that having the option checked does not mean you will be subject to RC testing: users for each RC issued by LL are selected entirely at random from the poll of official viewer users.

How are Viewers Progressed to Release?

As noted above, project viewers follow defined path: they initially appear as a public project viewer, and then may go through multiple iterations of improvement, updates, added capabilities, bug fixes, etc., before they reach a point where the Lab determines they are ready for upgrade to release candidate status.

Release candidate viewers are more closely monitored by the Lab through their various cohorts, whilst similarly being subject to multiple iterations designed to remove bugs, help with performance, address further perceived shortfalls in functionality, etc., based on things like bug reports and feature requests from users.

While this approach means that multiple viewers can be developed, tested and readied for promotion to de facto release status, it often means that at any one time, there are several RC viewers vying for release. When this happens:

  • The Lab will select a viewer or promotion based on a number of factors, including stability, performance, number of remaining bugs / issues, the potential impact of said bugs issues, the urgency with which an RC needs to be released (e.g. an “late breaking” RC with a hot fix could well be promoted ahead of other RCs that have been available for longer) and so on.
  • Generally speaking, the Lab tries to promote no more than one RC to de facto release status every two weeks. However, depending on the overall state of individual RC viewers, the period between promotions can be longer.
  • Once a release candidate has been promoted to release status, the first order of business is to merge the code it contains into all over available RC viewers and then monitor them to see how they behave when built using the “new” release code, a process that also feeds back into determining which of them might next be promoted.

What this all Means in Summary

Simply, put, that official viewer and viewer updates can be produced on a rolling basis, with some starting as project viewers, others directly as release candidates, with the latter being objectively monitored both individually and in comparison with one another to determine which is best suited to become the next de facto release viewer.

Continue reading “A closer look: Second Life viewer & simulator release processes” →