Category: SL User Group Meetings

2020 Content Creation User Group week #18 summary

Posted on by Inara Pey
The Getaway – Nutmeg, March 2020 – 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, April 30th 2020 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are are available on the Content Creation User Group wiki page.

Unfortunately, my recording software crashed some 2/3rds of the way through the meeting (and I was afk, so didn’t spot it), so I missed recording around the last 15-20 minutes of the discussions.

Jelly Dolls / Avatar Rendering

  • As noted in my week #16 CCUG summary, Vir has been looking at the jelly doll rendering code, which is not well optimised (e.g. it still draws rigged attachments) and it handles some operations inconsistently (e.g.setting an avatar to never render is actually more processing expensive that simply leaving it jelly dolled).
  • One of the things Vir has been experimenting with is displaying Jelly Dolls as monochrome system avatars sans rigged mesh and attachments.
  • An issue with this approach  is that non-human avatars use animations to reposition bones and joints, when can result in the system avatar looking very weird, even in monochrome. Vir has therefore been focused on finding a way to pause the animations when a non-human avatar is jelly dolled, and just running something like one or two of the default animations from the system locomotion graph.

In brief

BUG-228564 -Feature Request: New object property “Intangible”

This is possibly a duplicate request (those listed on the Jira are for different functionality, so not true duplicated), requesting an option to make certain in-world objects “invisible” to the viewer’s ray casting, so they they do not react to mouse clicks, but the objects beyond can.

Such a capability would be useful where semi-transparent objects are used to imitate sun beams or fog or rain, etc., otherwise block the ability to click on objects (e.g. seats, etc.), they surround / are in front of. However, such a change would require both viewer-side and back-end changes so, even if the Jira isn’t a duplicate of an existing request and is something LL accept, it is unlikely to be worked on until after the cloud uplift work has been completely, simply because it will require the introduction of a new object property on the simulator side / back end.

Education / Awareness

Much of the meeting was a general discussion on how to better inform / educate creators and users on the benefits of optimised content, and exactly what can impact things like perceived SL performance.

The major crux of this discussion came down to providing better documentation / information that both creators and users could be pointed to (e.g. more detailed information on mesh creation, including topics such as LOD generation, tri counts, use of maps, etc. for the former; clearly-worded instructions and benefits of using tools like ARC, etc., in the viewer to improve performance, etc., for the latter).

  • It was pointed out that LL have limited resources for the production of comprehensive best practices, and that perhaps the best sources for these might be creators themselves.
  • As the SL wiki is currently closed to general editing, those who have a specific desire to edit wiki pages / build articles can request access by sending an e-mail outlining who they are and why they want access to: letmein-at-lindenlab.com.

2020 Simulator User Group week #18 summary

Posted on by Inara Pey
Wizardhat Studios, March 2020 – blog post

The following notes were taken at the Simulator User Group meeting held on Tuesday, April 28th.

Simulator Deployments

Please refer to the simulator deployment thread for updates.

  • On Tuesday, April 28th, the majority of the grid was updated to server maintenance release 540213, previously deployed to an RC cluster and comprising simulator updates related to Premium benefits.
  • A single RC update is due on Wednesday, April 29th. No version number as available at the time of writing, but Rider Linden indicated it contains no functionality changes, but is an update to the simulator build tools.

SL Viewer

On Monday, April 27th, 2020, the Zirbenz RC viewer updated to version 6.4.1.540593.

At the time of writing, the remaining RC viewers have yet to be merged up to the EEP release, and there have been no project viewer updates, leaving the remaining official viewer pipelines as follows:

  • Release channel cohorts:
  • Project viewers:
    • Copy / Paste viewer, version 6.3.5.533365, December 9, 2019.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, November 22, 2019.
    • Legacy Profiles viewer, version 6.3.2.530836, September 17, 2019. Covers the re-integration of Viewer Profiles.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.

In Brief

  • The fix for the issue off-line inventory losses from objects (see: BUG-227179 “All offline inventory offers from scripted objects are STILL lost”) is still awaiting deployment.
  • Simon Linden is stepping back from running the SUG meetings to focus more on the cloud uplift work. He’ll still be attending, but Rider is taking the reins.

2020 Simulator User Group week #17 summary

Posted on by Inara Pey
Peacehaven, March 2020 – blog post

The following notes were taken at the Simulator User Group meeting held on Tuesday, April 14th.

Simulator Deployments

Please refer to the simulator deployment thread for updates.

  • There was no deployment to the majority of the grid on Tuesday, April 21st, leaving in on server maintenance update 539684.
  • On Wednesday, April 22nd, three RC deployment should take place:
    • 540213 – simulator updates related to Premium benefits.
    • 540369 – containing updates to fixes for the just released name changes after it was discovered the feature could, in a couple of places still call you by your former name for up to a week (“oops!”, as the Lab put it), and assorted internal changes.
    • A further deployment 540032 first deployed on April 15th, containing updates related to the cloud uplift.

SL Viewer

On Monday, April 20th, 2020, the EEP RC viewer, version 6.4.0.540188 and dated April 15th, was promoted to the de facto release viewer. See:

At the time of writing, the remaining RC viewers have yet to be merged up to the EEP release, and there have been no project viewer updates, leaving the remaining official viewer pipelines as follows:

  • Release channel cohorts:
    • Camera Presets RC viewer, version 6.3.9.538729 March 25.
    • Love Me Render RC viewer, version 6.3.9.538760, March 25.
    • Zirbenz Maintenance RC viewer, version 6.3.9.538719, issued March 19.
  • Project viewers:
    • Copy / Paste viewer, version 6.3.5.533365, December 9, 2019.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, November 22, 2019.
    • Legacy Profiles viewer, version 6.3.2.530836, September 17, 2019. Covers the re-integration of Viewer Profiles.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.

In Brief

