2018 Sansar product meetings week #28: July release preview

The Art of Drew Struzan: The Studio Experience blog post

It’s been a while since my last Sansar product update. This has been in part due to the fact that for a time they seemed to vanish from the Sansar events listing (they’re back, but under the more generic title of “Community meet-ups”). However, the following is a summary of the meeting held on Thursday, July 12th, 2018, which was particularly focused on many of the features and updates in the upcoming July Sansar release, due in week #29 (commencing Monday, July 16th).

July Release

Custom Avatars

It will be possible to upload custom avatars to Sansar, with skeletons and avatar meshes available through the knowledge base.

  • Custom avatars have a maximum tri limit of 40K (compared to 16K for the default avatars).
  • It will not be possible to clothe custom avatars or add attachments, etc., via the LookBook – they must be outfits prior to upload, hence the higher tri limit compared to the default avatars.
    • The option to change outfits on custom avatars through LookBook might be added in the future.
  • The base tri count limit is seen by the Lab as being for testing purposes, and to potentially allow custom avatars to be dressed, etc., using the LookBook and clothing from the Sansar Store in the future, hopefully without their overall tri count becoming exorbitantly high.

As a part of the overall work on avatars – but not part of the July release – the Lab is trying to improve face deformations, etc., to allow for more realistic facial moments when mimicking mouth movements, etc., when speaking.

Experience Interactions Changes

The July release should enable experience creators to define smoother interactions with objects in their scenes.

  • Dynamic objects / bodies will be completely responsive to physics; however, if multiple avatars are interacting with the same object  / body, it might vacillate between them.
  • With scripting, physics will be immediately applied in the client, so there may be an increase in perceived lag, as interactions make the client-server-client round trip.
  • These changes will be iterated upon and improved in future releases.

Scene Editor Updates

  • Selecting an object within the scene editor will display the triangle count for the object in a display similar to the diagnostics tool.
    • This may eventually be expanded to display further information – creator, etc.
  • The Scene Settings panel should no longer conflict with the Properties Panel.
  • It will be possible to select multiple objects in the scene editor, and apply something like an audio material across all of them, rather than having to apply it individually to each one.

Auto Decimation Changes

The June release included automatic decimation, which was later disabled. With the July release, it will be re-introduced, but made optional.

  • By default, any scene object (static or dynamic) being imported into Sansar will be set to auto decimate.
  • This can be disabled via a drop-down panel option.
  • The auto decimation will not apply to clothing or avatar attachments.

Script Updates

  • New scripts added to inventory: further scripts will be available in inventory by default (exact scripts TBA). Some of these will be packaged with the client, other may only be in specific folders (e.g. the Script API folder).
  • “Simple script examples”: a small library of approximately a dozen script examples designed for use by non-scripters to allow them to achieve object interactions, etc., and which can be stacked together within objects to achieve combined results.
    • These include things like a mover script (for opening / closing doors, moving platforms, etc.), a switch script (for light switches, etc.), a sound management script, etc.
    • They will be in the drop-down menu of an object-properties.
  • HTTP API: an http: API will be included in the July release. This will mean that data such as avatar name, avatar UUID, an avatar’s location within an experience, will be shareable with external databases.
  • .FBX animation imports: .FBX files with multiple animations can be imported and have scripts applied to them.

In Brief

  • Avatar comfort zones: The July release will include comfort zones, allowing people to define how close other avatars can come to their own avatar, depending on whether or not the other avatar is a friend or not.
  • People Search Update: the ability to search for other avatars within the People app is currently limited to using the Avatar ID. With the July release, this will be expanded to allow searches by avatar name, and using partial avatar IDs.
  • Copy chat: it should be possible to copy text from the chat window with the July release.
  • Panel positioning persistence: the client should remember the placement of any re-positioned panels between sessions, and re-open them at the “last used” position, rather than at their default screen location.
  • Bug fixes: the release will of course include a range of bug fixes.

Other Items

