2018 Sansar Product Meetings week #1 with audio

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

The January 5th afternoon meeting was attended by Ebbe Altberg, plus Carolyn from he Product Team and David and Sean from the Sansar character team. David has been working on the Marvelous Designer (MD) integration, and he and Sean were able to address questions around fashion, etc. Audio extracts feature Ebbe, David and Sean.

Avatar Notes

• Custom skins: textures are seen as an important aspect of the avatar, allowing age, muscle definition, etc., to be applied. As such, it is something the Lab wants to expand upon. However, the focus at the moment remains on the fashion work, rather than on custom texture uploads and application, and it is down to the product team as to where the latter sits on the roadmap.

• Texture resolutions: It has been noted that the avatar is a 60K polygon body apparently using 512×512 textures. Sean explained that the textures placed on the website aren’t actually the textures used on-line. Rather, an upload limit was hit within the ZenDesk software, forcing the use of lower resolution textures.
• Avatar shapes / customisation: greater avatar customisation (changing height, shape, etc.), is “on the roadmap”. Currently, the focus is on increasing the amount of customisation available with the avatar face, with further bone morphs, work that is seen as “foundational” to adding the ability to customise the rest of the avatar shape.
  • How the facial work will be implemented is an open discussion. Sliders have thus far been used (as with SL), but this can be limiting when other forms of deformation are also applied. Recent games have tended to use a form of pick map for customising facial features – the user clicks on a point of the face (e.g. the cheek), and all the bones affecting that area respond to adjustments with the mouse, rather than having to adjust individual bones with individual sliders – and is mirrored where appropriate (e.g. cheeks, ears, etc.). This result in more natural looks, and is something that is being considered as a way of managing customisation in Sansar.

Fashion / Marvelous Designer

Cloth Physics and Layering

The integration of MD has allowed cloth physics to be used in Sansar – although currently these can only be seen / set within the Avatar App Lookbook (formerly My Looks) when editing an avatar. Cloth physics are actually “built-in” to the patterns exported from MD, with the cloth simulation code from MD being used within the client. This means it is unlikely that designers will be able to use other tools  – such as Blender – with the cloth physics capabilities without using MD as well.

The reason for restricting cloth physics to LookBook for the time being is that simulating cloth movement, etc., in Sansar’s Runtime Mode can generate a considerable performance hit; the Lab therefore want to focus on making  various performance improvements and further Runtime optimisations before they start looking at introducing cloth physics into the Runtime environment.

