Discussion: Smooth rotation transition using llTargetOmega()

I was thinking about how to reduce the impact on screen real estate that a HUD attachment would have when I'm not using it. I thought of the possibility of having it rotate out of view when inactive, and started exploring the use of llSetRot() in steps to make the transition seem smoother. Then I realized that llTargetOmega() could be used to smoothly transition between two rotations, and if you quickly stop the llTargetOmega() and call llSetRot() at just the right moment, the transition could be seamless.

Here's a script I came up with that does this (apologies if this has already been done). Given an axis, an angle, a duration, and an initial rotation, this script will smoothly transition back and forth between two rotations each time the object is touched. To see a demo, just put this script in a prim and poke at it a few times Works on attachments and in-world objects.

// Lex Neva
//
// Smooth Rotation

// This script demonstrates how to use llTargetOmega() to smoothly transition between two 
// rotations.  Occasionally the object will under- or over-rotate, but generally, the effect
// is to rotate smoothly between a starting and ending rotation.


// how long to take to rotate
float ROT_TIME=1.0;

// axis to rotate around
vector ROT_AXIS=<0.0,0,1>;

// angle in radians to rotate
float ROT_ANGLE=PI_BY_TWO;

// initial rotation
rotation ROT_START=ZERO_ROTATION;

default
{
    state_entry() {
        // this needs to be a unit vector
        ROT_AXIS = llVecNorm(ROT_AXIS);
        
        // get the process started
        llSetRot(ROT_START * llAxisAngle2Rot(ROT_AXIS, ROT_ANGLE));
        state unflipped;
    }
}
    
state unflipped {
    state_entry()
    {
        llTargetOmega(ROT_AXIS,-ROT_ANGLE/ROT_TIME,1);
        llSleep(ROT_TIME);
        llTargetOmega(ROT_AXIS,0,1);        
        llSetRot(ROT_START);
    }

    touch_start(integer total_number)
    {
        state flipped;
    }
}

state flipped {
    state_entry()
    {
        llTargetOmega(ROT_AXIS,ROT_ANGLE/ROT_TIME,1);
        llSleep(ROT_TIME);
        llTargetOmega(ROT_AXIS,0,1);
        llSetRot(ROT_START * llAxisAngle2Rot(ROT_AXIS, ROT_ANGLE));
    }

    touch_start(integer total_number)
    {
        state unflipped;
    }
}

One good use for this script is a door. If you take a cube and cut it to 0.375,0.875 (I think), it should make it so that it rotates around one side rather than the center. Pop this script in unmodified, and you'll have a door that smoothly opens and closes when touched. No more jerky doors!

What would I do to make this not set the object to a zero rotation?

Great script by the way, the movement is excellent.

The line you want to change is this:

// initial rotation
rotation ROT_START=ZERO_ROTATION;

You'll have to set a rotation directly if you do it there. If you want to set a rotation that you get from the edit box, put a line like this in state_entry() of the default state:

ROT_START = llEuler2Rot(DEG_TO_RAD * <90,0,180>);

Fill in whatever rotation you want where I've written <90,0,180>.

Good idea! I've sometimes wondered how well a method like this would work (esp. WRT moving attachments, such as tails), but never bothered to give it a try myself. Guess I'll have to check it out next time I'm inworld.


Another more versatile solution is to use a transparent root prim as the "hinge". Put the script in the root prim, and the whole object will pivot around the root's center.

Ahh oke, thank you! I'll have smooth rotating doors in no time now! (and hopefully wings and tails as well )

Hmm I get a syntax error changing the rotation ROT_START to that. I get it inbetween the llEuler2Rot and the "". Adding a space gives me the same error.

I think I know what happened. If you're using the second method, you're actually going to have to leave the first ROT_START line alone and add a new one at the start of state_entry() to set it, because of the way global variables work. Hopefully this makes it more clear:

...

default
{
    state_entry() {
        // set a different start rotation
        ROT_START = llEuler2Rot(DEG_TO_RAD * <90,0,180>);

        // this needs to be a unit vector
        ROT_AXIS = llVecNorm(ROT_AXIS);
        
        // get the process started
        llSetRot(ROT_START * llAxisAngle2Rot(ROT_AXIS, ROT_ANGLE));
        state unflipped;
    }
}

