Sansar product meetings 2017: week #36 – Aug/Sept release

People gather at Astro Port for the first Friday September 8th 2017 Product meeting

The following notes are taken from the Sansar Product Meetings held on Friday, September 8th. These meetings are held every Friday at 09:30 PTD and 16:00 PTD, and are open to all.

There is no set agenda (currently), and the meetings are a mix of voice and text. Venues change on a weekly basis, and are announced in the Meet-up Announcements. The September 9th meeting took place at Mold3D’s Astro Port. The official meeting notes are generally published the week following each pair of meetings.

The meetings are chaired by Jenn (aka Xiola Linden) from the Community Team, and feature various members of the Sansar teams. Cara, Carolyn and Jeremy joined the Friday, September 8th meeting.

August / September Release

The long-awaited August / September release arrived on Friday, September 8th, 2017. Highlights of the release are noted  below (please refer to the release notes for full details of this release, including known issues). Note that many of these features are still work in progress, rather than being final / polished versions.

Terrain Editor / Sculpting

Experience creators can now edit terrain objects in Sansar: create mountains and hills, create dips, craters and valleys or uneven terrain (“noise”). This is the first iteration of these tools, and features will be added over time.

Simply drag and drop a terrain plain (in one of four texture defaults) from the system objects panel, then use the sculpt tool and options to shape it. Individual plains can be placed together to create as big an area of terrain as required (within Sansar’s own limitations).

See Working with terrain in the Sansar Knowledge Base for more information.

The Terrain toolbar with the sculpt and paint master controls highlighted, and option buttons to their right
  • Terrain plains can be sculpted on in defined areas, from around 32 metres on a side up to 256 metres on a side.
  • The paint tool can be used to apply textures (from pre-set families of four) to the sculpted terrain, with automatic attempts made to blend textures with height / depth (e.g. so grass gradually gives way to rock). The brush size for painting can also be varied in size from (approximately) one metre in size upwards.
  • The textures / materials associated with the editor are currently limited to only working with one family of four textures / materials at a time, although creators can hot swap between them.
  • This is not voxel editing, and is currently restricted to height maps, so no tunnelling into terrain at present. The sculpting tool is somewhat similar in approach somewhat similar to the Second Life terraforming tool, presenting a view of the terrain and the selected tool overlaid on it at the appropriate size, although unlike SL a choice of tool shapes is offered (round or square).
A terrain plain show a raw sculpt of a hill (left), and with smoothing being applied (right). Credit: Jeremy Linden
Future Terrain Editing Capabilities

The ability to add use custom terrain textures and height maps is coming soon, together with support for mega textures. The latter will allow more textures to be blended together at a time, which are then  composited together when an experience is published.

Jason (aka Widely Linden) indicated that the roadmap for terrain editing in Sansar currently includes (exact implementation still TBD):

  • A hybrid form of terraforming, using height maps for efficiency when sculpting the terrain, then switching to a voxel element when creating tunnels / caves, etc., which is then “stitched” into the mesh height map.
  • The ability to “geo-paint” environments – use a painting technique to add boulder, rocks, vegetation, etc., onto a terrain map. This will likely start with pre-defined geo elements, before moving to allow users to define their own elements.

A suggestion from Maxwell Graf to assist in making custom height maps (once they can be imported), is to consider installing Unreal or Unity (both free) and then purchasing a terrain editing tool for the relevant engine, and using that to create terrains, then export the height maps for import into Sansar (once possible) It was also noted that Visual Studio 2017 comes with Unity support, and it is easy to add Unreal support.

.OBJ File Format, Animated & Multi-part Object Import

The Animated objects capability isn’t, at this point, fully animated mesh – there is no ability to import or use a skeleton for an object (a-la SL’s animated objects project), although this is coming.

Future Capabilities / Ideas

Also coming in a future release for animated / multi-part objects, are collision meshes. These will allow can be bound to rendered meshes for collision purposes. So a multi-part cable car could have collisions enabled on specific parts to allow avatars to ride it. This has already been done as a test with the gondolas in Colossus Rising.

The cable car gondolas in Colossus Rising demonstrate how collision volumes can be bound to a rendered mesh object to allow interaction (in this case riding a gondola) with an avatar. This ability will be part of a future update to the animated / multi-part objects capability forming part of the August / September Sansar release

Jason indicated that – further into the future, and via a scripted / API meachanism which the Sansar product team is considering – animated objects should allow for very dynamic things like trees which not only sway in a breeze, but which move in accordance with the (changing) wind direction / force (rather than just randomly moving) or stop swaying if there is no wind. The same scripts will also be able to trigger associated sounds of the wind in the branches when affected by a breeze.

New Stereoscopic Media & UV Animation Shaders

A series of new shaders in the materials editor:

  • Standard + Emissive + Stereographic
  • Media Surface + Stereographic
  • Standard + Emissive + UV Animation
  • Standard + Alpha Mask + UV Animation.

UV animation supports both scrolling UVs and flipbook UV, and brings the ability to animate things like water, animated lighting, etc, in Sansar. Currently, these have to be configured and applied prior to upload, but future updates will allow editing and refinement of the maps post-upload.

Trigger Volumes

Trigger volumes allow scripted events (e.g. teleporting) without the need for dynamic objects, allowing for more flexible interactions inside events.

Continue reading “Sansar product meetings 2017: week #36 – Aug/Sept release”

Advertisements

SL project updates week 36/2: TPV Dev meeting + SL in the cloud

Brand New Colony; Inara Pey, September 2017, on FlickrBrand New Colonyblog post

Updated to reflect the release of the Wolfpack RC, which appeared after this article had been uploaded for publishing.

