Day: June 15, 2018

MindPillars, a Scottish themed Sim – blog post

Updated on June 15th: to include planned RC channel for Animesh deployment – see notes below. 

The following notes are taken from the Content Creation User Group (CCUG) meeting, held on  Thursday, June 14th, 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.

Note that the audio presented here may not be in the exact order of discussion during the meeting; as subjects were at times returned to following their initial discussion, I have attempted to bring together key points of discussion by topic / subject matter. Also, please note that audio drop-out when Vir is speaking appears to be an ongoing problem at his end.

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.

Resources

• Animesh User Guide
• Animesh test content
• Animesh LSL methods:
  • llStartObjectAnimation
  • llStopObjectAnimation
  • llGetObjectAnimationNames
• Animesh – Updated Limits and Cost Formulas
• Animesh feedback thread
• JIRA filter for Animesh

Current Status

It now appears that Animesh could be arriving on the server-side release channels on the main (SLS) grid as early as week #25 (week commencing Monday, June 18th, 2018). There are caveats to this: the status of issues with the viewer being one of them – there are certain issues the Lab is focused on, which they would ideally like to have some fix / workaround in place for prior to deploying the Animesh simulator code to Agni.

Update: At the TPVD meeting on Friday, June 15th, Oz Linden indicated that if the Animesh simulator code is deployed to an RC in week #25, it will most likely go to BlueSteel.

Current Viewer Issues

Encroachment / Position / Offsets: this is to ensure that the visual position of an Animesh object is not too far offset from its position as calculated by the simulator (e.g. using things like animation offsets to alter the visual position of all or part of an object). The fix for this is to force the bounding boxes for all joints and the meshes attached to them to remain within a specified distance – most likely 3 metres, although this is still TBC – from the location where the simulator has calculated the object should be.

This update should be in the next update to the Animesh project viewer, and will also utilise new infrastructure on the back-end to allow smarter tracking of the bounding boxes for rigged meshes. This be being done by tracking bounding boxes on a per joint basis, and then transforming them. While it can take a “noticeable” mount of time to do this, Vir’s belief is that it doesn’t unduly impact performance, although if it does become an issue, it may be re-thought.

Concerns were expressed that this would limit the scaling of Animesh creations. Vir states this shouldn’t be the case – the restriction is not ties to scale, but to position. So, for example, a dragon could still be 60 metres in length / height,  but the encroachment fix would mean where it appears in people’s viewers cannot be offset more than 10 metres from where the simulator calculates its actual position to be as a static mesh.

Z-Offset Height Setting: until now the z-offset height setting that can be specified when uploading a mesh to Second Life has been ignored when using meshes with it set to Animesh objects (the offset only works when the mesh is attached to and avatar).

It is hoped an update to fix this will be in the next project viewer update, which should appear before the server-side Animesh code arrives on an Agni RC channel.

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.

This is a long-standing issue which Graham and Vir Linden are working on, but a fix is unlikely to be available prior to Animesh arriving on Agni.

Broken Rotations Issues:

• 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, then are visually located where the avatar skeleton supporting them is located, but the physics shapes remain in the original location of the objects prior to linking / converting.

The recommendation here (for the time being) is that Animesh objects should have a non-mesh root object, and associate any physics representation to that non-mesh root object.  This should hopefully eliminate the current issues and help ensure that any mesh being propelled via scripts in the root object will move in a predictable manner (.i.e. moves forward when driven forward by a script).

Other Issues

Additional bugs: the above are not the only bugs being looked at, but they are the ones causing the most concern due to the risk of behavioural issues / changes they might cause, together with perceived content breakage, when Animesh starts being deployed to the Main grid. Other issues, which are not seen as having so direct an impact will continue to be looked at ad hopefully resolved as Animesh is tested on the Main grid, together with any other issues which may come to light.

GLOD: there is concern that the global LOD values set by the mesh uploader when creators don’t specify their own custom LODs incorrectly encourages poor optimisation, by rewarding those so decrease the calculated LOD values with lower LI post-upload. The feeling is that the reverse should be true. It’s anticipated that Project ARCTan should help to address this.

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

• Bakes on Mesh forum thread.
• Bakes on Mesh JIRA filter (courtesy of Whirly Fizzle).

Current Status

A new Bakes on Mesh project viewer arrived on Thursday, June 14th. Version 5.1.6.516270 includes the new “universal” wearable types corresponding to the 5 new bake channels. These are:

• LEFT_ARM_TATTOO – bakes to the mesh left arm.
• LEFT_LEG_TATTOO – bakes to the mesh left leg.
• AUX1_TATTOO – creator definable layer / channel.
• AUX2_TATTOO – creator definable layer / channel.
• AUX3_TATTOO – – creator definable layer / channel.

Note that none of these additional wearables can be applied to the system avatar mesh; which continues to use the original six bake channels.

It’s also not clear if alpha layers can mask these new channels at present. If not, that Vir agrees it is something that should be looked at.

Other points of note:

• There are no plans to extend Bake on Mesh to allow the use of wearable on non-wearable objects. This is because Bakes on Mesh uses the avatar bake service, which is not geared to apply wearables to in-world objects sans an avatar shape.
• There is no time frame for Bakes on Mesh deployment at the moment; the project is still in the process of being developed, tested and refined with the help of content creators.
• There is no updated on any form of scripted control for Bakes on Mesh. It hasn’t been ruled out, but no work is currently being done for scripted support.

In Brief

• Mesh uploader cost formula / calculations: there have been requests to offer a clearer explanation of mesh cost calculations through something like a clarified wiki page. In terms of Animesh, providing guidelines on potential cost is difficult, as the actual conversion of a mesh to an Animesh takes place post upload.
  • One suggestion to help estimate Animesh costs is to add an Animesh model type to the drop-down list of object types in the mesh uploader.
• Bento .BVH animation issue: the .BVH format allows for custom joint names for animations in addition to the default joint names. One such custom schema is to prefix joint name with “avatar_”. However, it has recently come to light that while the use of “avatar_” on pre-Bento joints works, trying to upload animations using any of the Bento bones prefixed with “avatar_” results in either an error message on upload (the SL viewer) or the animations uploading, but then being ignored on playback (tested with Firestorm). A JIRA bug report has been requested for this.