Category: SL User Group Meetings

2018 SL UG updates 47/1: Simulator User Group and News

Posted on by Inara Pey
Winter Wonderland

Server Deployment Plans

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

  • On Tuesday, November 20th, the SLS (Main) channel was updated with server release 18#18.11.09.521593, previously deployed to the RC channels and comprising internal fixes.
  • There are no planned deployments to the RC channels.

Due to the Fact the Lab is closed from Thursday onwards, it is unlikely there will be any deployments in week #48 (commencing Monday, November 26th).

SL Viewer

The Love Me Render RC viewer updated to version 6.0.1.521759 on November 20th, bringing it to parity with the Animesh release viewer.

Currently, the rest of the viewers in the official pipeline remain unchanged. Given this is US Thanksgiving week, the remaining viewers due an update for parity with the current release viewer may not be issued until week #48.

  • Current Release version 6.0.0.520636, dated October 18, promoted November 14. Formerly the Animesh RC viewer – NEW.
  • Release channel cohorts:
    • Spotykach Maintenance RC viewer, version 6.0.1.521757, November 15.
    • Estate Access Management (EAM) RC viewer, version 5.2.0.520057, September 28.
    • BugSplat RC viewer, version 5.1.9.519462, September 10. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – 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.

EEP

The next EEP function to see light of day should be llReplaceAgentEnvironment, that should allow an experience to override any environment setting currently being used by an avatar within that experience.

General News

Thanksgiving – Support Closed

Concierge Phone Support, Billing Phone Support, and Live Chat Support will be closed on Thursday and Friday, November 22nd & 23rd in observance of the US Thanksgiving holiday. Ticket submission will remain available, and support services will resume Saturday, November 24th, at 06:00 PST / SLT.

Winter Wonderland and 5 Weeks of Gifts

Winter Wonderland, the five-region activities area designed by Linden Lab and the LDPW, has reopened for the holiday season,, and the Lab is using it as the first swap on a gift hunt, which itself features the return of the Swaginator.  Find out more via Grab Your Winter Swaginator & Collect Exclusive New Gifts!

 

2018 SL UG updates 46/2: TPV Developer meeting

Posted on by Inara Pey
The EEP sky over the Linden Hippotropolis region, designed by Whirly Fizzle. Credit: Whirly Fizzle

The following notes are taken from the TPV Developer meeting held on Friday, November 16th, 2018. A video of the meeting is embedded below, my thanks as always to North for recording and providing it.

This was again a short meeting.

SL Viewer

Video: 1:10-3:37.

  • The Spotykach Maintenance RC viewer updated to version 6.0.1.521757 on November 15th.
  • The Environmental Enhancement Project (EEP) viewer updated to version 6.0.0.521803 on November 16th.

These updates bring both viewers up to parity with the newly promoted Animesh release viewer. The remainder of the viewer pipeline remains as:

  • Current Release version 6.0.0.520636, dated October 18th, promoted November 14th. Formerly the Animesh RC viewer – NEW.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
    • Love Me Render RC viewer, version 5.1.10.521635, November 13th.
    • Estate Access Management (EAM) RC viewer, version 5.2.0.520057, September 28th.
    • BugSplat RC viewer, version 5.1.9.519462, September 10th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
  • Project viewers:
  • 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.

Bakes On Mesh

The back-end support is now grid-wide, meaning that Bakes on Mesh can be tested by anyone using the project viewer, which itself will be updated, both to bring it into parity with the new release viewer and with further BoM fixes.

BugSplat Update

[11:55-14:40] There are Four things to note with Bugsplat:

  • As noted above, it will see the Lab switch to using the BugSplat system for crash reporting, rather than their  own Breakpad based crash reporting tools.
  • The Breakpad support code will remain in place with a build time option, so that TPVs wishing to continue to use it can do so.
  • The current parent process that handles viewer launch and also updates, will be removed. This means there will be some internal differences to how the viewer updater works, and one of the two executables for the viewer will vanish.
    • On windows, if the viewer is installed using an account that does not have admin privileges, the viewer installer will install as a local instance in the user’s local applications folder.
  • It will also resolve the viewer having 2 dock icons on MacOS.