The following were discussed at the meeting, but are not part of the July update.

  • Hand Controller / Keyboard Mapping: further work is to be carried on custom keyboard mapping, which will hopefully encompass headset hand controllers, allowing experience creators to define custom operations to keys and buttons (e.g. for use in games, etc.).
  • Events: there will at some point be an update (or updates) to Events to add many of the requested functions to events management (e.g. set recurring events, etc.).
  • Permissions system: this is still being worked on, with the Lab getting “closer” to having something ready to present, but no time frame on when it will appear.
  • User-to-user S$ transfers: this is also being worked on, and it is hoped to will appear “pretty soon”.
  • Aspirational roadmap: it’s been suggested that Linden Lab might follow the example of other platforms and provide an “aspirational roadmap” – a guide to what they’d like to achieve with Sansar’s capabilities over a broad range of periods (e.g. “short term”, “medium term” and “longer term”) which are tied to specific date ranges / time frames. This idea is being taken back the Sansar marketing and product teams for discussion.

Sansar Dollar Bundles

A relatively recent (I believe) update is the addition of purchasable Sansar dollar bundles, available at fixed prices, and which will be immediately delivered to your account on payment, rather than waiting for Sandex orders to be filled.

Sansar dollar bundles are available for purchase by those who do not wish to use the Sandex. This list of available bundles can be access by clicking on your account balance when logged-in to the Sansar website (arrowed, top right).
  • Click on your account balance (top right of the Sansar web pages when you are logged-in) to display a list of available bundles.
  • Click on the relevant red payment button to buy  a bundle – if you don’t have a payment method on file, you’ll be asked to provide one.
  • Note that the prices for bundles are not necessarily as competitive as buying through the Sandex, as the bundle prices are static.
  • A link at the bottom of the list of available bundles will take you to the Sandex (which is no longer listed in the website’s top menu).

Sansar Product Meeting #13/1: events, new users, fees

Sansar: The Whyst Garden, scene of the Tuesday, March 27th product meeting

The following notes are taken from the Sansar Product Meeting held on Tuesday, March 27th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week.

The subject for this meeting was events, although the discussions were inevitably far more wide-ranging.


The mid-March release, now called the It’s A Party release, included the client-side option for Sansar experience owners to promote events they are running through the Sansar events listings in both the client and on the web. This is part of the Lab’s desire to increase the active user count within Sansar and to encourage more social / fun activities on the platform.

Event Surfacing

Some issues have been identified with the way events are surfaced in both the Sansar Events web page and the client.

  • Currently, the Events app in the client and the Events page on the web have a Featured tab which only lists upcoming events. Ideally, this tab should only list those events selected by Linden Lab to be Featured events; there should be a separate tab for Upcoming events, listing them in chronological order.
    • The Lab has not actually started curating user-submitted events. This will start happening in the near future.
  • Within the client Atlas, Upcoming events are only displayed when the Featured experiences tab is selected. Switching to any other Atlas view – All, Sansar Studios, My Friends, Favourites – and the list of Upcoming events vanishes. Ideally, the Upcoming events should persist across all client Atlas views.
    • A suggestion is to add an Events tab to the Atlas (as well as having the Upcoming list), which could either list events, or (preferably) open / switch to the Events app window.

Promoting Events / Inviting people to Events

The Lab is currently considering way to promote events and inviting people to events, both within and beyond Sansar. This is seen a part of building a comprehensive notifications system.

  • The ability to promote through social media platforms requires the inclusion of the authorisation processes / APIs for those platform, something which isn’t on the immediate list (at the current point in time, inclusion of something like Facebook authorisation might not be viewed positively anyway).
  • An idea raised at the meeting to include the option to export event items to meetup.com pages or Eventbite pages, for those who wish to use those services.
  • Inviting people to events is, in the Lab’s eyes, a complex issue, as it is tied to the permissions system, and to things like future abilities for event organisers to host their events in experiences built and owned by others, etc.
    • However, being able to directly invite people into an event is seen as critical, and far more beneficial than simply placing an event notice out on the web or broadcasting it purely through social media in the hope of attracting interest.

