Working with radians

Hey folks,
Thanks to everyone who has helped me so far - greatly appreciated!!

Today, I am working on rotations. Here's a couple lines I'm looking at:

vRadBase = llRot2Euler(llGetRot());
llSetRot( llEuler2Rot(<0.0, 0.0,Z>)

I'm looking for how to calculate the value of "Z". I want to rotate a prim 120 deg from its current position. Now if I understand right, the vector value is something between 0-PI-0. Is there an easy way to add or subtract TWO_PI/3 rads or do you do it long hand?

As usual - thanks in advance for your replies

You can use the built-in constants RAD_TO_DEG and DEG_TO_RAD to convert from radians to degrees and back.


llSetRot (llEuler2Rot (<0.0, 0.0,Z> * DEG_TO_RAD)) is your friend.

edit:

I haven't played with rotations in a while but I think you want..

llSetRot (llGetRot() * llEuler2Rot (<0.0, 0.0, 120.0> * DEG_TO_RAD))

..to add 120 degrees rotation to the objects current Z.

OK

so convert to degrees - do my thing ie. add 120 - then convert back to rads?

Sounds much easier - thank you.

You could always just use the built-in conversion factors DEG_TO_RAD or RAD_TO_DEG, as in

vector xyz_angles = <0,1.0,0>;
vector angles_in_radians = xyz_angles*DEG_TO_RAD;

ETA: LOL.. She's faster than I am....

Oooo

I like that line!

Of course, 'TWO_PI/3.0' is certainly quite readable as well. I'd personally prefer it over '120.0*DEG_TO_RAD', though I have a pretty extensive mathematical background. If you're initializing a global variable, neither will work and you might want to calculate the literal value with an in-line comment reminding the viewer that it is actually pi/3 or 120 degrees converted to radians or whatever.

(edit)

I removed this because the next comment more clearly defines the issue.

Well I'm so confused I am replying to myself in the forums now...

I'm turning a prism relative to a box which is tilted on its X 90 deg so that its local Y axis is pointed straight up. the prism begins at zero rotation.

I want to rotate the prism on Z 1 deg at a time and the following works just fine...

rot_xyzq=llEuler2Rot(<0,0,1>*DEG_TO_RAD);
llSetLocalRot(llGetRot()*rot_xyzq/llGetRootRotation());

... until I rotate the the linked set on the world x or y axis. I can rotate it on z with no problem. I am repeating the above 30 times (with 4 scripts) for a total of 120 deg rotation on each call. If I don't use 4 scripts it is slow and jerky.

this method seems to work fine:

rot_xyzq=llEuler2Rot(<90,0,1>*DEG_TO_RAD);
llSetRot(rot_xyzq/llGetRootRotation());

except I can't repeat it with multiple scripts in parallel because it has to be 1 deg change, then 2 deg change, then 3 etc. With the first method I can just repeat the second line as many times as required.

Can someone offer a suggestion?

Non-physical movement/rotation will always look jerky unless you use multiple scripts because calling llSetPos or llSetRot will cause your script to sleep for 0.2 seconds. That's just the way scripts are - things that LL deems 'expensive' are limited in how often a script can call them. In this case, there's a delay because you're updating the object and the sim has to send that update to anybody who can see it - not something you want getting spammed.

Have you looked at llTargetOmega? That will start a smooth, continuous rotation with just one function call and doesn't require the object to be physical. http://wiki.secondlife.com/wiki/LlTargetOmega

Sindy,
Where llTargetOmega is client side it isn't possible to determine its rotation or make it stop at 120 degrees is it?

Not that I know of. You might also want to look at llLookAt/llRotLookAt but I think those both require the object to be physical..

No, those work for both physical and non-physical objects/prims.

/llRotLookAt won't work on a linked set will it? It has some other attributes that make it difficult as well such as damping.

I may have to end up using the:

rot_xyzq=llEuler2Rot(<90,0,1>*DEG_TO_RAD);
llSetRot(rot_xyzq/llGetRootRotation());

Then set up the four scripts to do like steps 1,5,9,13 in one, and 2,6,10, 14 in the next etc.

I was concerned about timing however. I can set millisecond start delays on each one (4th script starts after the third etc). But I have no idea if scripts stay in perfect sync as the run. If they go out of sync the prim would jerk back and forth. Do scripts stay in sync even through lag?

I had no idea I was asking for the impossible when I started this. I know how to pick them...