Sansar Product Meeting 2017 week #50

Sansar: Winter Wonderland by Beverly Zauberflote

The following notes are taken from the Sansar Product Meetings held on Friday, December 15th. These meetings are usually held every Friday at 9:30am PST and 4:00pm PST, and are open to all. There is currently no set agenda, and the meetings are a mix of voice and text. The official meeting notes are published in the week following each pair of meetings, while venues change each week, and are listed in the Meet-up Announcements. and the Sansar Atlas events section.

Nyx Linden attended the morning session; a former member of the engineering team for Second Life, Nyx is perhaps best known for his appearances in-world as the Tiny Robot, and leading the “old” Content Creation User Group meetings which used to take place in-world on Mondays. Nowadays, Nyx is a member of the Sansar product team, working on the planning / road mapping side of the platform’s development and coordinating the various development teams.

Fashion Release

Again, please refer to my week #49 and week #48 updates for notes on known elements in the upcoming release.

  • The Fashion release should be deployed during the week commencing Monday, December 18th.
  • This initial release will not include cloth physics within the run-time mode (although they may be available in the Avatar App). Instead the baking service will continue to handle clothing as is currently the case.
  • The avatar mesh models will be provided via the Knowledge base when the release is deployed. These will most likely be supplied as .FBX files, rather than a blend file – but this is still TBC.
  • It will be possible to upload hair attachments, but the recommendation appears to be for creators to initially keep to shorter hair styles to avoid hair cutting into the avatar bodies at this point in time
  • On the non-Fashion side, the release will include a number of script updates including keyboard commands for scripts and updates to object APIs.

Modifying Materials on In-World Objects

There is still considerable upset over the decision to allow experience creators to modify / change the materials of in-scene items. This change is due to be deployed with the Fashion update, but does not extend to avatar clothing or attachments and any changes made to an object last only as long as the object is within a scene – they cannot be saved back to inventory when the object is removed.

  • Some creators see this as a reason not to upload their items until such time as the permissions / licensing system is deployed.
  • Some want to see a guarantee from the Lab that the change will not be extending to include accessories / clothing in a future release, ahead of the licensing / permissions system deployment. This is to be escalated to senior management for feedback.

Character Creation Flow

A point to note with the Fashion release is that users logging-in to Sansar the first time after the release has been deployed will have to go through the character creation flow.

  • This is because existing clothing will no longer work with the update.
  • It will mean that any custom work done to the avatar’s face will have to be re-done as well.
  • It should not break existing attachments.
Sansar: The Club by Marcus

In Brief

  • Sansar Store: Product Updates: Nyx indicated that there are still complexities around licensing / pricing which need to be resolved. As such, the Lab is considering possibly going with a basic system to allow for updates through the store, and then enhancing it as other elements of work fall into place.  However, there is no time line as yet on when something might appear, but it is on the road map.
  • Permissions / Licensing System: the Lab is actively working on a permissions / licensing system, however, there is still no time frame as to when it might start to be deployed.
  • Dynamic mirrors and using in-scene cameras to record and project the scenes onto a surface: neither are on the road map as present. Dynamic mirrors can be rendering-heavy, and are not something the Lab is currently looking at.

SL project updates 50/3: TPV Developer meeting

The Outer Garden; Inara Pey, November 2017, on FlickrThe Outer Gardenblog post

The following notes are taken from the TPV Developer meeting held on Friday, December 15th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it.

SL Viewers

[2:35] The Alex Ivy 64-bit RC viewer has one more bug the Lab would like to resolve, this one with the updater within the viewer. The hope is a fix for the issue will be in a further update to the viewer at the start of week #51, commencing Monday, December 18th. If so, the viewer might be promoted to de facto release status before the holiday break.

[6:46] Once the Alex Ivy viewer is promoted to release status, the Lab will move to block versions of their viewer older than the 5.0.6 viewer (the HTTP updates from June 2017).