Currently, garments that are layered in MD (e.g a jacket over a shirt)and are exported to Sansar as a single item have their layering respected within Sansar (so the jacket renders over the shirt. However, individual items using the same layer will not be simulated correctly, and the Lab is working to rectify this. In the future, clothing should be layered relative to the order in which it is added to the avatar. So, for example, if you have a “layer 2” shirt and “layer 2” jeans, wearing the shirt first, then the jeans will result in the shirt appearing to be “tucked in” to the jeans, whereas wearing the jeans first, then the shirt, will result in the shirt appearing to be untucked.

In Brief

• Roughness maps, handled directly by MD are coming into Sansar “too shiny”, requiring creators tweak them manually. This is to be referred back to MD.
• It is currently anticipated that there will be no changes to the weighting / the way the IK rig is painted, etc.

User Engagement and Retention

2018 will see some attention switch away from developing technical capabilities towards broader issues of user engagement and retention.

• Locating people: An upcoming change to the Atlas will allow experiences to be sorted in terms of current usage: those experiences with people currently using them will be listed with the most popular at the top, and then descending to those which are not currently being used.
  • This may be accompanied by a generic indicator that people are using an experience. This will not initially be a physical count of avatars, as there are issues around instancing (e.g. there may be 100+ in an experience, but spread across two or three instances, each with a different number of actual avatars in it – so while the count is 100+, you might be directed to an instance with only 15 other avatars in it).
  • An actual numerical indicator of the number of avatars in an experience might follow in the future.

• 

  Sansar forums blogs, etc: it has finally been recognised that the current tool used for these – ZenDesk – is not well suited to the task (YAY!), although fixing this is not a high priority. There have been internal discussions at the Lab about using the platform and tools employed in creating the Second Life forums, blogs, etc., to build something for Sansar – potentially more as a cost saving opportunity then for the sake of functionality. Frankly, I’m still stunned that this wasn’t the route taken from the start given the Lab have the tools and the experience to use them, which could have been easily leveraged, rather than going for a tool entirely unsuited to the task and which presents information in a very unfriendly – and dare I say amateur – manner.

• Better in-world tools: emphasis will likely be given to providing “in-world” tools for better social interactions among users (e.g. things like group chat / group messaging, etc.).
• Avatar Animations and Interactivity: giving people things to do in Sansar would also help with user retention. This could be as simple as offering basic animations to allow avatar to sit, dance, Animations such as sitting are seen as more complex, for reasons previously noted, unless objects are specifically scripted for handling this;  however, it might be possible for the Lab to implement a simple ground sit.
• Improving the on-boarding process: the sign-up and getting started process is already seen (by the Lab) as a little complicated, so work may be put in on making this more straightforward.

One thing Ebbe indicated would be useful is collective agreements from creators / users on what they feel is needed to help with user retention. That is, not a myriad of individual ideas / suggestions, but a collection of ideas creator have agreed among themselves as perhaps being the most pertinent. While this should initially be geared towards the Lab’s focus of user engagement and retention, it might also include idea that help improve the creation and turn-around of scenes / experiences.

Feedback, Discussion, Engaging with the Lab and Future Meetings

In terms of engaging with the Lab, offering / receiving feedback (including discussing platform limitations / shortfalls)  can also be carried out through Discord, which can also draw other creators into discussions.  At some point in the future, the current meetings within Sansar may be expanded into a similar kind of structure as the SL User Group meetings: product, scripting, characters, engineering, etc.

Inventory – Scene and Avatar

Scene Inventory

The current inventory system in the Edit Mode doesn’t have any real inventory management tools. The have been discussions at the Lab on how to improve inventory & the inventory tools / options (e.g. use of nested folders, etc.). No single approach has been decided upon, but it is still being looked into – however, due to the emphasis on user engagement, it may slip down the priorities list.

Avatar Inventory

Unlike Second Life, Sansar avatars currently do not have a notion of inventory per se when in an experience; attachments and clothing can only be added / removed via the Avatar App – LookBook. This means that at present, an avatar cannot  simply change outfit or wear a gun or other accessory from within an experience – the use must go to LookBook, change the outfit  / add the attachment, then come back – and land at the experience’s spawn point.

From the point of view of games, this is hardly ideal. Options such as an avatar having a “backpack” (whether this would be physical or virtual is unclear) into which items can be placed and used, are being looked at. However, this kind of a solution also has questions around it: should such a backpack be persistent across experiences, so avatars can cross from one to another and retain items in it? Should it only apply to items collected in the current experience? Also, currently, only items from LookBook can only be associated with an avatar if worn / attached – so any notion of being able to “take” items from LookBook and drop them into a “backpack” to carry around experiences would require a considerable about of work – if possible.

Why Build an Engine from Scratch?

Sanasr’s engine is built from scratch, and a frequent question asked is why didn’t the Lab opt for Unity or Unreal as the core engine. Why this is so is a question Ebbe has addressed in the past – such as here, for example, and on which he expanded in the meeting:

Workarounds

A request from the Lab is for creators not to implement workarounds for shortfalls in Sansar’s current capabilities. Doing so can actually cause problems, such as impacting performance which can in turn result in such workarounds being intentionally broken. Where shortfalls are encounter, the engineering team would much rather the issue is written-up through the forums so it can be recorded and formally addressed.

 

Other Items

• Logos / Brand images in store images: some sellers have includes brand logos / images in their Sansar Stores. These are not currently allowed, and the Lab will be contacting those who have done so and asking them to remove the logos.
• In-scene roughness maps: a change in Sansar’s rendering appears to be making objects within a scene using roughness maps to appear unnaturally shiny, forcing creators to make unexpected updates to their experiences.
• Custom terrain texture uploads: these are planned, but are not on the immediate roadmap, particularly as some attention is switching away from technical capabilities within the platform and on to issues of user engagement and retention.
• Experience load progress bar / cancel option: a progress bar to show the progress on loading an experience is coming to Sansar. It has been agreed that a cancel button  – although technically awkward to implement – would also be useful to have, both for users and the Lab  (as it will let them see how many are cancelling experience loads due to long waiting times, etc.).
• Roadmap: long promised, that might now be in a position to be surfaced in some manner. Ebbe explained some of the complications in producing it: