Optimising basic rotation calculations

I'm making a lot of calls to llEuler2Rot, mostly of the form

llEuler2Rot (< BASE + (value * MULTIPLIER), 0.0, 0.0>;

where BASE and MULTIPLIER are effective constants. Is there a more efficient way of doing this by figuring out how to calculate the individual components of the resulting rotation? (I'm pretty sure that'd involve calculating at least two of the components separately).

I realise that for regular increments of "value" something like

llEuler2Rot (< (value += INCREMENT), 0.0, 0.0>;

would make more sense (and may be more amenable to direct calculation of a rotation), and that is high on my agenda, but in many cases the value of "value" is unpredictable.

Any comments or suggestions?

ETA: thinking a bit more about it, even the regular incremental setup could get unpredictable when lag rears its ugly head.

Well you could decide what would be acceptable for a resolution and take your values from a precalculated list.

integer getIndex(float value)
{
return (integer) value * (maxvalue - minvalue) / RESOLUTION ;
}

something along that line. The formula is certainly false but it's the idea^^.

I'd be looking at a minimum resolution of 60 for a clock's minute or second hands, up to 720 for the hour hands, and with several others at around 100 or so. I guess the number of entries and lists could be reduced by adding constants like PI or PI_BY_TWO to the extracted values, but I don't think there's enough spare memory available for even that - I'm trying to be a good boy by using a single script with a faked-up llSetLinkPrimitiveParamsNoDelay function in anticipation of the real thing. I shall ponder on this, though - thanks.

Maybe this will help you:

quat(float angle, vector axis)
{
float sin_a = llSin(angle / 2) ;
float cos_a = llCos(angle / 2) ;
rotation q ;

q.x = axis.x * sin_a ;
q.y = axis.y * sin_a ;
q.z = axis.z * sin_a ;
q.s = cos_a ;
llSay(0, "*"+(string)q) ;
}


default
{
    
    state_entry()
    {
    }

    touch_start(integer total_number)
    {
        llSay(0, "Touched.");
        integer m ;
        rotation r ;
        float a ;
        vector axis = < 1.0, 0.0, 0.0> ;
        for (m=0; m < 60; m++)
        {            
            a = 6 * m * DEG_TO_RAD ;
            r = llEuler2Rot(< a, 0, 0>);
            llSay(0, (string)(r)) ;
            quat(a, axis) ;
            
        }
        
    }
}

There are obvious optimizations such as removing q.y and q.z computations since you know it's going to be zero.

quat(float angle)
{
    angle /= 2.0 ;
    float sin_a = llSin(angle) ;
    float cos_a = llCos(angle) ;
    rotation q  = < sin_a, 0.0, 0.0, cos_a> ;
    llSay(0, "*"+(string)q) ;
}

time this?

Thanks Twisted, that does point me in a promising direction. I guess I need to try running some comparisons now to see how the different methods perform speed- and memory-wise. I'm pretty sure I've seen some kind of test scripts in the wiki somewhere.

you can incrementally add to a rotation by using local rotation....

lets assume

Now = ZERO_ROTATION

and Sec = llEuler2Rot( <0.0, 0.0, 6.0 * DEG_TO_RAD> ); //-- 1 sec around z

to add 1 sec,

Now = Sec * Now;

each execution of that line adds 6 degrees to now (or one second)

however most of the clocks math is going to be easier to do as Euler degrees, because at even only one axis of rotation, you have to change both the z and s parts of a rotation, for it to be a proper unit... although IIRC you can get away with just the z, which will change the scale, and it gets normalized before use, but there may be some caveats there.

Using the timing script from the LSL Script Efficiency page, my preliminary tests (which fall rather short of being thoroughly rigouous) seem to show that using llEuler2Rot works roughly twice as fast as calculating the two components of the rotation seperately.

However, when I tried it on an incremental rotation * rotation example it consistently returned a negative result...

I see a market for this when script limits come into effect

the consistent negative results is a side effect of mono and usually means really small, or not enough iterations)... retest in LSO, the figures are comparable.