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.
Logos representative only and should not be seen as an endorsement / preference / recommendation
Updates for the week ending Sunday, April 19th
This summary is generally published every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:
It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
Note that for purposes of length, TPV test viewers, preview / beta viewers / nightly builds are generally not recorded in these summaries.
Official LL Viewers
Current Release version version 6.3.8.538264, dated March 12, promoted March 18th. Formerly the Premium RC viewer – No Change.
Release channel cohorts:
EEP RC viewer updated to version 6.4.0.540188 on April 15th.
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.
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.
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.
The following notes were taken from my audio recording and chat log of the Content Creation User Group (CCUG) meeting held on Thursday, April 16th 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.
Environment Enhancement Project
Project Summary
A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.
The (possibly last) RC version of the viewer – version 6.4.0.540188 was issued on Wednesday, April 15th.
If all goes well with this RC viewer, then EEP will likely be promoted at week #17 (commencing Monday, April 20th).
Once EEP has been promoted, the flow of RCs in the coming weeks also being promoted – allowing for the Lab preferring to keep to one promotion per every 2 weeks – should increase.
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).
As of January 2020 ARCTan has effectively been split:
Immediate viewer-side changes, primarily focused on revising the Avatar Rendering Cost (ARC) calculations and providing additional viewer UI so that people can better visibility and control to seeing complexity. This work can essentially be broken down as:
Collect data.
Update ARC function.
Design and provide tool within the viewer UI (i.e. not a pop-up) that presents ARC information in a usable manner and lets users make decisions about rendering / performance.
Work on providing in-world object rendering costs (LOD models, etc.) which might affect Land Impact will be handled as a later tranche of project work, after the avatar work.
The belief is that “good” avatar ARC values can likely be used as a computational base for these rendering calculations.
Current Status
Vir is looking at the avatar visibility controls – jelly dolls (which are not optimised for avatars with a lot of attachments) and imposters.
He’s been particularly looking at getting better performance from jelly dolls (e.g. avoiding any drawing of rigged attachments for jelly dolled avatars, reducing the memory required to handle them).
There are places in the code where jelly dolled avatars are handled inconsistently (e.g. setting an avatar to never render should see it treated the same as jelly doll, but this in not the case – it can actually be more expensive to render as shadows are still turned on for it, etc).
Improvements arising from this work could be issued within a maintenance RC viewer, rather than awaiting a specific ARCTan viewer to fix them.
Another thing Vir has looked at briefly with a view to possibly looking at in more detail in the future, is the time taken to compute a mesh preview when right-clicking an avatar, which can impact the time it takes for the corresponding menu to be displayed. How big an effort it might be to improve this is unclear, but it “would be nice” to see it improved.
More on Jelly Dolls
One of the things Vir has been experimenting with vis jelly dolls, is displaying them as monochrome system avatars, so the system avatar mesh is used, and so rigged mesh it is wearing is ignored (as per notes above). A disadvantage here is that non-human avatar forms that are jelly dolled then look “a little weird”.
This could be avoided by ignoring all scripted transforms contained in any mesh the avatar is wearing, as these most directly deform the avatar, and so ignoring them would prevent the monochrome system avatar “looking weird”.
The question was asked if having non-human avatars appear in a humanoid shape if jelly dolled would be a problem, with the opinion broadly being that would be up to the person using the jelly doll option.
Some alternatives to jelly dolling discussed at the meeting included:
Simply render jelly dolled avatars as elliptical capsules.
Follow Firestorm’s lead and provide an option to only render avatars on a user’s Friend list (all others are ignored and not rendered).
Offer improved lower LOD options for avatars that could be automatically swapped (or used when jelly dolled).
One of the issues with jelly dolls is whether or not the capability is widely used – people tend to complain more about seeing mono-coloured avatars in their view than worrying about having their performance hit by fully rendering all the avatars around them; it’s not clear if alternative options would change this.
In brief
Mesh Uploader project viewer:
Not available as yet, but getting close to a project viewer release.
Incorporates Beq Janus’ contributions, as see in Firestorm.
Also adds additional information about joint offsets and provides better logging.
I admit I’m getting to this somewhat late, although I don’t recall seeing it reported elsewhere among the blogs, etc., I try to read.
In January 2020, Bright Canopy, the one remaining streaming service for Second Life (and OpenSim) ceased operations. I’m actually a little embarrassed by not having noticed the change, given that I played a very small role in it getting started.
While possibly not a well-known service, Bright Canopy was officially launched at the end of August 2015, having come about (at relatively high speed) as a result of the folding of the SL Go streaming service. SL Go had, in turn, been the first functional SL streaming service, put together with LL’s help by former game streaming company OnLive. It established a small but loyal following before it came to an end after OnLive was forced to sell its IP to Sony as a result of not being able to generate the revenue through its various services (including SL Go) it needed to remain viable.
At the time of SL Go’s demise, I ruminated on the potential of the Lab running a streamed SL service through Amazon AppSstream (see: Could the Lab use Amazon AppStream to “replace” SL Go?), and that prompted Second Life user and app developer Bill Glover to comment:
Let’s just do it ourselves! You really got me thinking. I’d can launch a service right now if I get enough folks for Beta.
Bill and Jeri Glover: creators of the Bright Canopy service
Bill and his wife, Jeri, set about working on the idea whilst user Nebadon Izumi, also picking up on my ruminations, started his own tests using AppsStream,. I reported on his work a few days later (see: Using Amazon AppStream to stream a viewer – although sadly Nebadon’s video that originally accompanied that article was later removed from You Tube), and as a result of that article, Nikola Bozinovic, founder and CEO of Frame, a cloud-based service focused on delivering Windows applications to users, suggested his service could be used to deliver Second Life through the cloud.
Nikola Bozinovic, founder of Frame, worked with Bill and Jeri to make Bright Canopy happen, with Frame eventually acquiring Bright Canopy as a service in June 2016
Bill and Nikola quickly got their heads together, and within 24 hours, they had their own proof-of-concept running, delivering the official SL viewer over Frame via Amazon (as an aside, even while Bill and Nikola were in discussions, I tried Frame directly for myself).
As a streaming service, Bright Canopy did incur a cost for users – initially US $17.00 a month (necessary as operating costs from both AWS and Frame needed to be covered), but it continued where SL Go left off, offering both the official viewer and Firestorm to users for the same quality of graphics delivered to almost any computer / device as offered directly by the viewer. Over time the service expanded, adding Singularity to the list of viewers available, together with Blender and Gimp for those who might want CPU / GPU horsepower for their content creation work.
I actually lost track of Bright Canopy in the years post 2016, but it continued to be available, and several friends continued to use it as an away-from-home alternative to their viewer. My interest was stirred again in late 2018, when I caught the news the Frame itself had been acquired by Nutanix, as I was curious as to what it might mean for Bright Canopy. But as nothing appeared to change, I once again lost track of things.
However, as Jodi Serenity – who used the service on occasion – informed me, things did change at the start of 2020, with Nutanix discontinuing Bright Canopy and an offering. No reason (such as lack of subscribers) has been given, and Jodi informs me she has no recollection of any e-mail that may have been circulated ahead of the suspension of the service.
The ending of Bright Canopy means that currently, there is no longer a streaming service for Second Life. However, the landscape for accessing the platform without resorting to a full blown viewer has also changed in the years since SL Go and Bright Canopy first arose. Apps like Lumiya have shown what can be done in terms of client apps that can also render the world, and we currently have Speedlight the Android / browser client with its nascent world rendering capability, while LL themselves have hinted their own iOS / Android client may eventually progress to world rendering.
Bright Canopy running Second Life through Frame, offering those on low-specification computers to enjoy the full graphic richness of the platform with (allowing for network vagaries) low latency
Of course, none of these options render Second Life to a fidelity that can be achieved by a streaming service – but they have the advantage of being offered at a lower price. That said, the cost of streaming is also slowly changing, and even the Lab has been pondering whether they might want to offer a service at some point in the future – so it is very possible (if not probable) that Bright Canopy’s passing is not the last we’ll hear of a Second Life streaming service.
On Tuesday, April 14th, the majority of the grid was updated to server maintenance update 539684, previously deployed to an RC channel on April7th, and comprising:
BUG-228417 Emails created by llTargetedEmail() in deeded objects show owner as NULL_KEY in the received email metadata.
BUG-228412 Emails created by llTargetedEmail() are missing header info in the received email.
SL-12941 Disable TARGETED_EMAIL_ROOT_CREATOR in llTargetedEmail
BUG-226917 EEP Environment, New Sky should default to midday and not 6pm
BUG-226737 [EEP] The ‘get parcel_dayoffset’ request returns the value of the ‘parcel daylength’ parameter in the Region Debug Console.
On Wednesday, April 15th, two RC deployment should take place:
540032 – containing infrastructure updates related to the cloud migration.
540037 – containing 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.
SL Viewer
At the time of writing, there had been no updates to the current crop of official viewers to mark the start of the week, leaving the current official viewer pipelines as follows:
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 RC viewer, version 6.3.9.538760, March 25.
EEP RC viewer updated to version 6.4.0.538823, March 20.
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.
Group Chat
With the general increase in user concurrency, issues are being experienced with group chat (general slowness, sent messages failing, etc). Commenting on the situation, Simon Linden said:
Group chat traffic grows in “interesting” mathematical ways … a single person will have X number of groups, and thus joins them all and increases the number of people in the group. That multiplies out as groups get larger so a single message goes to more people … it’s not linear. Add in the updates on people coming on-line or logging off and it bogs down – and yes, we’ve done some work on it and want to get time for more.
A factor that’s likely contributing to the issue is that the plan to cut back on the number of group update messages created when users log-on / log-off of Second Life was actually curtailed, with Simon also noting:
[There was] some pretty strong push-back that managers need that info … so it got more complicated about who should get what messages when, and the project went back on the shelf. But you can imagine the math … if you have a group with about 10 people on-line, every once in a while someone joins or leaves, and about 10 updates have to be sent out. Put 1000 people in a group … people are coming and going all the time, and 1000 updates have to go out if everyone needs to know
And yes – there are some different ways it can be fixed. The real issue is people getting upset if they can’t do something any more, and finding that magic spot where it works right for those that need the feature, and not a load slowing down chat for everyone
Inara Pey: Living in a Modemworld 