Day: October 13, 2017

The following notes are taken from the Content Creation User Group meeting, held on  Thursday, October 12th, 2017 at 13:00 SLT at the the Hippotropolis Camp Fire Circle. The meeting is chaired by Vir Linden, and agenda notes, etc, are usually available on the Content Creation User Group wiki page.

Medhue Simoni live steamed the meeting to You Tube, and his video is embedded at the end of this article, with key points of discussion noted below. Time stamps to the recording are included below, and clicking on any of them will launch the video in a separate browser tab at the assigned point. However as these notes present the meeting in terms of topics discussed, rather than a chronological breakdown of the meeting, so some time stamps may appear to be out of sequence.

Animesh (Animated Mesh)

“I like the name ‘animated objects’ because I think it’s unambiguous, but it takes a long time to type!” – Vir Linden joking about the name “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.

In short, an Animesh object:

• Can be any object (generally rigged / skinned mesh) which and contains the necessary animations and controlling scripts in its own inventory  (Contents tab of the Build floater) required for it to animate itself.
• Can be a single mesh object or a linkset of objects (link them first, then set them to Animated Mesh via the Build floater > Features).
• Has been flagged as and Animesh object in the project viewer, and so has an avatar skeleton associated with it.
• Can use many existing animations.

However Animated objects will not (initially):

• Have an avatar shape associated with them
• Make use of an avatar-like inventory (although individual parts can contain their own inventory such as animations and scripts)
• Make use of the server-side locomotion graph for walking, etc., and so will not use an AO
• Use the avatar baking service
• Will not support its own attachments in the initial release.

These are considered options for follow-on work, possibly starting with the notion of a body shape (to help with more fully-formed NPCs).

Viewer Progress

[1:11-3:40] We are now “very close” to seeing a project viewer, test content and test regions appearing. The viewer has been passed by LL’s QA team, the initial test content is being developed (and will be added to, although people can obviously also test their own content) and a total of five regions will be set-up on Aditi (the beta grid) for the purposes of test very soon. Four of these will be arranged in square and be rated Moderate (allowing for comprehensive content testing, including how Animesh is managed on region crossings), the fifth will be separate and rated Adult.

The main hold-up for now is documentation: release notes, wiki documentation, FAQ, etc. When all is ready, there will be a blog post on the project, and the viewer itself will be appearing on the Alternate Viewer wiki page – so those interested in testing Animesh should keep their eyes on both the official blogs and the viewer wiki page.

Root Positioning

[4:20-7:20] The most recent work with Animesh has remained focused on aligning the root joint of a skeleton associated with an Animesh to the position of the Animesh object in-world. The problem here is that the skeleton / avatars in SL are oriented along the X-axis; however, some tools (Avastar?) align along the Y-axis.

This means that when applying skeleton (X-axis orientation) with an in-world mesh objects with a Y-axis orientation to make it Animesh, the latter can jump and rotate. Vir had been looking to make changes in the skeleton’s orientation to handle mesh with a Y-axis orientation this. However, it turns out doing so could cause unwanted behavioural changes for scripts handling attachment rotation and positioning. To avoid this, the skeleton orientation will remaining X-axis oriented. Vir hopes that the upcoming testing will allow the settings for linking skeleton to mesh can be further refined to make the conversion from static mesh to Animesh as smooth as possible.

Animesh and Vehicles / Testing vs Release

[9:20-13:20] A view is expressed that Animesh is being “rushed” without sufficient thought being given to its application in vehicle design. This in part perhaps stems from confusion about public testing of Animesh and a release in Animesh. For example, while Bento had an initial “closed” period of develop to lay the ground work, it was followed by a broad and lengthy public period of testing, consultation and enhancement.

As such, the arrival of the project viewer doesn’t mark a move towards “releasing” Animesh – but rather allows more widespread testing of the capability, including its potential use in vehicles and elsewhere. Testing is the point at which the Lab can more fully look to creators for feedback, requests for improvement – and even fleshed-out feature requests  etc., which might be considered for folding-in to the current work or for follow-on work once the initial Animesh release has been made.

Quick Questions

• Land Impact:
  • [15:54-16:29] Overall land impact constraints of Animesh are still TBD (testing will help determine what might be required). However, Vir points out that in terms of individual LI applied to Animesh objects it will initially be focused on a per skeleton basis, not on a per mesh basis (so a linkset of several rigged meshes converted to Animesh will be seen as single object with an LI, not a group of mesh objects, each with an LI).
  • [37:35-38:34] Couldn’t the Animesh constraint be purely land impact based? possibly, but then attachments would be excluded – as they are with avatars, and the most costly element in terms of performance are avatars; by only using LI as a constraint, then Animesh could become as impactful as avatars with multiple high render cost attachments.
• [16:46-17:18] Is Animesh prim objects with an AO? No. Animesh is rigged mesh objects containing scripted animations within them, associated with an avatar skeleton.
• [17:22-17:57] If an Animesh has linked skeletons, do animations play across all of them? No – Animesh does not involve linking skeletons. It can comprise multiple rigged mesh objects which are linked to an individual skeleton, which can have animations applied to it.
• [18:09-18:30] will the attached mesh also count against the tri count? Yes. There will be a limit, most likely set to 20K when testing starts, but subject to review as testing proceeds.
• [26:02-27:35] Short description of how Animesh will work, as covered in some of the bullet points in the project description, above. Includes some discussion of using Animesh with pathfinding.
• [30:00-30:35] Is animation movement capped (in terms of moving an individual bone): yes, it is capped at 5 metres, as it always has been for avatars.
• [30:41-32:55] Physical properties discussion: Animesh objects will operate like avatars: they well not have physical collisions as a result of animation (e.g. a moving arm on an Animesh will not collide with a passing avatar, for example). However, Animesh objects will have physical properties (based on mesh physics shape), and so can fall, etc.
• [47:35-48:08] Will Animesh alter the land impact for existing objects in-world? No. Animesh is a new object property, only applicable to objects intentionally set as Animesh. As such, it will not affect pre-existing content in-world unless said content is converted to Animesh (if it can be).
• [48:48-49:58] Will Animesh behave at altitude? There  is an issue which sees mesh rigged with software skinning deforms at altitude (starting around 1,000m and getting worse from there). Animesh might suffer the same, but it hasn’t been tested.
• [52:47-56:10] The eyes have it – a discussion on automating eye movements on Animesh in a similar manner to avatars. Vir see this more as building-out the NPC-style capabilities with Animesh, which is very much a follow-up to the current project.
• [58:18-59:20] Can Animesh work with other mesh? It should; the complex part is liable to be keeping the object’s actual position in sync with its rendered position based on the animations playing, particularly as there won’t be a “sit” equivalent. Vir hopes this is something that will be poked at in testing.

Side notes on Animesh Constraints:

[44:08-45:21] As Vir has previously indicated, all of the constraints in the viewer – when it appears – are for testing purposes, and to provide a means by which things can be tested.  For a catch-up on constraints and testing, please refer to my previous CCUG update.

[20:21-20:45] Also, to help with constraints and information, Vir has been updating the viewer’s avatar complexity panel to provide information on triangles, which will also work for Animesh objects.

[22:45-29:08] A feature request has also been submitted for an alternative method of handling land impact and incorporating Animesh – see BUG-139203. This has been left open for comment. However, it is something the Lab is interested in taking a look at.

Continue reading “SL project updates 41/2: Content Creation User Group” →