Kitely Forums

Ok so I've got these great plasma pods inn gunga city:

the plasma in the bulbs is a linkset of torus and meshes.
as half of them are at 45 degree angles to the x and y axes, but they need to rotate on their own local axis ranndomly clockwise/counterclockwise at different speeds, they use the followinng script:

default
{
state_entry()
{
llSetTextureAnim(ANIM_ON|LOOP|SMOOTH,ALL_SIDES,1,1,1,1,0.25);
llTargetOmega(<-.7171,0.7171,0>,1,0.1);
llSetTimerEvent(llFrand(5.0));
}
timer()
{
float value = (llFrand((llSqrt(2)*1000))-((llSqrt(2)*1000)/ 2))/500;
llTargetOmega(<-value,value,0>,1,0.1);
llSetTimerEvent(llFrand(5.0));
}
}

Where the 'value' variable is positive or negative depending on whether the object is at 45, 135, 225 or 315 degree anngles.

However, I find that they occasionally precess on their local axis and would like a solution,

Here's an example of the problem. Thee precession gets worse

Hi Mike,

If the object rotates as expected when no rotation changes are made but builds up error on each rotation change then the center of mass around which the object rotation is reset isn't fixed. Please read http://wiki.secondlife.com/wiki/LlTargetOmega then review your linkset to make sure that what you're rotating has the expected center of mass.

Ilan Tochner wrote: ↑

Wed Jul 01, 2020 11:01 am

Hi Mike,

If the object rotates as expected when no rotation changes are made but builds up error on each rotation change then the center of mass around which the object rotation is reset isn't fixed. Please read http://wiki.secondlife.com/wiki/LlTargetOmega then review your linkset to make sure that what you're rotating has the expected center of mass.

If that were so, then I should see this tumbling on all of them, but the effect only exhibits on the ones that are at 45 degree angles to the x and y axes. This tells me that there is a problem with the vector being calculated by the funnction off axis.

I'm setting the vector radians based on llSqrt rather than SQRT2, so I'll try that . I suspect llSqrt does not go out to any significant digits and that's probably piling up errors

Ilan Tochner wrote: ↑

Wed Jul 01, 2020 11:01 am

Hi Mike,

If the object rotates as expected when no rotation changes are made but builds up error on each rotation change then the center of mass around which the object rotation is reset isn't fixed. Please read http://wiki.secondlife.com/wiki/LlTargetOmega then review your linkset to make sure that what you're rotating has the expected center of mass.

oook so I've been trying to edit the object so the root is at the objects center of mass, but there's something that is stopping the edit dialog from changing the last few ten thousandths. Have to keep moving the root because its last move moves the objects center of mass, etc etc. but I'm att the last adjustment. I've tried the SQRT2 edit and that did not improve things.

Ilan Tochner wrote: ↑

Wed Jul 01, 2020 11:01 am

Hi Mike,

If the object rotates as expected when no rotation changes are made but builds up error on each rotation change then the center of mass around which the object rotation is reset isn't fixed. Please read http://wiki.secondlife.com/wiki/LlTargetOmega then review your linkset to make sure that what you're rotating has the expected center of mass.

Ok after much testing of all four pods I believe I have narrowed down the source of the problem. The center of mass vs object center issue is not relevant. One pod I fixed the center of root prim to the center mass of the link set still precesses.

The problem is in the value of the vector in the llTargetOmega:

llTargetOmega(<-value,value,0>,1,0.1);
This tumbles due to the negative sign on the x value. This is necessary for two of the four pods. The other two goods have positive values for both x and y, and do not precess now. i.e. llTargetOmega(<value,value,0>,1,0.1);
The other four of the eight total pods that are in line with the x and y axes don't have any precession problem

Hi Mike,

If this problem is reproducible with a simple linkset with a negative sign on the x value then please file a Mantis for it. This is an OpenSim bug which we won't have time to address while we're still working on system wide scalability and performance improvements.