2018 SL project updates 21/2: Content Creator User Group

La Clef des Champs; Inara Pey, May 2018, on FlickrLa Clef des Champsblog post

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

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Current Status

  • Work is continuing on moving towards a main (Agni) grid deployment of the server-side code to support Animesh.
  • Everything has been through QA, and there is a remaining issue with validating attachments. This is liable to require an additional fix.
  • It is likely that the simulator code will initially be deployed grid-wide on the beta (Aditi) grid for a shakedown period, prior to starting its deployment to the main grid through the usual process of RC deployments ahead of a full deployment.
  • There are still a number of issues that are TBD within the viewer:
    • Broken Rotations Issue: two potentially related problems.
      • In one (BUG-139251), when some static mesh objects are converted to Animesh, the visual mesh is rotated through 90 degrees when seen in the Animesh viewer, but the physics mesh isn’t, leaving it perpendicular to the model. This is possibly an orientation issue, with the viewer expecting the mesh to be aligned to +x=forward – which not all mesh modelling tools follow.
      • The second problem is that when linking a series of objects into a single Animesh, visually located where the avatar skeleton supporting it is located, but the physics shapes remain in the original location of the objects prior to linking / converting.
      • What is to be done about this still hasn’t been determined, although the Lab has been playing with playing the physics shape in the root of the object.
    • Rigged Mesh Level of Detail / Bounding Box Issues: (BUG-214736) – Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. Graham linden has been working on some fixes for this which should improve accuracy and performance, but further work may be required. Once this has happened, there will be a further update to the project viewer.

Additional Animesh Discussions

  • Animesh Complexity: there is a further update to come to the Animesh complexity values (Advanced menu > Performance Tools > Show Avatar Complexity – applies to both avatars and Animesh objects in the project viewer). This should fix some inconsistencies in the reported values.
  • Animesh updated limits and cost formulas discussions:
    • Land Impact: streaming cost: some have questioned with some question with the 50% bounding on LODs could be more stringent. Vir’s view is that 50% is sufficient to allow for a broad range of capabilities among creators, and being more stringent could simply result in a greater addition to land impact, which could affect the use of Animesh. There is an argument that some models require 75% bounding between the high and medium models.
    • Triangle count limit: There have been requests for further changes to the triangle count limit (e.g. allowing land owners to somehow be able to change it). As the limit was raised to 100,000, it is unlikely to be changed again before Animesh is deployed, and the idea of land owners being able to adjust it is seen as potentially in inconsistencies in how Animesh works in different locations. If it is seen that there is a need to raise the tri count limit, it will be done globally.
    • Avatar attachments: due to performance concerns, the limit of only one Animesh attachment to an avatar at any given time is not going to be changed ahead of Animesh deployment, but might be revisited in the future.
  • Animesh ignores SL scale settings:  this is a result of how rigged meshes are handled – scaling doesn’t matter for worn mesh items, as other mechanisms are available for avatar scaling (e.g. the shape sliders, etc.). As these mechanisms aren’t available for Animesh in the initial release (e.g. there is no actual body shape associated with Animesh objects, ergo, no sliders), scaling is dependent upon custom joint positions.
    • Including more capabilities, such as possibly associating a body shape with an Animesh object, is seen as being a follow-on project to come some time after the initial release.

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 as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Additional Bake Channels

Anchor Linden is continuing to work on adding five further channels to the Bake Service (left arm, left foot + three additional “general purpose” channels to be defined and used as required by creators) and the associated tattoo layer UI support to the viewer to allow them to be used.

This is a three-way set of updates, requiring changes to the appearance service, the simulator and the viewer. This, combined with concerns over maintaining backwards compatibility in the appearance service means that getting the work to a testable state is taking a little longer to achieve.

In the meantime, the changes to the appearance service seem to have caused a glitch which can make some avatars appear to be wear “black skirts” when seen on the Animesh test regions Aditi. This will hopefully be corrected soon.

In Brief

Transparency shadow casting from rigged items: there is an issue with rigged / static meshes using transparencies (blended or masked), which causes shadows cast by them to render incorrectly (shadow rendering conforms only to the geometry silhouette).

Graham Linden is now looking at the issue, however, the release of Animesh is not contingency on the basis of any fix, which will probably be part of the ongoing rendering updates Graham is working on.

Rigged / static meshes using transparencies (blended or masked) tend to cast an incorrect shadow

Imposter Clipping: imposter avatars can appear “clipped”. This appears to be related to the problem of not having a good real-time bounding box associated with rigged meshes (which can result in some meshes appearing clipped as well). This is being looked at, and the hope is that if a better means of defining the bounding box for rigged meshes can be found, it will resolve the importer issue. However, the release of things like Animesh are again not contingent on a fix for this issue being implemented.

 

