TargetOmega Jerkiness

[Oberon Onmura]

I'm rotating a physical prim very slowly using llTargetOmega(). I need the prim to be physical so I can trigger the at_rot_target event later on in the script. No problem there.

 

My problem is that the rotating prim jerks - usually at around 22.5 degrees from where it begins its rotation. I've tried lots of different spinrate and gain values. I was thinking the problem was perhaps related to the sim or physics FPS of 45. But nothing has worked perfectly. I'm able to make the problem WORSE! But I haven't yet achieved a perfectly smooth, very slow rotation. Any ideas?

 

 

[Dora Gustafson]

If it physical it may bump into some other object or have contact to another object or to ground.
That would affect the spin.
Could that be the case?

[Oberon Onmura]

The prims are phantom.

[Rolig Loon]

This test script works just fine for me --- no stutter at all ....

integer gON;default{    touch_start(integer total_number)    {        if (!gON)        {            llSetStatus(STATUS_PHYSICS,TRUE);            llSetBuoyancy(1.0);            llTargetOmega(<0.0,0.0,1.0>,0.1,2.0);        }        else        {            llSetStatus(STATUS_PHYSICS,FALSE);            llTargetOmega(<0.0,0.0,1.0>,0.1,0.0);        }        gON = !gON;    }}

 My test prim is phantom too.

[Miranda Umino]

if it s not a more common problem , i guess i have met your problem in an another function as llsetkeyframedmotion .

It s when you have talked about slow rotations  , i have remembered this .

https://jira.secondlife.com/browse/SVC-7471

 

When the angular velocity is low , the prim stops its rotation .

For llsetkeyframedmotion , it was around under 0.15 radians / second

 

I ahve tried a simple script with lltargetomega . When the spinrate is for intsnace at PI /16 , the prim continues to turn .. but for a spinrate at PI /32 , the prim starts its rotation and stops suddenly .

 

default{    state_entry()    {        llTargetOmega(<0,0,1>,PI / 32, 1.0);    }}

 

For me , you meet a bug . Do a Jira and link it with mine

 

 

*edit*

I ahve tried to know the gap .. The gap is between PI / 20 and PI/21 , so exactly the same gap with llsetkeyframedmotion

[Oberon Onmura]

What you describe is exactly what is happening. Thanks for the heads up on the JIRA.

 

[Oberon Onmura]

I suspect that it is related to the server 45 FPS. It looks like a glitch - perhaps some dropped frames - when it attempts to update continuous motion. I've decided to live with it for now rather than try to figure out a work-around. I'll make a Jira entry when I get a chance. Thanks for doing the tests.