Sansar update: R34 and avatar 2.0

Creator Academy: Hall of Materials

The following notes combine the June 26th R34 release and aspects of the June 27th (week #26) Product Meeting. I’m a little late in getting to both, in part because of work related to SL16B, and in part because I had been waiting to see if a video from the June 27th Product Meeting will be officially posted.

R34: A Richer World Release

The new inventory filters for clothing

The R34 release, issued on June 26th, 2019. As with the majority of Sansar deployments, this update requires the automatic download and installation of a client update. Compared to other release releases, this was somewhat smaller in scope, offering the following:

New features

  • Gifts are now adjustable in increments of 100, amounts can be entered directly. Gifts are capped at a maximum of 9999 Sansar Dollars each.
  • New filters in the avatar editor that enables users to show male, female or all clothing in the inventory. This allows users to wear male clothing on female avatars and vice versa.

Improvements 

  • Chat improvements – less lag when joining an experience with a long backscroll.
  • More stable voice server connections – less disconnects and more reliable reconnects to the voice server.
  • Avatar broadcasting performance improvements – Better broadcasting behaviour for streaming performers and dealing with broadcast instance crashes.

In addition, the release included script updates and stability improvements – these are documented in the official release notes for R34.

Two additional updates to the release have since been issued:

  • The first, issued on June 28th, comprises bug fixes and a new script example, HintText.cs, available in the Scene Script Library. Details are again in the release notes.
  • The second (labelled “updates 2 and 3”), issued on July 3rd, included additional new features:
    • New support for the Valve Index controllers (although note that Sansar does not support the Valve Index headset).
    • A new Memo feature on the My Experience panel allows creators to write and view notes for each of the experiences they own.
    • The People panel has been updated so that the block/unblock and muting features can be more easily accessed. Some inactive buttons have also been removed.
    • The Chat panel has been updated to allow gifts to be send via it, and other users to be blocked/unblocked.
    • New script API for per user gravity factor, which allows scripts to define the gravity factor for individual users.
    • See the update release notes for full details, including fixed issues.
The new chat options for gifting and blocking / unblocking

Avatar 2.0

As I’ve previously reported, the new Sansar Avatar 2.0 is planned for release in September 2019 (see Sansar Product Meetings week #24: more on Avatar 2.0). During the June 27th Product Meeting, the Sansar team unveiled a video showing a “first look” of manipulating the new avatar face using the bone deformation capabilities with the upcoming new avatar system.

The video was (briefly) posted to You Tube, but then taken down while the Lab “decided what to do with it”. I contacted the Sansar Community Manager, Galileo, to ask if a capture from the meeting could be posted, and received a “should be OK” reply.

The video demonstrates the ability to manually adjust the features on the avatar through a touch interface that allows fine tuning of adjustments. For those used to having sliders to adjust features, as with Second Life, the approach taken with Sansar may appear a little odd. However, the full system, when ready for release will also include some sliders to allow for blend morphing.

The overall feedback from those watching the video appeared positive, with Lab staff noting that the approach should allow a highly diverse range of avatars to be created once Avatar 2.0 is released, and the skin texturing / layering system (still being worked on as well, and not shown in the video) should add to this, allows different skin tones, make-up finishes, freckles, wrinkles, tattoos, etc.

Avatar 2.0 Points of Discussion Raised at the Meeting

Please also refer to the week #24 meeting notes, as they bullet-point much of the Avatar 2.0 discussion that formed part of this meeting.

  • Avatar 2.0 will have around 30% less bones that the current avatar, which should simplify skinning to it. The face should have around 50% fewer bones (140 to 70).
  • A more neutral avatar mesh to better support deformation.
  • The skin texturing / layering system may not be part of the initial release, but will follow-on.
  • Bone deformation will only be for the face in the first release of Avatar 2.0, but will be extended in subsequent releases.
  • Avatar expressions available with the current avatar will still work with Avatar 2.0.
  • Mouth movement should also continue to work a seen today, and there is a be a refresh of the mouth / voice animations.
  • There will also be a refresh of the avatar IK system with Avatar 2.0.
  • The system includes a face preset feature that allows users to adjust their avatar’s face using the bone deformation feature and the blend morph sliders and then save the results, allowing them to be used with different avatar bodies.
    • While not in the first release, Avatar 2.0 will include the option for people to create and sell faces on the Sansar Store.
  • It is still planned to release the Avatar 2.0 reference files in August 2019, to allow creators to gain familiarity with the new skeleton ahead of support being deployed to Sansar, and to start updating those items they make / sell that require adjustment / re-rigging to work with Avatar 2.0.
    • As a part of this, the Lab will be running a Creator Programme,  to help creators to develop assets (avatar, rigged items for avatars, etc., and pass them for testing and feedback by the Lab.
    • Details on how to be a part of this programme will be issue by the Lab via e-mail in the near future.
  • Avatar 2.0 may support asymmetric faces. The ability is there, but the Lab hasn’t decided if / when the button to enable it will be toggled. This will in part be governed by feedback from users after Avatar 2.0 has been deployed.

In Brief

  • The Lab is working to extend blend shape support to custom avatars, and the importing of pre-morphed skeletons that can be used with the sliders.
  • The ability to give other avatars items will probably also be released around the time of Avatar 2.0 appearing, and will use the quest system to enable it.
  • Item update mechanism for the Sansar Store  – this is still being working on, and will most likely follow “a couple of releases” after Avatar 2.0.
  • Push-to-talk on the microphone has oft been requested, but not currently on the roadmap.

Sansar Product Meetings week #25: sustainability + feedback

Animal Sanctuary (WIP)

The following notes were taken from the Sansar Product Meeting held on Thursday, June 20th, with the opportunity for creators and users to offer feedback on Sansar (official video here). Note that not all items raised in the meeting are recorded here; I have restricted this summary to questions that drew detailed responses / issues that multiple creators are seeing as pain-points / questions or requests that have come up in other meetings but may not have previously been reflected in my Sansar summaries.

Sansar Sustainability

It’s now almost two years since Sansar opened its doors to the public, and general user concurrency is still only in or around the mid-20s level. This has raised questions of Sansar’s sustainability, and whether the Lab have set any goals for the platform that need to be achieved in order for it to be continued, etc.

Landon McDowell, the Lab’s Chief Product Officer, and the person most directly in charge of Sansar’s development, responded thus to one of these questions (audio also included):

I am not going to put any date on the board. I think we’re taking this day-by-day, week-by-week, month-by-month, release-by-release, and we want to see what is happening and what is resonating and what isn’t … I believe steadfastly in the future of virtual worlds, that what we’re doing here is really important … Are we happy with the result? I’m not happy with the result; I would want a million people in here today, and we’re obviously not there.

But in terms of sustainability, I think we know what our limits are, and we are proceeding accordingly. If we have 50 people in here in a year then yeah, I’m going to be really massively disappointed. I think everybody here is working hard to make this an absolutely monumental success … I feel that everyone that’s here is here because they’re digging something about what we’re doing, and I want that to spread like wildfire quite frankly. So we definitely have hopes and ambitions.

But again, I’m not going to put a dot on the board of, “this date and this time, this number of users”. I think we want many more users in, and we want them relatively quickly, and we go from there.

Experiences

As recorded in some of my previous Sansar Product Meeting summaries, the events system has changed recently so that events are held in copies of a published experience that are spawned when event is created in the events system. This has given rise to a number of issues including:

  • Where the event is being based on a public experience (rather than one built specifically for the event), the experience creator must update and publish the existing experience. This means:
    • People can access the event space ahead of the event itself via the published version of the experience, thus potential spoiling the surprise.
    • Creators often make incremental changes to the scene for a published experience in Edit Mode without necessarily updating the experience itself by publishing them. This allows ideas (such as different lighting, etc) to be experimented with, without them necessarily published. However, to hold an event using a published experience, all such updates must be completed (or removed) ready for the event version of the experience to be spawned, potentially adding to the overhead of running events.
    • As event instances of an experience are separate from the original and effectively locked against “casual” admittance ahead of the event (including, say, a performer at the event), it is not easy for changes requested by a performer (e.g. a change of lighting, repositioning of an item of a stage, etc.), to be made and reviewed by the performer.
    • A lack of “event permissions” can impede event management, as it effectively means that events more-or-less must be organised, managed and run by experience owners, which again can put them off running events.
  • Where an experience is being used to host multiple events during a week / month (as per 114 Harvest), multiple versions of the experience can be spawned without clear differentiation between them within Sansar’s Edit mode. This means it is possible to actually update a clone of the experience in error when preparing for a new event, only to have the updates ignored when the event is created, because the event system, as noted, spawns from the original version of the experience (which will not have the updates).
  • As the event version of an experience is separate to the published version, all traffic generated by the former does not help raise the profile of the latter within the Atlas. Therefore, experience creators often don’t see the advantage in hosting events.
    • This lack of traffic reporting can also influence whether or not people log-in to Sansar. An event might well attract 40-50+ people to it – but as this traffic isn’t reflected in the Atlas, a casual glance at the latter via the web might give the impression “nothing is happening” in Sasar, and so a user doesn’t log-in.
  • The broadcasting system (allowing an avatar in one instance of an experience to be seen and heard across all instances of that experience) can actually result in an event performer feeling they are playing to an “empty house”. The “master” version of the experience is full by the time they arrive, so they get spun-off into an instance that might only have (say) 3 or 4 people in it. Thus, while they may well be performing in front of an audience of dozens who can see them, they are only able to see those few in the same instance with them.

LL have indicated they have experienced these issues for themselves, and are working to try to address most / all of them.

Avatar 2.0

Concern has been raised about the overall impact of the Avatar 2.0 deployment (due in September 2019) on the general Sansar users base (e.g. those who don’t attend in-world meetings, etc.). specifically: reactions should users log-in and find their custom avatars “broken”.

LL are planning an announcement campaign via social media, e-mail, etc., to advise users of the changes ahead of the Avatar 2.0 deployment.

In Brief

  • Valve index controllers / finger tracking support: this is not seen as a major project in terms of integration, but will require some work. As such, the Lab is not currently planning on supporting the index controllers from day one of their release.
  • Oculus Quest support: as has been previously indicated, this is not currently on the cards. The Quest processor and general capabilities are seen as being unable to handle to quality of content LL want to provide without massive amounts of auto-decimation, which can be problematic. However, as the capabilities of emerging VR systems continues to improve and Sansar improves in terms of performance limits, the hope is that the two will converge at some point in the future.
  • Motion sickness: there are reports that Sansar induces higher levels of nausea when turning while moving in VR. Such nausea is generally related not so much to the speed of a turn, but its length – hence why snap-turns are becoming more popular in VR., although the Lab has yet to adopt this approach in Sansar. Dance spotting might help reduce symptoms, although the reverse of this was suggested in the meeting: move the head first, then make the turn (and this might be easier if you can turn your head, then “spot” an object and turn your avatar).
  • Site-to-site teleports between experiences: currently, it is not possible to employ site-to-site teleports between experiences. For example: arrive as a door in one experience and get teleported by it to the interior of a building in another experience, then being retuned to standing outside the door again when you “leave” the building – instead, you will be returned to the spawn point in the first experience. This can be immersion-breaking in something like a quest or adventure game. The Lab has acknowledged this as something that should be addressed.
  • Animation objects: the ability to have in-scene objects proved / control avatar animations (e.g. SL-style dance systems). This is not on the current roadmap for implementation, but it something the Lab want to provide in the future.
  • Snapshot / Machinima policy: currently, Sansar does not have a policy relating to the taking / use of images or film captured in Sansar, other than the permission of the experience creator should be sought – and they have the right to ask LL to remove images of their experiences uploaded to the Lab’s Sansar properties.
    • Given that experiences in Sansar differ from those in SL (an entire experience in Sansar, including all the objects within it is generally built by an individual or perhaps a couple of people working in unison, rather than the content coming from a wide variety of creators, as tend to be the case with SL), putting the onus on the experience creator is in some way understandable / relatively easy to manage – the entire experience is, after all, their IP.
    • However, this will not always be the case, and at some point a more structured policy – such as the one used with SL – is likely to be required.
    • This is obviously seen as a matter for the Lab’s legal team.
  • Sansar website: feedback was given that the Sansar website is perhaps under-utilised. There is no real blog, no news information, etc. Instead, people are directed to Discord which, frankly, is a painful means of disseminating news and information when compared to a website, as was noted in the session.

Sansar Product Meetings week #24: more on Avatar 2.0

Sansar Social Hub

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, June 13th, which primarily focused on the upcoming Avatar 2.0 release. The official video of the meeting is embedded at the end of this article.

R33 Update

A third R33 Give More, Get More update was deployed on June 11th. This comprises:

  • A new ability to copy and paste components within the “Object Structure” panel – creators can copy and paste audio, light, and script components in the ‘Object Structure’ panel via the right-click context menu. Components may be pasted within an object, or into another object.
  • A fix to prevent crashing when editing scenes that have objects with joints.

Avatar 2.0

Target Release Periods

  • The target date for the initial Avatar 2.0 update is early September 2019.
  • It is hoped that the Avatar 2.0 reference files will be available for release to creators in early August 2019
    • This is to allow creators to gain familiarity with the new skeleton ahead of support being deployed to Sansar, and to start updating those items they make / sell that require adjustment / re-rigging to work with Avatar 2.0.
    • As a part of this, the Lab will be running a Creator Programme, this will:
      • Allow creators to develop assets (avatar, rigged items for avatars, etc., and pass them to linden Lab for testing in an environment the Lab has that support Avatar 2.0, then allow creators to receive feedback on their assets: did they work, were there problems, did things not fit as expected, do adjustments need to be made, etc.
      • Be open to all interested creators, and details on how to participate will be made available when the avatar reference files are released.
      • It is noted that this may not be as effective as creators testing their items directly; however, as there is no public beta testing environment, there is no real alternative.

General Notes

  • This is both a new avatar skeleton and mesh. As noted in my previous meeting notes, this will support:
    • Bone deformation, allowing the avatar’s face to be directly selected and shaped / contoured / scaled as the user wants (default avatars only with the initial release, but will hopefully be extended to support custom avatars in later releases.
      • Facial presets will be a part of this, allowing users to make adjustments to their avatar’s face from a pre-set look.
      • These presets will extend to allowing creators to make and sell their own facial presets.
    • Blend shapes (initially just for the base avatar, but hopefully to be extended to support custom avatars).
    • Support for uploading and using custom skins for the base avatar.
  • A large part of the reasons behind the update are: to support bone deformation; to make the avatar more expressive, and to allow users to give their avatars more in the way of individuals looks.
  • Avatar 2.0 has:
    • A skeleton with 170 bones (compared to the 230 for Avatar 1.0), which should simplify skinning to it.
    • Bone-based facial deformation (rather than blend shapes) to better support both facial deformation and to support attachments that will correctly move in response to changes to the facial bone structure.
    • A more neutral avatar mesh to better support deformation.
    • A set of skeletons, from “complex” to “simple”, to make it easier to develop custom avatars (if you have an avatar design that doesn’t require all 170 bones, use one of the simpler versions).
  • It is acknowledged Avatar 2.0 represents a substantial change (particularly the male avatar).
  • Both the male and female default avatars will be of the same shoulder height (but obviously this can be adjusted through the uniform scaling option).
  • The overall aims for Avatar 2.0 is to provide an avatar system that:
    • Meets requirements as expressed by creators, and which forms a solid foundation for all future avatar enhancements / updates without having to completely overhaul the entire avatar system again.
    • Can be used to develop avatars using the default avatars which can in turn be solid through the Sansar Store.
    • Can be used to create wholly custom avatars.
  • Avatar 2.0 sees a re-working of the procedural speech animations and some IK reworking, both of which should result in improvements in animations and VR-related movements during body tracking.

Avatar 1.0 and Avatar 2.0

  • The Lab will not continue with supporting Avatar 1.0 when the new avatar is deployed.
  • Rigged objects (hair, clothes) designed for Avatar 1.0 will need to be re-rigged for Avatar 2.0.
  • There will be little in the way of bone matching between Avatar 1.0 and Avatar 2.0 (although creators can obviously do re-mapping through their own tools, if they wish, allowing for the potential of texture stretching).
  • As recorded in my previous meeting notes:
    • The Lab has been working on Marvelous Designer scaling and translation. This, together with a clothing translation tool LL are working on, should allow MD clothing to be more easily updated to fit the new avatar skeleton. However, some of this may be limited due to the fact that MD only support uniform scaling.
    • Run-time re-targeting in being introduced to allow animations and emotes using the core bones should work with Avatar 2.0.
      • Very specific custom animations may require the creator to re-target.
    • Similarly, a re-mapping capability for attachments is being looked at, primarily aimed at allowing attachments to be moved between attach points, but which may also ease some of the transition to the new skeleton.
  • Compensation / redelivery: it has been intimated:
    • Those who have purchased custom avatars / rigged items using the current avatar may receive some form of refund / stipend from the Lab in lieu of no longer being able to use those avatars.
    • Some form of update system will be made available to creators to allow them to make updates to items they’ve made specific to the current avatar to work with Avatar 2.0, and notify customers the update is available.

Capabilities Release Order

  • Lab’s first priority is to get Avatar 2.0 working smoothly enough for an initial release, which will support facial deformation.
  • Open things to allow texture (e.g. skin) uploads that can be applied to the base avatar (providing skin uploads for custom avatars is regarded as a harder option to support, due to the need to support custom UV maps).
  • Then extend support to full body bone deformation etc.

Custom Avatar Skeleton Pre-Morphing

This is a “would like to have” from the Lab. The idea is that for custom avatars with unusual both shapes (e.g. a gorilla with longer arms, shorter legs and a tapered torso), the skeleton can be morphed and skinned through Maya (or other tool), thus avoiding the need to additional UV work to avoid stretched textures when users adjust the avatar. The morphed skeleton (and skin) can then be uploaded into Sansar and run-time animation re-targeting can be used to ensure the default animations / emotes work with it.

Ultimately, the Lab would like to get to the point of supporting fully customised animations / locomotion graphs, but this is still a way off, and this is seen as a good initial step to help better support custom avatars.

Sansar Product Meetings week #23: Avatar 2.0 and a little Q and A

The Sansar World Oceans Day Charity Event: Virtual Beach Clean Up – help Linden Lab (with additional support from the Roddenberry Foundation) raise money for EarthEcho International. Find out more on the Sansar World Oceans Day event page.

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, June 7th, which was largely a general user Q&A and feedback session. The official video of the meeting is embedded at the end of this article for reference.

R33 Updates

The Early Access pop-up, displayed when installing the client / a client update

There have been a couple of updates to the R33 Give more, Get More Sansar update. These have focused on bug fixes, and were released on May 31st (release notes) and June 5th (release notes).

One of these updates appears to also have changed the client updates process – although this may have been done a while ago, and I’m only now seeing it; I’ve not been that active on Sansar recently.

On installing a client update (and presumably when installing it for the first time) and new pop-up in displayed once installation is complete.

As can be seen on the right, this confirms that Sansar is still in “Early Access” (which may well also be a reference to the Steam Early access programme, and so the pop-up may only appear to Sansar users coming to it via Steam or who have linked their Sansar account to Steam). It warns user that things are in a state of flux, and also provides links to the Sansar website and the Sansar Discord channel.

A Launch button at the bottom of the pop-up will launch the client proper, allowing a user to log-in to Sansar (either manually or automatically if they have Remember Me checked in the client log-in screen).

Avatar 2.0

  • Avatar 2.0 represents a substantial update to Sansar and is currently one of the primary focuses for the Sansar team. It will include:
    • An updated avatar skeleton.
    • Bone deformation (e.g. allowing the avatar’s face to be directly selected and shaped / contoured as the user wants).
      • For this initial release, the deformation system will only work with the Sansar base avatar.
      • As resources become available, it is hoped to expand this to custom avatars in later releases.
    • Volumetric morphs (e.g. using sliders built-in to the base mesh to make adjustments).
    • Support for uploading and using custom skins for the base avatar.
    • The ability to use the base avatar to create custom avatars directly, which can then be sold through the Sansar Store (although this functionality will not be in the initial Avatar 2.0 release).
      • This will hopefully include the ability to create avatar shapes (a-la Second Life), rather than having to create entire avatars.
  • Avatar 2.0 reference files for use by creators are in development.
    • The current plan is to make these files available to creators approximately a month before the actual Avatar 2.0 deployment.
    • This early release of the reference files will be supported by the Sansar avatar development team, who will be available to test avatars and clothing built / rigged to the new avatar format and test them internally at the Lab and provide feedback, as creators will not be able to test directly until the new avatar system has been deployed.
    • It is anticipated that this process will work in a similar manner to the way in which Sansar fashion support with Marvelous Designer was deployed at the end of 2017; the difference her being the files will be available to all creators wishing to experiment with them, rather than just a selected few.
    • Note: the recent updates to the avatar reference files that have been distributed to so creators for testing purposes are not avatar 2.0; they are updates to the current avatar intended to reduce issues found with blend files, together with a general clean-up of the files.
    • It is anticipated that additional updates to the reference files will see the inclusion of textures. However, decimation for these reference files will remain a user task, although the plan is to include decimation support in the avatar 2.0. reference files.
  • Avatar 2.0 will not initially support different  / custom bone structures, although support for this may be added in the future.
  • To help with the introduction of Avatar 2.0:
    • The Lab has been working on Marvelous Designer scaling and translation, which may be deployed in week #24 (commencing Monday, June 10th). This will allow MD clothing to be more easily scaled / rotated / translated, hopefully making it easier to update to fit the new avatar skeleton (and other shapes).
    • Emotes are being re-targeted, so they should continue to work with the new avatar.
    • Similarly, a re-mapping capability for attachments is being looked at, primarily aimed at allowing attachments to be moved between attach points, but which may also ease some of the transition to the new skeleton.
  • It is currently not clear what will happen with the current avatar skeleton when Avatar 2.0 is ready for release.
    • The Lab view trying to support both skeletons as being “difficult”, and they may opt to only support avatar 2.0 going forward.
    • This calls into question content breakage for all of the current custom avatars (and rigged items) associated with the current avatar skeleton.
    • It was intimated during the meeting that those who have purchased custom avatars using the current avatar may receive some form of refund / stipend from the Lab in lieu of no longer being able to use those avatars.
    • It was also indicated that some form of update system will be made available to creators to allow them to make updates to items they’ve made specific to the current avatar to work with Avatar 2.0, and distribute them to customer who have purchased the previous version.
  • Given the extent of the changes with Avatar 2.0 and the fact that some decisions are still in flux, it has been suggested that in the weeks / months leading up to the release:
    • A portion of each Product Meeting is allocated to discussing Avatar 2.0, particularly where the Lab has reached a decision.
    • A Product Meeting ahead of the actual deployment (when it is ready to roll) is devoted to Avatar 2.0.
  • A goal with the updates is to (at some point) open up the materials editor for the avatar both pre- and post-upload, so maps can be altered / updated for both the base and custom avatars.

Look Book

  • Currently, Look Book cannot be searched. For those with a sizeable avatar inventory.
  • This can make finding a specific item painful it is:
    • Either a lot of scrolling through clothing or accessories within Look Book to find the required item(s),
    • Or, if a search function is to be used, going to the Store, searching there, clicking the Wear It Now button (which applies to already purchased items as well) to return to look Book and seeing it worn.
  • The Lab is working on adding more functionality to Look Book, but right now, the focus is on Avatar 2.0 (see above), and so it will be a while before anything for Look Book is deployed.

General Inventory Capabilities

Inventory in Sansar essentially comes in two forms: Avatar inventory (clothing, hair, accessories) that can be obtained through the Sansar Store and which is available via the Look Book. Object style inventory – scripts, building, sounds, media, plants, rocks, lights, etc., which can also be uploaded and obtained through the Sansar Store but which are available only through the Edit Mode inventory.

  • LL have been discussing making the latter more user friendly through the introduction of folders.
  • There has also been some discussion of providing an “experience” style of inventory, such that an avatar can obtain / carry / select items they wish to use directly within an experience.
  • Currently no information is available on how either approach may work or when they might be ready for deployment.

The “Three Pillars” of Sansar

In the discussion, Landon McDowell, the Lab’s Chief Product Officer, defined the primary “three pillars” for Sansar as a platform as being:

  • Content creation – including provided a set of well-round tools / support for tools for both avatar and world creation.
  • Socialisation – making sure people can interact with one another, make friends, hold social events.
  • Gaming  / exploration – quests, mini-games, people exploring experiences and discovering what has been put into them.

So if someone wants to come into Sansar and do something under one (or more) of these umbrellas, the Lab wants to be able to support them.

In Brief

  • Local persistence: something the Lab wants to offer, but not currently being worked on.
  • Questing system:
    • Further Lab-built questions will be forthcoming.
    • The quest system itself is being enhanced and improved, but is not yet user-friendly enough to be opened to experience creators.
    • The plan remains to make the question system available once it is robust and friendly enough to be used by experience creators. It is liable to be several more months before it is available on a platform use.
    • The system will most likely include a scripting API.
  • Particle system: this is something the Lab want to do this, but the focus at the moment is on performance, and will remain so for another “couple of months”, so development of any particle system is deferred until at least this work has been completed.

Sansar R33 Give More Get More release overview

Courtesy of Linden Lab

On Thursday, May 30th, Linden Lab updated the Sansar Give More, Get More (R33) release. An official summary of the update is available, and please refer to that document for details of bug fixes. Highlights of the release key features reviewed here are:

  • Client Atlas updates.

Initial Notes

As with the majority of Sansar deployments, this update requires the automatic download and installation of a client update.

Client Atlas Face-Lift

R33 bring with it an overhaul of the in-client Atlas. The new format comprises three broad categories: What’s Happing In Sansar; Popular Now and Featured.

The new in-client Atlas Discovery panel

This appears to in preparation for changes to the Atlas outlined by the Lab in recent Sansar Product Meetings that will see the Atlas display three selections of experiences that have been previously defined as:

  • Three featured experiences reserved for the Lab’s content partners.
  • Three featured experiences that align with other internal goals the Lab has which “may or may not be obvious”. These might, for example, focus on live music concerts.
  • Three  featured experiences open to Sansar creators, and will be changed on a weekly basis, and selected through a new criteria mechanism (details TBA).

The Experiences category will switch to the familiar listing of Sansar experiences, complete with the sub-selection options (All, Friends, Favourites), search bar and ordering options drop-down menu.

The new in-client Atlas experiences layout

The final category option is Events, offering the familiar listing of upcoming events with the sub-categories for listing past events, those you are hosting, and your calendar of all events you’ve bookmarked, and which are rounded out by the button for setting-up new events you wish to host.

The updated Atlas Events category

Other Updates with R33

  • Gifting: transaction fees for gifting Sansar dollars are to be removed, so the full amount of Sansar dollars will be passed to the recipient.
  • Event creation  / experience caps: as per my Sansar week #20 Product Meeting notes, with R33, event versions of experiences will no longer count towards the total number of experiences a creator can have published. Creators will for now be able to create / host as many events as they wish without hitting the ceiling on the total number of experiences they are allowed to have published within their subscription banding.
    • This is seen as a “temporary” change, pending further revisions to the events system, including finding a means to link events back to the originating experience.
  • New Item inventory icon: new items purchased  / obtained via the Store will be tagged with a “new” icon in their inventory thumbnail image.
The “new” icon for new i(and previously unworn / used) items in your inventory
  • New progress bar scripting API: this enables creators to add a progress bar or countdown timer when an action is triggered in an Experience. Descriptive text may also be included with the progress bar.
  • Foot IK improvement: an avatar’s feet turn when it changes direction in desktop, just like in VR
  • New right click capability: this enables users to cut, copy and paste text on various text fields.

Improvements List

This list taken directly from the release notes:

  • Avatar related:
    • Upgrading an avatar caused the Marvelous Designer clothing to fit over whatever the avatar had on during the upgrade process.
    • Marvelous Designer clothing can now be adjusted with two hands in VR.
    • The Customise option no longer exists after upgrading an avatar that has been deleted from the user’s inventory.
    • Make an empty fist in VR without worrying about other controller actions from working.
    • The scale values now apply properly on avatars using avatar animations that were uploaded using a partial skeleton.
  • Decimated crashes triggered from the avatar editor and scene editor.
  • New fix for exposure metering on Nvidia RTX GPUs to correct the problem that varied the experience brightness from one video card to another.
  • Making changes to a group of similar script attributes no longer changes the wrong attribute of some of the selected scripts.
  • Assets that contained unlicensed information no longer prevent the gizmos from appearing when selecting object structure components such as containers, static meshes, or volume components.

Sansar Product Meetings week #20: avatar LOD, policies, and more

Sitting at the Product Meeting, Wurfi (r) demonstrates that with the R32 release, it is possible to be a Tiny in Sansar …

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, May 16th, which covered the avatar LOD system, further changes to events, rendering updates and policy reviews feedback.

Avatar LOD System

  • The avatar level of detail (LOD) system has now been deployed.
  • This applies to all avatars in Sansar, whether default or custom.
  • It is an automated process that produces five LOD versions of the avatar using different tri counts, and which are automatically used / swapped so that avatars become progressively less complex the further they are from the observer, reducing the impact they may have on performance.
  • The process is “quality” based, rather than tri-count tied, so the system tries to reduce tri count without unduly impacting on the overall shape of an avatar.
  • The LOD models are generated after the avatar has been dressed and hidden surfaces removed as the avatar is baked (after something like selection in Look Book or a change of outfit).
  • It has been noted that the system isn’t working as well as might be the case with certain avatars and / or avatar attachments (e.g. eyes bugging out when lower LOD models are used by the system).
    • Those who do notice particularly odd / deformed avatars in their view are asked to take a screen shot and send it to the Lab via a bug report / on Discord.
    • If there are specific issues that occur with default avatars that do not seem to reproduce on custom avatars, again, the Lab request a screen shot showing both.

Event Changes

  • There have been reservations voiced about the way events are counted.
  • As events now take place in special instances of experiences, these can count against the total number of experiences a creator is allowed to have published, which has been seen as a problem for some creators.
  • The Lab is now “temporarily” withdrawing this, until such time as the events system has been improved.
  • Thus, creators will for now be able to create / host as many events as they wish without hitting the ceiling on the total number of experiences they are allowed to have published within their subscription banding.

Rendering Updates

  • The Sansar R32 movement update included some rendering updates there were not documented in the release notes. These updates comprise:
    • Bloom setting on the scene settings menu – improved to be less blurry and more “bloomy” (so fog may appear denser, for example). This might require experience creators to check any of their scenes using bloom to ensure things are rendering correctly, or whether adjustments are required.
    • Billboard material – has been enhanced to include scroll UV support and a non-scrolling mask. An occlusion issue with billboards has also been fixed so they should not occlude other billboards.
    • New features for fixed shimmering by scrolling emissive materials. This should also fix a problem with anti-aliasing across the edges of objects, and shimmer when scrolling UVs are used for colour cycling effects.
    • Transparent multi-bump scrolling speed has been fixed.
  • None of the fixes should require the re-upload on content; they should simply see things now working as expected.

Policy Feedback and Content Guidelines

  • Concerns were raised at a recent community meet-up about some of the policies enforced around Sansar. These include the Community Standards and their governance, and the guidelines relating to the Sansar Store not being clear / enforced.
  • This has resulted in an internal discussion within the Lab concerning which guidelines may not be as clear as they perhaps could be, those that might be a little heavy-handed and might require further adjustment, and equally those that may need to be made both clearer and stronger.
  • In terms of Guidelines, some changes / updates being considered include:
    • Store Listing Guidelines – enforcing the (community-suggested) requirement that the screen shot associated with an item listing in the Store must be taken from within Sansar. In addition, the overall listing requirements may be subject to review.
    • Atlas Publishing Guidelines and Events Guidelines – these are not currently subject to review, but will be re-evaluated for fitness for purpose based on the feedback from the community meet-up.
  • There is a feeling that the Community Standards are inconsistently applied one person in violation of the standards might be treated one way, another committing the same violation is treated a different way, for example).
    • LL have acknowledged this and a new process to ensure consistent application of the standards is to be put in place.
    • Once ready, the process will be shared with the community, so people can understand what is in place / what to expect should infractions occur.
    • The process will be designed to allow those who may have contravened the standards to be aware of what is happening and why – and to give a response that may equally weight on any decision about action the Lab might take.
    • The only exception to this is liable to be where the infraction is clearly and significantly egregious and clearly upsetting to others / in violation of the platform’s requirements for decency, etc.
  • In terms of general communications / concerns about policy / direction, etc., Galileo, as the community Manager is in place to act as a bridge and enabler of communications between users and the Lab (and obviously, vice-versa).
    • As such, people are encouraged to content him to open conversations / feedback, rather than letting concerns fester.
    • It is acknowledged that the platform is at a unique point in its development to allow this (the community is still of a size where these interactions can take place), so people are encouraged to make use of it.

Selected Q&A Items

  • Experience maximum avatar capacity: the current default for the maximum number of avatars in an experience is still 35 per instance.
    • The Lab can manually raise the limit for specific events (e.g. Product Meetings now often run with 40+ avatars present).
    • It is hoped that as a result of various improvements and the introduction of the avatar LOD system, the limit can be raised more generally soon. However, more testing is required before this can be done.
    • In the future it might be possible for the maximum count cap to be exposed to experience creators to allow them to set their own limit on the number of avatars able to access a single instance of an experience (e.g. for use in games geared for a specific number of players).
      • As the Lab faces additional costs for spinning-up instances of experiences that have a low avatar count, limiting the number of avatars able to access an experience to very low numbers might be subject to that cost being passed on to the experience creators requiring it – or even to those wishing to access the experience. However, this all still needs to be examined by the Lab.
  • Instances:
    • As noted in past Sansar articles in these pages, instances of experiences run entirely independently to one another, so that avatars in one instance cannot cross to another, nor can they see one another.
    • The lab is already thinking about how to make it possible for friends who all visit a popular experience all end up in the same instance, rather than possibly being split between instances because some fall on the “wrong side” of the experience avatar cap.
  • Avatar 2.0: work continues on developing Sansar’s “avatar 2.0”. The target date for release is currently August 2019, but this may be subject to alteration.
    • This will hopefully see:
      • Changes to the base mesh, with male and female avatars are a lot more similar in a size and frame.
      • This latter point is to make clothing items potentially more unisex: if a jacket fits a male avatar frame, it will also fit a female avatar frame.
      • More sliders for morphing / customisation. These will initially be focused on the face, with body customisation capabilities following after the initial release of avatar 2.0.
    • It’s not clear what will happen with the current “avatar 1.0” as the new avatar system is deployed.
    • Avatar 2.0 will likely result in the breakage of rigged avatar clothing. However, clothing modelled in Marvelous Designer can be resized to fit the new avatars.
      • In addition the Lab is working on an MD scaling translation system to allow MD clothing to be scaled and repositioned.
    • It is also planned for avatar 2.0 to have defined attachment points for accessories.
  • Store redelivery system: the Lab would “like to have a redelivery system in place around the time” avatar 2.0 is released. However, they are still looking at how easy / hard it will be to deliver in that kind of time frame.