Advertisements

2018 SL project updates 21/1: Simulator User Group meeting

The Shire; Inara Pey, May 2018, on FlickrThe Shireblog post

It’s a quiet start to the week.

Server Deployments for week #21

There are no server deployments planned for week #21! To quote Mazidox Linden in the server deployment thread:

Hey everyone! We’ve got a bunch of things we’re still testing this week and don’t have any rolls for any channels (Second Life Server, RC Bluesteel, RC LeTigre, RC Magnum, or RC Cruller), and we don’t anticipate any rolling restarts. We’re aiming to have at least one new server version through testing by next week, and hopefully we’ll have a better view of that by Thursday. If you’re interested please join us at the SBUG meeting on Aditi.

RC Cruller is likely one of the smaller RC selections (like Snack and Cake), and is apparently named for the small cake made of rich dough twisted or curled and fried in deep fat (I can feel my arteries hardening just typing that!).

SL Viewer

The Ouzo Maintenance viewer, version 5.1.4.515016, was promoted to the de facto release viewer in week #20. As a result:

  • The Love Me Render RC viewer containing rendering fixes and improvements updated to version 5.1.5.515528 on May 22nd, 2018.
  • A new Maintenance RC viewer, code-named Pálinka, after the traditional fruit brandy popular in Central Europe, was release on May 21st, 2018. Maintenance RC 5.1.5.515527 contains some 36 fixes and improvements, as specified in the release notes.

Outside of these updates, the viewer pipelines are as follows:

  • Current Release version 5.1.4.515016, dated May 7, promoted May 16 – formerly the Ouzo Release Candidate.
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

2018 viewer release summaries week #20

Logos representative only and should not be seen as an endorsement / preference / recommendation

Updates for the week ending Sunday, May 20th

This summary is generally published on every Monday, and is a list of SL viewer / client releases (official and TPV) made during the previous week. When reading it, please note:

  • It is based on my Current Viewer Releases Page, a list of all Second Life viewers and clients that are in popular use (and of which I am aware), and which are recognised as adhering to the TPV Policy. This page includes comprehensive links to download pages, blog notes, release notes, etc., as well as links to any / all reviews of specific viewers / clients made within this blog.
  • By its nature, this summary presented here will always be in arrears, please refer to the Current Viewer Release Page for more up-to-date information.
  • Note that test viewers, preview / beta viewers / nightly builds are not recorded in these summaries.

Official LL Viewers

LL Viewer Resources

Third-party Viewers

V5-style

V1-style

  • No Updates.

Mobile / Other Clients

  • No updates.

Additional TPV Resources

Related Links

2018 SL project updates 20/2: Content Creator User Group w/audio

Bay of Dreams; Inara Pey, April 2018, on FlickrBay of Dreams – Blog post

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, May 17th, 2018 at 13:00 SLT.  The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Audio extracts from the meeting are included, where relevant. Please note, however, that Vir’s microphone occasionally seemed to cut out while I was recording, so some of his comments may sound a little choppy.

Animesh

Project Summary

The goal of this project is to provide a means of animating rigged mesh objects using the avatar skeleton, in whole or in part, to provide things like independently moveable pets / creatures, and animated scenery features via scripted animation. It involves both viewer and server-side changes.

Project Viewer

The Animesh project viewer was updated on Tuesday, May 15th to version 5.1.4.515420. This update comprises:

  • Bug fixes, including improved handling of animation notifications which should result in fewer cases of animations failing to display for some Animesh objects.
  • New checks on when a skeleton is needed for a nominally Animesh object  – now one should be present only when the linkset contains at least one rigged mesh, and this should update correctly when link/unlink operations take place, or other state changes.
  • The ARC calculations for animesh objects has also been updated based on some feedback with the previous build.

Alongside of this there has been a simulator update in support of some of the changes in the viewer (e.g. with regard to animation notifications and updates). Also, to help with persistent across things like region crossings and region restarts, animation information is now stored in the state of the Animesh object itself, when it gets serialised. However, there are reports the animation data is lost on a SHIFT-copy action.

Server-Side Work

As well as the simulator updates for Animesh mentioned above, the Lab is continuing with QA work on server-side support for Animesh to prepare it for deployment to the main (Agni) grid. However, no ETA as yet for the server-side code.

Remaining Major Issues

Rigged Mesh Level of Detail / Bounding Box Issues:This has been the subject of several recent CCUG report in these pages, and is the subject of BUG-214736. Essentially, attachments on avatars swap their LOD models as if they were scaled to the overall avatar bounding box. For example, if an avatar bounding box is forced to 15 metres on a side, any rigged object worn by that avatar will swap LODs as if it were 15 metres in size, no matter how small, forcing viewers around it to use its highest LOD model unnecessarily.

Investigations had led to questions in the Lab of how to get things to behave correctly while recognising there may be broader performance issue that need to be addressed. So Graham Linden has been trying to make sense of what might be pulled into the current Animesh project to improve things and what might require a deeper dive into performance in general as a separate piece of work. So at present this remains in the category of “to be determined” in terms of moving to making Animesh available on the main grid.

Joint Offset Constraints: It’s been noted that setting (deliberately or accidentally) a bad joint offset with something like the mPelvis bound can result in undesired results (the cited example is an Animesh test bear on Aditi appearing to stand 75 metres off the ground when not animating). This has led the Lab to consider constraining he distance a joint can be offset to no more than 5 metres for Animesh objects. However, as this is recognised that doing so could break existing content, a more elaborate solution is still being investigated by the Lab.

Adjacent Regions and Animesh Animations: There is an issue where Animesh objects in adjacent regions fail to animate from a avatar’s perspective when someone logs-in. This is thought to be a handshaking / viewer update issue. Essentially, it can take up to a minute for adjacent regions to understand an agent (avatar) in another region can “see” objects within it, and needs to start sending animation updates to the viewer controlling that avatar.

90-degree Rotation Issue: It’s been noted that when converting some static mesh objects to Animesh, the visual mesh appears rotated through 90 degrees when seen in the Animesh viewer. However, the physics mesh doesn’t have the same rotation applied, leaving it perpendicular to the visible mesh – see BUG-139251.

This appears to be related to the fact that the viewer expects the mesh to be aligned to +x=forward – whereas mesh creation tools such as Blender and Maya don’t – by default – use the same orientation. As the issue only affects some mesh (and in theory could be corrected by setting the required rotation in mesh building tools), Vir asked the question if this is something that should be addressed in the viewer.

  • If this issue isn’t addressed in the viewer (which is where it manifests), it potentially means a good proportion of existing content which might otherwise be converted to Animesh will exhibit the same issue when associated with an avatar skeleton, possibly eliminating it from use as Animesh.
  • If the issue is to be addressed in the viewer, the problem is how to apply the logic to ensure mesh items which don’t exhibit the physics rotation issue don’t end up exhibiting the issue as a result of the fix being incorrectly applied.

Z-Axis offset un the Mesh Uploader: This currently doesn’t work when a  skeleton is applied to a mesh object.

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 as well as system avatars. This involves server-side changes, including updating the baking service to support 1024×1024 textures, and may in time lead to a reduction in the complexity of mesh avatar bodies and heads.

This work does not include normal or specular map support, as these are not part of the existing baking service.

Resources

Additional Bake Channels

Anchor Linden is investigating adding further channels to the Bake Service in addition to those recently added, again specifically for use with Bakes on Meshes (they will not work with the system avatar). These will hopefully comprise:

  • Separate channels for the left arm and left (currently these are mirrored from the avatar’s right side) to allow for asymmetrical avatar options.
  • Three additional “general purpose” channels to be defined and used as required by creators.

These channels will eventually be surfaced as tattoo layers in the viewer, which will have an updated UI for creating new layers.

Injecting Texture Information into the Bake Stack

There has been a request to allow applier creators to use a scripted means to “inject” textures into the Bake Service via a script (see BUG-216137).

It has arisen out of concern that Bakes on Mesh a) won’t offer the same ease-of-use as HUD-based appliers many users are familiar with; b) it could make the majority of existing applier systems obsolete as mesh head / body creators move towards less complex “onion layer” designs, requiring applier makers to completely re-work all of their existing clothing options. Offering a means to provide Bakes on Mesh with a similar capability as applier systems and allow applier makers to more easily update their existing systems. However:

  • The proposed solution is a non-starter, as the Outfit system on which the Bake Service relies, has no notion of textures. Thus, offering a means to “inject” textures into the bake stack essentially creates a separate (and potentially conflicting) representation of the bake stack.
  • If it is seen that a more applier-like approach to Bakes on Mesh, any solution will form part of a follow-up project, rather than being part of the initial implementation.

 

Ouzo: a viewer aperitif for Second Life

Linden Lab has promoted the latest Maintenance RC to de facto release status. The viewer follows the Lab’s convention of naming their maintenance updates for the viewer after popular alcoholic beverages and aperitifs.

