-Fukuju Amaterasu
====================================
October 12, 2016 (FINAL edit: 15OCT16)
Hi all movers (and shakers :-)
I am the artistic director of Ballet Pixelle.
Ballet Pixelle uses original animations (almost all created by myself). The dancers do not use any HUDs, poseballs, or synchronizing devices of any kind!
In SL, only 26 bones of the 206 bones in the human body are allowed. And SL animations always return to the starting position -- that's why you sometimes see "snapback". Synchronization of when you and another person see movement is dependent on each each person's client-SL server latency, load, and bandwidth. And importantly, the music is from a different source (server) than the animations and that path and latency to each person is different.
I am proposing an advanced group discussion and workshop on "Animation Creation". I think [JIRA] BUG-7729 (llStartAnimationSynced() would be a good starting point. I would love to exchange information with people smarter than me! It would be open to all who create animations, but especially dance animators and scripters. Would you or someone you know be interested? Please let me know by IM or notecard.
Thanks!
Inarra Saarinen
Artistic Director
Animator & Choreographerr
Ballet Pixelle
balletpixelle.org
https://en.wikipedia.org/wiki/Ballet_Pixelle
***
A good introduction:
http://avastar.online/knowledge/the-sl-skeleton/
The JIRA:
https://jira.secondlife.com/browse/BUG-7729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
Haravikk Mistral updated BUG-7729:
----------------------------------
Description:
h1. How would you like the feature to work?
This proposal is for the following new function:
{code:title=New Function}llStartAnimationSynced(string anim, list timestamp);{code}
It behaves identically to [{{llStartAnimation()}}|http://wiki.secondlife.com/wiki/LlStartAnimation] except that it takes an additional parameter specifying a timestamp with millisecond accuracy. The first value in the timestamp takes the time in seconds (such as you would get with [{{llGetUnixTime()}}|http://wiki.secondlife.com/wiki/LlGetUnixTime]) and the second is a fractional part for milliseconds, nanoseconds etc, with a view toward SL gaining a function to provide such a timestamp directly (see [{{llGetUnixTimeFraction()}}|https://jira.secondlife.com/browse/BUG-7731]).
Basically when an animation is triggered this way, the time-stamp is used to determine when the animation should have started. When the animation does eventually download on the viewer, the viewer can then synchronise the animation to this time-stamp, likewise when the animation loops etc.
For example, if I were to call {{llStartAnimationSynced()}} with the current timestamp, triggering a 30 second animation that takes 10 seconds to download. Then instead of the viewer playing the animation from the start, it would play from 10 seconds in. If another viewer connects and a looping, synchronised animation is already in progress then it will likewise try to start from the correct point; for example if the animation is still 30 seconds, but was synchronised to a time 140 seconds ago, then the animation should begin at the 20 second (140 modulo 30) mark.
h1. Why is this feature important to you? How would it benefit the community?
Currently animations in SL are a bit of a crapshoot; you trigger an animation but have no idea when it will download for each nearby viewer, which can result in all kinds of oddities such as an avatar suddenly doing something that is no longer relevant.
Even worse is when two animations are supposed to occur simultaneously, or a single animation is supposed to coincide with some kind of object effect. For example say you wanted to give another avatar a high-five; the action necessarily requires two different animations (unlike most hug emotes) but with no way to synchronise them you will almost always end up with each avatar slapping wildly at the air, unless the animations were already cached from earlier.
was:
h1. How would you like the feature to work?
This proposal is for the following new function:
{code:title=New Function}llStartAnimationSynced(string anim, integer tsSeconds, float tsFraction);{code}
It behaves identically to [llStartAnimation ()|http://wiki.secondlife.com/wiki/LlStartAnimation] except that it takes two additional parameters specifying a timestamp. The first takes the timestamp in seconds (such as you would get with [llGetUnixTime()|http://wiki.secondlife.com/wiki/LlGetUnixTime]) and the second is a fractional part for milliseconds, nanoseconds etc, with a view toward SL gaining a function to provide such a timestamp.
Basically when an animation is triggered this way, the time-stamp is used to determine when the animation should have started. When the animation does eventually download on the viewer, the viewer can then synchronise the animation to this time-stamp, likewise when the animation loops etc.
For example, if I were to call {{llStartAnimationSynced()}} with the current timestamp, triggering a 30 second animation that takes 10 seconds to download. Then instead of the viewer playing the animation from the start, it would play from 10 seconds in. If another viewer connects and a looping, synchronised animation is already in progress then it will likewise try to start from the correct point; for example if the animation is still 30 seconds, but was synchronised to a time 140 seconds ago, then the animation should begin at the 20 second (140 modulo 30) mark.
I just want to note that the time-stamp implementation isn't strict; it depends what the best way to implement it would be since LSL still has no support for 64-bit integers. Unless we're going to get 64-bit support in LSL any time soon, then integer + float is my preferred method, as it gives good compatibility with the widest range of functions including [llSleep()|http://wiki.secondlife.com/wiki/LlSleep] for example.
h1. Why is this feature important to you? How would it benefit the community?
Currently animations in SL are a bit of a crapshoot; you trigger an animation but have no idea when it will download for each nearby viewer, which can result in all kinds of oddities such as an avatar suddenly doing something that is no longer relevant.
Even worse is when two animations are supposed to occur simultaneously, or a single animation is supposed to coincide with some kind of object effect. For example say you wanted to give another avatar a high-five; the action necessarily requires two different animations (unlike most hug emotes) but with no way to synchronise them you will almost always end up with each avatar slapping wildly at the air, unless the animations were already cached from earlier.
> llStartAnimationSynced() - synchronised animation support
> ---------------------------------------------------------
>
> Key: BUG-7729
> URL: https://jira.secondlife.com/browse/BUG-7729
> Project: 1. BUG Project
> Issue Type: New Feature Request
> Security Level: Public
> Environment: Feature
> Reporter: Haravikk Mistral
>
> h1. How would you like the feature to work?
> This proposal is for the following new function:
> {code:title=New Function}llStartAnimationSynced(string anim, list timestamp);{code}
> It behaves identically to [{{llStartAnimation()}}|http://wiki.secondlife.com/wiki/LlStartAnimation] except that it takes an additional parameter specifying a timestamp with millisecond accuracy. The first value in the timestamp takes the time in seconds (such as you would get with [{{llGetUnixTime()}}|http://wiki.secondlife.com/wiki/LlGetUnixTime]) and the second is a fractional part for milliseconds, nanoseconds etc, with a view toward SL gaining a function to provide such a timestamp directly (see [{{llGetUnixTimeFraction()}}|https://jira.secondlife.com/browse/BUG-7731]).
> Basically when an animation is triggered this way, the time-stamp is used to determine when the animation should have started. When the animation does eventually download on the viewer, the viewer can then synchronise the animation to this time-stamp, likewise when the animation loops etc.
> For example, if I were to call {{llStartAnimationSynced()}} with the current timestamp, triggering a 30 second animation that takes 10 seconds to download. Then instead of the viewer playing the animation from the start, it would play from 10 seconds in. If another viewer connects and a looping, synchronised animation is already in progress then it will likewise try to start from the correct point; for example if the animation is still 30 seconds, but was synchronised to a time 140 seconds ago, then the animation should begin at the 20 second (140 modulo 30) mark.
> h1. Why is this feature important to you? How would it benefit the community?
> Currently animations in SL are a bit of a crapshoot; you trigger an animation but have no idea when it will download for each nearby viewer, which can result in all kinds of oddities such as an avatar suddenly doing something that is no longer relevant.
> Even worse is when two animations are supposed to occur simultaneously, or a single animation is supposed to coincide with some kind of object effect. For example say you wanted to give another avatar a high-five; the action necessarily requires two different animations (unlike most hug emotes) but with no way to synchronise them you will almost always end up with each avatar slapping wildly at the air, unless the animations were already cached from earlier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira