Category: SL Tech

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

Land Impact: a simulator bug has been found that is being fixed. In short, if an Animesh object has a conventional prim as its root, the required 15 LI for the Animesh skeleton is not applied. This LI is an aggregate value for Animesh skeletons during testing Animesh performance for a defined set of test Animesh objects across a range of systems.

This has led to some alarmist blog posts about prim returns, following a (somewhat sensationalist) forum post on Animesh being delayed by 2 weeks (itself guesswork) on the matter. Given that Animesh hasn’t reached release status, and there are few (if any) commercially-available Animesh objects at present, it’s not unfair to say both the blog posts and the forum thread are something of an over-reaction.

Performance Impact: (see BUG-225584 and forum thread). This is related to the new dynamic bound box used with Animesh. Beq Janus from the Firestorm team has been involved in investigations as to the degree of potential impact, and has discovered a potential baseline performance impact of around 8-10% between an Animesh-capable and non-Animesh viewer, regardless of the presence of Animesh.

The latest update to the Animesh viewer (version 6.0.0.520636 at the time of writing), should mitigate a lot of the performance impact resulting from the dynamic bounding box.

Animesh vs. Avatars: while there will be a baseline impact for Animesh objects, this should be less than the baseline impact seen with avatars, which not only have a skeleton, they also have a shape and appearance elements associated with them. The the complexity of a mesh body to an avatar (with a baselines of around 400 faces, plus mesh clothing, attachments, etc., and avatars tend to be a lot more complex than most considered Animesh should be.

Animesh follow-up: there has been a lot of talk about a follow-up project for Animesh since the project started. These include adding a body shape (allowing Animesh humanoid objects to gain slider support), which is viewed by the Lab as being possibly the preferred follow-on project, although it is acknowledged given the wide variety of arbitrary mesh forms that could be converted to Animesh, slider use might be limited. However, it is unlikely any follow-on project will be an immediate follow-on to the current work, as there are several other projects currently in the pipeline awaiting attention.

Animesh attachments: another long-term request has been to attach objects to Animesh creations. A problem here is that attachments are managed by the simulator-side avatar agent – and Animesh objects do not have an avatar agent associated with them, so they don’t have the back-end support for tracking attachments. This is an issue that needs to be solved before attachments on Animesh can be handled – and even then, there is the question for potential performance impact. Various alternative ideas have been suggested to allow for attachment support n Animesh, but these may also have their own issues, and are unlikely to be adopted.

Animesh “assembling” issue?: we’re all familiar with the way mesh bodies “assemble” when logging-in / teleporting to an occupied region: the various mesh elements stack-up, usually at their default attach points, while some may appear offset or oversized, then the position, rigging, LOD, etc., data is received by the viewer and things “assemble” into an avatar. This behaviour can occur with multi-part Animesh objects as well, and there is a report that sometimes the Animesh “assembling” can leaves parts floating around for up to a minute before “snapping into place”.  Thus far, the problem has only manifested with one creator using the pre-release of the Firestorm Animesh viewer, so it’s not clear whether there is an underpinning issue with Animesh or not.

Environmental Enhancement Project (EEP)

Project Summary

A set of environmental enhancements allowing the environment (sky, sun, moon, clouds, water settings) to be set region or parcel level, with support for up to 7 days per cycle and sky environments set by altitude. Uses a new set of inventory assets (Sky, Water, Day) that can be stored in inventory and traded through the Marketplace / exchanged with others, and which can additionally be used in experiences. A new set of render shaders to support atmospheric effects such as rainbows, crepuscular rays (“God rays”), better horizon haze and fogging (but will not include rain / snow). The ability to change the Sun and Moon and cloud textures with custom textures.

Resources

• Project definition document.
• Project summary (this blog).
• Full EEP Documentation.
• Project Viewer – via Alternate viewers wiki page.
• EEP testing region: secondlife://Aditi/secondlife/EEPTesting/247/44/23
• EEP Feedback forum thread.
• EEP sneak peeks forum thread.
• EEP Jira filter.

Current Status

As per my week #43 SUG update, a simulator update has been updated to fix the issue of racing skies when EEP-enabled regions are seen on non-EEP viewers. In addition, Rider is working on the first pass of the LSL support for EEP.

Bakes On Mesh

Work is continuing with fixing the Bake Service issues. however, as Anchor Linden, the lead for the project, is on vacation, this work will likely remain open until his return.

Other Items

• Animations: there have been multiple requests for improvements to the animation system, including: allowing animation constraints to be set; extending the .ANIM format, animations by .DAE file and support for animation scaling. The Lab is aware of the requests being made, although not formal project has been defined at this point.
• Morph Targets: there have been requests to allow morph targets within the avatar shape so that the shape sliders can be manipulated via LSL (so an avatar “gorging” itself at a scripted meal gets fatter, as a simple visual example). There are concerns that opening the body shape parameters to LSL manipulation could result in over-use and performance impact (e.g. rapid LSL adjustments to “animate” an avatar rather than using an actual animation), but some ability to allow morph targets is seen as potentially “interesting” – although this is not to say it will become a project.
• Date of next meeting: due to the start-of-month internal meeting at LL, the next CCUG meeting will be on Thursday, November 8th, 2018.