targetOmaga to key frame omega

[steph Arnott]

Could i get a procedure on the key framed version, i looked at the example but frankly was lost. Object rotates and stops on  a link message. Thats it.

[Rolig Loon]

Which example are you studying, Steph?

[steph Arnott]

I look at the wiki example, but am confuesed with what i need to add. Target omega has just one function, x.y,z, spin rate, key frame appears to need more info.

coded by Dora Gustafson

llSetKeyframedMotion( L+L+L, [KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_LOOP]);

i gather it something to do with this.

[Rolig Loon]

I don't see an example of llSetKeyframedMotion being used this way in the LSL wiki, but it's easyenough to write one.  Like this ....

integer gON;default{    touch_start(integer total_number)    {        llSetTimerEvent(0.5*(gON = !gON));    }        timer()    {        llSetKeyframedMotion([],[]);        llSetKeyframedMotion([llEuler2Rot(<0.0,0.0,PI/2>), 0.5],[KFM_DATA,KFM_ROTATION]);    }}

When you click on the object, it makes an endless number of smooth 90 degree rotations until you click it again.  The first statement in the timer event stops the previous keyframed rotation.  This example is functionally equivalent to writing a llTargetOmega script with llTargetOmega(<0.0,0.0,1.0>,PI,1.0), since it takes 2 full seconds to make a 360 degree turn.

 EDIT:  Small correction in llTargetOmega so that it, too, rotates PI radians per second.

[steph Arnott]

Thankyou, tho i be honest am still none the wiser. Can see everything is in a list, but thats about it. I will go thru all the wiki on these new ideas. BTW was reading this one http://wiki.secondlife.com/wiki/LlTargetOmega_Replacement

[steph Arnott]

Where do you suggest the best place start with this key frame stuff? As in reading.

[Rolig Loon]

Dora's script is really doing exactly what mine does, except that she is dividing the full 360 degree rotation into three 120 degree parts instead of four 90 degree parts.  Her use of llAxisAngle2Rot doesn;t have anything to do with the keyframed motion itself.  It's just that she is using it to calculate the rotation angle, while I specified it directly with llEuler2Rot.

Keyframed motion, as a basic concept, is fairly simple,  Basically, you are creating a parameterized server-side animation, dividing a path for your object to travel in a bunch of discrete steps.  Each step is defined by three parameters: (1) a distance, (2) a rotation, and (3) a travel time. So, for example, if you just want your object to move 2.0 m in the X direction for 5 seconds and to rotate 45 degrees around its Z axis while doing it, you'd write

llSetKeyframedMotion([<2.0,0.0,0.0>,llEuler2Rot(<0.0,0.0,PI/4>),5.0] , []);

The movement parameters for that step are all expressed as a single list (that first [ ] bracketed part of the statement, and any special conditions to be observed are expressed in the second list in the statement.  In this example, the empty list is simply saying, use the default conditions.  That is, act on a translation and a rotation, do it once, and that's it.  If you look at the wiki entry for llSetKeyframedMotion, you'll see that you could choose several special conditions instead, to make the object follow a looping path or a ping-pong one, for example.  In the script I posted above, the special condition that I used was [KFM_DATA,KFM_ROTATION], which means "Don't expect any translation.  There are only rotations in this path."  Dora did the same thing and also specified KFM_LOOP, which I could leave out because I was deliberately stopping the motion in each time step. (That's what llSetKeyframedMotion([],[]) means. )

If you have a more interesting path with multiple steps, then the list in that first set of [ ] brackets simply includes all of the individual steps, one after another ... [translation, rotation, time, translation,rotation, time, translation, rotation, time .... ].  You can make that list as long as it takes to describe the entire path, one chunk at a time.  Imagine describing the path that a car might follow from one waypoint to another for mile after mile after mile.  Each set of translation, rotation, time in the list describes what happens between one waypont and the next.

The best place to read is the wiki page itself, although you will find quite a few threads in the archives for this forum that include examples or discussions of finer points. I'd also suggest using SL's search function to look for any articles that the keyword phrase "keyframed motion" will bring up.

[steph Arnott]

OK, i understood all that, i have copy pasted your statement so i can re read it as a reference, unless you object. Really no need to reply unless you do, Thanks for the time you took, i appriciate it very much,bbee blessed.

[Dora Gustafson]

There is a good reason for using 120° parts
This way the rotation direction is given in a none ambiguous way
I experienced that with 180° parts the prim would sometimes spin one way and sometimes the other

Instead of ½ I decided to use ⅓ of a full circle

:smileysurprised::smileyvery-happy:

[Rolig Loon]

Yes, I understood that, Dora. I chose to use 90 degrees for the same reason.  It removes the ambiguity.

I should have been clear in my post that there is one other difference between your solution and mine.  You are using the KFM_MODE,KFM_LOOP parameter to make the object spin continually.  I used a timer event to do the same thing, matching the period of the timer to the period of the KFM step and then adding a llSetKeyframedMotion([],[]) statement as insurance.  Both methods work, it seems. I can't see a reason to prefer one over the other at the moment.

[Dora Gustafson]

Of course Rolig:)

Another difference you pointed out is in the way the rotation is calculated.
I chose llAxisAngle2Rot because I made a function to replace llTargetOmega
This function takes exactly the same parameter values as llTargetOmega but use no 'gain' parameter

:smileysurprised::smileyvery-happy:

[Rolig Loon]

Yes, I like that.  I don't use llAxisAngle2Rot as much as I ought to.  It's a handy function. I like the way you've applied it here.

[steph Arnott]

I just could not understand your example, i just wanted know what was needed to do in the new version as opposed to llTargetOmega and got lost. As i understand it, the angle from 0 to 30 is being devided by the time it needs to reaches the end angle. So 0deg would be the first frame and 30deg the last 2nd frame if 0.0sec was used. I think! Am sure that is correct.

[Dora Gustafson]

The spinrate (used here and for llTargetOmega) is how many radians per second the spin is

Say: one rotation per second gives a spinrate = 2π/1; [rad/second]

The KFM use a time which you get by: 2π/spinrate = 1 [second]

Since a full circle is composed of three parts the time for each part is (2π/3)/spinrate = ⅓ [second]

 

KeyFramedOmega( vector axis, float spinrate){    llSetKeyframedMotion( [], []);    if ( spinrate )    {                if ( spinrate < 0 ) v = -v;        list L = [llAxisAngle2Rot( axis/llGetRot(), v), ];        llSetKeyframedMotion( L+L+L, [KFM_DATA, KFM_ROTATION, KFM_MODE, KFM_LOOP]);    }}

 I hope this makes it more clear

:smileysurprised::smileyvery-happy:

 

[steph Arnott]

ok, thanks.