Category: SL Tech

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.

2020 Content Creation User Group week #16 summary

Posted on by Inara Pey
Otter Lake, February 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 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.

Resources

Current Status

  • 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.
  • Next meeting: Thursday, April 23rd.

Bright Canopy, the streaming service for SL, discontinued

Posted on by Inara Pey

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.

2020 Simulator User Group week #16 summary

Posted on by Inara Pey
Lake NumB, February 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.

  • 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
    • SL-11502 New LSL function 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

2020 viewer release summaries week #15

Posted on by Inara Pey
Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, April 12th

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:
    • No updates.
  • Project viewers:
    • No updates.

LL Viewer Resources

Third-party Viewers

V6-style

  • No updates.

V1-style

Mobile / Other Clients

Additional TPV Resources

Related Links

Speedlight: looking at the 3D world view

Posted on by Inara Pey
via Speedlight

At the end of March 2020, Speedlight, the browser / Android Second Life client, extended its world rendering capability to Free account holders whilst also offering Gold members the ability to move their avatars around.

Over the last few days, I’ve had the opportunity to take Speedlight’s world view for a test on both Free and Gold accounts, and this article is intended to act as both an introduction to the capability and to provide insight into where it stands at this stage of its development.

Before getting down to specifics, it should be remembered that it is still very early days in the development of Speedlight’s rendering capabilities – what is seen here is by no means anything close to what might be considered a “finished” product. Avatars, for example, are only presented as rudimentary “manniquins”, as the emphasis thus far has been on rendering in-world objects, and the Speedlight team plan to improve avatar looks in the future.

The Speedlight world view showing our living area at home. The rendering is acceptable, although there are some niggles that will doubtless be addressed in future updates (e.g. in this image, the “glass” doors rendered as soid grey objects, the ceiling rendering as black). Certainly, they are not enough to detract from what has been achieved at this early stage of work

Also at this point in time, the world view doesn’t offer any avatar / object interaction (no right-click options, etc.), and interaction (chatting, IMs) with other avatars is via switching tasks using the left menu. Other points worth keeping in mind with the world view are:

  • As I understand it, Speedlight uses an intermediary server for organising asset data information for download to the client, and this can have an impact of how fast a scene can be rendered. It also means that rendering can occur in “bursts” as object and texture data is collected (visible in the information bars at the top of the world view panel – see below), so it’s perhaps preferable to refrain from changing your camera view / moving your avatar until the scene has loaded.
  •  Key differences between Free and Gold accounts in terms of world rendering are:
    • Free accounts do not (as of the April 1st 4.093.0825 release) have the ability to move their avatar, but can orbit / zoom their camera.
    • Gold account can move their avatar via the Arrows keys when running in a browser, or via the on-screen “joystick” when using the dedicated Android app.
    • I understand from Speedlight support that the number of textures / objects a scene loads is “capped” for Free accounts at present, in order to prevent the intermediary server from being flooded with requests to handle asset information.
  • The world view requires a minimum of Android 7.0 to work on an Android device (either using the dedicated app or when running Speedlight through an Android flavour of a web browser). As I only have Android 6.0.1 at my disposal, this precluded me from trying Speedlight’s rendering on a mobile device.
  • In order to limit any excessive load, rendering is limited to a radius of apprximately 50-60m around your avatar / camera, with objects fading into haze – an effect that helps disguise what might otherwise be glaring “holes” in a scene.

Accessing the World View

  • Log-in to Second Life via your Speedlight account and Open your avatar account.
  • The Summary screen will be displayed.
  • Click / tap the 3D World View option in the left side menu.
  • If you have not run the 3D world view during the current session, a blank window is displayed with the message: Avatar Is Not Rendering 3D World.
  • Click / tap the button under the message to start the rendering process.
  • Rendering will commence, with a warning that it could take 2 mins. Given the variables involved (complexity of scene, information fetching / caching, network connectivity and speed, etc.) this is a not unreasonable estimate.
  • The information bars at the top of the world view (see image below) will report the land area, the number of textures and objects that are being processed / loaded.
The world view explained: 1: the X, Y, Z region coordinates of your avatar; 2: object and texture load count – will change as you cam / move / teleport. 3: horizon hazing at the limits of the pre-set draw distance; 4: avatar mannequin – displays a small green arrow (not always visible) to show direction being faced / avatar will move in (Gold only); 5: information bar – Gold membership shown; Free accounts have a yellow panel located on the left of the world view, carrying different information

Observations

Given this is still very much a first cut at scene rendering, what is presented is impressive, if with some niggles to be addressed, as noted above, and with things like dealing with blended alpha masks and with some transparent surfaces, etc.). However, these will hopefully be addressed over time.

Movement also seems to have a degree of latency surrounding it – possibly because of the use of an intermediary server on top of general network / connectivity aspects. This can be particularly noticeable when ceasing avatar movement, which can result in a degree of “rubber banding” as the avatar’s position as estimated by the client is updated with its position as recorded by the simulator. As such, I found it preferable to use light, repeated taps on the movement keys rather than holding them down for extended periods.

I also encountered a peculiar issue with my avatar simply refusing to stop walking, even after a teleport; something that I could only remedy by relogging. It’s something that may well be unique to me, although I’ve reported it to the Speedlight team just in case. Should anyone trying Gold membership with Speedlight encounter a similar problem also advise the Speedlight team?

Overall, and in terms of appearance, it is not unfair to say that Speedlight’s world view is pretty much on a par at this point in its development with that Lumiya’s world view during its earliest days of development – and look how far that went over time. Whether Speedlight will go on to mature to a similar level of capability with its rendering obviously remains to be seen. However, given that development is only a couple of months old (and niggles aside) what has been produced thus far is not to be sneezed at, and I look forward to continuing to cover the client’s development in the future.

Related Links