Problem with OMEGA rotations.

[Grim Bracken]

Hello everyone,

I'm working on a project where the root prim rotates a child prim using the following code.

rotate_counter()
{
    vector rotationAngle = <0, 1, 0> * llTan(85);
    llSetLinkPrimitiveParams(3, [ PRIM_OMEGA, rotationAngle, 1.0, 1.0 ]);
}

This root prim also sets the same child prim texture and texture animation every six seconds using the following code.

llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, "blah", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0]);

llSetLinkTextureAnim(3, ANIM_ON | LOOP, ALL_SIDES, 4, 4, 1.0, 11.0, 23 );

For some reason the code that changes the texture and it's texture animation causes the child prim to stop it's OMEGA spin. Sometimes, it doesn't and sometimes it does. The behavior is intermittent and there doesn't seem to be a pattern.

Does anyone have any ideas why the problem occurs? Is there another, more predictable way of spinning a child prim smoothly?

Thanks for any help,

-Grim

[Rolig Loon]

llTargetOmega and Its SLPP equivalent are animations.  When you run llSetTextureAnimation at the same time, you're getting conflicts between the two of them.  It's no surprise that one has to stop to let the other one take over.  I wouldn't expect anything else. 

You might try rotating your prim with llSetKeyframedMotion, which is fairly smooth, but you won't be able to sustain its rotation indefinitely the way you can with llTargetOmega.

[Xiija]

not sure if this helps, but...

this will give a kinda smooth child rotation in a 0.02 second timer... ( rotating child prim ....#3, root is #1)

 

timer()
    {
          vector rotationAngle = <0, 0.03, 0> ;
          list params = llGetLinkPrimitiveParams(3,[PRIM_ROT_LOCAL]);
          rotation childRot = llList2Rot(params,0);
          llSetLinkPrimitiveParamsFast(3, [ PRIM_ROT_LOCAL, childRot * llEuler2Rot(rotationAngle) ]);
    }

[Parrish Ashbourne]

---

Grim Bracken wrote:

Hello everyone,

I'm working on a project where the root prim rotates a child prim using the following code.

rotate_counter(){    vector rotationAngle = <0, 1, 0> * llTan(85);    llSetLinkPrimitiveParams(3, [ PRIM_OMEGA, rotationAngle, 1.0, 1.0 ]);}

This root prim also sets the same child prim texture and texture animation every six seconds using the following code.

llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, "blah", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0]);llSetLinkTextureAnim(3, ANIM_ON | LOOP, ALL_SIDES, 4, 4, 1.0, 11.0, 23 );

For some reason the code that changes the texture and it's texture animation causes the child prim to stop it's OMEGA spin. Sometimes, it doesn't and sometimes it does. The behavior is intermittent and there doesn't seem to be a pattern.

Does anyone have any ideas why the problem occurs? Is there another, more predictable way of spinning a child prim smoothly?

Thanks for any help,

-Grim

---

you could try adding a forced restart of the targetomega after each texture change by adding your rotate_counter() after llSetLinkTextureAnim(3, ANIM_ON | LOOP, ALL_SIDES, 4, 4, 1.0, 11.0, 23 );

I all so see that your using

llSetLinkPrimitiveParams(0.2 second delay) for the omega and

llSetLinkPrimitiveParamsFast( )for the texture change. 

the first one has a delay built in, which could conflict with your 6 second timer ? might be why your having intermittent problems.  Try using llSetLinkPrimitiveParamsFast( ) for both.

 UPDATE:

Made a test script and I can get what your describing to work, din't test my first suggestion and my second dosen't seem to matter.

 Not sure if this works for your use, but dose demonstrate omega with a timed texture, and animation change. 

The omega survived having the object be copyed and rerezzed from inventory, not sure about a sim restart.

integer toggle;rotate_counter(){    vector rotationAngle = <0, 1, 0> * llTan(85);    llSetLinkPrimitiveParams(3, [ PRIM_OMEGA, rotationAngle, 1.0, 1.0 ]);}default{    state_entry()    {        rotate_counter();        llSetTimerEvent(6);    }    timer()    {        toggle=!toggle;        if(toggle)        {            llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, "ec122289-1239-74fd-708f-ab4b949b7cdb", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0]);            llSetLinkTextureAnim(3, ANIM_ON | LOOP, ALL_SIDES, 4, 4, 1.0, 11.0, 23 );        }                    else        {            llSetLinkPrimitiveParamsFast(3, [PRIM_TEXTURE, ALL_SIDES, "6ea53ede-fbe7-b96d-4222-da0a65014642", <1.0, 1.0, 0.0>, <0.0, 0.0, 0.0>, 0.0]);            llSetLinkTextureAnim(3, ANIM_ON | LOOP, ALL_SIDES, 4, 4, 1.0, 11.0, 23 );        }    }}

 

[Parrish Ashbourne]

---

Xiija wrote:

not sure if this helps, but...

this will give a kinda smooth child rotation in a 0.02 second timer... ( rotating child prim ....#3, root is #1)

 

timer()

    {

          vector rotationAngle = <0, 0.03, 0> ;

          list params = llGetLinkPrimitiveParams(3,[PRIM_ROT_LOCAL]);

          rotation childRot = llList2Rot(params,0);

          llSetLinkPrimitiveParamsFast(3, [ PRIM_ROT_LOCAL, childRot * llEuler2Rot(rotationAngle) ]);

    }

---

to tired to try right now, but wondering what happens when you combine this with target omega, at different spin rates, in different directions?

[Grim Bracken]

Thanks for all the great suggestions. I will try them today and report back what I find.

 

- Grim

[Grim Bracken]

---

Xiija wrote:

not sure if this helps, but...

this will give a kinda smooth child rotation in a 0.02 second timer... ( rotating child prim ....#3, root is #1)

 

timer()

    {

          vector rotationAngle = <0, 0.03, 0> ;

          list params = llGetLinkPrimitiveParams(3,[PRIM_ROT_LOCAL]);

          rotation childRot = llList2Rot(params,0);

          llSetLinkPrimitiveParamsFast(3, [ PRIM_ROT_LOCAL, childRot * llEuler2Rot(rotationAngle) ]);

    }

---

This is the solution that worked best for my project. The Omega spin did not work reliably no matter what way I engaged it. PRIM_ROT_LOCAL seems to be that way to go. It's actually pretty darn smooth using the above settings. Again, thanks to everyone for your help!

- Grim

[Vulpinus]

Just keep in mind that doing it this way, by changing the actual parameters of the object, means a much higher load on the server, your bandwidth, and everyone elses' that has the object within their draw distance.

The animations are (usually) just a client-side effect - the server sends the initial info, then your viewers do the rest making things animate locally. Nice and easy, very low bandwidth and server load.

Now, there are 50 * server calculations and object updates every second that have to be sent out to everyone within range, and updated in their viewers in order to redisply the object.

You can see what I mean by turning on the 'show updates to objects' by pressing CTRL-ALT-SHIFT-U and looking at the object. Compare what you see to something running an animation with TargetOmega or TextureAnim. Press that sequence again to turn off the feature.

I'm not saying not to do it, but you need to know the consequences of doing things that way. Basically, potential lag.

 

* Actually fewer, you can't do that many even if you set the timer for 0.02s.