llTargetOmega

I tearing my hair out on this...

I'm using llTargetOmega(<0.0, 0.0, 1.0> * llGetRot(), spinrate, gain) to rotate a prim. The command should - according to the wiki - rotate the prim around one axis only, no matter in what direction it's globally rotated. But it's not rotating around one axis only, but around like two. I'm using a very slow rotation speed, that's when this occurs - when I speed it up, it looks fine.

Try to rez a cube and rotate it to about 280 degrees, then start the rotation - it's drifting...

What am I missing?

http://wiki.secondlife.com/wiki/LlTargetOmega
behaves differently if object is physical and if script is in root prim or not.

I read the wiki forward and backwards meanwhile and I'm dreaming of rotations already...

Here's what I got:

// change spinrate and degToTurn as you wish
// in- or decrease the spinrate by values of 0.01 only... 

float spinrate = 0.04; // Speed at which the object is rotating
float degToTurn = 5.0;    // Amount of degrees to turn into both directions

// Nothing to be changed after this line :)

float time;             

rotation originalRot;

vector omegaRot = <1.0, 0.0, 0.0>;

rotation rotPositive;   // Rotation that's reached at the end of the left swing
rotation rotNegative;   // Rotation that's reached at then end of the right swing

integer isPositive;

// Function to compute all the vectors and rotations 
// will be called everytime the object gets touched
// in case that the object has been turned in the meantime

computeAngles(){
   
    time = degToTurn / (spinrate * 100) * 3.8;  // Time that's needed for a whole swing
    
    originalRot = llGetRot();
    
    rotation x_45 = llEuler2Rot(<degToTurn * DEG_TO_RAD, 0, 0>);    // Compute the positive (left) position 
    rotPositive = x_45 * llGetRot();
    
    x_45 = llEuler2Rot(<-(degToTurn * DEG_TO_RAD),0, 0>);           // Compute the negative (right) position
    rotNegative = x_45 * llGetRot();
}

default
{
    state_entry()
    {
        llSetAlpha(0.0, ALL_SIDES);
        llTargetOmega(ZERO_VECTOR, 0, 0);   // Stop movement if there is any
    }
    
    touch_start(integer total_number)
    {
        computeAngles();    // Compute the positive and negative positions according to the actual rotation
        state running;
    }
}

state running
{
    state_entry()
    {   
        llTargetOmega(omegaRot * originalRot, spinrate, 1);
        isPositive = TRUE;
        llSetTimerEvent(time/2);    // The first time we spin, we have only the half rotation, thus, set the time to half of the value
    }

    touch_start(integer total_number)   // Stop Swinging and got back to the original state/rotation
    {
        llTargetOmega(ZERO_VECTOR, 0, 0);
        llSetRot(originalRot);
        llSetTimerEvent(0);
        llResetScript();
    }
    
    timer()
    {
        llSetTimerEvent(time);  // Now we need the whole time for a complete swing
        
        llTargetOmega(ZERO_VECTOR, 0, 0);   // Stop rotation and set either positive or negative rotation
        
        if(isPositive){
            llSetRot(rotPositive);
        }else{
            llSetRot(rotNegative);
        }    
        
        spinrate *= -1;
        
        llTargetOmega(omegaRot * llGetRot(), spinrate, 1);
        
        isPositive=!isPositive;
    }
}

This script is in the root prim of an object - kind of a swing (what else...)...

It works fine as long as I have the swing set up a «even» angles (0 deg/90 deg...).

But as soon as I have an odd angle (say 287 deg), the thing «hops», means, the root prim doesn't really rotate around just one axis, but around like 3 (I guess)...

Problem is - as you all know, I guess, that I _have_ to reset the the rotation from time to time because the timer-event is not reliable. So I thought re-setting it every time the swing reaches an end position would be good (which it is, as long as I don't have odd angles)...

Any ideas?

[Edit]

Interestingly - when I set the spinrate higher (say 1.0 instead of 0.04), it looks good - but then it's way too fast...

Would using llRotLookAt between your points possibly be more predictable? With targetOmega you sort of have to hope that either the client (nonphys) or the server(phys) keeps your timers and the physical rotation in sync.. but with llRotLookAt you can specifically say 'swing to here' 'swing to there' and adjust the speeds.

Thanks Shadow

But the problem is actually, that llTargetOmega doesn't rotate the way I compute the two stop-rotations. In the wiki it says, that using llTargetOmega(<0.0, 0.0, 1.0> * llGetRot(), spinrate, gain) should rotate the object around the z-axis only. This is true, as long as the object itself faces north/south/east/west. As soon as the object is rotated, llTargetOmega doesn't act the way as I expect it... don't think that llRotLookAt() would help here...

You DO realize that means the object's LOCAL z-axis, right? Not the global z-axis. If you want to rotate about the global z-axis, you just use an unmodified <0.0, 0.0, 1.0>.

Yup - that's exactly what I wanna do... local - not global-rotation...

I think what you want is this, replacing the "spinrate" and "gain" parameters with what work for you...

default
{
state_entry()
{
rotation rot = llGetRot();

llTargetOmega(-llRot2Up(rot), PI / 12.0, 1.0);
}

}

Thanks Ace

Same effect, though... It seems that I can't get to rotate the object around just one axis at a very slow speed. It works when I set the speed higher, but I need the slow rotation...

I can verify what you see, I see the same thing. I played around a bit with your script and it looks to me that the server side:'llSetRot' and the client side: 'llTargetOmega' just do not agree about the endpoints. It shows that when the swing is stopped the object is turned by llSetRot before it swings back. I tried to run the script without the llSetRot and the object turns more and more out of position. My only conclusion is that this is the way it is by design. I can not think of any work around.

Thanks Dora

It is kind of good to know, that it doesn't seem to be my fault, although, I'd prefer that... Well, maybe with some more playing around I can «fool» those two functions so they come to the same conclusion

The problem is really that the rotation has to go forward and backwards, so I do need to adjust it because - as you saw it - the rotation is out of tune after like two or three «swings»...

i am getting the same results. It has worked properly many times for me before. (though lltargetOmega has been constantly screwed for about the last two months - now its screwed in a brand new way. This is driving me nuts.)

Whenever I go for a very slow rotation around a single axis - it decides to turn very slightly around the other ones too.

I just did some testing - it seems to depend on the angle of an axis that it is not rotating around as to how much it goes out of whack - if its straight - n,s,w,e - it stays true, straight up and down movement - even at a 45 degree angle it seems to stay true. Anything outside of that and its no good.

Looks like some time recently some slight miscalculation has been introduced into either llTargetOmega or llGetLocalRot. Could it have something to do with havoc4?