A question was raised over the potential for EEP to cause “lag” (with up to 4 altitude layers for EEP sky settings plus the use of parcel environment options, there is concern loading and reloading the required textures could impact travellers. In response to the concern, Simon Linden said:

Compared to the cost and payload of stopping your AV on one region, sending the data to the next and adding you into that part of the world, the EEP data change is pretty small. Your viewer might have a little more work to get textures and set up the sky and lighting, but I don’t think those will be significant.

Rider, Ptolemy and Euclid Linden, the three major movers behind EEP will be on the Friday, April 24th edition of Lab Gab.

Environment Enhancement Project: a primer

Posted on by Inara Pey
The Environment Enhancement Project (EEP) is a set of environmental enhancements designed to replace windlight XML settings to control the water and sky environments seen in Second Life, and provides a wide range of additional / new capabilities for region holders, parcel holders and general users. It represents a fundamental shift in how environment settings are used and applied.

In brief EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows the Sun, Moon and Cloud textures to be replaced with custom textures uploaded to the viewer.
Table of Contents
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Allows users to override region / parcel settings as seen within their own viewer, by either attaching EEP settings to their avatar or through the Personal Lighting floater.
  • Provides new LSL functions to allow scripts to interact with parcel environments.
EEP allows you to have a little fun, if you wish. Credit: Bellimora

Many have already gained familiarity with EEP whilst it has been in development, using both the original project viewer and iterations of the release candidate viewer. However, given it is such a fundamental shift in how environment settings are created and used, I have attempted to break things down into more easily digestible pieces through the use of this EEP primer, and a more comprehensive EEP tutorial.

  • This primer is designed to provide an overview of the basic EEP capabilities and options from the point-of user of someone wishing to use them.
  • The EEP Tutorial is intended to provide a comprehensive breakdown of EEP capabilities, including how to create new EEP sky, water and day settings for personal use or which can be given or sold to others.

You can use either this primer or the tutorial to better understand EEP (the information here is also presented in the tutorial, which also explores the various floaters and options in greater depth).

For official information on EEP, please refer to the Environment Enhancement Project SL wiki page.

EEP Basic Concepts and Terminology

In brief EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others – including selling (subject to the SL permissions system) via in-world stores and on the Marketplace.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows custom textures for the Sun, Moon and clouds.
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Means that as environments settings are simulator-side, and so by default are automatically seen by anyone using any EEP enabled viewer on entering the region / estate / parcel.
  • Still allows the use of “personal” settings seen only be the use applying them, for the purposes of photography, machinima, etc.

Terminology

EEP uses some key terminology that should be understood.

  • Settings: used to define the environment you see. There are three settings types:
    • Sky: define the atmosphere and lighting for a day (or night); the movement, density, etc., of the clouds; and the appearance of the Sun and / or the Moon (which remain in a fixed point in the sky).
    • Water: define the appearance of Linden Water (prim or mesh animated water is not affected): water colour and reflection; wave movement; amount of light refraction, etc.
    • Day Cycles: collections of Sky and Water settings that are combined to present a dynamically changing environment over a user-defined time period representative of a “day” (by default this is set to the legacy Second Life day / night cycle of 4 hours, but can be extended out to represent physical world time periods of up to one week).
    • Note that Sky and Water settings are referred to as Fixed Environments.
  • EEP assets: physical “containers” for storing EEP settings. These are inventory items that by default, are stored in the new Settings folder in your inventory (see below), they are split into three types:
    • Sky – Sky settings. Icon: a blue sky with clouds.
    • Water – Water settings. Icon: a water droplet.
    • Day Cycle – for Day Cycles. Icon: a split Sun / Moon.
    • EEP assets (permissions allowing) can be exchanged, given away, and / or sold through a store or via the Marketplace.

Note that EEP settings are:

  • Created or edited using their corresponding EEP asset (e.g. to create Sky settings, you use the Sky asset type).
    • New EEP assets can be created directly from inventory, just like any other system inventory asset type (notecard, clothing item, gesture, script, body part).
    • Creating / editing EEP assets and settings is covered in depth in my EEP tutorial.
  • By default stored within a new system folder in inventory – the Settings folder. This folder may be hidden until such time as an EEP asset is created.
By default, EEP assets are stored and created in the Settings folder in your inventory (l). If you want, you can manually sub-divide your settings into suitable folders for easier tracking (r)

EEP Permissions

There are a few notes on permissions associated with EEP settings / assets.

  • Copy/no-copy: EEP settings assets may never be marked no-copy. A person who owns a setting object may always make a copy of it in their inventory.
  • Transfer/no-transfer: the no-transfer permission is persistent. If you import any no-transfer day or water setting into a day cycle, that day cycle will also become no-transfer. Once saved, this change cannot be undone.
  • Modify/no-modify: these permissions behave as normal.

EEP Library Assets

EEP includes a collection of Sky, Water and Day Cycles, together with a set of textures that can be used for clouds and / or to replace the Sun and Moon, etc.

  • These are located in Inventory (CTRL-I) → Library → Environments.
  • They can be used in one of two ways:
    • Unmodified, directly from Library → Environments.
    • By copying them to your inventory (e.g. to your own Settings folder, if it is visible through the creation of an EEP asset; if not, any other folder can be used), where they will become modifiable, allowing you to adjust them / use them to create your own settings.
    • See my EEP Tutorial for editing / modifying EEP assets and settings.

Differences to Windlight

Some of the key differences between EEP and windlight are:

  • EEP settings are stored in inventory assets, not as XML files saved to your computer.
  • Because they are server-side, EEP settings are by default seen by any viewer affected by the. This can mean:
    • Parcel owners using a specific set of environment settings no longer have to request visitors manually switch to them.
    • Settings are no longer dependent on visitors to a parcel with a custom environment having the precise windlight XML file stored on their computer.
  • EEP setting do not require any external storage (e.g. Dropbox) in order to be shared with other users, if they are to be given away.
Pages: 1 2

Second Life: EEP – the Environment Enhancement Project

Posted on by Inara Pey
The Environment Enhancement Project introduces an entirely new way to create and use environment settings for the appearance of the sky, day cycles and , Linden Water, within the viewer. Among other things, EEP capabilities include the means to apply environment settings to individual parcels, allows them to the sold and bought,enable day cycles that can last up to 168 hours, and permit the use of custom Sun / Moon textures, as seen here, with settings by default automatically to all viewers they affect.

On April 20th, 2020, Linden Lab announced the official release of the Environment Enhancement Project (EEP). Originally announced in 2017 – see Second Life Windlight environment enhancements – it has taken longer than anticipated to reach a release status, but it brings with a host of new features and capabilities.

What is EEP?

For those who many have missed it, EEP provides an whole new way of creating, modifying and applying environments (sky and water settings and day cycles) in Second Life. in brief, EEP:

  • Uses environment objects that you can keep in your inventory and / or share with others – including selling (subject to the SL permissions system) via in-world stores and on the Marketplace.
  • Provides parcel-level control of environments.
  • Allows up to four different, independently controlled sky layers.
  • Allows the Sun, Moon and Cloud textures to be replaced with custom textures. uploaded to the viewer.
  • Provides an extended day cycle of up to 168 hours (thus allowing a 7-day, 24-hour day / night cycle to be defined, for example).
  • Allows users to override region / parcel settings as seen within their own viewer for the purposes of photography, etc.
  • Provides new LSL functions to allow scripts to interact with parcel environments.

Currently, to use EEP, you will require the official Second Life viewer – version 6.4.0.540188, dated April 15th (or later). However, TPVs will be releasing version supporting EEP in due course.

I’m in the processes of polishing a basic EEP Primer and an in-depth EEP tutorial, which will be published shortly. In the meantime, here’s the official video on EEP.

2020 SL project updates week #16: TPVD summary

Posted on by Inara Pey
Little World, February 2020 – blog post

The following notes are taken from the TPV Developer meeting held on Friday, April 17th, 2020. These meetings are generally held every other week, unless otherwise noted in any given summary. The embedded video is provided to Pantera – my thanks to her for recording and providing it. Time stamps are included with the notes will open the video at the point(s) where a specific topic is discussed.

The latter part of this meeting as largely general text chat related to group chat issues – please refer to the video, if required.

SL Viewer News

[0:00-7:20]

  • As per my week #16 CCUG meeting notes, the EEP RC viewer updated to version 6.4.0.540188 on Wednesday, April 15th.
  • If no issues are found with this version of the viewer, it will likely be promoted to de facto release status in week #17 (commencing Monday, April 20th).

The remainder of the official views currently in progress remained unchanged through the week as:

  • Current Release version  version 6.3.8.538264, dated March 12, promoted March 18th. Formerly the Premium RC viewer – No change.
  • Release channel cohorts:
    • Camera Presets RC viewer, version 6.3.9.538729 March 25.
    • Love Me Render (LMR) RC viewer, version 6.3.9.538760, March 25.
    • Zirbenz Maintenance RC viewer, version 6.3.9.538719, issued March 19.
  • Project viewers:
    • Copy / Paste viewer, version 6.3.5.533365, December 9, 2019.
    • Project Muscadine (Animesh follow-on) project viewer, version 6.4.0.532999, November 22, 2019.
    • Legacy Profiles viewer, version 6.3.2.530836, September 17, 2019. Covers the re-integration of Viewer Profiles.
    • 360 Snapshot project viewer, version 6.2.4.529111, July 16, 2019.

General Viewer Notes

  • EEP is expected to be promoted “early” in week #17. By close of business Friday, the viewer had around 1/3 of the preferred number of users hours LL look to have before determining on a viewer’s promotion.
    • This viewer should allow personal environment settings applied to an avatar to persist across log-ins. However, if this is used with custom settings, there is a risk the viewer will crash on logging-in; a fix for this will follow the viewer’s release.
  • The order of promotion for the remaining RC viewers still TBD.
    • It had been indicated that the LMR RC would not follow behind EEP in the order of promotions, as the Lab did not want to have two sets of rendering updates going out almost back-to-back to one another (allowing for the 2-week gap between release promotions). However, from comments made at the CCUG and the TPVD meetings, LMR may be the next to be promoted after EEP.
    • However, all of the current RC viewers appear to be in good shape and ready for promotion over the next 1-2 months.
  • The Camera Presets RC viewer is currently suffering from around an issue a week cropping up that is preventing it being declared as fit for promotion.
  • The mesh upload updates viewer is expected to appear in project viewer form soon, but could rapidly move to RC status once available.
  • Another viewer due to appear is the build tools viewer (using the updated tool chain with VS 2017  / a more recent version of Xcode). This currently has a couple of significant crash issues that are to be resolved, but once available might also go through a short cycle to achieve release status.
  • Once the build tools viewer is out, there are plans to upload the viewer’s Chrome Embedded Framework (CEF) for media handling, that should result in improvements to handling more (and more recent) video codecs.

In Brief

  • [11:18-16:10] Names Changes
    • Currently causes a breakage in the viewer’s ability to handle chat logs and settings (e.g. if you have a log of “user XY” who changes their name to “user XZ”, the viewer cannot reconcile the two names and give you the complete chat history using both names). There is currently no viewer-side change being implemented to auto-update chat logs should someone change their user name. But if this becomes an issues, LL will consider doing so – although a contributed patch would be most welcome.
    • Despite the US $40 fee, name changes have proven popular, as has been noted by the Lab and by Firestorm (who have received a lot of support calls over it). Oz noted in particularly that the initial demand has gone higher than the more optimistic forecasts by LL.
    • Scripted support for finding and listing the past names of and avatar will not be supported.
    • It was suggested by user Anastasia Horngold that Premium members should be able to pay the fee to change the name of the alt accounts without having to upgrade said accounts to Premium as well – and it has been suggested that the idea be submitted as a feature request.
  • [18:23-20:03] Could the viewer have a separate rendering distance for shadows (e.g. so a user can have draw distance set to 200m, but can set the maximum distance for rendering shadows to (say) 20m), to reduce the processing load on their system?
    • Would need to be tested for potential performance boost, but could be worth considering. Again, a feature request has been requested.
    • An ancillary suggestion to this would be to tie shadow rendering to an object’s LOD settings so shadows are only rendered on the high and medium models.
    • It was also suggested a simple general cap on the distance from the camera at which shadows are rendered might also help with performance.
  • [30:50-33:05] Could terrain drawing be decoupled from object drawing, so aviators, etc., have a “long” terrain draw set so they can see the land ahead, but without the load of object data transmission / rendering? LL is not well-disposed to setting relatively “long” drawing ranges (e.g. 512m or greater), as this ends up putting extra update load on all the simulators on which an avatar could have a child agent.
  • [36:57-39:24 + beyond in text chat] Chat lag: the increase in user concurrency has resulted in some strain on the group chat services, particularly those handling very large groups – however, the issue is not a common across-the-board issue with all groups.
    • It is believed the issues of failing group chat message delivery is down to an issue with a single group chat server that has a couple of “spectacularly large” groups running on it, which at present cannot be relocated (efforts focused on cloud uplift). LL is investigating to see if something else can be done to alleviate the problem.
    • It is hoped that transitioning group chat services to the cloud will help improve general performance, but it is likely that specific issues such as group loads will require algorithmic changes to the code itself.