Paid Events

The Lab’s initial thinking around paid events takes two forms:

  • Ticketing: allowing event organisers to set up a “paywall” in front of their event (e.g. those wishing to attend must purchase a ticket through the Sansar Store).
  • Tipping: the means for those attending an event to tip the organisers at some point. This would include scripted support so tippers can be recorded / acknowledged. There will also be a means for event organisers to see how well their events are helping to monetise their experiences. Tipping can be approached in a number of ways:
    • Via a scripted object, which pays the experience owner / object owner directly;
    • Via gifting – payment from one person to another, although this requires the permissions system to be in place.
    • Via the Sansar Store – purchase a set price “tip jar” to pay the creator / event host (as both will currently likely be the same).

Event Co-ordination

The question was raised about encouraging event co-ordinators from Second Life into Sansar.

  • On the plus side, some event co-ordinators are content to obtain space (available for free in Sansar) and build-out their event using purchases from the Marketplace (or in this case, the Sansar Store).
  • One the minus side, there is no way, currently, for event co-ordinators to collaborate with experience owners in developing and building-out an event in partnership nor is there any means for event co-ordinators to be paid via the platform by an experience owner to plan and run an event on the experience creator’s behalf.

Other Events-Related Items in Brief

  • Support for Recurring Events: currently, events can only be created on an individual basis – there is no means to create a recurring event. This has been requested multiple times since the It’s A Party release was deployed, and it is something the Lab as added to their list of capabilities to be added to the events feature.
  • Linden Lab’s Current Events  / Marketing Approach: Linden Lab is currently experimenting with pulling live stream events into Sansar and trying to build an audience around them. In early Mars, for example, there was a series of Twitch live streams – painting, playing chess, dungeons and dragons discussions, etc.
  • Offering gifts: gifts can form a major part of events in Second Life. currently, event organisers cannot easily offer gifts directly to visitors to their events in Sansar – gifts can only be made available through the Sansar Store, which means they are available to anyone, rather than exclusive to the event.

New User On-Boarding

The Lab is in the process of developing a more advanced new user experience. This is to include a new tutorial, and may take the approach of dropping new users into a lobby space where they can socialise together, learn how to control their avatar, etc., prior to moving them on to the Atlas and broader explorations.

Events are seen as an important element of this work, as ideally, the Lab would like to direct new users coming into Sansar through their on-boarding process to places where there is activity and they will likely be welcomed.

Payment Channels for Sansar Dollars

The Lab is still looking to provide more channels for purchasing Sansar Dollars – e.g. PayPal, with plans to broaden the choices to match those in Second Life (e.g. credit / debit cards, PayPal, Skrill). However, this work has been on hold for a while, and it is not clear where it sits in the Lab’s current road map.

Transaction Fees

Sansar operates on a fundamentally different model to Second Life, in which transaction fees play a much large role as a means for Linden Lab to generate revenue from the platform.

This means, for example, that tips, as with any form of monetised transaction will be subject to a transaction fee (the same fee as applied to the Sansar Store). This will be applied on top of the tip / transfer amount, rather than subtracted from it (as with Second Life). So, for example, if the Sansar transaction fee is 15%, someone tipping another person S$100 will be charged S$115, including the transaction fee.

The Lab has been considering a minimum threshold amount that can be gifted that is fee-free, but once payments / transfers exceed that amount, the transaction fee is applied, the thinking being the payment is essentially for services rendered, and thus subject to “tax”.

It has been pointed out that for creators, up to 26.5% in fees can be levied (15% transaction fee, 10% fee for converting a S$ amount to fiat currency, and a bank transfer fee applied to the amount).

  • The Lab feels that while not necessarily set in stone, the fees represent a fair price point when compared to other content selling sites, where the fees and bt 30% or more. However, they also note those sites are able to offer revenue generation at volume to those selling through them, which Sansar cannot currently offer due to the user base size.

Ability to Pay Subscriptions via Sansar Dollar Income

