Month: June 2019

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.