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