In Second life, it is possible to cash-out Linden Dollar amount to fiat money and then leave the amount on account to pay things like Premium membership fees and tier. No similar mechanism currently exists in Sansar to allow creators to cash-out their $S balances and use the result $ balance to pay their subscription fees. This has now been raised as a feature request.

Sansar Product Meeting #12/1: publishing and access control

Radio Grind presents…The Experience: Part V The Dirty Grind IAC Live Music Venue & Listening Lounge – scene of the March 20th Product Meeting

The following notes are taken from the Sansar Product Meeting held on Tuesday, March 20th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

A portion of the meeting looked at the mid-March update, which is covered separately here. The latter half of the meeting was also  an extended  – and at times confused – general discussion on access control. Part of this did highlight the benefit of more scripted capabilities for access control and persistence of scripts, etc., (e.g. limited ban times, rather than a one-time “forever” ban until revoked; or the ability to apply the same access control list across multiple experiences). The discussion did not draw specific conclusions, but highlighted the potential for more focused discussions with specific product experts in the future.

Given the above, these notes focus on the core feedback provided by Boden and Jenn in terms of how the Lab views things.

Publishing on Sansar

There is some concern in the Lab that the current route to surfacing an experience is potentially confusing for some creators, in terms of knowing whether or not their experience is actually listed.

The current flow is to go to the publishing options, which opens on the Who Can Visit tab (below left), where the general access options can be set (Public, Only Me, by lists – Friends, Guest, banned).

The user then moves to the Atlas Listing tab (below right) – the first option of which is set to Hide This Experience From The Atlas by default, which unless unchecked, means the experience will not be surfaced in the Atlas, regardless of anything set in Who Can Visit – hence the confusion.

By being checked by default, is the Hide This Experience From The Atlas causing confusion when publishing an experience?

This led to an extended conversation about access, terminology (e.g. given a scene has a URL, isn’t that technically “published” anyway, regardless of the status of the experience?), options, etc.

Purely in terms of dealing with the confusion over whether or not an experience can be seen in the Atlas, the simplest approach would seem to be to leave the Hide This Experience option unchecked – this would also then more accurately reflect the explanatory text given with the Why? link.

Tool Tips

The suggestion was put forward that why going forward, and allowing for complexities of language localisation, etc., the Lab should look to ways to offer tool (or hover) tips within elements of the UI to help users better understand options and buttons.

Access Control Roadmap

In terms of access control to experiences / events, the current order of things at the Lab seems to be:

  • Implementing the underlying infrastructure to allow event ticketing.
  • Then build-out the tools to allow pay-to-access events (this will initially be internally / possibly with partners, prior to the tools being publicly surfaced).
  • Then, depending on how demand for events grows, go on to provide:
    • Experience / event owners to appoint moderators for their events, who can help manage the actual event (e.g. remove people causing problems).
    • Event organisers to rent experiences so they can host events without necessarily having to build a dedicated experience / contract someone to build it.

Does Access Control Mean Adult Content May Be Allowed in Sansar?

  • Currently no. Linden Lab’s Terms of Service, Sansar Terms and Conditions, etc., remain unchanged.
  • While access control may offer a step towards allowing adult content, there are other factors still to be put into place (e.g. age verification – something which could affect the experience owner as much as LL).
  • As the product is still in a “beta” status, the Lab is sensitive towards how it is perceived in the media (understandably, given the history of SL and certain elements in the media).
  • Adult content may come in the future, as Sansar grows, particularly as the environment means there is not necessarily the kind of “link” between moderate and adult content as might be seen with Second Life, simply because spaces in Sansar can be clearly separated one from another.

Other areas of consideration include the Sansar Store, and how Adult material would be handled there: would there need to be a separate Store for such content?

While no final decision on adult content has been made vis Sansar, Boden pointed out that the steps being taken now in enhancing access control, providing the means to support groups with different interests and requirements, etc., could eventually lead to adult content support as Sansar matures.

Access Control & Dress Code

