Rotating Texture animations

Hi everyone, I ahve a coupel of (possibly rather dim) questions about the use of llSetTextureAnim with the ROTATE and SMOOTH flags set.

The ever delightful Wikki says that the Start and Length parameters are start and length of anim in radians and that the Rate parameter determines animation frame rate.

It appears to me that the Rate parameter is not only an update frequency but also a rotation speed in radians per second (a value of TWO_PI/60 gave me a rotation speed of approx 1.0RPM) Can anyone confirm/deny ?

As you may have guessed I'm making a clock, and to ensure that the hands are positioned accurately I have a periodic timer set to recalculate the angle of the hands and reset the animation. Currently this is going off once per minute but I'm hoping to cut that down to once every 5 or even 10 minutes.
The problem I'm having is that llSetTextureAnim is producing very odd results when the timer goes off, even feeding in a static Start parameter causes the clock hand to skip around the dial.

Anyone have any clues for the clueless ?

Rate is the frame-rate (update frequency) if you are using tiled animation (where youur texture is divided into x_frames across and y_frames down).
For rotating (or scaling, or sliding) textures, it is indeed revs (or zooms, or slides) per second, as you have discovered.

Mmmmmm, this is an old problem with llTargetOmega which is also a client-side animator. I wonder if maybe llSetTextureAnim suffers from the same problem.
You might want to try animating the seconds hand with a rotating texture, synching it to the clock very seldom, and using llSetLocalRot to get the minute and hour hands to do discrete jumps instead.

Goody, that'll make the rest of the sums easier.

Is there a protocol for updating the Wikki with things like this ?



I'm hoping to avoid using rotations if possible, not least because it prevents the final object from being useful as an Avatar atachment. This can't be the only way to get an accurate rotation client side.

I am suspicious that SetTextureAnim is taking the start parameter as an offset from the client side rotation of the texture, but I need more experimentation time to be certain.
It may well be possible to call llGetTextureRot to even out the problem.