In Brief

Group Notifications

[3:34-4:40] A resource has been assigned to look into the unreliable delivery of group notices. It appears the reason some notices are being received when people log-in to Second Life is because they are not actually being recorded in the database that manages the delivery of things like off-line notices. Investigations are therefore focused on backtracking through the various systems to work out where things are breaking down.

EEP On Legacy Viewers

[5:04-6:24] It’s been noted that when seen of non-EEP viewers, applied EEP skies appear odd – stars persistently overlay the sky and fail to render correctly, for example.

This is because the simulator end of EEP tries to take the environment and tries to approximate it for delivery to non-EEP viewers using the “old” environment settings system for delivery to those viewers – something that works at best imperfectly. The Lab has not determined how much effort will be put into making EEP fully backwards compatible with the older environment rendering system, as the issues should only exist through a transitional period as the viewer-side EEP code reaches all maintained viewers.

The same sky seen at the top of this article, but through a non-EEP viewer, demonstrating how an EEP environment is translated for rendering on a non-EEP viewer

Duplicate Calling Cards

[21:35-24:00] This was an issue some time ago that saw people’s calling cards duplicated – sometimes multiple times. The core issue was largely corrected, so people with duplicates could generally delete them and not see further duplications. However, duplicates could sometimes still be created as a result of inventory issues a logging-in, and sometimes clearing duplicates requires a request to support to run and inventory transform.

Thanksgiving USA

Week #47 (commencing Monday, November 19th, 2018) is Thanksgiving week in the United States. This means there will be limited updates and releases during the week, and the Lab will be closed on Thursday and Friday, except for essential support.

2018 SL UG updates 46/2: content Creation Summary

Posted on by Inara Pey
Animesh is live!

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, November 15th, 2018 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Animesh

Animesh is now officially released. Blog posts:

This means that the Animesh code will now be merged with all current RC and project viewers in the coming days /  weeks. Firestorm support for Animesh will be coming soon, as is the other case for TPVs that have not already started making releases with Animesh support.

Resources

To help people get started with Animesh, there is already a range of available resources, including:

Discussion

  • Concern has been raised about the 2 Animesh attachment option for Premium members impacting performance at major events given the lack of “public” testing of the ability (which had always stated as being one Animesh attachment per avatar across the board).
    • Interestingly, when the one Animesh attachment per avatar was first set, it was seen as too limiting, with some wanting as many as five per avatar.
  • The tri count cap remains unchanged at 100K per Animesh.

Environmental Enhancement Project (EEP)

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, 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 which include the ability to use custom Sun, Moon and cloud textures. These can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

The project also includes a new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow).

Resources

Current Status

  • There are a couple of blockers that have come up on the next viewer update, and which are currently being worked on, and should hopefully be cleared by the end of the week.
  • The first scripted functionality for EEP is now available: llGetEnvironment. This:
    • Returns a list containing the current environment values for the parcel and region as a list of attributes.
    • Takes a list of attributes to retrieve in parameters and returns them in the order requested.
  • llGetTimeOfDay has also been revised in line with EEP.
  • Graham Linden is continuing to work on the rendering side, including crepuscular rays. He is however, also engaged in other work related to viewer rendering (such as project ARCTan).
    • As a part of Graham’s work, there is a further update to the EEP sky settings that will allow the atmospheric settings to be altered

Bakes On Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • The required Bake Service update (which in part allows the support of 1024×1024 textures) was deployed in week #46.
  • Anchor Linden is now working on updates to the viewer, which is considered to be the only blocker to Bakes on Mesh going live.
  • Additional channels have been added to the Bake Service already which include the left arm and left leg. A request following this update was to allow upper and lower body skin textures to these channels – this will not be a part of the initial Bakes on Mesh release.
  • It has yet to be tested, but as Animesh objects do not have the necessary shape support for the Bake Service to use, it is thought BoM will not work (or at least not work as anticipated) with Animesh attachments on an avatar.

Normal and Specular Maps Support Experiment

As noted in the project summary above, Bakes on Mesh will not by default support normal and specular maps when released.

