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.

Sansar Product Meetings week #19: R32 updates and LOD support

Sansar: Eternity

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, May 9th, which covered updates to the R32 release and an overview of the upcoming deployment of initial level of detail (LOD) support in Sansar.

R32 May 7th Update

The R32 Movement release (overview here) was updated on May 7th, which offered a number of improvements and fixes and two additional features:

  • Toast notifications for Events: users now receive notifications when adding and removing events from their calendars
  • People indicator for Events: a new people indicator shows the number of users in an Event.

LOD Release

  • This is an update that is coming “very soon” and “before the next major release”.
  • It will mark the first time the Sansar level of detail (LOD) system will be enabled, and will initially only apply to avatars.
    • This will be an automated process, which will take place 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).
    • Five LOD versions of the avatar will be created with different tri counts
  • LOD models will be selected based on the distance between the avatar and a viewing camera (e.g. the further an avatar is from your camera position, the lower the LOD version for that avatar that will be used).
  • Effort has been put into trying the minimise the sudden increase in detail (which can cause an avatar to suddenly “pop” into shape) when moving to higher LOD models as an avatar in approached.
  • It is hoped that this will have a “non-trivial” effect on improving performance in experiences / events where there is a high avatar presence.
  • In the future:
    • The system may be opened-out to give creators more control over the LOD models that are generated and / or users greater control over when the different LOD models should be used within their view.
    • An avatar imposter system might also be implemented.
  • LOD options for objects and terrain are under consideration, and will become available in the future, and the Lab is looking to consider issues of (again) creator / user control; management of objects taking up large amounts of screen real estate, texture loading, etc.

Experience Stress Test

The meeting included an experience stress test  – users were requested to come in one of three avatar types in order to help the Lab gather data on experience instance performance under avatar loads. The test was similar to those that have been carried out internally at the Lab, and are specifically aimed towards gathering data to help the Lab expand the numbers of avatars an instance of an experience can comfortably handle.

A second part of the exercise was to gather feedback on how people feel about being asked to wear a specific type of avatar to an event. Apparently one of the ideas being looked at is that, in order to manage avatar loads, people attending a large-scale event will be asked to (made to?) use a pre-defined avatar & outfit.

In Brief

Featured Experiences in the Atlas

It should be noted that the new format for featured experiences in the Atlas is still to be deployed. However, he plan remains for this to be:

  • 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 TBD criteria set.

Avatar Contest: New User Carousel Edition

  • To encourage creators to make custom avatars suitable for presentation to new users through the carousel, Linden Lab launched the Avatar Contest: New User Carousel Edition in April.
  • As of the closing date (May 9th, 2019), no entries had been received.
  • Feedback was offered at the meeting on why there had not been any entries. This ranged from some creators not feeling confident in competing with more experienced avatar creators; some creators feeling that the amount of work involved in developing a fully dressed avatar was beyond their usual avatar design remit given the value of the prize; some felt that new users would be more attracted to customisable avatars that could be dressed / use other clothing off the Store, rather than being supplied “complete”. Even the length of time of the competition (a month) was considered problematic.
  • This feedback was taken by the Lab and will be used to determine how this and competitions might be revised to make them more appealing.
  • It was also pointed out that there is nothing stopping creators from selling undressed versions of a “new starter avatar”, or from selling the avatar itself through their store when it is not featured on the avatar carousel for new users (when it is on the carousel, it must be free).

User-Generated Documentation

  • A new Help page has been created for user-generated Sansar documentation.
  • If this proves popular over time, then effort may be put into developing a formal Sansar wiki.

Sansar: R32 Movement update

Desktop mode throw indicator (shown in 1st person view here). One of the R32 additions to Sansar. Credit: Linden Lab

On Tuesday, April 30th, Linden Lab updated the Sansar Movement 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:

  • Avatar customisation, movement and gameplay updates.
  • Client Store updates.
  • Scripting updates.
  • Edit mode improvements.

Initial Notes

As with the majority of Sansar deployments, this update requires the automatic download and installation of a client update, particularly as it involves changes affecting the Sansar avatar system.

Avatar Updates

Uniform Scaling

Until this release, all avatars in Sansar have been of the same male / female height. With R32, users can now individually scale their avatars from 0.5 to 1.25 the scale of the default avatar size.

