llTargetOmega(vector axis, float spinrate, float gain)

Sets target omega. Makes an object rotate smoothly, without "choppy" steps.

axis is a vector describing the axis the object will rotate around. For example, <0,0,1> will rotate the object around the Z (vertical) axis.¹
spinrate is the rate at which the object will spin (rotate) around the given axis (in radians per second).
gain is the strength of the spin, which only has an effect on physical objects. However, it still must be non-zero for non-physical objects.

NOTE: Currently llTargetOmega() is not performing properly, especially when involved in an avatar attachment. llTargetOmega cannot currently be relied upon to rotate avatar attachments properly, and exhibits inconsistent results on non-attached objects.
--Concerning HUDs, llTargetOmega() works without any problems.

This function can be used in a child link (in which case the child will rotate locally around its own center) or in a root link, in which case the entire linkset will rotate around the root's origin. (As used in the planets thing in the main grid's welcome area here). See also this forum note.

Beginners are often confused about the difference between this function and llSetRot. llTargetOmega makes the object SPIN with the specified angular velocity. llSetRot just turns it ONCE to face in a particular direction.

Notes:

• The rotation speed is based on the axis vector multiplied by spinrate, so it is a good idea to normalize (see llVecNorm) the axis vector or spinrate won't act like radians per second. For example, consider llTargetOmega(<0,0,1>,1,1). Then (<0,0,2>,1,1) would rotate twice as fast, (<1,1,0>,1,1) would rotate llSqrt(2); times as fast.
• When the object is physical it interacts with the physics engine² and is frequently updated.
• When the object is physical llTargetOmega affects the local axis of rotation.
• When the object is non-physical llTargetOmega effects the global axis of rotation
• When an object is non-physical (the more common use) the effect is simulated purely on the client ("client-side") and not the server (this rotation "state" is sent once). No updates, other than the start of rotation, is necessary so it reduces the server and network overhead, but means the object will not actually move according to the server; it just moves to the client. This can be confirmed with llGetRot. This also means:
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Selecting the object in edit mode will show the object as the server sees it.
• Avatars will collide with the object's bounding box as it was before rotation began. It is a good idea to phantom larger objects so avatars won't bounce into things they can't see.
• The start of rotation is not synchronized, so not everyone will see the same thing. At some time the object may appear to be rotated, for example, 45 degrees from its initial position to one person, yet 60 degrees to someone else.
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Calling llTargetOmega again will rotate the object from the original position, not from where it looks like it is at the moment of the call.
• *This quirk appears to be no longer present in SL v1.13. Could LL or another party confirm?* Other scripting calls that force a client data update of the object will seem to reset the effect (physically moving or changing the properties of the object will cause the object to stutter/twitch instead of rotate freely/smoothly).
• To disable a previous llTargetOmega() call, do this: llTargetOmega(ZERO_VECTOR, 0, 0);
• A nonzero gain with a zero spin_rate causes the object to try to stop all spin, rather than simply cancelling a previous llTargetOmega() call.
• When stopping llTargetOmega() in a HUD, the position of the prim will be the exact same as when llTargetOmega() was called.
• If there are other forces applied to a prim together with llTargetOmega(), (using llSetForce), use llTargetOmega(-llGetOmega(), 0., 1.) to cancel spin. Note that the gain must be non-zero, but not necessarily 1.

¹: To get a rotation around a specific axis no matter how the prim/object is rotated, use llRot2*(llGetRot()) (where * is "Up", "Fwd", or "Left") for the axis. Note: the llTargetOmega script will have to be recompiled/reset if the prim/object is rotated while running or it will no longer rotate around the specific axis correctly.
²: It seems easy to oddly launch things this way, though. Be careful with this combination.

---

This article wasn't helpful for you? Maybe the related article at the LSL Portal is able to bring enlightenment.

---

Functions | Dynamics | Rotation

float lastCall = -1; // To avoid destroying the value of llGetTime by calling llResetTime.
targetOmega(vector axis, float spinrate, float gain) {
    spinRate *= llVecMag(axis); // To compensate for normalizing.
    axis = llVecNorm(axis);
    if (lastCall != -1) // If we were spinning...
        llSetRot(llAxisAngle2Rot(axis, spinRate * (llGetTime() - lastCall)));
    llTargetOmega(axis, spinrate, gain);
    lastCall = llGetTime();
}

// Before beginning rotation

rotation quat=llEuler2Rot(DEG_TO_RAD*<270,1,270>);
//set 1 degree off desired final rotation.  
//Can put in rotation coordinates; I keep in degrees for illustration.
llSetRot(quat);
llTargetOmega(<0.0, 0.0, 1.0>, -PI/2, 1.0); // start spinning

// When stopping rotation

rotation quat=llEuler2Rot(DEG_TO_RAD*<270,0,270>); // desired final rotation
llSetRot(quat);
llTargetOmega(<0.0, 0.0, 1.0>, 0, 1.0); // stop spinning

llTargetOmega(<1.0, 0.0, 0.0>, 0.0, 0.0); // stop the rotation
llSetRot(<0.1, 0, 0, 1>);  // some bogus value
llSetRot(<0.0, 0, 0, 1>);  // desired rotation