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)

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)