The majority of the notes in this update are taken from the TPV Developer meeting held on Friday, September 8th 2017. The video of that meeting is embedded at the end of this update, my thanks as always to North for recording and providing it. Timestamps in the text below will open the video in a separate window at the relevant point for those wishing to listen to the discussions.

Server Deployments Week #36 – Recap

Please refer to the deployment notice for the week for latest updates and news.

Region Return Issues

Whether connected to the Wednesday deployment or the grid-wide issues experienced later that day, but some regions reported significant returns of in-world objects (Mother Road, on the Main (SLS) channel, which I blogged about here, suffered the problem, as Heavenly Views (Magnum RC) also apparently did). Most of these problems seem to have been rectified by a roll-back of the affected regions.

SL Viewer

A new RC viewer, codenamed Wolfpack – version 5.0.8.328879 – was released late on September 8th. This viewer is functionally identical to the release viewer, but includes additional back-end logging to “help catch some squirrelly issues”.

[1:15-4:15] Otherwise have been no further viewer updates since the start of the week, leaving the current pipeline as follows:

  • Current Release version 5.0.7.328060, dated August 9, promoted August 23 – formerly the Maintenance RC
  • RC viewers:
    • Alex Ivy 64-bit RC viewer version 5.1.0.508209, dated September 5th
    • Voice RC viewer updated version 5.0.8.328552, dated September 1st
    • Maintenance RC viewer version 5.0.8.328812, dated August 31st
  • Project viewers:
  • Obsolete platform viewer version 3.7.28.300847, dated May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

The Alex Ivy and Voice updates bring these RCs into parity with the current release viewer. These updates have lowered the overall crash rates for both viewers, although the Voice viewer’s crash rate is still somewhat elevated compared to the release viewer. This elevated crash rate is something the Lab has seen in the various viewers for the last few months, and are working to lower.

Alex Ivy will likely have two more RC releases before it is ready for promotion to de facto release status, as there are a couple of issues the Lab wants to clear up before any promotion of this viewer.

It is hoped work will shortly be resuming on the 360-degree snapshot viewer, part of which will also be bringing it up to parity with more recent releases.

New Viewer Splash / Log-in Screen

[4:25-8:07] The Lab is in the process of revamping the official viewer’s splash / log-in screen. This should be inherited automatically by those TPVs using the Lab’s splash screen. This will see the screen have a different look and feel, with the information arranged a little differently, with the grid status made somewhat more prominent. Some of the information widgets associated with the splash screen are also being updated as a part of this work, and will require testing by TPVs when available (RSS feeds should not be affected).

This work is being carried out by Phronimos Linden, one of the more recent (3 months ago at the time of writing) Lab staff recruited to work on Second Life.

Moving to the Cloud

[15:52-25:25] As confirmed in a recent Lab blog post, Second Life services are moving to the cloud. There are no specific details on this as yet, but in short:

  • The work will be carried out in stages.
  • It will include providing regions from the cloud (rather than the Lab’s own co-located servers).
  • As many know, the asset services has been in S3 cloud servers for several years.
  • The order of moving services hasn’t been determined as yet, but the aim will be to move services, then test for reliability and performance before opening them up / moving to the next service(s).
  • Some testing has already begun, using services only accessed indirectly by users.
  • The Lab has been working on the infrastructure for this for a while, but none of the major services have been moved.

It is unlikely this will lead to regions of a different size to those presently on the grid, or which can be varied in size (a-la the OpenSim varregions), as region size is very deeply baked into the simulator and viewer code (and probably elsewhere in the overall SL code base); although some at the Lab would love to be able to have such a region capability. However – as indicated in the Lab’s blog post – it may allow the Lab to introduce new region products, possibly ones capable of handling greater loads.

It is hoped that this work will result in lower tier over time, but whether this will be the case of not is still and open question at this time, as it is unclear as to what costs will be involved in terms of cloud instance types., etc., that will be required to support simulators.

Overall, there is a lot the Lab hopes to achieve with the move, but the precise benefits are likely to only become clear once things have been tried and found to work / over time as the work progresses and beyond. However, at this point time scales are TBD, and it is liable to be some time before user-visible aspects of the service move to the cloud (although non-visible services – such as the log-in service, for example – could be moved sooner).

A precursor to this project is the continuing work to update the servers to newer version of Linux, work which is making “good progress”.

Other Items

Asset HTTP Messaging and Asset HTTP Issues

[10:11-10:45 and 12:10-15:23] With the promotion of the Asset HTTP viewer to release status in June 2017, the majority of assets are now delivered to the viewer using HTTP via the Content Delivery Network(s) used by the Lab. This means that UDP messaging for all of the affected asset types will be turned off at the server end at some point.  Currently no date has been set for this, and it looks like it may not occur much before February 2018.

There is still an issue related to fetching assets over HTTP in general which is experienced by some users some of the time   whereby something causes the pipeline textures to get out of sync and things to go awry. As the problem happens for some and not others, the Lab is still trying to determine the root cause for the problem, but it is a matter the Lab is trying to resolve.

Catznip viewer reports issues with textures over HTTP “stalling” for between 5-10 minutes on their pre-release viewer with the latest HTTP updates, but this isn’t something the Lab is aware of as a more general issue.

Estate Tool Ban List Improvements

[10:48-11:43] The Lab did some initial work to improve ban lists at the estate / region level a while ago, but the intended work to improvement to overall layout for the lists, etc., has been delayed do to work on dealing with viewer crashes, etc. This work is apparently now “next in line” once some of the existing viewer projects are shipped.

The conversation from 26 minutes to the end is more general chat on viewer stats, speculation on the reason for the texture load stalls, and an ad for the Firestorm birthday party.