Key Frame Movement Help

[Imsu]

Greetings all

So a friend and I are working on a little animation using KFM (quite inexperienced, heads up) 

The object moves up, rotates, moves back down.

        llSetLinkPrimitiveParamsFast(LINK_THIS, [
            PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX,
            PRIM_PHANTOM, TRUE,
            PRIM_PHYSICS, FALSE
        ]);
        llSleep(0.5); // Small delay just to make sure that physical shape was applied
        llSetKeyframedMotion(
            [<0.0, 0.0, 0.08>, 0.3],
            [KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_FORWARD]);
            llSleep(0.3);
            turn();
            llSleep(0.1);
            llSetKeyframedMotion(
            [<0.0, 0.0, -0.08>, 0.3],[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_FORWARD]
        );

What's puzzling us is that sometimes (not every time) the object will not return to it's original height, it will end up lower on the Z axis than when it started. We were wondering if anyone had any insight as to why that might be the case.

Now I don't have the code to hand but she's added something to it that sets the objects starting position based on where they click on the floor. Using debug I can see the coordinates are correct, and like I said most of the time the object will return to that exact position with no issue.

I hope there's enough information here to brainstorm without the additional code (I'll have to get a copy of it another time but wanted to get a head start thinking about it)

 

Thank you

[Quistess Alpha]

1 hour ago, Imsu said:

it will end up lower on the Z axis than when it started.

I'm not sure if it affects Keyframe Motion, but you could try setting the physics gravity to 0 and see if that helps: llSetPhysicsMaterial(GRAVITY_MULTIPLIER,0,0,0,0);

The unfortunate reality though is that keyframe motion just wasn't built to be 100% accurate. The normal 'solution's are to either recalculate the keyframes periodically to account for any error that has accumulated, or to directly set the position of the object (llSetRegionPos()) to where you expected the object to land after the keyframe motion is finished.

[Imsu]

1 hour ago, Quistess Alpha said:

I'm not sure if it affects Keyframe Motion, but you could try setting the physics gravity to 0 and see if that helps: llSetPhysicsMaterial(GRAVITY_MULTIPLIER,0,0,0,0);

The unfortunate reality though is that keyframe motion just wasn't built to be 100% accurate. The normal 'solution's are to either recalculate the keyframes periodically to account for any error that has accumulated, or to directly set the position of the object (llSetRegionPos()) to where you expected the object to land after the keyframe motion is finished.

Thanks Quistess. Is it possible to set the position relative to wherever the object might be rezzed? I've only ever done it by exact coordinates.

[Quistess Alpha]

3 minutes ago, Imsu said:

Is it possible to set the position relative to wherever the object might be rezzed?

KFM is already relative. Adding some checks to your example might look like:

llSetLinkPrimitiveParamsFast(LINK_THIS, [
    PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX,
    PRIM_PHANTOM, TRUE,
    PRIM_PHYSICS, FALSE
]);
llSetPhysicsMaterial(8,0,0,0,0); // set 0 gravity. (may have no effect)
llSleep(0.5);
vector posStart = llGetPos(); // remember where we start.
llSetKeyframedMotion( // unchanged.
   [<0.0, 0.0, 0.08>, 0.3],
   [KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_FORWARD]);
llSleep(0.32); // adding an extra millisecond or two might help ensure we don't wake up too early.
turn();
llSleep(0.12);
vector posNow = llGetPos(); // expect this to be roughly posStart+<0,0,0.08>, but not exactly.
llSetKeyframedMotion(
    [posStart-posNow, 0.3], // difference should be roughly <0,0,-0.08>
    [KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_FORWARD]);
llSleep(0.32);
llSetRegionPos(posStart); // force exact landing. 

 

[Profaitchikenz Haiku]

Quote

What's puzzling us is that sometimes (not every time) the object will not return to it's original height, it will end up lower on the Z axis than when it started. We were wondering if anyone had any insight as to why that might be the case.

 

I've seen this particularly in things that are making small regular movement. I think it's the server sometimes not being quick enough to catch what is in effect a very small movement. For example, I have a pub sign that is meant to swing gently from side to side through a few degrees of arc, but it frequently rachets it's way up one side or the other.

 

The answer is to have a defined stating point, (and sometimes even a defined ending point) and use the moving_end() event to do two things:

stop keyframed motion

Set position and/or rotation to where it should have got to according to the initial position and specified translation.

moving_end() // beware my typos :)
{
  llSetKeyframedmotion([],[]);
  llSetRegionPos(startPos + deltaPos)
  // and then let something (timer, touch, etc trigger the next movement
}

ETA:

A further couple of points have struck me

 

1) Keframed motion objects are phantom anyway whilst moving, so you only need to do something when KFM stops, ie set it non-phantom 

2) I think that the root prim of the object should be physics type prim and all children convex? I wonder if this is the cause of the drift you are seeing? The server is going to be less concerned with precise positioning of a a convex hull object than a prim one?

Edited September 25 by Profaitchikenz Haiku

[Imsu]

Thank you both for your interesting comprehensive replies! This gives me some food for thought and something to kick around when we look at it later  x