There are three ways to rotate an object in SecondLife, each with their own advantages and disadvantages.

The simplest is llSetRot. Once you have got you head round SecondLife’s rotation vectors, and the various associated functions (such as llRot2Axis), it is quite easy to use. It’s main drawback is that there is a delay of 0.2 seconds when it is called, which makes it impossible to use it for smooth rotation. As a result the most common use of this function is for scripted doors, which only need to make one call at a time to this function.

The other commonly-used way to rotate objects is to make them physical, and turn them into vehicles. If you want to create (for example) a fairground carousel, this is the option to go for. It creates smooth rotation, but at the cost of having to get to grips with SecondLife’s vehicle system.

The third alternative, and the one I want to look at in this entry, is the rather oddly-named llTargetOmega. This isn’t as well-known as the other two methods (perhaps because there is little in the name to suggest to non-mathematicians that it has anything to do with rotation!), and has its own disadvantages, but for certain purposes it can be very useful.

Before explaining the advantages and disadvantages, let’s take a look at the function itself, by way of a simple example of a call to it:

llTargetOmega(<0.0, 1.0, 0.0>, TWO_PI, 1);

The first parameter is axis of rotation. The above example rotates the object around the Y axis at (approximately) one rotation per second.

The second parameter is the rate of rotation. (To be honest, I am not entirely sure of the relationship between this and the rotation speeds defined in the axis vector).

The third parameter is the gain. It shouldn’t be zero, but other than that its effect is too subtle to be apparent.

The function isn’t much more difficult to use than the llSetRot function. Once it has been applied, the object will constantly and smoothly rotate at the specified rate (set the rate to 0.0 to stop it moving).

The main disadvantage is that the rotation is client-side. What this means is that every viewer will see the rotation differently, because the rotation is actually rendered in the client-viewer rather than being calculated by the server and then sent to each viewer.

This makes it unusable for objects which need all the clients to be synchronised — you couldn’t use this function for the fairground carousel mentioned above.

On the other hand, imagine a small fan, or the rotating blades of a helicopter. There is no real need for every viewer to see exactly the same rotation for these objects, so they can reasonably be rotated using llTargetOmega.

Here’s a small sample script. Drop this into a prim (a cube is probably the best for showing the rotation). Clicking the prim will start it rotating. Click again to stop.

integer spinning = FALSE;
default
{
    touch_start(integer total_number)
    {
        if(!spinning)
        {
            spinning = TRUE;
            llTargetOmega(<0.0, 1.0, 0.0>, TWO_PI, 0.1);
        }
        else
        {
            llTargetOmega(<0.0, 1.0, 0.0>, 0.0, 0.1);
            spinning = FALSE;
        }
    }
}

Recently I created a Zoetrope – a Victorian ‘toy’ which creates an animated display – using llTargetOmega for the spinning section (and hence prompting this article). If you want to see an example of this function in action, you can pay a visit to Morgridge Mansion and take a look.