In early discussions on Sansar, Ebbe Altberg raised the idea that experience creators would be able to define what outfits could be worn in their experiences, if they wished.  So for example, a steampunk themed role-play experience might require visitors to be dressed in appropriate costumes, thus avoiding the immersive nature of the experience being broken by someone waddling around as a pigeon toed under grown flying purple people eater (so to speak). This is apparently still on the roadmap for some point in the future.

Sansar Product Meetings #11/1: mid-March release news

Pierre (centre, in sunglasses) and Cara (to his left, with wings) discussing the upcoming mid-March Sansar release on Tuesday, March 13th at Skye Naturae Virtualis

The following notes are taken from the Sansar Product Meeting held on Tuesday, March 13th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

Originally, the subject for the meeting had been listed as being the Sansar avatar. However, this was updated to a discussion about the upcoming “mid month” Sansar release.


March 2018 will see a “mid-month” release for Sansar – the exact date is still TBA, and it is being made because  a number of features are available earlier than the Lab had anticipated, and which Linden Lab is keen to get in front of users.

The following is a high-level overview of what to expect. Obviously, I’ll have more information on this when the release is deployed, and the release notes are available.

Performance Improvements

The Lab convened a “strike team” to address a number of performance issues, and the upcoming release should be marked by a umber of performance improvements.

Terrain Editor and Performance

One of the findings from the performance investigations is that the terrain editor used to sculpt height maps from within Sansar, and the terrains edited using it, can have a significant performance impact in both Edit and Run-time modes. There is no quick fix for this at present, as the terrain editor requires a significant amount of work, and the resources aren’t available at the moment. Because of this:

  • The terrain editor will be disabled with the next release.
  • There’s no date as to when a replace terrain editing system will be implemented.
  • Between now and the end of April, creators who have extensively used the terrain editor and height maps to produce terrain in their scenes / experiences, will be asked to remove / delete their existing terrain sculpts with tiles made via alternative means (e.g. custom made externally and uploaded for “as-is” use).

Pierre outlines the terrain editor issue

This means that with the mid-March update:

  • It will no longer be possible to upload new height maps.
  • It will no longer be possible to list new height maps on the Store, either uploaded or those already in inventory.
  • Creators who have placed height maps on the Store will be asked if they could unlist them to prevent people for purchasing them and using them in their scenes.
  • It will no longer be possible to paint, sculpt, reposition, rotate, etc., terrain in  scene.
  • It will no longer be possible to pull terrain sculpts from inventory for use in a scene.
  • Terrain elements will still work as expected in published experiences, but again, they will not be editable within the experience’s scene.

Then, between the mid-March update and the end of April:

  • Creators will be encouraged to remove / delete custom terrain sculpts as noted above, and replace them.
  • Terrain maps not removed by the end of April will be replaced by a place-holder item.
  • To help people get to grips with creating and uploading terrain elements, the Lab will be providing a new Sansar knowledge base article.

Feedback from those at the meeting:

  • A request has been made that the Lab allow higher resolution textures to be used with uploaded terrain tiles, particularly where larger experiences are concerned.
  • Another request was made for the Lab to make at least some of the scene template elements (e.g. the rocks and cliffs) available through the Store so that experience creators would have some “pre-built” terrain elements they could use.

Both ideas are being taken back to the Lab for consideration.

Events Creation

As reported in my week #10 update, with this upcoming release it will be possible for Sansar experience owners to create their own event listings.

  • The option to create an event – a meet-up, game, tour, and so on will only be in the client (it will not be possible to create events from the web).
  • Using the client, it will be possible to set the location, date, time and duration of an event (presumably with some form of description, although this wasn’t specified in the meeting).
  • Once created, all events will be displayed in both the client Atlas events section and on the Sansar Events page.

Scripting Improvements

Script Update Capability