This release includes a range of updates and improvements to the viewer which are worth highlighting, and which will be finding their way into third-party viewers as time goes forward (if they are not already present). Including the following.

Installation and Log-in Improvements

  • The “Your account will not be available until” login failure message has now been removed, as it is no longer meaningful.
  • The GPU Benchmark test no longer causing issues when installing the viewer or when setting viewer defaults.
  • Non-English versions of the viewer can now be installed into non-default paths without causing incorrect fonts to be loaded, corrupting the text of the Terms of Service display in the viewer.
  • Mac OS updates:
    • Incorrect VFS (cache) creation time no longer shown in “help>about SL”.
    • Full version of the build in the applications is now displayed after install on Mac.

Avatar Appearance Updates

  • A new option added to the Appearance Editor right-click menu: Wear Only This Outfit.
  • The Edit Outfit panel in the Appearance Editor no longer displays “Loading…” when there is nothing to load.
  • An avatar’s hairbase is now correctly rendered in Appearance mode when ALM is enabled, and the alpha mask will correctly hide the default hair in the Outfit Editor.
  • A seated avatar’s rotation is now correctly updated when the object the avatar is sitting on is changed via the build floater X, Y, Z spinners.
  • Object position (and sometimes size) no longer greyed out when editing avatar parts or attachments.
  • Temporary attachments can now be detached via gear menu in Appearance >Wearing.

UI Improvements

  • Abuse Report floater clean-up.
  • Error messages no longer doubled (the first being generic, the second being accurate).
  • It is no longer possible to delete an inventory folder while trying to rename it by holding down the Delete key a little too long.
  • Chat scroll bar now properly displayed after a panel resize.
  • “Walk/run/fly” toolbar button no longer turns off “fly mode” once per session.
  • Received Items improvements:
    • The “New” icon in the Received Items folder now correctly disappears when navigating with keys.
    • The “New” tag now appears in front of folders when searching.
    • “Properties” menu item disabled for multiple selection in Object content, because it was causing Received Items to disappear.
  • The Donation check box no longer covered by the Purchase button when buying land from a group you’re already donating to.
  • Bottom part of “Filter” button at Snapshot window can now be properly clicked.
  • World Map no longer shows first friend location after searches.
  • Unicode correctly appears in the Windows viewer display name.
  • Arrows ‘Navigate back’ and ‘Navigate forward’ had wrong state.
  • Profiles now have a Back button.
  • Debug setting AvatarHoverOffsetZ will work regardless of whether Set Hover Height modal has been opened.

Efficiency & Performance Improvements

  • This viewer uses the new off-line messages capability to correctly fetch off-line IMs following log-in, hopefully resolving the issue of lost off-line messages.
  • Viewer no longer attempting to load file/mesh/LOD indefinitely in case of most failures.
  • Advanced Lighting Mode (ALM) improvements
    • Normal and specular maps no longer downloaded when ALM is disabled.
    • Local Textures for Advanced Lighting Projectors now keep the selected texture.
  • Particles attached to the muted avatars no longer render.
  • Texture animation flicker at certain frame rates has been removed.
  • Sculpties should no longer appear as spheres before their shape data has been received by the viewer.
  • Scripts memory usage should no longer return incorrect values in the Estate Tools.
  • Unneeded exception handling from LLAppViewer::frame() removed.
  • ExportCharts for performance analysis re-enabled.
  • Mods to allow nVidia nSight to capture frames of Viewer rendering have been added.
  • Deprecated and unused private memory pooling removed.
  • Various translation updates.

Media Updates

  • (MAC only): viewer Media Browser no longer doubles entered Cyrillic capital letters.
  • Magnify glass button no longer returns camera to avatar after select other nearby media in “Start/Stop ALL Media” tab.
  • Scrollbar should decrease when the number of displayed media decreases.
  • The viewer no longer sends multiple GET requests against prim media when PRIM_MEDIA_AUTO_PLAY is enabled.
  • Social floaters launch a somewhat different version of the internal browser.

Crash Fixes

The viewer includes a range of crash fixes, as detailed in the release notes.

Downloads

The viewer can be downloaded from the viewer’s release notes page, if preferred.

2018 SL project updates 20/1: Simulator User Group meeting

The Apothecary; Inara Pey, April 2018, on FlickrThe Apothecaryblog post

Server Deployments