However, in week #45, Cathy Foil suggested it might be possible to allow Bakes on Mesh to indirectly support normal and specular maps using a combination of three additional bake channels within the Bake Service and a scripted “applier” option, similar to current skin and clothing applier mechanisms.

Since that time, she’s been carrying out tests using the existing three Aux Bake Service channels, added to the system as a part of Bakes on Mesh. While the approach appears to work with normal maps, there are a number of questions relating to alpha blending, deriving specularity (normal maps use the alpha channels for specular power in the SL materials setup), etc. These would require more in-depth testing through a suitable viewer, and as such, this isn’t seen as a viable approach at this point in time.

New Projects

No decisions have been made as to what user-visible projects will come next.

  • There is an infrastructure related project for inventory, but this shouldn’t have user-visible impact.
  • Project ARCTan (avatar and object complexity calculation improvements) has been on hold, awaiting resources, which are now becoming available.
  • There are a mix of options in the pot for Animesh and BoM follow-ups, but any follow-on work hasn’t been officially defined.
  • There are a number of other potential projects the Lab isn’t ready to announce as moving forward just yet.

Next Meeting

The next CCUG meeting will be on Thursday, November 29th, 2018.

Animesh officially released for Second Life

Posted on by Inara Pey
Anmesh Halloween boogie, October 2017, Courtesy of Alexa Linden

On Wednesday, November 14th, Linden Lab announced the official release of Animesh, with the promotion of the Animesh viewer as the de facto release viewer.

Animesh has been in development for about a year, and like Bento, has been a collaborative effort between Linden Lab and Second Life content creators.  Essentially, it allows the avatar skeleton to be applied to any suitable rigged mesh object, and then used to animate the object, much as we see today with mesh avatars. This opens up a whole range of opportunities for content creators and animators to provide things like independently moveable pets / creatures, and animated scenery features.

Alpha flipping: use of multiple mesh models to achieve a sense of movement by rapidly cycling through them via script, revealing and then hiding each one in sequence – in this can giving the illusion the squirrel climbs and swings from the bird feeder

One of the potential advantages with Animesh is that it might help eliminate the need to “alpha flipping” across multiple versions of a mesh creature in order to simulate its movement.

To explain: if you right-click and edit animated mesh creatures in SL, you’ll see that they can appear to have multiple parts, most of which are invisible. When they are active, a script renders then sequentially, causing each of the models to be rendered in turn before hiding it again using an alpha mask.

Like a set of flip book drawings, this gives the illusion of movement: be it a sheep or horse or cow raising and lowering its head to appear as if it is grazing, or a rabbit hopping back and forth over the ground, or simply mimic the movement of legs as an animal wanders along a pre-determined path. As long as the script is cycling the motion is repeated.

The problem with alpha-flipping is that is can be render intensive, impacting viewer performance, so the hope is  – and as well as bringing other benefits – Animesh will, over time, hopefully encourage creators to switch away from alpha flipping methods of animation.

Animesh also includes the ability to attach a single object to an avatar (or two, if you are Premium) which can then behave independently of the avatar. Quite how this will be used remains to be seen – but again, one obvious option is more render-efficient pets, or perhaps an animated item of clothing that simulates being blown by the breeze, and so on. Another potential is with things like avatar tails – while Bento also allows for items like these, the use of an Animesh with its own skeleton could avoid potential conflicts when trying to use two Bento items that use the same set of bones in the avatar, and so conflict with one another.

There are some initial limitations with this release of Animesh. As a couple of quick examples: when it comes to pets, for example, because rigged mesh is used, it’s not possible to simply put a pet on the ground after carrying by using Drop so it can run around – you have to go via Detach and inventory. Also, there is no avatar shape associated with Animesh at present, which may limit its adoption for use with NPCs, as there is no real ability to custom body shape and size (the addition of a body shape to Animesh, and the ability to modify it via the sliders is being considered for a future Animesh project).

Animesh Resources

To help people get started with Animesh, there is already a range of available resources, including:

Rigged mesh can be set to be used as Animesh through the Build / Editor floater