[4:00] The Voice RC viewer updated to version on December 12th. This is doing “very well” and is currently being held from promotion due to the wish to promote the Alex Ivy viewer. As a result, the Lab might do a further RC update for it, with a new update from Vivox.

[5:19] A new Maintenance viewer, version, appeared on December 13th. It features a range of fixes, and is code-named Nalewka, in keeping with the Lab’s new habit of naming Maintenance viewers after alcoholic beverages. Nalewka is, according to Wikipedia, a rather interesting beverage mixing alcohol (vodka or neutral spirits) and fruits, herbs, spices, sugar / molasses and which has a liquer-like taste.

[5:43] The anticipated 360-snapshot viewer update has been held while it is integrated with Second Life Place Pages. This will allow 360 images to be uploaded to Place Pages and used in hero images, etc. It is anticipated that these updates will now appear early in the New Year and the viewer should move quickly to RC status thereafter.

[4:43] TPVs attempting to use the viewer updater have encountered issues, often resulting in them disabling it. Oz Linden acknowledges it isn’t easy for TPVs to update it, but has offered to work with them to fix issues once the Alex Ivy viewer (which uses a new version of the updater) reaches release status, coupled with a code refactoring to make updating it easier in the future.

Linux and the Viewer

[20:51-24:28] As per my previous TPV meeting notes, once the Alex Ivy 64-bit viewer (Windows and Mac) goes to release status, the Lab will look to TPV / open-source developers to help move the Linux viewer build to a Debian package without the additional libraries. this will allow TPVs to add the dependencies they require for their flavour of Linux build. If help is given and the project is successful, the Lab will then maintain the Linux build, with the caveat that it will only be subject to cursory QA, and will continue to look to the Linux community for fixes.

A repository for code submissions will be made available, together with a blog post / open-source community notification on the specifics, after the 64-bit viewer has been promoted to release status. Those wishing to support the work will need to sign a contribution agreement with the Lab.

Texture Decoding and Texture Memory Limits

[28:23-29:52] The Lab is making improvements to texture handling (e.g. using raw texture data rather than encoded). Some of this work is in the current rendering project viewer; there is another non-public viewer which uses a new structure for the rendering cache – although this hasn’t been overly successful in testing thus far. Oz is anticipating his team spending more time on rendering in early 2018.

Environment Enhancement Project (EEP)

A set of environmental enhancements, including the ability to define the environment (sky, sun, moon, clouds, water settings) at the parcel level; a new environment asset type that can be stored in inventory and traded through the Marketplace / exchanged with others; scripted, experience-based environment functions, an extended day cycle and extended environmental parameters. This work involves both a viewer updates (with a project viewer coming soon) and server-side updates.

[10:01-11:34] “Rider’s been on a power trip since starting this project!” Grumpity joked at the meeting, “Moving these celestial bodies around the sky!” – which Rider admitted was fun.

Progress continues, and it is anticipated that test regions on Aditi and a project viewer will be available “soon after” the new year, although these may not initially support using environment settings and inventory assets.


Server-side Reset Skeleton

[30:10-35:25] Bento introduced a reset skeleton option for details with avatar deformations. However, it is viewer-side only – therefore, if someone swaps between skeletons / avatars + attachments and is displayed deformed (e.g. BUG11310) or with attachments wrongly place (or a combination), they, and everyone viewing them has to individually perform a reset skeleton on their avatar to correct how they appear.

A preferred means of handling this might be for a local reset to be sent update the appearance system to ensure everyone gets updated (so if I’m deformed, I can use reset skeleton, and everyone around me gets the update as well, rather than having to also use the reset skeleton option). Oz has requested clear, concise feature request on the idea. Grumpity has indicated she’ll follow-up on the specifics of BUG-11310, which the Lab thought to be resolved through and internal JIRA.

Simulator Resources and Simulator Crashes / Performance Degradation