As always, please refer to the server deployment thread for the latest updates.

  • On Tuesday, May 15th, the Main (SLS) channel received server maintenance package 18#18.05.07.515224, which includes two new LSL functions: llRequestUserKey and llName2Key –  see below for more.
  • On Wednesday, May 16th, the Release Candidate channels were currently marked as TBD at the time of writing. However, during the Simulator User Group meeting on Tuesday, May 15th, Rider Linden indicated there would be two RC deployments:
    • The BlueSteel and LeTigre deployment should comprise internal fixes, together with simulator-side updates for better management of estate level ban lists – although these will require a viewer update to be visible.
    • The Magnum RC update should comprise the same internal fixes, together with the simulator-side updates for abuse report categories.

llRequestUserKey and llName2Key

llRequestUserKey and llNameToKey, both of which will be across all RC channels following the Wednesday deployment, are in connection with the upcoming return of Last Names (see this blog post and this blog post for more). These functions can be summarised as:

  • llRequestUserKey:
    • Requests the Agent ID for the agent identified by name from the dataserver. The name given may be either the current name of an avatar or a historical name that has been used in the past. If no agent can be found with the supplied name this function returns the value NULL_KEY.
    • It returns a handle (a key) that can be used to identify the request when the dataserver event is raised.
    • Note that agent being searched for with this function does not need to be signed on to Second Life.
    • See the llRequestRequestUserKey wiki page for more.
  • llName2Key:
    • Returns a key the Agent ID for the named agent in the region. If there is no agent with the specified name currently signed onto the region, this function returns the value NULL_KEY. Names are always provided in the form “First[ Last]” or “first[.last]” (first name with an optional last name.)
    • If the last name is omitted a last name of “Resident” is assumed. Case is not considered when resolving agent names.
    • Uses a different mechanism to look up agent information to the older llKey2Name().
    • See the llName2Key wiki page for more.

Abuse Report Category Capability

As I’ve noted in my TPV Developer meeting updates, a new capability is being introduced that will allow the viewer to call abuse report categories from the simulator, rather than having them hard-cored into the viewer itself. This will help ensure abuse reports are filed using valid AR categories, while at the same time making it easier for the Lab to maintain the AR categories.

The deployment to the Magnum RC is the first phase of this work to be made to the grid. Once the simulator changes are available grid-wide, a viewer with the new capability should be made available, with a request that TPVs adopt the updates as soon as they can in their own release cycles.

SL Viewer

The Ouzo Maintenance viewer has updated to version 5.1.4.515016 (dated May 7th, but the update wasn’t listed in the Alternate Viewers page until week #20).

The Animesh viewer updated to version 5.1.4.515420 on May 15th.

The rest of the viewer pipelines remain as:

  • Current Release version 5.1.3.513644, dated March 27, promoted April 13 – formerly the media update RC.
  • Release channel cohorts (please see my notes on manually installing RC viewer versions if you wish to install any release candidate(s) yourself):
  • Project viewers:
  • Linux Spur viewer, version 5.0.9.329906, dated November 17, 2017 and promoted to release status 29 November – offered pending a Linux version of the Alex Ivy viewer code.
  • Obsolete platform viewer, version 3.7.28.300847, May 8, 2015 – provided for users on Windows XP and OS X versions below 10.7.

Other Items

Mesh Pivot Points and the Uploader

A long-time problem with the mesh uploader is that it ignores pivot points set within tools like Blender when a model is uploaded to SL. This means, for example, that doors set with a pivot point in Blender won’t work using that pivot when uploaded to SL. A feature request to enable the uploader to recognised pre-set pivot points in mesh objects was raised in 2015 – see BUG-37617 –  and more recently, Beq Janus has been looking to add further information to it.

Region Crossing Updates

Code to improve communications during region crossings went grid-wide in week #19. A further round of simulator-side updates is likely to be deployed in the next few weeks. In the meantime, Joe Magarac (animats) believes most of the minor issues relating to “partial unsits” can be handled with changes to scripting / the viewer – see BUG-214653. He’s offered to rally support to help the Lab dig more deeply into this issue, by arrange group tests, etc., if the Lab can made simulator-side changes to help improve things.

Three major issues for vehicles are No Script parcels / regions, ban lines and scripted security systems. The  former can be harder to deal with, as there is no advanced warning that scripts are disabled until the boundary is crossed. Scripted security systems tend to provide some warning which can generally allow those straying into a private area time to get out (unless the delay time has been set ridiculously short). Ban lines are somewhat insidious, however, as they can physically “snag” a vehicle whilst ejecting the occupants – with the vehicle often remaining in place with no auto-return.

There has been a feature request to handle ban lines better (BUG-216276), with another request for ban-lines to “deflect” vehicles, rather than allowing vehicle to cross them and becoming snagged when the occupants are ejected. It’s not clear if the Lab will adopt these ideas.