In particular, the user guide and test content offer the best way of getting started with Animesh for those who haven’t tried it thus far.

Again, Animesh isn’t just for content creators: it has been designed such that just about any Rigged mesh can be converted to Animesh directly from the Build / Edit floater. Do be aware, however that simply converting an object will not cause it to start animating – you’ll obviously need suitable animations and a script to run them.

Like any other object utilising animation, this is done by adding the animations and scripts via the Edit > Contents tab for your converted object. If you’re not a scripter / animator, you can still use the Animesh test content and have a play around with things.

Quite where Animesh will go will be known in time – even at the Content Creation User Group meetings some fairly imaginative use-cases were being pondered by some (using Animesh in vehicles for animating wheels, for example). To try to help users find Animesh content, the Lab note they’ve created a new Marketplace category – Animated Objects – but going on a brief parse through what’s there already, this may need some form of curation if it is to be for Animesh – several of the items I notes didn’t appear to be Animesh – so be sure to read descriptions carefully and perhaps check in-world as good start to appear.

As with all things, Animesh can be subject to bug and issues, and Whirly Fizzle has created a JIRA filter for Animesh for easy tracking of known issues. If you do hit upon a bug or issue, do be sure to raise a Jira report and label it for [Animesh].

A razzle of raptors? Animesh used to animate rigged mesh raptors from Linden Lab

Additional Links

 

2018 SL UG updates 46/1: Simulator User Group

Posted on by Inara Pey

Malaika Park; Inara Pey, October 2018, on FlickrMalaika Park – blog post

Server Deployment Plans

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

  • On Tuesday, November 13th, the SLS (Main) channel was updated with server release 18#18.11.01.521329, previously deployed to the Magnum RC, and comprising a fix for Animesh land impact calculations – see below – and also internal logging fixes.
  • On Wednesday, November 14th, 2018, the three main RC channels should be updated with the same server update, 18#18.11.09.521593, comprising internal fixes.
  • There is no planned simulator update for EEP.

Land Impact Calculation Revision

The Land Impact update deployed to the SLS channel this week (and to the RC channels in week #45) is to correct an error in the Animesh code. In short, if an Animesh object has a conventional prim as its root, the required 15 LI for the Animesh skeleton is not applied.

This 15 LI is an aggregate value for Animesh arrived at during testing Animesh performance across a range of systems. It has also been subject to some alarmist blog posts about unexpected prim returns, but given Animesh products are not generally available as yet, this is unlikely.

SL Server

On Tuesday, November 13th:

All other viewers remain as per the end of week #45:

  • Current Release version 5.1.9.519298, dated September 5, promoted September 26. Formerly the Rakomelo Maintenance RC viewer – No change.
  • Release channel cohorts:
    • Animesh RC viewer, version 6.0.0.520636, dated October 18th.
    • Estate Access Management (EAM) RC viewer, version 5.2.0.520057, dated September 28th.
    • BugSplat RC viewer, version 5.1.9.519462, dated September 10th. This viewer is functionally identical to the current release viewer, but uses BugSplat for crash reporting, rather than the Lab’s own Breakpad based crash reporting tools.
  • Project viewers:
    • Environmental Enhancement Project (EEP) viewer, version 5.1.10.521312,  dated November 2nd.
    • Bakes on Mesh project viewer, version 5.1.10.520711, dated October 29th.
    • 360 snapshot viewer, version 5.1.6.515934, dated June 6th.
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 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.

Recalling Viewer 2.0

There is one thing I’d like to mention, and that today is the anniversary of a very special moment in Second Life history. November 13th is V2 Day. Nine years ago we released version 2 of the viewer, which many people mark as the beginning of the end of Second Life.

– Simon Linden, Simulator User Group

While I’d possibly dispute the date – I have blog posts from March 2010 marking the release of Viewer 2.0 as the “default” viewer available from the Lab, prior to that it was a Beta viewer (remember those?) – so perhaps “first issued” might have been a better term, it is nevertheless true that viewer 2.0 was subject to a lot of sturm und drang; I wasn’t a great fan when it arrived, although as it developed and improved, I did become something of a convert over time, and I also agree with Simon’s summation of the early work:

I know the intentions of V2 were good … the old SL viewer UI was a crazy mess of things patched on by engineers with no overall design. But personally I think they made the mistake of trying to meet a schedule date and not waiting until it was right.

And again, as Simon notes, at the end of the day and despite all the pronouncements of Viewer 2.0 heralding the end of SL, here we are, nine years later, still SL-ing!

Fake Firestorm Website

There are in-world IMs / notices, doing the rounds pointing to a fake Firestorm website. for details, please refer to my blog post here.

 

2018 SL UG updates 45/2: CCUG summary

Posted on by Inara Pey

Frog Hollow; Inara Pey, September 2018, on FlickrFrog Hollow – blog post

The majority of following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, November 8th, 2018 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

SL Viewer Updates

The Spotykach RC viewer updates to version 5.1.10.521459 on Thursday, November 8th, 2018. Otherwise, all other viewer remain as per part #1 of these weekly updates.

Environmental Enhancement Project (EEP)

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. Uses a new set of inventory assets (Sky, Water, Day) that can be stored in inventory and traded through the Marketplace / exchanged with others, and which can additionally be used in experiences. A new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow). The ability to change the Sun and Moon and cloud textures with custom textures.

