LlSetKeyframedMotion for Linked prim

[Atami Merlin]

I thought unsurely about robotics or mechanism with junctioned arms. Some would be the physical base for A.I. ,  pets, steamed punk mech or other machines/creatures. 

To that end, we need a mechanism for moving linked parts in synchronized timing. In a nutshell, It should work as something like "Pseudo junction motor"

I guessed it would come to realization with llSetLinkPrimitiveParamsFast and its sliced time use and eccentric rotation etc. , but llSetKeyframedMotion came.

I tested it and saw ball went up and down by 10cm in PingPong motion. it's set in 0.5sec on my 20fps viewer "Phoenix". It still has penalties of missing some frames.

I or We should wait llLinkedSetKeyframedMotion?

[Miranda Umino]

if you  paste a part of your code , we could help you .

 

if i understand , you have a light drift ? There is one drift who is caused when your framekey is not a multiple of the time of one frame .

For instance :

The sim is ruled with 45 Frames per seconds theorically  ( your frame/per seconds of the viewer is not important . The variable  frames per seconds of the sim is not important  neither. Only the FPS theoric is important . On the grids of secondlife its always 45 FPS .But there are some grids with OpenSim where the theoric FPS is 50 FPS . Nevertheless , llSetKeyFramedMotion is not implemented yet in these grids ).

You anime  10 meters in one axis in 2 seconds and 10 meters in the opposite axis in 0.7 seconds. Theorically at the end of the animation you should have kept the same position.

But 0.7 seconds = 31.5 frame . 31.5 is not  integer , so the decimal part of 31.5 is not played . So you loose the information of  movement of 0.5 frame .

The velocity of your prim is 10 m / 0.7 seconds = 14.2857 m/sec 

0.5 frame at this velocity =  (14.2857 * 0.5 ) / 45 = 0.1587 m. It explains your drift

 

 

To fix it  , change 0.5 seconds by 22.0/45.0  or 23.0/45.0. It s very near of 0.5 seconds , but it  will fix your main shift .

 

Now after to have fixed this , you should see again a shift . But very low for a cube 0.5 m with a motion of 10 m  . Something like 0.001 meters . It exists too a shift about rotations . Sometimes it can reach 0.02 degrees per keyframe .. 

 

 

Now i ve readen you move only of 0.1 meters .. Maybe you could watch again a drift important . I guess , but i am not sure that , it s because the sim doesn t handle positions with full precisions but with a gap .

when the items are small or keymotion are small, every frame , the position is rounded to stick at the grid of the sim .

And finally after several frames there is a drift important   .

It s just an intuition . I need to prove it mathematically

 

 The third drift who can exist is because your velocity is too low . For instance your animmation goes 0.1 meter on X axis in 4 seconds and -0.1 meter  in the opposed axis X quicly below the second . And you loop your animation .. In reality , only some frames are played in the first part of the loop and it does 0. 022 meter on the X positive  axis  and 0.1 meter on the X negative axis /

 

The fourth drift i know is to touch your prim when it moves . There is no BLOCK_GRAB status . There are no llTouchFilter as it exists llCollisionFilter, and your motion is altered 

Well .. It does many problems . And there are other things not explained 

 

[Atami Merlin]

Sorry, my test below aborted with a message "Delta times must be >0.1s"

I think it means that two places of decimals are not allowed ???

 

float   time = 0.5;float   iv;integer sw;default{    state_entry(){        llSetLinkPrimitiveParamsFast(LINK_THIS,             [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);        iv= llCeil(time*45)/45;    }    touch_start(integer total_number){        if(!sw){            llSetKeyframedMotion(                [<0,0,0.1>, iv, <0,0,-0.1>, iv]               ,[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);            sw=1;        }else{            llSetKeyframedMotion([] ,[KFM_COMMAND, KFM_CMD_STOP]);            sw=0;        }    }}

 

[Miranda Umino]

You write

 

iv= llCeil(time*45)/45

 

But , 45 is an integer typed . So the result of the division will be an integer  ( even if the result is stored in a float)

Fot time = 0.5 , iv = 0.0000  with this formula .

 

You need to force the division in float 

either by

iv= llCeil(time*45)/45.0

either by

iv= llCeil(time*45)/(float)45

 

 

[Atami Merlin]

Thank you for your replies.

The ball bounced smoothly. But I saw the start point of bouncing unexpectedly got out of placed position. It also stopped at the same misguided position. Reset of script was inefficient to correct it.

So I knew it was the drift what you said.

Anyhow I appreciate your intuition. I've seen similar phenomena in sculpt animation and very thin sliced time motion by llSetLinkPrimitiveParamsFast. But I thought it caused by my feeble PC power. 

[Rolig Loon]

When that happens, you can always cheat by doing a final llSetPos after the motion ends, to place the object where it should have stopped.

[Atami Merlin]

Thx for your reply.

 If that motion is allowed, piston rages out of cylinder, elevator goes through shaft,,,,etc.

[Miranda Umino]

I don t think you meet a drift but you meet an inaccuracy .

 

I have modified your script to be able to test with different values of times and heights an test if the prim has reached the limits

 

For small moves , i will tell < 0.2 meters , the movement is inaccuracy , but it doesn t drift from one time to an another time 

For instance with a move of 0.15 meters and an intitial height of 25 meters  have

OUT OF BOUNDS p=<105.32670, 138.10400, 24.96087> t=2011-12-06T15:06:08.347683Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.97392> t=2011-12-06T15:06:08.391186Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.98696> t=2011-12-06T15:06:08.437041Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.98696> t=2011-12-06T15:06:09.191955Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.97392> t=2011-12-06T15:06:09.236484Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.96087> t=2011-12-06T15:06:09.281234Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.98696> t=2011-12-06T15:06:12.259004Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.97392> t=2011-12-06T15:06:12.304179Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.96087> t=2011-12-06T15:06:12.348156Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.94783> t=2011-12-06T15:06:12.392698Z
[07:06] Object: OUT OF BOUNDS p=<105.32670, 138.10400, 24.96087> t=2011-12-06T15:06:12.437836Z

 

float   time = 0.5;float   iv;integer sw;vector offset = <0.0,0.0, 0.2>;float initial_height = 25.0;default{    state_entry(){        llSetLinkPrimitiveParamsFast(LINK_THIS,             [PRIM_PHYSICS_SHAPE_TYPE, PRIM_PHYSICS_SHAPE_CONVEX]);        iv= llCeil(time*45)/45.0;        llSetStatus(STATUS_BLOCK_GRAB, TRUE);    }    touch_start(integer total_number){                llOwnerSay("p="+(string)llGetPos()+ " t="+llGetTimestamp());        if(!sw){            llOwnerSay("time between keyframes in frames "+(string)(iv*45.0));            vector v = llGetPos();            while ( v.z != initial_height )            {                v.z = initial_height;                llSetPos(v);                v = llGetPos();            }            llSetTimerEvent( 1.0/45.0) ;            llSetKeyframedMotion(                [offset, iv, -offset, iv]               ,[KFM_DATA, KFM_TRANSLATION, KFM_MODE, KFM_PING_PONG]);            sw=1;        }else{            llSetKeyframedMotion([] ,[KFM_COMMAND, KFM_CMD_STOP]);            llSetTimerEvent( 0.0) ;            sw=0;        }    }    timer()    {        vector v = llGetPos();        if ( ( v.z < initial_height)||( v.z > ( initial_height + offset.z) ) )        {            llOwnerSay("OUT OF BOUNDS p="+(string)v+ " t="+llGetTimestamp());         }            }}

 I don t meet any problems with moves >= 0.2 meter ( except at the start of the animation but it s quicly resynced and doesn t happen anymore)

 

It happens too only because your second framekey is opposite to the the first framekey . If you do

0.1 up , 0.1 up , 0.1 up , you will have 0.3 without loss of accuracy . But if if you 0.1 up , 0.1 down you loose some accuracy . 

 

When you stop an animation it doesn t stop in one keyframe  postition (execpt if you have luck) but between keyframes.

[Atami Merlin]

My result is below.

Initial height was 29.6  It's above my bar counter. I saw the ball suddenly went up to about 29.8 after this sequence and never went down under 29.6. it bounced at 29.6 as lowest height.

I tested it on RC LeTigre 11.11.30.245889 server SIM.

[07:51] Object: time between keyframes in frames 23.000000
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.59130> t=2011-12-06T15:51:16.367088Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.57391> t=2011-12-06T15:51:16.410334Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.55652> t=2011-12-06T15:51:16.454640Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.53913> t=2011-12-06T15:51:16.500046Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.52174> t=2011-12-06T15:51:16.543538Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.50435> t=2011-12-06T15:51:16.590663Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.48696> t=2011-12-06T15:51:16.634741Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.46957> t=2011-12-06T15:51:16.678288Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.45218> t=2011-12-06T15:51:16.722991Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.43478> t=2011-12-06T15:51:16.766898Z
[07:51] Object: OUT OF BOUNDS p=<92.22149, 102.99250, 29.40870> t=2011-12-06T15:51:16.855145Z

 

I saw SVC-7462 and knew "drift" was detected by system.