Target Omega Local Rotation

[Emma Krokus]

1. My head has trouble getting around rotations.

2. I may not be using the right terminology.

I have a multi-prim rotating object which uses llTargetOmega in its root prim. Works fine with tweaks to vectors in llTargetOmega as long as the rotation is at right angles (0, 90, 270).

Goes wonky, weaves as though drunk (<< technical terms) when it's anything other, e.g. 95 degrees. 

Can I make it rotate nice and straight when, say, its Z axis is at 95 degrees?

The script:

integer switch;

default
{
    touch_start(integer num_detected)
    {
        if (switch)
        {
            llTargetOmega(<0,0,0>, 0.0, 0.0);//OFF
            llStopSound();
            switch = !switch;
        }
        else
        {
            llTargetOmega(<0,-7,0>, 0.36, 0.3);//ON
            llLoopSound("sound_UUID", 1.0);
            switch = !switch;
        }
    }
}

Maybe what I want can't be done with llTargetOmega?

Should I be using llSetPrimitiveParameters for the rotation instead? Maybe a function that updates the rotation according to the root prims rotation? An example would be much appreciated!

Thank you for pointers in the right direction.

Emma  

Edited November 18, 2020 by Emma Krokus

[Qie Niangao]

If I understand what's wanted here, try this:
 llTargetOmega((<0,-7,0>*DEG_TO_RAD)*llGetRot(), 2.36, 0.3);//ON

That DEG_TO_RAD conversion is only necessary if the -7 is in degrees, not radians. And assuming the script is in the root prim, applying *llGetRot() should make the spin "straight" relative to that root prim's orientation.

[Emma Krokus]

30 minutes ago, Qie Niangao said:

If I understand what's wanted here, try this:
 llTargetOmega((<0,-7,0>*DEG_TO_RAD)*llGetRot(), 2.36, 0.3);//ON

That DEG_TO_RAD conversion is only necessary if the -7 is in degrees, not radians. And assuming the script is in the root prim, applying *llGetRot() should make the spin "straight" relative to that root prim's orientation.

That does exactly what I wanted - thank you so much, Qie. And yes, the script is in the root prim. Your explanation is much appreciated.

I really had to crank up the float spinrate (to 23.0) to get anything resembling the original speed. I wonder what the reason for this is?

Emma  

[Qie Niangao]

Yeah, now that I look at the llTargetOmega documentation on the wiki, it's kind of ... well, wrong, I think, when it says the spinrate is the "rate of rotation in radians per second." I'm pretty sure it's really the number of times per second the magnitude of the axis of rotation is applied to the object. So -7 radians is kind of a bunch rotation, right? like more than a full circle. So you originally multiplied that by 0.36 to get the desired spin per second. On the other hand, 7 degrees is a pretty small part of a circle, so it needs to do that many more times a second.

Let's do the arithmetic. 7 radians is 1.114085 complete circles. 0.36 of that would be 0.401071 circles per second. 7 degrees is 0.019444 of a circle, so to get that same number of circles per second, we'd need to do it 0.401071 / 0.019444 = 20.626510 times a second... which is kinda close to 23, sorta.

Now a typical way of specifying llTargetOmega's axis is by converting it to a unit vector using llVecNorm, so then it really does represent one radian of spin around the specified axis. That may have been less confusing than my suggestion to change the axis dimensions from degrees to radians.

[Emma Krokus]

Oww my head!!!!

I will never get radians. Give me degrees anytime (... Bsc, MSc, PhD... hehehe).

Your explanation at least makes sense to me. And that's saying something!!

I guess I will just head over to the Wiki page for llVecNorm to see if I can wrap my head around that.

Again, thank you so much, Qie.

Emma  

[Wulfie Reanimator]

51 minutes ago, Emma Krokus said:

Oww my head!!!!

I will never get radians. Give me degrees anytime (... Bsc, MSc, PhD... hehehe).

Your explanation at least makes sense to me. And that's saying something!!

I guess I will just head over to the Wiki page for llVecNorm to see if I can wrap my head around that.

Again, thank you so much, Qie.

Emma  

I understand radians but my head was spinning at the explanation of llTargetOmega. No pun intended.

 

Converting between the two is not particularly difficult. Some easy reading:
https://www.wikihow.com/Convert-Radians-to-Degrees
https://www.rapidtables.com/convert/number/degrees-to-radians.html

Since the conversion is based on static values (always the same, never changing), it can be pre-calculated to a single number, then multiplied.

DEG_TO_RAD = PI / 180.0
RAD_TO_DEG = 180.0 / PI
  
vector axis_in_degrees = <0, -7, 0>;
llTargetOmega(axis_in_degrees * DEG_TO_RAD * llGetRot(), 2.36, 0.3);

And so on.

@Qie Niangao If you can come up with a better (more accurate) way to explain how it works, I'd be able to edit the wiki.

[Emma Krokus]

34 minutes ago, Wulfie Reanimator said:

I understand radians but my head was spinning at the explanation of llTargetOmega. No pun intended.

 

Converting between the two is not particularly difficult. Some easy reading:
https://www.wikihow.com/Convert-Radians-to-Degrees
https://www.rapidtables.com/convert/number/degrees-to-radians.html

Since the conversion is based on static values (always the same, never changing), it can be pre-calculated to a single number, then multiplied.

DEG_TO_RAD = PI / 180.0
RAD_TO_DEG = 180.0 / PI
  
vector axis_in_degrees = <0, -7, 0>;
llTargetOmega(axis_in_degrees * DEG_TO_RAD * llGetRot(), 2.36, 0.3);

And so on.

@Qie Niangao If you can come up with a better (more accurate) way to explain how it works, I'd be able to edit the wiki.

Thank you, Wulfie - I do have difficulty finding things in the Wiki because I don't always know the right terms to use - and google is not always helpful.

RapidTables looks like something I've been looking for all my life!

Emma  

[Qie Niangao]

1 hour ago, Wulfie Reanimator said:

@Qie Niangao If you can come up with a better (more accurate) way to explain how it works, I'd be able to edit the wiki.

To be honest, I'm not 100% sure how it works. It's just that the rate of rotation seems to be llVecMag(axis)*spinrate radians/sec, rather than simply spinrate radians/sec. I'm even less sure how one expresses that (speculative) calculation as a coherent definition of the spinrate argument.

On balance, probably a good thing I don't have wiki-editing permission. 😋