[43:53-50:20] Discussion on simulator resource use / loading balancing. This proceeds from the false assumption that a region / simulator can be crashed “just” by overloading it via a resource / physics hungry script. While there may still be exploits where this might be the case, the Lab long ago imposed absolute limits on script and physics time per frame. What more usually happens is that excessive script / physics loading on a region as whole as a whole can degrade performance as some script / physics executions are skipped within a frame (so scripted objects are slow in responding / may not respond as anticipated, for example); although it is acknowledged that specific items – intentionally or through bad scripting – can have an undue impact on performance.  Anyone encountering specific objects, which can individually adversely impact region / simulator resources / performance is asked to file a JIRA with details of the object in question, so that the Lab can obtain a copy and poke at it.

Other Items

  • [13:24] Estate access / ban lists: (Estate/Region floater) – work has stalled on this.
    • [14:21] A question was raised on the ability to teleport others home from, or out of, your own parcel, a capability that had been available in the older v1 (and v2?) viewers. Having an ability to remove people at parcel level is something the Lab will likely look at as they continue to work on the land tools.
    • [16:59] the updates to the estate tools will include a log of ban actions taken – who banned whom and when – which will be visible to all Estate Managers (not general group / land users).
  • [35:35-36:20] Semi-automatic viewer tests: Kitty Barnett (Catznip) have a number of semi-automated viewer tests (e.g. checking to see if all UI elements / floaters work in different languages). The Lab have found that as the viewer is updated / changed so often, such tests rarely maintain their value over a period of time. However, Oz is willing to learn more about at Kitty’s framework if it avoids such issues.
  • [36:39-37:53] Viewer support for local meshes: this has been a frequent request, particularly with content creators. It is also something the Lab and Firestorm have looked into. However, supporting multiple mesh formats, dealing with LOD compositing, etc., makes it complex and difficult to implement within the viewer. However, if the Lab can find a way for the viewer to do this, they would consider implementing it.
  • [50:43-55:07] Phishing/ URL link spoofing: a discussion on the use of URL link spoofing – which has affected Second Life and is a general issue on the web as a whole. Short version: always check URLs before clicking whatever you’re doing, and in terms of SL: always treat links receiving (e.g. via dialogue boxes, via unexpected / unknown IM, etc.) with caution, and while it does not eliminate risks, configure your viewer to use an external web browser to open external links. Obviously, and like any other company, the Lab cannot – and will not – every guarantee the safety of accessing URLs which are outside of its control.
While not foolproof, setting your viewer to use an external web browser or to only use the built-in browser for trusted links from LL, might provide some added protection against scam URLs you might obtain through in-world sources
  • Lab No Change window: runs from Thursday, December 19th 2017 through until Tuesday, January 2nd, 2018.
  • Next TPV Developer meeting: Friday, January 12th, 2018.
  • Firestorm release: the next Firestorm release now looks set to go to beta in the week commencing Monday, December 18th, with a release to be made early in the New Year.



Lab’s Christmas 2017 Shop and Hop event opens

Shop and Hop / Shop ‘Til You Drop – until January 1st, 2018

The Shop and Hop (or Shop ‘Til You Drop, if you prefer the region descriptions) event, organised by Linden Lab, and featuring 60 SL merchants and designers, has opened its doors to shoppers.

Following the success of the SL14B in-world shopping event, in November, the Lab posted an invitation for merchants to sign-up for a Christmas event which would be timed to run through the holiday season until January 1st, 2018. The invitation in part described the event thus: “We are looking for merchants willing to offer a discount on some of their items (think Black Friday and Cyber Monday deals!) and possibly provide a little non-exclusive gift to holiday shoppers.”

The result is 60 stores within the event’s mall-style environment offering a broad cross-section of goods: clothing, accessories, jewellery, homes and prefabs, furnishings, decor, landscaping, boats, novelty items – all of which makes the event something for everyone.