With the upcoming release, scripters will be able to offer updates to their scripts listed on the  Sansar Store. The basic process will be:

  • Update the script and upload it to inventory.
  • In the client, locate the revised script, right-click on it and select the “Replace Item on Store” option.
  • This will take the script creator through a workflow to replace an existing script associated with a Store listing with the updated script.
    • If required, the listing can also be updated to include release notes or details of changes made to the script.
  • Those who then wish to update their versions of the script can then go to the store and download the update (which will be added to their inventory without deleting / replacing the original version) or, if they prefer, just keep using the original.

This functionality has been implemented and is being deployed to help with situations where changes to Sansar’s evolving script APIs can result in scripts being broken following updates. other options for updating goods on the Store will come in the future.

C# File Size Increase

With the upcoming release the file size for C# script files is increased to 1 MB.

LookBook Update

When using the LookBook to view your own  avatar accessories for listing purposes, etc, the green corner button will be replaced by a right-click option, which should also display the item name.

Continue reading “Sansar Product Meetings #11/1: mid-March release news”

Sansar Product Meetings #10: events in Sansar

Sansar: The Whyst Garden – blog post

The following notes are taken from the Sansar Product Meetings held on Tuesday, March 6th and Thursday, March 8th. These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

The subject for both of the week #10 meetings was Events in Sansar. These notes are an attempt to bring together the key points of discussion from the meeting note that they represent discussion points, not necessarily ideas the Lab will be implementing in Sansar.

Changes to Event Submissions

Currently, the process of adding events to the Sansar events calendar (visible on the Web Atlas events page, and within the Client Atlas) is via e-mail submission to Linden Lab.

  • This will be changing soon to allow users to post their events directly to the events listings.
  • However, the option will initially be limited to hosting events in a user’s own experience – it will not be possible to post events taking place in an experience run by someone else.
    • This is primarily to prevent issues of people trying to unfairly monetise other people’s experiences.
    • Once there is a means for splitting revenue between event organiser and event “host” (experience creator), this restriction would likely be lifted.
    • As an alternative, LL might consider ruling that events can be held in any public experience, but where the experience creator is not the event organiser, than the event must be free of charge to access.
  • Some time after the events submissions process is revised, the system will be expanded to allow people to invite other users directly to their events.

How Should Events / Event Access Be Governed?

Controlling who can access events is still under discussion, with the Lab courting feedback on ideas for how this might be managed.

  • The Lab’s thinking is that there should be two broad categories of events:
    • Public – as in anyone can attend (subject to the payment of any associated access costs)
    • Private – the event is restricted to a defined access list / via invitation for the event host / experience owner only.
  • The above could be expanded  to a more defined set of event types that experience creators might use to define their events (e.g. live music, DJ / Dance, etc.,).
    • This is seen by some as potentially limiting and requiring additional management overhead (maintenance of the central list to suit all needs; experience owners having to resign “allowed” events depending on what they want in an experience at any given time, etc.).
  • There has been a feature request for the Lab to provide event-focused access control lists (ACLs).
    • A single ACL could be used to control access to multiple activities of a similar nature across multiple experiences.
    • Combined with the idea of scene “privacy volumes”, ACLs could be used to control access to content with an experience (e.g. there is a puppet show in the experience, but casual visitors don’t get to see / enter it, as it is within a privacy volume, until they “pay” an entry booth, which then adds their information to the controlling ACL – and they can access all other puppet shows controlled by the same ACL).
  • A counterpoint to this is that if better persistence of data is provided by LL – such as an API to allow experience creators to store data in an external database -, then such “hard-coded” ACLs would not be required, and experience creators could script them.
    • There are questions as to how user-friendly would individually coded access lists be; how would they scale, etc.

Accessing Events and Event Instances

Instances of experiences are capped for the number of users able to access them. No hard limit has been officially defined, although the number is currently around 30, and the Lab has indicated they are aiming to perhaps have 100 avatars active within an individual instance of an experience.

However, when attending events, this does raise questions, including:

  • How can large numbers of people witness a single event?
  • How can people wishing to attend an event together be sure they will be able to access the same instance of that event, and thus share it?

