You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Mar 28, 2024. It is now read-only.
This proposal is for a new option for llSetKeyframedMotion() called KFM_SYNC_TIME which will take an integer and a float describing a time against which the animation will be synchronised. It effectively depends upon:
KFM_STRICT_TIMING: as this will implement the basic capabilities required for synchronising the animation timing.
Once a timestamp is set for a keyframed motion, the motion will be synchronised such that it is at the correct position as if it had started at exactly the specified time; if the time is in the future then the motion will instead be delayed until the specified time. As long as KFM_STRICT_TIMING is set, the animation will also be periodically re-synchronised to guarantee that no drift in timing occurs, or that it is corrected as soon as possible.
For example, if an animation has a frame that last five seconds, but its timestamp was set for one second in the past, then the animation should begin one second in. If the time were 8 seconds ago, then the animation would begin 3 seconds into the next frame and so-on.
Why is this feature important to you? How would it benefit the community?
The aim of this feature is to guarantee the start-time of a key-framed motion in order to eliminate any possible lag or delays in a script, and also crucially to more easily synchronise animations between multiple objects, e.g - picture a pair of sliding doors that meet in the middle, but are animated to give the impression that they're stuck (constantly closing then re-opening); any drift in timing could result in one door closing as the other opens, and similar oddities, but with a sync time and strict timing set they should appear correctly every time.
KFM_SYNC_TIME - Synchronised Timing for llSetKeyframedMotion()
Type
New Feature Request
Priority
Unset
Status
Been Triaged
Resolution
Triaged
Reporter
Haravikk Mistral (haravikk.mistral)
Created at
2014-11-22T15:11:16Z
Updated at
2016-10-06T14:39:02Z
{
'Business Unit': ['Platform'],
'How would you like the feature to work?': 'This proposal is for a new option for [{{llSetKeyframedMotion()}}|https://wiki.secondlife.com/wiki/LlSetKeyframedMotion] called {{KFM_SYNC_TIME}} which will take an integer and a float describing a time against which the animation will be synchronised. It effectively depends upon:\r\n\r\n* [{{KFM_STRICT_TIMING}}|https://jira.secondlife.com/browse/BUG-7767]: as this will implement the basic capabilities required for synchronising the animation timing.\r\n* [{{llGetUnixTimeFraction()}}|https://jira.secondlife.com/browse/BUG-7767]: as this will produce suitable timestamps for use in the function.\r\n\r\nOnce a timestamp is set for a keyframed motion, the motion will be synchronised such that it is at the correct position if it had started at exactly the specified time; if the time is in the future then the motion will be delayed until the specified time. As long as {{KFM_STRICT_TIMING}} is set, the animation will also be periodically re-synchronised to guarantee that no drift in timing occurs, or that it is corrected as soon as possible.\r\n\r\nFor example, if an animation has a frame that last five seconds, but its timestamp was set for one second in the past, then the animation should begin one second in. If the time were 8 seconds ago, then the animation would begin 3 seconds into the next frame and so-on.',
'Severity': 'Unset',
'Target Viewer Version': 'viewer-development',
'Why is this feature important to you? How would it benefit the community?': "The aim of this feature is to guarantee the start-time of a key-framed motion in order to eliminate any possible lag or delays in a script, and also crucially to more easily synchronise animations between multiple objects, e.g - picture a pair of sliding doors that meet in the middle, but are animated to give the impression that they're stuck (constantly closing then re-opening); any drift in timing could result in one door closing as the other opens, and similar oddities, but with a sync time and strict timing set they should appear correctly every time.",
}
The text was updated successfully, but these errors were encountered:
How would you like the feature to work?
This proposal is for a new option for
llSetKeyframedMotion()
calledKFM_SYNC_TIME
which will take an integer and a float describing a time against which the animation will be synchronised. It effectively depends upon:KFM_STRICT_TIMING
: as this will implement the basic capabilities required for synchronising the animation timing.llGetUnixTimeFraction()
: as this will produce suitable timestamps for use in the function.Once a timestamp is set for a keyframed motion, the motion will be synchronised such that it is at the correct position as if it had started at exactly the specified time; if the time is in the future then the motion will instead be delayed until the specified time. As long as
KFM_STRICT_TIMING
is set, the animation will also be periodically re-synchronised to guarantee that no drift in timing occurs, or that it is corrected as soon as possible.For example, if an animation has a frame that last five seconds, but its timestamp was set for one second in the past, then the animation should begin one second in. If the time were 8 seconds ago, then the animation would begin 3 seconds into the next frame and so-on.
Why is this feature important to you? How would it benefit the community?
The aim of this feature is to guarantee the start-time of a key-framed motion in order to eliminate any possible lag or delays in a script, and also crucially to more easily synchronise animations between multiple objects, e.g - picture a pair of sliding doors that meet in the middle, but are animated to give the impression that they're stuck (constantly closing then re-opening); any drift in timing could result in one door closing as the other opens, and similar oddities, but with a sync time and strict timing set they should appear correctly every time.
Links
Depends on
Original Jira Fields
The text was updated successfully, but these errors were encountered: