Summary

This Jira is for official support for deformations. Deformations are what moves the bending joints of the avatar to new locations, to allow for large, small and interestingly shaped avatars with joints that bend as expected. Technically: This Jira is to allow for the reading and rendering of both rotation AND position information for any specified joint from an uploaded animation.

Desired Implementation Criteria

Enhance BVH parsing, and allow positional information as an option. This allows for single-length snap-to deformations (single looping frame) as well as animated deformations (animating a limb getting longer or shorter). It also easily allows animations to be included in a deformation, meaning instead of 19 animations (18 deformations + 1 animation) the whole thing can be done in one animation.

Specifically

• If a joint in the hierarchy data has x, y, and zposition in addition to the standard rotation, expect to have three new values in each frame of the motion data, or second half of the BVH file.
• Use the same "not changed between frame 1 and frame 2" tactic to ignore a joint, but separate the position and rotation. If the position changes between frame one and two, deform it. But if the rotation on the same joint doesn't, activate no animation on it – just the deformation.
• Position information can be played like animations. That is, you can animate limbs lengthing and shortening, as well as simply snapping into place with a one-frame loop. Old deformations can do this.
• When the deformation animation is no longer being "played," the avatar returns to normal. This can be done by replacing or adding a default priority 0 animation to the avatar that includes the default position information.
• The limits for the distance a joint can move would be no less than it is now, which is currently dependent on the joint and shape, and allows for extremely large avatars.
• Continue to ignore the joint offsets in the hierarchy data in the first half of the BVH files. This joint position data in the hierarchy is essentially obsoleted by the appearance sliders within Second Life. Also, the data provided in the default SL BVH files do not match the default avatar, and many people use their own models in their 3D applications which generate very different hierarchy data in their BVH files.
• Eyes can currently be deformed, as they are a bone on the skeleton. Allowing the addition of the eye into the BVH heirarchy and their deformation – and subsequent restoration, would be ideal.

Existing problems and solutions

P: After deforming an avatar playing animations, the legs will buckle when attempting to IK at the ground. By changing the avatar's shape the hip height will be recalculated – but not to the correct spot. Occasionally, different viewers will see the avatar's hip at different default heights while deformed.
S1: Preferably, the hip height should update with the length of the legs. This would mean that existing animations can be used on a deformed avatar. Currently, completely new animations are required for the hip height to be the correct distance off the ground.
S2: If that's not possible, second choice is perhaps a script-based method of setting the hip offset to a fixed value. This would still allow existing animations to be used by manually setting the hip offset to a proper height. For example, llSetAvatarHips(AVATAR_HIP_DEFAULT) or llHipHeight(30.0)
S3: Last choice is that deformations don't effect the hip height at all. This means that all new animations will be required for deformed avatars. Since the current limit for animations is to move within a 5m box away from the avatar's hip, an increase on this level to 10m, or even better 20m would allow for avatars of an acceptable size without requiring additional scripting resources to manually lift the avatar.

P: The bounding box on a large avatar is a peaspeck compared to the avatar itself.
S1: Create a separate script function to change the avatar's bounding box size. For example, llSetAvatarBBox(AVATAR_BBOX_DEFAULT), or llSetAvatarBBox(<10.0,5.0,5.0>);
S2: Automatically increase the bounding box when an avatar is deformed.

Examples

In the BVH file, the hierarchy for the head would normally be:

OFFSET 0.000000 10.266162 -0.273764
CHANNELS 3 Xrotation Zrotation Yrotation
JOINT head

But if the joint is to be deformed, it would be changed to:

OFFSET 0.000000 10.266162 -0.273764
CHANNELS 3 Xposition Yposition Zposition Xrotation Zrotation Yrotation
JOINT head

And three additional floats would be added to the motion data on each line in the second half.

The existing problems with (old) deformations that the new deformations should solve:
----
1) Requires 18 animations to deform every joint. This can slow down the server and client.
2) All 18 animations must play at some point after a third party looks at the avatar for them to see the deformations.
3) A third party who looked at a now-not-deformed avatar and hasn't moved out of visual range and back must see the avatar play the "undeformation" animations to see them normal again. (Or, the avatar must be forced out of the third party's viewing range and back again.)
4) With the avatar being stretched vertically, if the shape changes, then the avatar will sink into the ground or float. Since when a third party loads the avatar, there's no real way to tell if the deformation animations or the shape will be applied first, then it's a dice roll if the deformed avatar is loaded in the proper order.