To address the first question, the Lab has already raised the idea of having a “broadcast” or “parent” event.

  • This would be the primary instance of an event (e.g. a live band performing on stage, a presenter on stage addressing and audience, etc.), which broadcasts out to multiple instances of the event as they are spun-up to meet the needs of the audience numbers.
  • Those in the “audience” instances might not be able to communicate into the “parent” instance or directly interact with avatars in other “audience” instances (e.g. dance with them) – but they would see / hear everything going on in the “parent”.
  • There is currently no time frame on when this capability might be introduced.

To address the second question – people being able to access the same instance of an event together – the Lab is looking at various ideas, including:

  • Access based on group size / queuing: people define themselves as a group, and effectively access an event together, allowing them to be sent to the same instance.
  • An “event lobby” system where users can see where they could go in order to be together.
  • The ability for people to directly invite one another into an instance of an experience.
  • Some combination of all of the above.

Monetising Events

The ability to monetise events – particularly events hosted in experiences created by someone other than the event host – is unlikely to occur until the supply chain / licensing system has been deployed. However, some ideas for monetisation that have been put forward include:

  • The ability for people to “rent” experiences built by others for a specific event / specific period of time.
  • The ability to make the “parent” instance of an event a “premium” experience, where people pay extra to be in it and able to interact with the performers / presenter(s) – so they could, for example, ask questions during a presentation.
  • The ability for people to charge subscriptions to events / activities.
  • The ability for event hosts / experience creators to define a specific “event” scene of a public experience.
    • This “event” version could be “reserved” for those paying / allowed to access the event (e.g. a dance, a hunt, a game, etc.), and instanced accordingly.
    • Anyone not paying the admission fee go to a “normal” instance of the experience which does not have the event running within it.
    • However, creation of such an “event scene” of an experience would still count against the creator’s allowed total of published experiences, even if it is effectively a “copy” of an existing published experience (although the scene could obviously be unpublished after the event).
    • A suggestion put forward to offset hitting the cap on the number of published experiences a creator can have, is to allow a creator to pay a nominal fee to have an “extra” experience published for a specified period of time, before it then goes away.

Monetising events touches on the wider aspect of monetising experiences in general, and during the meetings the Lab re-iterated that coming on the roadmap is:

  • The ability for creators to build and sell entire scenes / experiences.
  • The ability to offer direct tips in Sansar Dollars (which encompasses both events and experiences).
    • This is seen as more relevant at this point in time than offering a means to pay wall experiences.
  • Possibly the ability for experience creators to charge people wishing to access their experiences.
    • This does raise the question – as the Lab acknowledges – of how do users gain an assurance that the experience / content is worth paying for in order to view it?

Continue reading “Sansar Product Meetings #10: events in Sansar”

Sansar Product Meetings #9: interactivity

The Wednesday February 28th, 2018 Product Meeting

The following notes are taken from the Sansar Product Meeting held on Wednesday, February 28th. The subject for the meeting was Interactivity in Sansar, although more than this was covered. These notes are an attempt to bring together the key points of discussion from the meeting.

These weekly Product Meetings are open to anyone to attend, are a mix of voice (primarily) and text chat. Dates and times are currently floating, so check the Meet-up Announcements and the Sansar Atlas events sections each week. Official notes, when published can be found here.

Bust a Move Release and Update

  • The Bust a Move (February) release was made subsequent to the meeting, which includes some of the updates indicated in the meeting – these have been noted below.
  • An update to the Bust a Move release was made on Friday, March 2nd, 2018, specifically aimed at fixing the issue of complex Marvelous Designer clothing items exploding briefly when entering cloth simulation mode.

Roadmap Notes – Interactivity