...

I'm not even sure whether this worked smoothly enough before 1.7 came out... I imagine someone would have thought of it before. One annoying problem is that sometimes, attachments simply fail to respond to llTargetOmega() calls until you poke at them, leave the sim, relog, etc. Argh. Anyway, I'd love to see if you get this working on a realistic-looking attachment!



Well, sure. I was just sort of going for the simplest possible method, there. Box prims are special cases because you can move the rotation axis an "edge" by cutting it in half.

Oke, I will try that in a bit here. Hopefully it works!

I've heard about attachments not continuosly responding to llTargetOmega. I am hoping I can find some way around it when I try this script out in a series of wings I have made. (Scripting (clearly) is not my strong point as I am fairly unpracticed in it.)

Thanks for the further help!

Yes! My doors work exactly how I want them to now. I commented out the initial ROT_START and put in "rotation ROT_START . . ." right above each of the actual rotation codes as so:

    integer open() // Opens the door.
    {
    	rotation ROT_START = llEuler2Rot ( DEG_TO_RAD * <0,0,270>);
    	// vv  Replace this snippet with custom code to close the door vv 
 		llTargetOmega(-ROT_AXIS,ROT_ANGLE/ROT_TIME,1); //Negatives added to ROT_AXIS for right-side door -HQ
    		llSleep(ROT_TIME);
    		llTargetOmega(-ROT_AXIS,0,1);
    		llSetRot(ROT_START * llAxisAngle2Rot(-ROT_AXIS, ROT_ANGLE));
    	// ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
    	return TRUE;
    }
    //- - - - - - - - - - - - - - - -	 
    integer close() // Closes the door.
    {
    	rotation ROT_START = llEuler2Rot ( DEG_TO_RAD * <0,0,270>);
    	// vv  Replace this snippet with custom code to close the door vv
    		llTargetOmega(-ROT_AXIS,-ROT_ANGLE/ROT_TIME,1);
    		llSleep(ROT_TIME);
    		llTargetOmega(-ROT_AXIS,0,1);		
    		llSetRot(ROT_START);
    	// ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^ ^
    	return FALSE;
    }

Now to start in on my bird wings.

This slow rotation is exactly what i need for a rotating door fixed to an object, but i need the door to be a linked child prim. Is it possible to adapt this script to allow that? Is it also possible to explain how to do it without using the terms 'euler vector' or 'quaternion' which mean NOTHING to me!

Actually i can almost get the rotation to work but the ROT_START thing confuses me, it resets the prim to zero rotation as it's supposed to, but i need it to assume a start position relative to the root prim.

Is that possible?

EDIT: It appears that it IS possible cos i seem to have done it...basically just changed all the llSetRot to llSetLocalRot and played around with the settings. Seems to work fine, haven't managed to get it to mess-up yet and it looks amazing compared to the previous 'snap' rotation the door had.

Yup, you got it I have a version that does root-relative rotation, but all I did was to change llSetRot() to llSetLocalRot().

just be careful because target omega can appear under/over rotate depending on server or viewer lag, and then snap to it's new physical destination. not so bad with a single small time frame like this, messy for bigger or more continuous calls (or changed directions called without setting a position). also the door looks to be staying solid so it's not actualy open till it's finished with the set * rot. (could make it phantom inbetween if it's unlinked)

PS I like it though =)

I just tried it out on a Mono sim and it doesn't like Mono, or vice versa. A bit ironic that i should find Lex's excellent script just before mono breaks it!

Under mono it gives me the over-rotate problem Void describes and then it snaps back to its correct position. Presumably something to do with the (previously seamless) shift between llTargetOmega() and call llSetRot()?

Hopefully that can be fixed in the script or in Mono, I'd hate to lose this now...

I'll take a look at it when I have a chance and file a bug report.

it's kinda weird, since overrotating is usually caused by sim lag, and under rotating by viewer lag... could be how mono treats some of the commands (sleep would be my guess).

Had a spare moment, so i tried this script again in the latest beta of Mono - and it works! Whatever was causing it to over-rotate before seems to have been fixed with the latest mono build and we're good to go...smooth as silk actually, let's hope that lasts too.

That matches what I saw when I tested this in mono last week. Yay!