llTargetOmega - How to go ultra slow?

[Indy Inglewood]

Hi, 

I have a sphere - a hemisphere really - that I am using for a sky dome.  In it, I have a simple rotation script, called by a menu where I can also change textures.  I want the sky to rotate verrry slowly, barely perceptibally.  Kind of like a real sky.  I am using llGetLocalRot.  I seem to be up against some kind of "minimum limit."  I created variables for axis, spinrate, and gain to play with it, but it seems I cannot go with any lower values, or fractions in some cases, no matter which way I switch the numbers around.  For instance, using the variables below, when I switch any of them to be less than what they are, then run the script, rotation does not happen.  Any help greatly appreciated!

// llTargetOmega variables

vector AXIS = <0,0,.026>;
float SPINRATE = -1;
float GAIN = 1;

...(snipped code to function call...)      

if (_option == "ON")

llTargetOmega(AXIS,SPINRATE,GAIN);

 

[Dora Gustafson]

I would set the parameters like this

vector AXIS = <0.0,0.0,1.0>;float SPINRATE = -0.026;float GAIN = 1;

But maybe you already tried that:)

You have another option: Key Framed Motion, it has a limit to how fast it can move but I never heard how slow it can go

[Rolig Loon]

llGetLocalRot isn't going to make any difference to llTargetOmega, since any movement that llTargetOmega creates is only client-side.  Your object's actual rotation, as far as the servers are concerned, doesn't change at all (unless your object is physical, which yours isn't).  I'm not aware of a lower limit on llTarget Omega's speed, but there may be one. Instead of llTargetOmega, though, try using llSetRot and actually changing the rotation server-side.

There is a limit to how small a change you can make in rotation before the servers simply don't recognize it, however  A standard trick is to force the servers to update your object anyway.  You can do that by adding a statement like llSetText("",<1.0,1.0,1.0>,1.0); right after your llSetLocalRot, which will do nothing visible to your object but will require the servers to update it anyway.

[Indy Inglewood]

Thanks Rolig and Dora...but doh!  I realized I put llGetLocalRot in the message title here instead of llTargetOmega!  I am sooo silly sometimes! 

Dora...I will still play around with the numbers--and yes I tried spinrate at -0.026 to no avail.  Seems like every time I tried using a number lower than that, it just did nothing.  And gain...not even sure what that does.  Seems to be irrelevant?  Still gonna look at llSetKeyframedMotion too!

Rolig, I will explore llSetText.  But now I am thinking...instead of rotating the entirie dome, maybe rotate the texture on the dome instead, using llSet TextureAnim.  I tried that last night and it seems to move a LOT slower than I could get using llTargetOmega to rotate the dome.  Which is my goal.  But having a bit of difficulty using it on a hemisphere instead of a sphere...mapping the sky textures correctly.   I'd like to use the hemisphere instead of a whole sphere...sigh...so much to learn.

Thank you for your ideas and if anyone else has any, please keep them coming!

 

[Qie Niangao]

I haven't tried keyframed motion for anything quite like this, but two things to consider.

First, KFM is server-side, so (assuming it works) all viewers will see the same state of the sky, regardless of how recently they arrived in the sim. I don't think that can be assumed with llTargetOmega() motion--I think it starts from the same point for each observer at the time they first rez the object, so that may be confusing when people arrive at different times. (I also suspect that texture animation, too, starts from the beginning when an already animated surface first comes in view.)

Second, KFM is server-side, so every change is sent as an update to the viewer. I really have no idea how often a slowly rotating dome would send updates, but I'd want to show object updates and see if it's too busy.