llStartAnimationWithParams: Queuing, Syncing, and other low-hanging animation enhancements | Voters

llStartAnimationWithParams: Queuing, Syncing, and other low-hanging animation enhancements

Tapple Gao

Scripters have long bemoaned the limitations of

llStartAnimation

and

llStartObjectAnimation

, and proposed a number of enhancements. It could be a lot better with only minimal changes to the simulator and the simulator-viewer protocol. Here are examples of great enhancements that could be made by just sending a little bit more data to the viewer along with the

llStartAnimation

message. To illustrate, I will name the new functions:

llStartAnimationWithParams
llStartObjectAnimationWithParams

1. Queuing

When I ask others how the animation system is lacking, the most common complaint is Queuing one animation to play after another. Now, a script can send the viewer the message:

llStartAnimationWithParams(anim, [ANIM_QUEUING]);

When the viewer receives this message, it will do one of the following:

If the avatar has no other active animation marked
ANIM_QUEUING
, it will play the animation normally
Otherwise, the viewer will delay the animation start until all earlier
ANIM_QUEUING
animations on that avatar have stopped, either from ending, or by calling
llStopAnimation
.

Caveat: This will currently not work well on Animesh, because animesh animations never automatically stop. I find this caveat acceptable.

This is similar to the existing sound function

llStartSoundQueuing

2. Syncing

This one is near to my heart. A script is animating two or more avatars. It designates one of those avatars as the leader:

llRequestPermissions(leader, PERMISSION_TRIGGER_ANIMATIONS);
llStartAnimationWithParams(leader_anim, [ANIM_SYNC_LEADING]);

It designates the other avatars as followers:

llRequestPermissions(follower, PERMISSION_TRIGGER_ANIMATIONS);
llStartAnimationWithParams(follower_anim, [ANIM_SYNC_FOLLOWING, leader]);

When the viewer is asked to start an animation marked

ANIM_SYNC_FOLLOWING

, it:

Downloads the animation
Waits until any leader animation marked
ANIM_SYNC_LEADER
encounters a loop point (including waiting until an
ANIM_SYNC_LEADER
animation is started at all)
Starts the animation normally

This is very similar to these existing sound functions:

llLoopSoundMaster
llLoopSoundSlave
llPlaySoundSlave

It would be up to the animator to create animations suitable for syncing. Synced animations should usually:

Have identical loop durations
Have no loop-in period

The most flexible leading animation will be 0 priority and an animate zero bones; providing nothing but a looping beat. This is also true of

llLoopSoundMaster

; The best master sounds are silent.

3. Property overrides

Animation assets have a number of parameters you can set at upload time, but can't be changed afterward. It would sometimes be nice if you could change them, and,

llStartAnimationWithParams

provides a convenient place to override them. The most useful ones to override would be:

ANIM_PRIORITY
ANIM_DURATION
ANIM_EASE_IN
ANIM_EASE_OUT

4. Speedup

Similar to

ANIM_DURATION

above, but, speed up the animation by a constant factor, regardless of the asset's native duration:

llStartAnimationWithParams(anim, [ANIM_SPEED, 2.0]); // Double speed = half duration
llStartAnimationWithParams(anim, [ANIM_SPEED, 0.5]); // Half speed = double duration

5. Blending

Allow an animation to not fully replace any channels in animations in overrides, but, linearly blend the bones between this animation, and the next-lowest one in the animation stack:

llStartAnimationWithParams("breathing", [ANIM_BLENDING, 0.1]);

This one would require the most changes to the viewer, but would open up new ways to animate characters, and would often allow multiple animations to be consolidated together more flexibly

Summary

I hope you can consider this proposal. I considered it carefully so that it can be implemented with minimal changes to either simulator or viewer. I heavily limited the scope, so it has a clear end point, unlike Puppetry:

It does not require changing the animation asset format
It does not require any new viewer -> simulator communication, beyond the existing message "hey this animation ended".
It does not require the simulator to download or understand animation assets.
It does not require new simulator -> viewer communication. It only adds a few new fields to the existing "animation started" message
llStopAnimation
and
llStopObjectAnimation
require no changes

4 hours ago

lifeon13 Resident

All or even a few of these changes would drastically improve the potential control creators have over avatars and animesh alike, which is an increasing need as the complexity of interactive avatars & animesh has become significant with SL's age.  The function to modify parameters for ease in/out, as well as run animations in sync and with blending weights is present in most major animation engines.
Animation sellers and AO scripters alike would have much better control over the quality of the final product if they are able to control settings beyond the first time upload & schedule the conditions they play with more scrutiny.
I would also argue that additional server messages/parameters per animation message should be an acceptable priority, as SL itself is very enriched by animation, we all know the uncanny feeling of a sim of entirely static mesh.
These improvements would be especially helpful alongside the new potentials of LUA scripts, given LUA can handle sequenced and queued events with much more elegance than LSL.

Tapple Gao

Additional comments regarding Syncing

This is the part of the proposal I personally care the most about. One of my products (Mythril Teeglepet Dressage) was so prone to desync that I simulated the above proposal server-side, by not starting queued animations until a timer with the same duration as the animations went off. However, being server-side, it's still susceptible to unpredictable latency from download and cache load.

It wouldn't be awful if animation leader worked like sound master, and synced all following animations in the scene. However, unlike with sound, animations can be far apart and visually unrelated (due to vision being much higher bandwidth than hearing). Thus, I'd prefer that animations were only synced locally within one script, and not globally across the scene

Applications of Syncing

synced horse and rider animations
any other other couples animator where both partners aren't static and playing the same animation (sex animations are prime to desync)
advanced dance performances where every dancer is in sync, but not playing identical animations

Optional additional syncing features:

If the
ANIM_SYNC_FOLLOWING
animation has a loop-in period, the viewer starts it ahead of the next leader loop point so that the leading and following animations run their next loop point on the same frame

However, I think it's perfectly fine if animation meant for syncing should be expected to have no loop-in period

If the Leading animation is stopped, then Following animations tied to it also stop. However, these slave animations remain in viewer memory as if they are still playing. They start again when a new master animation is started. This allows re-syncing when the master animation duration needs to change
A way to sync sounds and animations. However:

This would require a new proposal
this hasn't actually been a problem that my customers complain about.
It might break content that uses
llLoopSoundMaster
, as it syncs based on the master nearest the camera, rather than a specified leader

Tapple Gao

Related Proposals from elsewhere on canny:

Queuing

Syncing

Property overrides

Speedup