The mall is the same 3-region space used for the SL14B event, with the buildings redressed for a more seasonal look: ponds are frozen, stripped candies rise from flower planters, decorative wreaths and snowflakes are mounted on walls, together with wintry scenes photographed from around Second Life, while many of the participating merchants have also dressed their store spaces for the event.

In all, the participating merchants are: !APHORISM!, !Rebel Hope Designs, .{PSYCHO:Byts}., .TeaBunny., [ JUSTICE ], [ west end ], /*KC|Couture* /, *YS&YS*, #adored, ~Tableau Vivant~, ADRIATIC line, alaskametro<3, alme., amara beauty, Apple May, AZ Emporium, bella moda, Blueberry, by Crash, Cae, Canimal, Cheeky Pea, ChiC buildings – surrounds – prefabs – decor props and poses, CONSTRUCT, Contraption, Dictatorshop, Dynamic Evolutions, e l i a v a h ~, E.V.E, Envious,  etham, eXxEsS Hair, Fancy Decor, Grimes Central Design (GCD MESH),  Heart Trees Flowers Plants, hello dave, Hucci, ISON, Lapointe Bastchild, Lemon Chilliz, Lune Bleue, MadPea, Maven Homes, Maxi Gossamer, MOCO HOMES Emporium, Musa, Nani, Never Totally Dead … , New CHEZ MOI Furnitures, NOX. & Third Eye,  PATRON, Petit Chat, Potomac Signature Homes, ROC, Sweet Thing, The Forge & EZ, The Mesh Shop, Vanity Hair,, zed designz  and Zibska.

All of the regions are rated Moderate, and the SLurls to each are:

the SLurls to the regions are:

SL project updates 50/2: Content Creation User Group

Queen of Dragons? Surrounded by Animesh dragons by Wanders Nowhere and used by Lucia Nightfire as Animesh test models

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, December 14th, 2017 at 13:00 SLT. For the purposes of Animesh testing, the meetings have relocated to the Animesh4 region on Aditi, the beta grid – look for the seating area towards the middle of the region. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live streamed the meeting, and his video is embedded at the end of this article – thanks to Medhue, as always, for the recording. Time stamps in the body text will open the video in a separate tab for ease of reference to the relevant parts of the text. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

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 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. The project is in two phases:

  • The current work to update the baking service to support 1024×1024 textures.
  • An intended follow-on project to actually support baking textures onto mesh surfaces. This has yet to fully defined in terms of implementation and when it might be slotted into SL development time frames.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Current Progress

[1:54-3:40] Testing of the updated baking servers to handle 1024×1024 is now complete. Originally, it had been thought that the Bakes on Mesh would require changes to objects themselves when using 1024×1024 textures, which would have required simulator updates as well.

The approach now being taken is the let the viewer recognise when 1024×1024 textures are being handled via the texture UUID, which should hopefully eliminate any simulator side updates as well in order to get the service running. However, this does raise the question of how to make the system avatar transparent / invisible without continuing to rely on an alpha mask – right now the Lab is looking at a number of possible approaches.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

  • Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
  • Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
  • Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
  • Can use many existing animations.
  • Will not support its own attachments in the initial release.

Note that the focus of this project is not currently about providing fully functional NPCs at this point in time, which is seen as a follow-on project.


Appearance Service Update

[4:28-6:18] The appearance services has to perform a number of calculations based on the mesh attachments an avatar is wearing. For example, these calculations are run to try to ensure an avatar appears to stay reasonably on the ground  when wearing a rigged mesh which might otherwise alter the avatar’s centre position above the ground.

These calculations don’t work particularly well for Animesh attachments, as they have their own skeleton, so the appearance service has been updated so it can differentiate between Animesh and non-Animesh attachments for the purposes of calculating and avatar’s height. The update is being tested on Aditi, and also includes a fix for rigged mesh attachments being incorrectly handled.

Viewer Status

[6:21-8:01] The Animesh project viewer updated to version on Monday December 11th. This updates includes the following changes:

  • Animesh objects should now display correctly as impostors, using the same rules that avatars do currently.
  • Animesh objects now display animation information for objects you have permission to view.
  • Fix for a crash triggered by unchecking the animated mesh check box for an Animesh attachment.
  • Fix for Animesh attachment getting removed after teleport.
  • Fix for some of the cases where animesh graphics state could get corrupted.
  • Various clean-ups and optimisations.

[6:32-7:30] There is also a forthcoming fix to the mesh uploader – not in the viewer version above – and mesh attachments with spaces in their names (actually a Collada file issue). In short, the Lab is implementing a similar kind of fix to that used by Firestorm to allows objects with underscores in their names, rather than spaces.

Testing Limits: Tri Count Increased to 50K

[8:07-9:03] There has been a lot of feedback that the 20K tri count limit imposed for testing Animesh is insufficient for some creators. In fairness, some of the complaints appear to be more to do with testing completed Animesh products rather than testing the Animesh capabilities to ensure they work as expected; however, the Lab has relented and increased the testing limit on tri counts to 50K. Again, this isn’t the final limit – it is purely for testing. Final limits – hard or soft, tri, number of attachment, LI, etc., – won’t be addressed until actual load testing and scaling takes place as one of the final steps in the project.

Avatar Animesh Attachments

[12:27-19:40] (with lengthy silences)] Other limits, such as the number of Animesh attachments an avatar can wear (set to one for testing) remain unchanged at this point.

Attahments are seen as an interesting use-case with suggestions that as well as pets, it could be used for further animating hair (as rigged mesh hair can already be somewhat animated with head movements, etc). The latter is something that it was suggested Bento might further achieve (bones allowing). Using Animesh would provide more bones for animating hair, but ensuring animations remain in sync with body movements might be difficult.  It could allow hair to be a “pet” (a Medusa-like heads for of snakes).

Attachments for Animesh Objects

[24:45-32:18] Animesh will not support attachment swapping in the initial release – attachments will need to be defined as part of the overall Animesh. Adding / removing attachments is seen as part of the follow-on project.

This section includes discussion of a specific prim-based issue with Animesh encountered by one creator, and a discussion on non-rigged elements of Animesh objects not correctly moving with the rest of an Animesh object (e.g. unrigged eyes failing to properly move with the rest of an Animesh creature’s head).

Bugs Focus

[19:56-23:00] Vir’s current focus for the project is bug fixing. These include:

  • Some Animesh objects seeming to disappear when in their static (non-animated) state.
  • Left-click interactions with Animesh: it’s possible to right-click and Touch an Animesh object via the menu, but left-click interaction currently isn’t possible. Left-clicking on multiple Animesh objects to select them also isn’t possible at present.
  • Animesh LOD selection: currently the selection of the LOD for displaying an Animesh is the same as used for avatars; Vir’s feeling is that Animesh should use the same selection process as for in-world mesh objects.
  • Animesh objects do not always update correctly when camming onto them.

There are also a couple of feature requests that are still being considered around LSL capabilities.

In Brief

  • [34:23-35:22] Avatar skeleton as its own asset type? This has previously been discussed in the Bento project, and while an interesting idea, is seen as being a large amount of work and crosses into the realm of arbitrary skeletons, which could complicate the user experience (e.g. items working with one type of skeleton, but not another).  As such, it remains something the Lab isn’t currently considering, although it may be something they will look at in the future.
  • [39:49-52:06] Discussion on rez-on-entry resource caps, issues of Animesh animations starting / stopping correctly, and how updates are handled – how people see an Animesh that is already in a region being animated can depend on the frequency of the animation updates. The potential need for a shape to effectively place bones / attachments.
  • [54:35-end] Discussion on feature request BUG-139203 tri counts / land impact / LODs and issues / exploits.