Why is this feature important to you? How would it benefit the community?

The Project Bento extends the avatar skeleton by facial bones and hand bones. This gives the mesh heads the ability of facial expressions. But different mesh heads will be rigged differently, hence the animations for facial expressions must be made for every mesh individually.

On the other side the legacy animations for facial expressions are based on morphs and cannot be played on mesh heads at all. While bone-based animations working on mesh heads will not work for a legacy shape.

As conclusion, the already existing facial expression HUDs (among other products) are useless for the mesh heads, as they start the built-in expression animations. Such a HUD would now have to check if it wants to animate a legacy shape (than it starts the built-in expression animation) or when it is a mesh head than the HUD has to select the correct individual expression animation. While it is not clear yet how this selection would happen.

This feature request depicts a way to avoid those problems. The idea is simple: When the mesh head is worn, a script in this head registers the individual animations to override the built-in expression animations. Whenever now an expression HUD (or any other product) starts the overridden expression animation, the replacement animation will be started instead. When the mesh head is not worn, the expression animation is not overridden and will play normally and animate the legacy shape.

We achieve this way the backward compatibility and avoid conflict problems when the animation is played that not works correctly on the particular mesh head.

How would you like the feature to work?

I suggest two approaches to achieve this goal.

Extending the llSetAnimationOverride functions

LSL has three functions already that manage the server-side animation override:

• [llSetAnimationOverride|http://wiki.secondlife.com/wiki/LlSetAnimationOverride]( string anim_state, string anim )

• string [llGetAnimationOverride|http://wiki.secondlife.com/wiki/LlGetAnimationOverride]( string anim_state )

• [llResetAnimationOverride|http://wiki.secondlife.com/wiki/LlResetAnimationOverride]( string anim_state )

  These functions override default animations played on event of the specified animation state of the avatar. The extension will simply allow to override also built-in animations by using this functions.

  As anim_state is now any name allowed, not only animation state. When it is the animation state, e.g. "Walking" than the specified animation is called on state event (e.g. on avatar walking), when it is a built-in animation name, than the animation runs when the built-in animation was started.

  The built-in animations (including expression anmimations) are lised here: Internal Animations.

  Example: We set an override for the built-in expression animation "express_smile". This call is performed by the script inside the mesh head upon wearing it:

  llSetAnimationOverride("express_smile", "smile_tiny_female_06");

  Now the expression HUD starts the expression animation wihout knowing it is overriden:

  llStartAnimation("express_smile");

  Since the animation is overridden, the animation "smile_tiny_female_06" will run instead.

Big note: The animation that starts is installed in the mesh head, not in the HUD prim where the script is installed that actually triggered the overridden animation.

Providing separate functions

The function llSetAnimationOverride sets an animation override and we need to override built-in animations, so using llSetAnimationOverride functions looks to serve our goal. But from the implementation view it may not, because we want to override the built-in animations and not the default state animations.

When it is the case, than three similar functions can be better:

• llSetExpressionOverride( string expr_name, string anim )

• string llGetExpressionOverride( string expr_name )

• llResetExpressionOverride( string expr_name )

  The "Expression" in the name is probably not a good choice (I hope for regular expressions coming one day to LSL) and not only the facial expressions should be overridden but all the built-in functions, at least those using morphs. But I did not found a better name.

  expr_name is name of the built-in animation. anim is name of the animation that will start when the avatar should play the expr_name animation. anim can not be a name of a built-in animation, it must be name of the animation in prim inventory (otherwise we can generate a loop of overrides.)

  llSetExpressionOverride sets the override, llGetExpressionOverride reports the set override and llResetExpressionOverride resets the override of the expr_name animation.

  To call the functions, the runtime permission PERMISSION_OVERRIDE_ANIMATIONS is required.

  Having two separate overrides (even when they works similarly) has also the advantage, that the animation override can be reset while expression override remains set.

  Handling animation keys

  The built-in animations are given via names and keys, for example the animation "express_smile" can also be started via the key "b7c7c833-e3d3-c4e3-9fc0-131237446312".

  The animation override must be always set via name, not via key. However, when the built-in animation is started via key, still the overriding animation must be started.

  Overriding unknown functions

  When an override is set for a name that is not a built-in animation (and not an animation state), we have an undefined case. What happens, depends on the implementation.

  Example: A script A into the mesh head sets an override to an animation "smile", instead of the built-in animation "express_smile":

  llSetAnimationOverride("smile", "smile_tiny_female_06");

  Now the script B into the expression HUD starts the overridden animation:

  llStartAnimation("smile");

  So, what happens?

  Override table

  The override can work with a table with predefined animation names. Than only these can be overridden. Overriding the animation "smile" will fail than as it is not in the table.

  Either setting the override will fail with error or silently or starting the unknown animation "smile" will fail with a message that the animation is not found.

  This solution is sufficient and it avoids memory leaks due overriding large number of unknown animations. But it requires that the table will be extended when at later point new expressions or hand poses will come and need an override. And this will definitely happen.

  Override list

  The override could also work with a list that is extensible. The animation is added to the list when the override is set and removed when the override is reset.

  This way the expression HUD will start the animation "smile" while the overriding animation "smile_tiny_female_06" will played from the mesh head.

  This solution allows the creators of mesh heads and bodies to extend the list of override-able animations and create so the standard of hand poses and facial expressions without needs of LL to maintain this list.

{
  'Business Unit': ['Platform'],
  'How would you like the feature to work?': 'a',
  'ReOpened Count': 0.0,
  'Severity': 'Unset',
  'Target Viewer Version': 'viewer-development',
  'Why is this feature important to you? How would it benefit the community?': 'b',
}