Jump to content
Iva Rhapsody

Issues with rotation using keyframe animation

Recommended Posts

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 by Iva Rhapsody

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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 by Iva Rhapsody

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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 by Ichi Rexen

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

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?

Share this post


Link to post
Share on other sites
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.

  • Thanks 1

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
1 minute ago, Rolig Loon said:

one function is nested inside the other

But... that would compile??

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.  😎

  • Like 1

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×