Resources

Current Status

The new simulator update deployed to the Snack channel on Wednesday, November 7th, 2018. This allows environment information to be pulled from the parcel or region, and further scripting work is due in time. There will also be further updates to the viewer in due course.

There has been a request to allow parcel owners set the transition time for EEP settings when moving between parcels, rather than just using the fixed (roughly 10-second) transition time. This is something Rider is reluctant to consider for the first pass of the EEP work, as it is a complex matter to tackle, and constitutes the kind of scope creep he’d rather avoid in trying to get the first pass of EEP out of the door. However, it is among the items to be considered as a part of any EEP follow-up project.  This said, it will be possible to set the transition time on EEP settings directly applied to avatars (once the scripted EEP support is available).

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Resources

Current Status

The Land Impact fix for Animesh is now deployed to the RC channels – this ensures that Animesh objects with a regular prim root (rather than a mesh root) should have their default 15 LI including in land impact calculations. If all goes according to plan, this fix will hopefully be deployed to the main (SLS) channel in week #46.

There are no specific updates in the works for the viewer at present, so the simulator update might see Animesh go to release status in the immediate future.

The meeting covered a lot of ground covered in the previous meeting – performance / bound box fixes; avatar shapes for a follow-up project, etc., so please refer to my notes from that meeting for details.

Bakes On Mesh

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies as well as system avatars. This involves viewer and server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables.

Resources

Current Status

Work is continuing with fixing the Bake Service / appearance service. Some of this work is currently with the Lab’s QA team. Anchor is also working on some viewer-side issues as well.

Normal and Specular Maps Support?

By default, Bakes on Mesh will not support normal and specular maps. This is because the Bake Service managing the avatar appearance does not recognise normal or specular maps, and updating it to do so is seen as a major task in terms of software and hardware.

However, in examining the issue, Cathy Foil has put forward a way to allow Bakes on Mesh to indirectly support normal and specular maps using a combination of three additional bake channels within the Bake Service and a scripted “applier” option, similar to current skin and clothing applier mechanisms.

Would this conflict with mesh body parts that already have a specular or normal map already assigned? While she’s not tested the idea in practice, Cathy believes not, as the additional Bake Service channels are not actually applied to the avatar,  they are simply a means to communicate what should be applied.

However, Graham Linden believes that even this approach would still require alterations to correctly composite the normal and specular maps. It would also likely need some kind of alpha masking capability to ensure odd outcomes are avoided (such as a normal or specular map for, say an underwear layer bleeding through to a skirt layer of clothing).  Cathy has indicated she’ll try doing some testing ahead of the next CCUG.

If nothing else, the provision of further Bake channels that might be seen as for “general purpose” use could lead to creators using them in a variety of ways, leading to further consumer confusion simply because there is no standard approach to how each auxiliary Bake channel is to be used.