Aleks summarised the following as the key points for interactivity in Sansar the Lab has deployed , or is looking to, deploy and build on, over the coming months.

  • Keyframed motion type: introduced with the Bust a Move release on March 1st, which allows objects to be moved by object animations and certain script API functions.
    • This means that, while they are capable of movement, they are unaffected by gravity, cannot collide with static or keyframed objects, and can collide with dynamic objects and avatars, but are not moved by them.
    • Keyframed objects are useful for creating things like doors, that need to perform a specific motion reliably without adding unnecessary strain to the physics simulation.
    • It is acknowledged by the Lab that “keyframed” in this context is perhaps not the best descriptor for the functionality, and it may be changing to “scripted objects”.
  • A New Dynamic objects flag: used to determine if a dynamic object can be picked up or not.
  • Gravity / Centre of Mass:
    • Initial gravity scaling (0 through 5x “normal”) introduced with the Bust A Move release.This is straight up-and-down gravity.
    • Does not affect animations / locomotion, etc., at this time (a walk in 0 gee will be the same as in 1 gee, for example).
    • Ability to set centre of mass of objects and adjust the mass of objects via script will be coming.
    • Cylindrical and / or spherical gravity are not being worked on at this time.
    • Opens the case for avatar jumping / flying.
  • Friction and bounce controls to be made available for both terrain and objects surfaces. So ice will be slippery, a lead cannon ball many be set so it doesn’t bounce, but a rubber ball does, etc.
  • Scripted object interactions: this will allow creators to define what items  support interactivity, and how users can interact with them.
    • Will likely take the form of some kind of indicator which is visible when a mouse pointer (Desktop Mode) or hand (VR mode) is over the object, perhaps with a little tool-tip outlining the available interaction.
  • Manipulation abilities: the Lab is investigating how best to allow creators to define how items are held (e.g. a rifle and a hammer have different means of being held, one to the other) and for users to manipulate the objects they are holding (left hand? right hand? swapping between hands? etc).
  • Resource containers: objects that can be used to contain all of the sounds or animations or textures or rezzable which might be used in a scene, which can then be called via script as needed.
  • New interaction API: to provide abilities such as touching a button to change the colour or intensity or brightness of a light, or pull a lever, etc.
    • Again such capabilities will be introduced iteratively over time.
  • Scripted animation of textures: the ability to animation multiple textures on a surface, and potentially hook-in to a flipbook of textures.

Persistence Across Sessions

  • The Lab is looking at how to handle data persistence across sessions in Sansar (e.g. progress to date in a quest, or points scored in a game, etc.).
  • It’s not clear if this will be something handled internally with experiences, or by providing experience creators with some form of API, allowing them to create external mechanicals to store such data.
  • Seen as a capability which will be added once more in the way of game creation capabilities have been added to Sansar.


  • Not on the immediate  roadmap, and viewed as a “nice to have”, but not a priority at this point.
  • Are being considered with regards to emotes, e.g. type or say “smile” and a smiley pops up over your avatar or similar.
    • (Quite how this wouldn’t be as “immersion breaking” as having an unobtrusive voice indicator illuminate over an avatar’s head when voice is being used, as some at the lab claim, totally escapes me.)

Scripted Animation

  • Comprehensive scripted controls (start, stop, select a frame, change speed, etc.) for animations (and eventually leveraging the ability for .FBX files to contain multiple animations?) are being developed.
  • Initial work will be to provide scripted access to one animation on an object, rather than being able to control multiple animations.
  • The ability to swap between different sets of animations is acknowledged, but seen as “further out”.
  • This should allow for a range of NPC-style creations which can respond to avatar proximity.

Permissions System / Supply Chain

  • Still being worked on by the Lab.
  • Seen as a “sticking point” for many capabilities  / options within Sansar.
  • Currently prioritised is a script update system.
    • This won’t extend to objects, which will eventually have their own update mechanism.
    • It is not an automated update process (i.e. a new script is released and all previous versions are automatically updated).
  • Overall, the permissions system / supply chain is split into a number of areas, none of which is set for deployment in the near-term.

Performance Improvements

  • Voice is being revised so that when in an experience, only the voice data for those you can hear speaking is sent to the client, rather than voice data for all users in the experience, regardless of whether or not you can hear them.
  • Avatar LODs are also being looked at to help reduce the amount of avatar data being transferred to the client (do you really need to have every single tri in an avatar’s hair rendered when they are 300 metres away?).