Day: August 30, 2019

Sansar Product Meetings week #35: feedback and Q&A

Posted on by Inara Pey

Courtesy of Sansar on YouTube

The following notes were taken from my audio recording of the August 29th (week #35) Sansar Product Meeting, which took the form of a general Q&A  / feedback session. As always, key points are summaries, but please also refer to the official video.

The Nexus Release

The Nexus Release had been anticipated as being deployed this week, but bug fixing derailed the plans for this. This is to now hopefully make an appearance in week #36 (commencing Monday, September 2nd).

Fees / Commission Rates

In October 2018, Linden Lab announced that Sansar’s availability would be extending to the Steam platform at the end of the year, being made available under that platform’s Early Access programme (and which duly occurred in December). As a part the October 2018 announcement, it was indicated that credit processing fees for Sansar Dollars would increase to S$250 to the dollar, with early access creators receiving a legacy conversion rate of S$143 to $1 until December 31st, 2019.

On Wednesday, August 28th, 2019, Linden Lab announced the conversion rate for all early access creators who process credit from Sansar will remain at the S$143 to $1 through until December 31st, 2020 – so a further year’s extension.

Q&A

Nexus, Prime Portal and Codex

  • People will still be able to access their Home Space once the Nexus Release has been deployed

    Will people always have to log-in to the Nexus, once deployed? What about issues of trolling / harassment? Won’t this increase load times – a scene plus all the avatars?

    • Yes, all users (including Lindens) will by default be logged-in to the Nexus (or an instance thereof).
    • The comfort zone controls, muting / blocking abilities will all be available to users.
    • People will still be able to access their Home Space if they wish / need to, and will be able to cancel the Nexus load to go directly to the Home Space at log-in, if they wish.
    • Avatars are also cached, so allowing for cache limits, if there are avatars previously encountered at the Nexus, this could help mitigate additional load time at log-in / a return visit.
    • Load times and interactions within the Nexus will be monitored closely as well, in case adjustments have to be made.
  • Is there a risk that by making people go to the Nexus whenever they want to discover potential destinations they have not yet visited, people will be less inclined to explore?
    • The hope is that no, it won’t, but it will be closely monitored when first deployed.
  • As avatars can impact an experience when first loading in, could the Nexus suffer with lots of avatars constantly logging-in to it?
    • This is a concern and again will be monitored.
    • It is likely that the Nexus will initially have a lower avatar limit prior to spawning a further instance to try to mitigate this (although it is acknowledged this could cause issues with meeting friends in the same instance of the Nexus).
    • Avatar loading has also been moved to a separate thread to try to minimise performance impacts.
  • Do creators have to go through the Nexus to get to their scenes and work on them? If logging-in the Sansar, yes.
    • However, once logged-in to Sansar, all other routes to edit a scene are available and no further visit to the Nexus is required.
  • Will the Codex make visited experiences visible as a single list, or will it have categories, or will something like the top 10 popular experiences out of those visited be listed first?
    • The Codex will just be a searchable list of places a user has visited.
    • The Prime Portal at the Nexus, however, will be more Atlas-like as it will contain all public experiences (aka “worlds”) and have categories, etc., as well as being searchable.
    • In respect of both, the Lab recognises that they will have to look at ways to improve the discoverability of both existing and new content.
  • Will people be able to set their own home location – such as one of their own experiences, rather than having to go to the Nexus or their Home Space? This idea has been noted.

Avatar 2.0 and Avatar Related

  • The reference files for the male avatar are the same as the avatar base shape, so yes, the male avatar does look skinny; the explanation for this that LL are trying to make both female and male avatars similar in shape to allow easy sharing of clothing and accessories between the two (so a shirt for a male avatar should fit a female avatar, for example).
  • The similarity is also to help with body deformation (when that becomes available) – so that the base shape for both avatars has a “common ground” for deformation.
  • The base shape is, apparently, intentionally more stylised than realistic. It has particularly been noted by many, including blogger Ryan Schultz that the female avatar’s proportions are off, which has prompted discussion on the Sansar Discord channel.
    • However, it should be noted that this has long been the case with SL avatars, but deformation, etc., means it is possible for those who want a more realistic shape can have it, while those who want more out-of-proportion shapes (e.g. for an alien or something) can also do so.
  • The avatar 2.0 head / face will have (as previously reported) a series of presets to help users define a particular / preferred look.
    • In addition accessories (e.g. earrings, nose rings, etc.) should move as facial deformation / different presets are used.
    • There will also be a translation / rotation tools to allow accessories to be moved around and positioned.
    • Auto-skinning will be applied to that accessories should automatically follow a part of the face that’s in motion (so a lip ring should follow the lip movements, for example).
  • Will the bounding box for the avatar be increased in size? This is something the Lab is looking at, but no firm commitment to change as yet.
  • Will avatar 2.0 be scalable at release?
    • Uniform scaling, as with avatar 1.0, yes.
    • Non-uniform scaling, no, not until full body deformation is released.
    • Head scaling will be possible separately to the body.
  • Avatar texture caching: there is an ongoing project to improve how avatar textures are handled and cached / logged. The work should be surfacing in one or two near-future releases.
    • An initial element of this will be a cap on per-avatar textures within an experience. Avatars entering the experience with their texture load below the cap will be seen as intended, those over the cap will have textures downsampled to bring them under the limit.
    • This might be extended to be handled on a client basis – so those with more powerful systems can crank the limit up, for example.
  • Will avatar 2.0 have a user-adjustable height offset to prevent feet / shoes appearing to sink into the ground? Not currently planned. If there are significant issues, test cases should be forwarded to the Lab to see if adjustments to the IK system are required.

General Q&A

  • The usual five:
    • High heels for avatars: not on the roadmap at present.
    • 3D mouse support: not on the roadmap, will more likely be a general project to support game pads, joysticks, etc., if done.
    • Valve Index support: something the Lab wants, but no time frame, other than when the Lab get to work on it, it is estimated to be around 2-3 weeks of work.
    • Wiki: the more user-submitted guides that are made to the forum public documentation area, the more weight is given to the case for the Lab creating and offering / managing a wiki.
    • Persistence: the Sansar devs would love documented requirements on where and how persistence might be needed / used, particularly as persistence is under consideration at the moment.
  • Collaborative building in Sansar plus the ability to build experiences for others:
    • Collaborative building within a single space still very much on the cards. Is still a question of when the Lab can get to it, and also how to manage the permissions (who can do what within the scene).
    • Building for others is seen as something the Lab also want to make possible – with creators able to build scenes or entire experiences and making them available through the Sansar Store to others – but again, no time frame on when this will happen.
  • Moderation within an experience (e.g. giving the ability to provide others with the ability to ban people from a scene, to administer / manage it on behalf of the owner, etc). Also on the roadmap, but no overall time-frame.
  • Vehicles:
    • Something the Lab would like to do, but there are complexities: how is control of a vehicle subscribed? How to provide a good level of responsiveness to vehicle handling through the scripting system, etc.
    • Initially, what is being proposed is more “remote control” style vehicles, operating at lower speeds – presumably rideable, rather than just mini RC cars and things.
  • Event related:
    • Will the ticketing system be exposed to creators, and will creators be able to use it to charge for entry to events?
      • No plans to expose the ticketing system or allow creators to change for events (both of which appear to be a change from past statements).
      • Major reason cited is complexity of transactional management and tracking between users.
      • Suggestions for potential ticketed events (paid or unpaid) should be proposed to Linden Lab.
    • Can event creators have access to the number of people who register interest in an event (e.g. to help determine it date / times need to be revised in future similar events if 50 register interest and only 6 show up)? Yes, this has been considered by the Lab, along with other events improvements; it’s just a case of when and how things will be tweaked.
    • Can there be special LL-derived physical world prizes (e.g. “Sansar Early Access” t-shirts, etc.), people can win, so helping encourage engagement and involvement in events within Sansar – and help promote the platform? Will be taken into consideration.
  • Why is there an option to set a re-sale price for clothing when we cannot actually allow others to re-sell it? Because the capability hasn’t been released, and requires the on-going work in integrating the permissions system with the avatar system – but the ability to allow re-sale is coming.

The PrimPossible 1 LI Bento Piano

Posted on by Inara Pey
The PrimPossible Bento Mo-Cap 1LI Piano, shown in the built-in white finish option

Ample Clarity, the owner of the PrimPossible brand, made his mark producing 1-prim household items, initially using sculpties (not good for rendering, etc., but nevertheless impressive for their time for those pushed for LI) and more recently for doing much of the same with mesh. He’s well aware of my fondness for the piano, and so recently sent me a beta version of his new 1 LI mesh Bento baby grand piano featuring a selection of motion captured animations, and I decided I’d take it for a quick spin.

I cannot speak to the packaging of the piano, as it was delivered to me unboxed. However, in terms of shape and styling, it follows the expected form for a grand, and rezzes with the lid open and music stand raised. The former will tend to close when an avatar sits on the stool, but typing “open lid” (no quotes required when typing) in open chat will set it open once more.

Given this is pretty much a single mesh, there are some elements that can catch the eye a little: the curves of the housing rim perhaps aren’t as smooth as seen on other piano models; the detailing of the soundboard / plate / strings is a little basic compared to other piano models I’ve tried (but also better than others). Certainly, the keys and nicely raised and the texturing of the ivory gives them something of a look of having been used, rather than appearing utterly pristine – a touch I appreciate in my SL pianos.

The PrimPossible Bento Mo-Cap 1LI Piano, shown in the built-in white finish

Sitting at the piano will open the main menu, the top level of which provides access to the piano’s impressively broad range of animations. Depending on which animations are available, depends on whether you have the Adult or PG variant. For the PG variant, which I have, the animations are broken down into the following categories / sub-menus:

  • Bento: general single (male or female avatar) and couples sitting animations than make use of Bento animations. This can place avatars on or around the piano in a variety of animated poses.
  • Non-Bento: similar to the above in terms of general sits / cuddle, but also with non-Bento piano playing animations (female, male and duets), and a selection of “friends” animations that again place avatars in poses for chatting, etc., around or on the piano.
  • Bento piano: a set of four playing styles created for Bento hands and finger movements.
  • Bento Mo-Cap: as set of single and duet playing styles for Bento hands and created using motion capture software.

The Bento piano animations offer sufficient range for playing most of the pieces of music included in the piano, with Piano Boss adding a little athletic fun to the start of any playing for those so inclined! The Mo-Cap options (two single pianist options for “standard” and “tall” avatars, plus three duet pairs) are, like the Bento animations, fluid, and offer perhaps a more natural placement of hands whilst playing (as they have been motion captured).

Bento hand animations

A total of 24 pieces of music are supplied, the majority of them classical and public domain (Ernest Gold’s theme from Exodus would have entered public domain in 2017, had it not been for the 1978 change to US copyright laws….). Accessible through the Extras > Music Menu option, these are a familiar and popular selection – Bach, Beethoven, Brahms, Grieg, Mendelssohn, Satie, etc., – with a touch of Gershwin.

The music menu includes a Start / Stop option (so you can play the piano sans music, if you have music playing over the stream, etc.), plus options for selecting / playing / looping pieces, and for adjusting the piano’s internal playback volume. I confess that some of the pieces seemed to suffer in places from recording levels perhaps being set too high, with a – to my ears at least – a noticeable distortion.

When playing music, it is also possible to alter the playing animation to better match the piece selected, if desired, and the duets options offer a nice sense of shared moments, although having a couple of additional pieces obviously suited to duet play might be nice. For those who enjoy their piano to play by itself, this is possible: simply use the music menu to select the music and play mode and then click Play (if the piano isn’t already playing). You can do this either whilst seated at the piano or with a touch to bring up the menu when standing.

Also included in the menu are options to set permissions on who can use it (owner, group or anyone), plus texturing options and to adjust the level of shine, the ability to set it to phantom (and avoid bouncing into the air when standing up!), and to adjust your sitting position. The latter brings out one of the little niggles I have with all pianos that have both the instrument and the stool as a single item: as the stool is “fixed” relative to the piano, I never can quite get my avatar to what I feel is the optimal position for playing.

A final thing to note about this piano is the LI. The single LI count of the piano applies to when it is not in use; as soon as an avatar sits at the piano, the LI count will increase to 3. This is necessary due to the nature of SL and sit targets: the PrimPossible piano requires an additional (and invisible) “shell” to be rezzed with it in order for avatars to be correctly sit targeted. This shell is automatically deleted when the piano is not in use, returning it to the advertised 1 LI.  So, if you opt for this piano, do keep this in mind should you note the LI count changing – it’s not an issue / error.

Under the lid, the detailing is perhaps a little limited compared to some other piano makes, but at least as good as others – and remember, this is a single LI mesh object

The PrimPossible Bento piano is available in four versions and price points:

  • No Copy, Mod or Transfer PG at L$800 or Adult at L$950.
  • Copy, No Mod / Transfer PG at L$2,000 or Adult at L$2,400.

These prices are also listed as being “introductory beta”, and I understand that further animations and Mo-Caps will be added over the coming months. Even so, when comparing the L$2,000 price tag for the Copy version to something like the Culprit Sonata Bento Baby Grand (supplied Copy, No Mod / Transfer, and which I reviewed in March 2019), that’s a hefty difference should you be in need of a Copy version of a piano. Were I to give a very quick, high-level contrast between the PrimPossible and the Culprit it would be:

  • PrimPossible lower rendering and server costs (4576 and 1.0 respectively), lower LI (1 or 3), but fewer music options (24) and playing styles (for the present). Includes non-playing animations.
  • Culprit: higher LI (11) with a higher level of detail (particularly the soundboard / plate / strings / hammers  / dampeners), more music options (56) and playing styles. Higher rendering / server costs (8561 and 10.7 respectively).
The PrimPossible Bento Mo-Cap 1LI Piano

As it is, the Culprit wins out for me for general home display / use. I find the playing styles more varied (and some more reflective of piano playing techniques) – although it’ll be interesting to see what else is added to the PrimPossible model as the beta progresses. As someone who loves the grand piano, I also appreciate the amount of work put into the Culprit’s “innards”, and I’m not sure I like seeing one clambered all over / sat on, so the additional sitting animations in the PrimPossible model, while potentially fun, hold no real appeal here.

For those who might be pushed for LI, and given more is to come with the PrimPossible piano, it is certainly worth a look and consideration, given the range of prices and the additional animations. As it is, the PrimPossible has been added to my Linden Home houseboat (where it will admittedly be more decorative than functional), where it looks quite at home.

Links

2019 SL User Groups 35/2: Content Creation summary

Posted on by Inara Pey
(fae forest), July 2019 – blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on Thursday, August 29th 2019 at 13:00 SLT. These meetings are chaired by Vir Linden, and agenda notes, meeting SLurl, etc, are usually available on the Content Creation User Group wiki page.

Bakes on Mesh

Project Summary

Extending the current avatar baking service to allow wearable textures (skins, tattoos, clothing) to be applied directly to mesh bodies and heads. This involves viewer and server-side changes, including updating the Bake Service to support 1024×1024 textures, but does not include normal or specular map support, as these are not part of the existing Bake Service, nor are they recognised as system wearables. Adding materials support may be considered in the future.

Resources

Current Status

  • BoM is now live. See:
  • There are some local edit issues  – some already noted in the viewer release notes – that can produce odd results when using the appearance editor which correct themselves on exiting the appearance editor and when baked via the Baking Service.
Cathy Foil has noted this glitch than can occur with Baked_Lower wearables on BOM: when editing locally in the appearance editor, the leg does not appear to be masked correctly by the wearable (which is also incomplete at the waist). Once baked, however, the wearable appears correctly applied and in full (r). Credit: Cathy Foil.
  • Some of these local edit issues may not be specific to Bakes on Mesh, but may be more noticeable as a result of BoM, and the Lab is looking to resolve them.

Animesh Follow-On – Project Muscadine

Project Summary

Currently: offer the means to change an Animesh size parameters via LSL.

Current Status

  • The simulator support on Aditi (the beta grid) – DRTSIM-421 (region Bakes on Mesh) has been updated, but there are no feature changes within it.
  • The project viewer has been merged with Bakes on Mesh (as the release viewer) and is passing through the Lab’s QA, and so should be appearing soon.

ARCTan

Project Summary

An attempt to re-evaluate object and avatar rendering costs to make them more reflective of the actual impact of rendering both. The overall aim is to try to correct some inherent negative incentives for creating optimised content (e.g. with regards to generating LOD models with mesh), and to update the calculations to reflect current resource constraints, rather than basing them on outdated constraints (e.g. graphics systems, network capabilities, etc).

Current Status

  • Work has now resumed.
  • First part of this is to continue data-gathering and look at re-aligning some figures based on the changes made for Animesh.
  • Thus far, the project primarily comprises enhanced logging to assist the Lab in data collection, allowing information on the overall cost of a specific avatar or in-world object to be gathered.
  • Once enough data has been gathered across a broader enough spectrum of content to give the Lab confidence they have a good understanding of things, then work can start on adjusting the cost calculations for rendering, etc.
  • It’s important to note that any user-viewable changes as a result of ARCTan are still some way off, and the Lab will be staging things to let users know what is happening when, and what it is likely to impact.
  • There was a lot of general conversation towards the end of the meeting on what people hope ARCTan will do (e.g. forcing creators to make proper use of avatar LODs, etc.).

Environment Enhancement Project

Project Summary

A set of environmental enhancements (e.g. the sky, sun, moon, clouds, and water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. It uses a new set of inventory assets (Sky, Water, Day), and includes the ability to use custom Sun, Moon and cloud textures. The assets can be stored in inventory and traded through the Marketplace / exchanged with others, and can additionally be used in experiences.

Due to performance issues, the initial implementation of EEP will now likely not include certain atmospherics such as crepuscular rays (“God rays”).

Resources

Current Status

  • Work continues on rendering bug fixes.
  • The number of remaining issues is “trending downwards”.

Misc. Items

  • The upcoming Voice RC (or project) viewer mentioned at the last TPVD meeting still has a couple of issues preventing it from surfacing in the Alternative Viewers page.
  • The Umeshu Maintenance viewer (currently version 6.3.1.530411, merged with Bakes on Mesh) could be promoted to de facto release status as early as week #36 (commencing Monday, September 2nd), in a break from the Lab’s preferred 2-week gap between release promotions.
  • Date of next meeting: Thursday, September 12th, 2019.