Issues with rotation using keyframe animation

[Iva Rhapsody]

I am attempting to move an object from one waypoint to another, I want the object to rotate so that it's facing the next waypoint then move forward to the waypoint, rotate to face the next then move and so on, but the object will occasionally fail to face the new position andd move backwards etc.

 

Next()
{

    if (special==0 & on==TRUE)
    {   index++;
        if (index >= llGetListLength(targets))
        {
            index=0;
        }
        special = llList2Integer(specials,index);
        target = llList2Vector(targets,index);
        float dist=llVecDist(target,llGetPos());
        integer speed2=llList2Integer(speeds,index)+1;
        llSetTimerEvent( (7-speed2)*.1 );
        vector pos =  llGetPos();
        rotation rot = llRotBetween( <1.0,0.0,0.0>, llVecNorm( <target.x,target.y,pos.z> - pos ));
        llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_STOP]);
        llSetKeyframedMotion(
        [<0,0,0>,NormRot(rot/llGetRot()),.2,(target - pos)*rot,ZERO_ROTATION, dist*2/(speed2+1)],
        []);

 

rotation NormRot(rotation Q)
{
    float MagQ = llSqrt(Q.x*Q.x + Q.y*Q.y +Q.z*Q.z + Q.s*Q.s);
 
    return
        <Q.x/MagQ, Q.y/MagQ, Q.z/MagQ, Q.s/MagQ>;
}
    }  
}

Edited January 11, 2019 by Iva Rhapsody

[Rolig Loon]

That can happen if you try to execute a new KFM command while a previous one is running.  KFM motions are basically animations.  When you reach a waypoint, try stopping the current step explicitly with

llSetKeyframedMotion([ ],[ ]);

See if that helps.

[Iva Rhapsody]

I'll give that a shot is it functionally different then llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_STOP]);   ?

 

 

hmmm I seem to be getting the same results

 

Edited January 11, 2019 by Iva Rhapsody

[Rolig Loon]

59 minutes ago, Iva Rhapsody said:

hmmm I seem to be getting the same results

Well, it was worth trying.

1 hour ago, Iva Rhapsody said:

is it functionally different then llSetKeyframedMotion([],[KFM_COMMAND, KFM_CMD_STOP]);   ?

In theory, yes.  Using KFM_CMD_STOP will stop the animation but I am not sure that it empties the command lists as effectively as llSetKeyframedMotion([ ],[ ]); does.  You might try issuing that command at the start of your Next() function, however.  Because KFM is running as an animation, I believe that the servers still assume that its real position hasn't changed until you reach the end of one of your trip segments.  (That's analogous to the way that the servers don't think that you are moving at all while you are dancing at Frank's.)  So, if you grab values for your pos and rot variables before stopping the current movement, the system may assume that you meant the values at the start of the segment.

[Ichi Rexen]

Okay, this might not be it and probably isn't , but. Try if(index==llGetListLength...) at the minute you could be going one over the last entry in the list which will return nothing on anything called from the list. That might be why it's rotating weirdly

Edited January 11, 2019 by Ichi Rexen

[Iva Rhapsody]

still having issues and I can't understand why, anyone out there have any ideas ?

[steph Arnott]

4 hours ago, Iva Rhapsody said:

still having issues and I can't understand why, anyone out there have any ideas ?

The issue is this part.

rotation NormRot(rotation Q)

[Rolig Loon]

2 hours ago, steph Arnott said:

The issue is this part.

rotation NormRot(rotation Q)

I don't see why that's a problem here, Steph.  Can you explain? That's a fairly standard normalization function.  In fact, I added that specific bit of code as an example in the LSL wiki about 5 years ago.

[steph Arnott]

2 minutes ago, Rolig Loon said:

I don't see why that's a problem here, Steph.  Can you explain? That's a fairly standard normalization function.  In fact, I added that specific bit of code as an example in the LSL wiki about 5 years ago.

No result is being added to the frame. It just returns jibberish which does nothing here ' NormRot(rot/llGetRot()) ' The result needs adding then used. If that makes sense.

[Rolig Loon]

My mind must be slow today.  I still don't see the problem.  That function returns a normalized rotation to

On 1/11/2019 at 12:45 PM, Iva Rhapsody said:

llSetKeyframedMotion(   [<0,0,0>,NormRot(rot/llGetRot()),.2,(target - pos)*rot,ZERO_ROTATION, dist*2/(speed2+1)],  [ ]);

Where's the jibberish?

[steph Arnott]

Just now, Rolig Loon said:

My mind must be slow today.  I still don't see the problem.  That function returns a normalized rotation to

Where's the jibberish?

Where is the result being added to each frame? The old rot needs to be known, then the new and added for the new frame. Then normalized in the list. At the moment the llGetRot is a function within a list.

[Rolig Loon]

Oh, I see your point.  It's not the normalization routine that you're questioning.  I was totally focusing on the function, not noticing that the OP has buried it inside his own Next() function.  It's an awkward bit of formatting, so I missed seeing that one function is nested inside the other.  Nice catch, Steph.

[Qie Niangao]

On 1/11/2019 at 1:45 PM, Iva Rhapsody said:

the object will occasionally fail to face the new position andd move backwards etc.

Does this mean the object fails to move to the next waypoint, or that it moves there while facing the wrong direction?

If the latter: I'm always queasy about llRotBetween(), which is said in the wiki to be flaky when the direction vectors are nearly opposite. Just to rule that out, I might try the suggested drop-in replacement and see if it makes any difference.

[Qie Niangao]

1 minute ago, Rolig Loon said:

one function is nested inside the other

But... that would compile??

[Rolig Loon]

1 minute ago, Qie Niangao said:

If the latter: I'm always queasy about llRotBetween(), which is said in the wiki to be flaky when the direction vectors are nearly opposite.

I assume that's why the OP has decided to normalize the rotation, Qie.  That might make sense if he's dealing with small angle changes from one waypoint to the next.

[Rolig Loon]

2 minutes ago, Qie Niangao said:

4 minutes ago, Rolig Loon said:

one function is nested inside the other

But... that would compile??

It shouldn't.  So either the OP has posted something other than his working code or there's magic afoot.

[steph Arnott]

2 minutes ago, Rolig Loon said:

It shouldn't.  So either the OP has posted something other than his working code or there's magic afoot.

With LSL i would not be suprised it did compile and simply ignore the function.

[Rolig Loon]

Just now, steph Arnott said:

With LSL i would not be suprised it did compile and simply ignore the function.

Heh.  I don't quite believe in that much magic.  😎

[steph Arnott]

3 minutes ago, Rolig Loon said:

Heh.  I don't quite believe in that much magic.  😎

Depends on the magic or it could be simply read it as text. Who knows. It is wrong any way.