The scaling option will scale both avatar and current outfit and accessories. As it is part of the overall avatar customisation process, scaling can be applied to both existing looks  – or now looks can be created and scaled for specific purposes, if preferred (so you could have a small and tall avatar in the same outfit for visiting different experiences, just by changing your look, rather than adjusting the scale of the one avatar).

To change an avatar’s scale:

  • Click the Create button and then Style My Avatar to go to Look Book.
  • From the Look Book panel, select the avatar you’d like to re-scale (if you have more than one).
  • Click customise (lower right corner of our Home Space  / Look Book display,
  • Click the avatar icon (arrowed below) in the Avatar style panel to display the avatar customisation options.
  • Click the slider button at the top of the panel (arrowed below, right).
  • Use the Scale slider to uniformly re-scale your current avatar.
  • Save the look.
Sansar avatar uniform scaling, accessed through the Look Book and Avatar customisation panel (right), and the two extremes of height compared with the default female avatar height (note the sofa behind the avatars for reference).

Points of note with avatar scaling:

  • Scaling will work on custom avatars.
  • Scaling does not affect the avatar locomotion graph, so small avatars will appear to move faster than their taller cousins. Similarly, very tall avatars will seem to move more lugubriously than their smaller cousins.
  • In VR mode, the world view is scaled accordingly to avatar height.
  • Scaling can cause some clothing glitches to become more apparent.

Avatar Crouching

Avatars can now crouch and move. In Desktop mode, make sure the mouse isn’t in the Chat panel and tap C to crouch  /  stand up, and move as usual. In VR move, users must physical adopt a crouched pose.

Avatar crouching. Credit: Linden Lab

Points of note with crouching:

  • The avatar’s motion will be correspondingly slower when crouched – just as we tend to move slower when crouched in the physical world.
  • The collider / bounding box for the avatar will also automatically adjust to match the avatar’s height as well, making it possible for tunnels, etc., to be made through which avatars must move when crouched.
  • The collider / bounding box in VR will collapse in accordance to how low the user crouched.

Desktop Movement Updates

Two new options have been adding to the Settings panel (More Options > Settings, then scroll down).

  • Keyboard Turn: if set to On, your avatar turns left and right when pressing A or D ( / Left or Right arrow) respectively. If set to Off, your avatar sidesteps to the left or right (without turning) instead.
  • Face Forward: if set to On, your avatar attempts to face the direction your camera is looking while you are moving. If set to Off, your avatar faces the direction your are moving.

Remember to click the Save button to preserve your preferred settings.

The new Desktop avatar movement Settings options (left – see notes above) and the new Desktop mode throw indicators (right – see below)

Avatar Gameplay Updates

With R32, Desktop mode now also has a new desktop throw indicator. To use it:

  • Pick up an object (left-click on the object).
  • Click and hold the left mouse button. A dotted line arc will appear showing the flight of the object when the mouse button is released.
  • A blue circle at the end of the dotted line arc will show the likely destination of the object when thrown – use the mouse wheel to adjust this back and forth.
  • When ready, release the left mouse button as usual to throw.

Note that depending on your Desktop movement settings, you might be able to adjust the left/right aspect of your throw by moving to the left or right (this can be easier in 1st person (F3) mode).

Additional Avatar Options

  • New simple skeleton: a simplified avatar skeleton reference file (70 bones, and refered to as a “low resolution” skeleton in the reference documents) to make it easier to hook up animations. See Avatar reference files in the Sansar knowledge base.
  • Mixamo animation support: use the simplified skeleton on Mixamo and take advantage of their library of animations. See Using the animation skeleton to create custom animations in the Sansar knowledge base.

Continue reading “Sansar: R32 Movement update”

Sansar Product Meetings week #17: R32 overview

Scorpion’s lair: Hall of Light

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, April 25th, which served to introduce members of the Sansar team, discussing the upcoming April release.

Avatar Controls

  • Extra tracker controls for VR: as per my week #14 notes, R32 will include fully body tracking for the HTC Vive, utilising the hip and ankle trackers.

  • Desktop throw indicators: when attempting to throw something when in Desktop mode, a visual indicator of the arc the object will take when released will be displayed, and the mouse scroll wheel can be used to adjust the strength of the throw.
    • The visual arc is not a perfect representation of where the object will go, and will fade out after a time, but is designed to give overall guidance.
  • Avatar crouching: crouching will be joining jumping as an option with R32.
    • Crouching will be physically enabled in VR, and via keyboard in Desktop mode.
    • The avatar’s motion will be correspondingly slower when crouched.
    • The collider / bounding box for the avatar will also automatically adjust to match the avatar’s height as well, making it possible for tunnels, etc., to be made through which avatars must move when crouched.
    • The collider / bounding box in VR will collapse in accordance to how low the user crouches.
  • Keyboard turn / face forward:
    • Currently, when moving sideways using A and  D, the avatar will strafe to the left or to the right whilst walking, while S will cause the avatar to walk backwards.
    • With this new keyboard option enabled, the avatar will turn to face the direction of travel when walking to the left or right or backwards, and the camera will automatically follow.
    • With the option disabled, the avatar will resume the strafing walk.
    • Users weill be able to set whichever they prefer or toggle according to circumstance.


  • Avatar scaling: R32 will see the first implementation of avatar scaling to allow differently sized avatars.
    • The initial release will allow avatars to be uniformly scaled down to 1/2 the size of the current default Sansar avatar and 1.25 times larger.
    • Scaling will be applicable to custom avatars as well, and will include all avatar attachments.
    • Initially walk / run speed, jump and crouch heights will be normalised against the default avatar’s height / stride (e.g. so if your avatar is of a small size, it will seem to move very fast proportionate to its size; when made larger, it will appear to take shorter strides).
    • This may be revised in the future so that walk speed / stride / jump height, etc., will be proportionate to the actual avatar size.
  • Partial animations:
    • A new simplified Sansar skeleton (with around 70 bones) will be available for download to be used specifically for animations.
    • This does not mean a simpler skeleton is being used by the avatar – that remains unchanged and will see animations created using the new simple skeleton will be applied to the full skeleton; any bones not used by the simplified skeleton will remain in the reference pose.
    • The importer will (obviously) work with this simpler skeleton, and with any other skeleton, as long as it is topologically the same in terms of ordering and naming for bones.
    • This will hook-in to third-party tools such as Mixamo’s animator tools.
    • As the full skeleton is still used by the avatar, things like facial animations can still be driven through Speech Graphics, although dedicated facial animations will still require the download and use of the full skeleton.
  • Object movement APIs:
    • There will be a new moveable from script objects flag that when enable will allow use the flagged object (mesh, sound, trigger volume, light, etc.), will be moved.
    • This also allows interactive objects and the root element of animations to be moved without them having to have a rigid body.
    • It will enable frame-perfect animation; movements can be properly queued to be executed at specific times / in a specific order by the engine of the desired frame and allow animations to ease-in and ease-out one to the next.
    • Overall this should allow:
      • The development and movement of simple non-player characters (NPCs), allowing simple patrol / follow behaviours, etc.
      • Dynamic assets to drive animated assets, which in turn should enable things like animated held objects like guns, etc.

  • Rigged assets to support collision meshes: R32 will allow keyframed physics rigid bodies to individual bones (so an animated trunk on an elephant can physically knock / move things around, for example).
    • Should be used with consideration, as adding this to every bone in a body could place considerable additional load on a scene.
    • Not suitable for ragdoll physics, as this requires the set-up of physics joints between the bones.
  • Atlas and events updates: as per the week #16 product meeting, the Atlas and events will once again be more closely integrated.
  • Sansar Store:
    • The Store will be updated so that Marvelous Designer items will be more clearly tagged.
    • It should be easier to wear newly purchased wearables when purchased through the client version of the store.
  • Edit mode: the gizmo tools for moving / rotating objects within a scene should be more selectable / easier to use.
  • Scripting updates: these will include the ability to call the Sansar new user experience tutorial when required, among other changes.

Sansar Product Meetings week #16: Lindens and events

Skye Naturae Virtualis

The majority of the following notes were taken from my recording of the Sansar Product Meeting held on Thursday, April 18th, which served to introduce members of the Sansar team, discussing changes to featured experiences, and raised the possible instigation of a possible Office Hours with the product team. The meeting was followed on April 19th by an announcement concerning the use of PayPal as a supported payment service provider, which is noted at the end of this report.


The meeting took the opportunity to introduce:

  • Kelly Linden: Kelly is worked at the Lab for 15 years, obviously primarily with Second Life, where he headed the scripting team; he now leads the scripting development team for Sansar.
  • Skylar Linden: Skylar heads the Sansar Live Events team, and is leading the work on the work with events and the Atlas that is currently in progress.
  • Signal Linden: has been part of the Sansar team for three years, working in a number of areas, including the web API, and is currently focused on some transform tool changes in the Edit mode, and which see the addition of some hot keys to allow toggling between things like move and rotate, etc.
  • Lankston Linden: a data analyst  for Sansar, focusing on typical activities within Sansar – how many people are doing X at a given time, etc., how many are using Y, helping to determine trends within the platform, etc.
    • The analytics Lankston is helping develop are intended for use by the Lab, but Landon Linden indicated that developing analytics for use by Sansar creators. This should hopefully start to happen towards the end of the second half of 2019.
  • Harley Linden, who head the Sansar support team.

Featured Experiences

Featured (Recommended in the web version of the Atlas) have not been updated in a while. The web version comprises a 3×3 grid, and in the future:

  • Three of these featured experiences will probably be reserved for the Lab’s content partners.
  • Three will feature 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.
  • The remaining three will be open to Sansar creators, and will be changed on a weekly basis.

The criteria on how the last three are selected still have to be determined, however:

  • It is likely that a creator featured one week will not be eligible to be featured the following week, even with a different experience.
  • There is likely to be some form of public “voting / nomination” for potential experiences through the Sansar Discord channel.
  • It might be that the three slots will be determined by an over-arching theme (e.g. holiday themes during notable holiday weeks, or themes like clubs, games, etc.


  • Sansar’s Discord channels have been opened to the public.
    • A new public channel (or channels) is available for those who might hear about Sansar and who want to check the community, etc., before opting to install the client and sign-up.
    • This means the content of the existing channels will be available for anyone on the public Sansar Discord channel to read, but only registered Sansar users will be able to post to them.
  • The Lab is additionally look to reach out to other communities on Discord and generate interest in Sansar (e.g. the live music community).

In Brief from the Meeting

  • Linden Lab is looking to expand the number of avatars a single instance of an experience can handle. The limit has been 35, but 50 is being looked at with tests of up to 65.
  • There is a known issue with voice that can see it suddenly drop / fail within an experience where multiple people are chatting.
  • With the next release (as previously reported) events and the Atlas should be fully re-integrated. However, it is still TBD on whether the event will feature the primary instance of the supporting experience, or will be tied to a dedicated instance of the experience.
  • Product Office Hours: the idea here is for sessions (possibly on Twitch) in which specific topics could be addressed (e.g. “how to rig an avatar”). Feedback on this idea has been asked for via Discord.

PayPal Support

On Friday, April 19th, Linden Lab announced – via Steam – that with immediate effect, they would supporting PayPal as a payment service provider, allowing users to purchase Sansar Dollars, store items, and tickets to events using PayPal.This is something users have been requested since at least the time of the public beta.

Full details on adding PayPal to your Sansar account can be found in Adding a payment method to your account, which also includes:

Sansar Product Meetings week #15: custom avatars and contest

Felsenmeer – Silas Merlin – blog post

The following notes were taken from my recording of the Sansar Product Meeting held on Thursday, April 11th intended to be on the subjects of custom avatars, upcoming changes to the Sansar Discord channel, and moderation capabilities in Sansar.

Custom Avatars

First Time Avatar Selection for New Users

  • With the March Jumping and Questing release, new users can select from a range of (user-created) custom avatars via a new carousel (or opt to create their own look using the system avatars via the Customise button).
  • Stats show that around 50% of new user avatar selections are now custom avatars.
  • Custom avatars are currently selected on the basis of:
    • How good it looks in the Lab’s eyes, particularly to gamers.
    • How appealing the avatar is to all allowed age groups. – including whether the avatar is fully clothed (allowing new users to go directly “in-world” to experiences without having to go to the Look Book to customise their look.
    • Whether the avatar can be easily dressed using Marvelous Designer clothing.
    • Whether the avatar is offered for free in the Sansar Store.
  • The selection of custom avatars will continued to be curated and updated.
A sample of the custom (user-created) avatars on the avatar carousel and available at the time of writing to new Sansar users on signing-up

Avatar Contest: New User Carousel Edition

  • To encourage creators to make custom avatars suitable for presentation to new users through the carousel, Linden Lab have launched the Avatar Contest: New User Carousel Edition.
  • Full details are available in the official blog post. However, in brief:
    • Creators are invited to present custom avatars suitable for use on the new user avatar carousel.
    • Avatars must meet the requirements outlined above, and additionally must have properly rigged hands and mouths.
    • Creators may submit up to five entries (but can only win one of the prizes).
    • Five avatars will be selected from entries, and the designers awards S$27,500 each.
    • The onus is on humanoid avatars, or human anthropomorphic avatars.
    • Avatars can be submitted through until 17:00 PDT on Thursday, May 9th, 2019.
  • If the contest proves popular, it may be run again in the future.

Discord Changes

These are due to come into effect from Monday, April 15th, 2019.

  • Those who wish to keep their view of Discord as it is will be able to do so. All of the changes / new features will be on an opt-in basis.
  • A new public channel (or channels) is to be introduced (most likely on Monday, April 15th) alongside the current “user” channels,.
    • This is specifically aimed at those who might hear about Sansar and who want to check the community, etc., before opting to install the client and sign-up.
    • Existing users are encouraged to join the public channel and participate in discussions there, answer questions, etc.
  • The existing “user” channels will remain only accessible for interaction to those with a Sansar account (which will continue to be the point of entry to them).
    • However, the content of the channels will be available for anyone on the public Sansar Discord channel to read.
  • If the public channel aspect doesn’t work as anticipated, it might be rolled back in the future.


This was more of a general discussion / feedback session, rather than an announcement of new features or changes to the current moderation / blocking capabilities. Key points from the discussion are summarised below:

  • The current set of moderation tools with their focus on avatar / avatar blocking have been developed from the perspective of helping new users deal with unwanted situations. It is acknowledged that a broader toolset is required,
  • At present, users can block one another’s avatars – useful if someone is being a particular nuisance, but the experience owner isn’t around to intervene, or if they are just being a very specific annoyance for another user. However:
    • There has been feedback that the current blocking is insufficient, as it doesn’t include removing their text comments from local chat.
    • There is no personal block list, so it is difficult for some to determine whom they might have blocked (possibly accidentally) without the subject of their block actually being present in an experience with them (but being invisible to them).
    • How to unblock also lacks clarity.
  • A lack of ability for experience creators to quickly ban troublemakers from causing issues within an experience being enjoyed by others – such as a single-click eject (back to the user’s Home Space?) / ban capability.
    • Avatar blocking doesn’t work in this situation, as it is purely avatar-to-avatar, so the nuisance can still go on to bother others in an event game, and can also be disruptive as they can continue to interact with elements in the scene.
    • Having to record an avatar’s name, then go to Create > Build Experiences > My Experiences > Publish > Publishing Options > Ban List and then add a name is (rightly) seen as too long-winded.
    • This is something the Lab has considered alongside the current moderation tools and are planning to provide. However, it is also something that hasn’t as yet been prioritised.
    • However, the Lab have looked upon such capabilities as being more event-driven (e.g. large-scale events that require specific moderation  / some form of moderator role which would include the required capabilities.
    • The problem with the Lab’s approach is that potentially, without a broader, more accessible set of moderation capabilities available to them, experience creators already in Sansar are reluctant to hold major events of their own, simply because of the overhead involved in taking action against a troublemaker (or worse, a group of troublemakers) with the current capabilities.
  • Part of the Lab’s approach to moderation is to provide tools that allow users to be both pro-active and to consider the options at their disposal in accordance with a situation (does someone’s behaviour actually warrant blocking, or is muting sufficient? Should they be banned for an experience  – where banning is an option – or should they be reported? Should they be banned and reported? etc).
  • As it is, blocking / muting in VR is not that intuitive. The Lab is aware of this and looking to improve things.