Talk:LlSetKeyframedMotion

Animation Types

Instead of setting integer Loop, let's reuse animation flags that was built for llSetTextureAnim function as list to combine flags usage.
LOOP REVERSE PING_PONG SMOOTH ROTATE SCALE and maybe add another flag POSITION(0x80)?

---

LOOP

Starts from the beginning to the end and returns back to the beginning to start again.

REVERSE

Played backward in following order of the list.

PING_PONG

Starts from the beginning to the end and play backward back to the beginning to start again.

SMOOTH

Could be used as another suggestion between sliding to the next target instead of "llSetPos"-like frames.

ROTATE, SCALE, and POSITION

Allow user to trim list down a bit without the needs to add all three at the same time. (Might be a wishful thinking though.)

---

Generally allow users to develop system that could have more than one LlSetKeyframedAnimation function call, long as it's not using same axis/scale/position again, which overrides the first of that same flag. One function call use position and second function call use rotation and scale for a type of event call.

I must point out a discussion about stopping, how do to about it. At the moment, suggesting use STOP(0x00) with combination of any flag from above? -- ₪ 03:07, 31 August 2011 (PDT)

These are great suggestions. I'd make a few tweaks, though:

• Only LOOP, PING_PONG, and maybe REVERSE make sense here (SMOOTH is implicit in the way keyframing works--it is always a smooth interpolation)
• ROTATE and TRANSLATE make sense and are a good way to reduce the size of the lists required. However, it would not be feasible to support multiple merging the keyframe sets from different calls (e.g., one call with ROTATE and one with TRANSLATE)
• SCALE is not possibly to implement for physical objects in a way that ensures satisfactory performance. Modifying the scale of a physics shape requires (in simplified terms): (1) rebuilding the shape from scratch, (2) removing the object from the world, (3) applying the new shape to the object, and (4) adding the object back into the world. #1, 2, and 4 are all expensive operations.

To stop the animation, you could simply pass in an empty list of keyframes.

Falcon Linden 19:11, 6 September 2011 (PDT)

As to how to supply these to the function, how about [..., ANIM_FLAGS, integer flags, ...]. -- Strife ^{(talk|contribs)} 11:01, 8 September 2011 (PDT)

About SMOOTH, I simply meant when it's not flagged to have SMOOTH, it would just skip straight to the next frame, no animating between the two frames.

As for ROTATE and POSITION(TRANSLATE), treat them separately instead of merging them as one. Which also would cut down the list further when you don't have to have a data at fixed "frame" from where they should perform.

I knew SCALE was a wishful thinking... Maybe only applied to phantom/attachment/hud prims, where physic doesn't apply? People are gonna want something like this for visual display. -- ₪ 09:35, 26 September 2011 (PDT)

Interpolation

I've got a couple ideas for interpolation:

1. Separate flags for configuring interpolation mode for position and orientation parameters. Defaults being LERP and SLERP respectively. Also some flags that provide smoother acceleration.
2. Allow the user to instead of supplying a vector or a rotation parameter in the list to supply a float, which should be in the range [0, 1] indicating a proportional interpolated position/orientation between previous and future frames. aka B-Frames
   • So [<0,0,0>, <0,0,0,1>, 0.0, 0.25, 0.0, 0.5, <4,0,0>, <0,0,0,1>, 1.0]
     • So by 0.5 seconds, the position is only <1,0,0> not, <2,0,0> and by 0.75 seconds it would be at <3,0,0>.
   • There is no real reason to restrict the user to the [0, 1] range, and the user may want to overshoot the end so they can mimic oscillating about the end point before reaching it (and having to calculate out the frames).

-- Strife ^{(talk|contribs)} 11:01, 8 September 2011 (PDT)

Hey Strife,

Your suggestion has some merit, but also comes with a few major drawbacks:

1. It makes the list more confusing to understand (and more error-prone to process)
2. It significantly complicates interpretation and processing of the keyframes (which, right can, can be almost directly passed to Havok for application to the physics body)
3. It's just plain harder to implement. This is important because, most likely, if this method comes to fruition, it will be implemented exclusively by yours truly and exclusively in my free time (aka when I'm not working on something else at LL and/or on weekends/evenings.) Since I'm only willing to give up so much of my free time to developing these features, we need to keep them as simple as possible. :)

Also, it's worth pointing out that accelerations will always be infinite or zero. That is, the object will always have constant linear and angular velocity and it will switch to new linear/angular velocities in a single simulation frame (aka infinite acceleration). Doing it any other way would remove all benefit from using Havok's keyframing system and would be equivalent to implementing a full-blown object animation system (which is not currently feasible). Surprisingly, I discovered that for reasonable velocities, these limitations don't have any noticeable visual artifacts.

All that said, it is possible that such a feature could be added in the future given the flexibility of the options list parameter.

Falcon Linden 18:51, 8 September 2011 (PDT)

No sweat really, it can be done by preprocessing the list in user code. -- Strife ^{(talk|contribs)} 19:19, 8 September 2011 (PDT)

KFA_DATA

I'm thinking that if KFA_DATA is required, than it shouldn't be part of the options but a function parameter. Does it need to be explicit? It could be inferred from the types in the list but that limits future syntax changes. On the flip side having it in the options simplifies serialization as you can then store them in the same list as opposed to a separate variable that must be (de)serialized along with the lists.

-- Strife ^{(talk|contribs)} 11:14, 16 September 2011 (PDT)

some thoughts

just heard about this, sounds really nice, a few thoughts came up when it got mention on the forums...

"Animation" seems kinda misleading to what it does as when on think 3d they tend to think of animation more like changing the relation of multiple parts, I suggested "Motion", Kaluura suggested "Target". mostly minor either way as long as it does what's expected of it.

Kalurra mentioned a callback, although I suppose the "Target" functions could work for that, they are all global, which both limits the use of the function and forces extra calculations to get the global frame.

and finally a minor tweak, allowing blank list items to be cast as the appropriate "zero", so that the list is more collapsible for items that don't change during a frame... that would allow the structure to be retained, but be less overhead for the script (I think).
-- Void ^{(talk|contribs)} 23:30, 17 September 2011 (PDT)

llSetPrimitiveAnimation()

Just heard about this via SCR-203, and wanted to point to an older issue of mine in the form of SVC-347, in case it has anything that needs considering, though this function proposal seems like it may be a better format overall.

I wanted to add that with regards to the timing restriction (no translations faster than 0.1 seconds), surely this restriction could be relaxed if the effect were somehow designated as client-side only, since client-side animation is the more desirable case for a lot of applications that would otherwise be very wasteful if done on the simulator-side. In particular, a lot of current animating objects such as prim NPC's could be replaced with a suitable prim-animation feature, however there wouldn't be much point if the simulator-side is still a bottleneck for lag, as even without the script-delay issue any network lag could still mess up effects. Related to this is the consideration of synchronising time features, both for simulator-side and client-side effects, as per SCR-13 and SVC-4897, as this could give us a better idea of what state the animation will be in at a particular moment.

Lastly, one other useful addition may be a PAUSE command that can set the object to a specific keyframe, or a LOOP_UNTIL or some such command; since a script cannot guarantee the state of the animation since 5 seconds of animation and 5 seconds of script wait or timer-delay may not always coincide as closely as expected.
-- Haravikk ^{(talk|contribs)} 12:06, 20 September 2011 (PDT)

In particular, what I'd like to see is the use of LOOP, PING_PONG etc. within the key-frames list. As these are integer constants it should be perfectly safe to do as the keyframes themselves are vectors and/or rotations and floats. In this way, if an integer is encountered, then it will simply set a new state for the rest of the animation. This could potentially be done using a bit-filed like so:

<lsl>llSetKeyframedAnimation(

   [
       COMMAND, PLAY, // Start the animation
       FLAGS, SMOOTH | EASE_IN, // Set flags for all following key-frames to use smooth interpolation, and "ease-in" (decelerating movement)
       LOOP, 3, // All following key-frames will loop a total of 3 times
           <0, 0, 10>, ZERO_ROTATION, 5.0, // Move up 10m in 5 seconds
           <0, 0, -10>, ZERO_ROTATION, 5.0, // Move down 10m in 5 seconds
       PING_PONG, 2, // End of previous loop, all following key-frames will ping-pong a total of 2 times (frames will play forward, then play back, then stop)
           <5, 0, 0>, ZERO_ROTATION, 1.0, // Move right 5m in 1 second
           <-5, 0, 0> ZERO_ROTATION, 1.0, // Move left 5m in 1 second
   ],
   TRUE // Animation is performed client-side only

); llSleep(60.0); llSetKeyframedAnimation([COMMAND, PLAY], TRUE); // Play the animation again client-side</lsl>

Either that, or a key-frame constant can be used, with two choices, so that one constant may be used to specify a short-hand keyframe (vector only or rotation only) or a full keyframe.
-- Haravikk ^{(talk|contribs)} 12:20, 20 September 2011 (PDT)

TRANSLATE: Regions or Local?

Starting to realize that we also might need an integer to set this Local or not. Any thoughts? -- ₪ 13:18, 4 November 2011 (PDT)

The problem is what happens when you add in KFM_ROTATION? Unless you have sat down and solved the equations for the movement, you won't know where your prim will end up. What you really want is the movement to be local to some starting rotation, not a continuously changing rotation. For the sake of everyones sanity (especially the implementors) there should be a [KFM_SHIFT_ROT, rotation rot] and [KFM_SHIFT_POS, vector pos] flags to allow the user to shift the entire animation, otherwise you have to translate ever single frame in the list if you want to tweak it... not fun. -- Strife ^{(talk|contribs)} 16:58, 5 November 2011 (PDT)