Project Bento User Group update 12 with audio

Project Bento – extending the SL avatar skeleton
Project Bento – extending the SL avatar skeleton

The following notes and audio were taken from the weekly Bento User Group meeting, held on Thursday, April 21st at 13:00 SLT on Aditi. For details on each meeting and the location, please refer to the Bento User Group wiki page.

Note that this update is not intended to offer a full transcript of the meeting, nor does it present the discussion points in chronological order. Rather, it represents the core points of discussion to Project Bento, grouped together by subject matter were relevant / possible.

Bento Promotion

Troy Linden, the product team lead for Project Bento opened the meeting by offering thanks to all those who have participated in the project. The Lab is now preparing to deploy the project to the main grid, most likely some time in Q2 2016. In support of this, they want to hear from content creators who would be willing to submit avatars for use in Bento promotional videos and supporting documentation. Those interested in helping the Lab by providing content are asked to content Troy directly, indicating what they are producing, so a good cross-section of content can be demonstrated.

Skeleton Status and Viewer

From the TPV Developer Meeting, Friday April 22nd

It is believed the skeleton in now frozen, and the Lab would prefer not to add further bones / amend the existing bones. There will be a period of test (around two weeks) to ensure there are no further significant changes which must be made before the project progress to the main grid. Work is continuing on trying to resolve or at least improve issues which pre-date Bento but what have an impact on it (e.g. the various default animation issues discussed in these reports), although these are not considered blockers to the project moving forward, so they may or may not be all resolved over time.

Joint Offsets and Overrides

Partial Offsets

Note: see the forum thread discussion commencing here, and the three messages immediately following it, and further follow-ups  here and here (plus the two messages immediately following it) for additional background.

One problem people have encountered is when defining partial joint offsets – that is, having a mesh that specifies the override positions for some of the joints but leaves  other joints alone. This is seen as particularly useful in allowing different meshes to be mixed and matched to create an avatar look. However, there appear to be issues in how both the viewer and – possibly – Avastar are handling things.

The issues within the viewer have been identified as the viewer failing to handle  multiple root bones in a mesh with partial rigging correctly. For example, if a creator is trying to override the shape of both hands in a mesh without overriding anything else (and so no common root such as the pelvis is defined), the viewer currently applies the defined offsets to one hand, but not the other due to them having separate root bones. It is hoped a fix for this will be in the next project viewer update.

Flagging joint Overrides

Another issue is that currently, there is no means to flag whether or not a joint has an override on an individual basis. The current assumption is that all the joints that are skinned to either also have an offset defined, or none of them do.

The problem is how to let people specify individual overrides without changing the mesh asset structure as it is currently defined, as it would really be outside the scope for Bento (an example of this would be providing a custom attribute to specify offsets)

Suggested options are:

  • Treat certain values in the mesh asset as indicating there is no offset. There are issues associated with this. For example, if 0,0,0 were to be used, then joints would not have any offsets relative to the pelvis, leaving them all in that position, squishing the model
  • Use the default location for a joint offset as a kind of “magic” value, indicating that nothing is to be changed.

The latter is seen as preferable, although it is acknowledged it might not suit all cases or might cause more issues if using the default positions proves complex. Vir has therefore invited further discussion on the matter through the forum thread.

One other suggestion was put forward: using a true / false boolean to define the state of offsets on a joint by joint basis. However, this would again mean changes to the mesh asset structure and, if included in the mesh uploader as suggested in the discussion, a complex and potentially confusing update to the viewer UI.

Facial Sliders: Animation Translation vs. Slider Offset Conflicts

As noted in my update #11, there are concerns about the potential for animations which reposition the facial bones conflicting with the use of facial sliders to adjust the position of the same bones, particularly when using bone translations in animations. This could potentially make it difficult to make portable facial animations, as they can end up conflicting with facial bone positions set by the sliders.

In short:

  • When using rotations in an animation, the rotation will generally take its baseline from whatever offset is selected by adjusting the associated slider. So changing the size / position of a facial element with the sliders shouldn’t drastically impact the appearance when the animations are running
  • When using translations, however, their offset is taken as an absolute. This means that if the associated appearance slider only uses an offset to define the size of a bone – such as with the new ear-tip bones – changes made using the slider will be instantly overridden by the animation as soon as the appearance editor is closed (so if an animal’s ears are made larger using the sliders, then will instantly “snap back” to the size defined by the animation translation)
  • The problem should be limited to the sliders which only use offsets rather than scaling to achieve results, and these are thought to be a minority. However, further discussions will be had to try to determine how the issues might be remedied
  • Krystal Silverweb has offered some examples of issues on the forum thread Which continues through to page 58, at the time of writing), and Gaia Clary has added some further notes concerning the translation / rotation of joints and the use of the appearance sliders to the Avatar documentation.  See also discussions within the thread under the heading “Facial animations and appearance sliders compatibility….”

Vir is considering starting a best practices document on the use of animations and sliders, and is hoping that further testing can be carried out to see what works best, where limitations reside, etc., and that people will help expand this to provide practical help and support to others. This will likely be linked to the Good Building Practices for ease of reference.

Initial discussion on sliders and issues

Post-meeting discussion on sliders / offsets and animation bone rotations / translations between Medhue, Cathy and Elizabeth

Other Points of Discussion

Linking Bones to Create Snakes

Medhue Simoni referenced his observations in trying to link bones together to produce avatars such as snakes, where a large number of bones have to be linked to effectively produce a spine. The expanded into a broad discussion on the use of the “hind limb” bones, and the use of custom skeletons within 3D tools for the purposes of animating and constraining the SL skeleton bones.

Bones and Rigging

One problem with the volume of bones the skeleton is what to rig and when in creating avatar models. Following the core meeting a brief discussion was held with further explanations given on:

  • teeth bones: designed to ensure the teeth in an avatar accurately follow the movement / position of the lips; if the teeth are rigged to the lips, misalignment /warping can occur
  • Chin bone: to allow for easier adjustments to the head.

This also covered some of the thinking behind the linking of the facial sliders to the Bento bones.