llTargetOmega switched

[IvyTechEngineer]

Hello

I would like to turn "on" and "off" the rotation of an object using a switch. The script of the spinning object is:

default
{
    state_entry()
    {
        llTargetOmega(<0.0,0.0,0.0>,TWO_PI,1.0);         
    }
    
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(str=="stop")
        {
        llTargetOmega(<0.0,0.0,0.0>,TWO_PI,1.0);
        }
        if(str=="start")
        {
        llTargetOmega(<0.0,0.1,0.0>,TWO_PI,1.0);
        }
    }
} 

And the results show that the object spins around the y axis vs the x axis. If the first term in the llTargetOmega comman is vector axis.  

[Fenix Eldritch]

The script you provided will accomplish the task of starting or stopping an object from spinning. Though in this case, the trigger for it happening is in receiving an internal message of either "start" or "stop" from the llMessageLinked command. That implies there is another script somewhere in your linkset which actually sends out the message.

You should also read the specification for the llTargetOmega function as well. It explains what each of the input parameters do. In which case, yes, setting the y component of the vector would result in the omega spinning about the y axis. The specification also says that if you supply a gain (the 3rd parameter) of zero, that will also have the effect of stopping the spin.

It is worth mentioning that two scripts are not needed to accomplish this task: you can achieve the same effect with a single script using the llSetLinkPrimitiveParams or llSetLinkPrimitiveParamsFast functions. These functions are excellent for letting a single script make multiple changes at once against a selection of different links in a linkset.

Below is a simple example using llSetLinkPrimitiveParamsFast and a touch event to start/stop a prim's spin. In this case, simply clicking on the prim is the trigger, and it will also communicate its status to you via the llOwnerSay function.

integer toggle = FALSE;
integer targetLink = LINK_THIS;     //change this to target other link numbers

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,0.0,0.0>, TWO_PI, 0.0 ]);      
    }
    
    touch_start(integer total_number)
    {
        if(toggle = !toggle)
        {
            llOwnerSay("on");
            llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,1.0,0.0>, TWO_PI, 1.0 ]);
        }
        else
        {
            llOwnerSay("off");
            llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,1.0,0.0>, TWO_PI, 0.0 ]);
        }
    }
} 

 

[Quistess Alpha]

1 hour ago, Fenix Eldritch said:

The specification also says that if you supply a gain (the 3rd parameter) of zero, that will also have the effect of stopping the spin.

Which leads to a fun non-branching trick:

llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,1.0,0.0>, TWO_PI, (toggle=!toggle) ]);

 

[IvyTechEngineer]

5 hours ago, Fenix Eldritch said:

The script you provided will accomplish the task of starting or stopping an object from spinning. Though in this case, the trigger for it happening is in receiving an internal message of either "start" or "stop" from the llMessageLinked command. That implies there is another script somewhere in your linkset which actually sends out the message.

You should also read the specification for the llTargetOmega function as well. It explains what each of the input parameters do. In which case, yes, setting the y component of the vector would result in the omega spinning about the y axis. The specification also says that if you supply a gain (the 3rd parameter) of zero, that will also have the effect of stopping the spin.

It is worth mentioning that two scripts are not needed to accomplish this task: you can achieve the same effect with a single script using the llSetLinkPrimitiveParams or llSetLinkPrimitiveParamsFast functions. These functions are excellent for letting a single script make multiple changes at once against a selection of different links in a linkset.

Below is a simple example using llSetLinkPrimitiveParamsFast and a touch event to start/stop a prim's spin. In this case, simply clicking on the prim is the trigger, and it will also communicate its status to you via the llOwnerSay function.

integer toggle = FALSE;
integer targetLink = LINK_THIS;     //change this to target other link numbers

default
{
    state_entry()
    {
        llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,0.0,0.0>, TWO_PI, 0.0 ]);      
    }
    
    touch_start(integer total_number)
    {
        if(toggle = !toggle)
        {
            llOwnerSay("on");
            llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,1.0,0.0>, TWO_PI, 1.0 ]);
        }
        else
        {
            llOwnerSay("off");
            llSetLinkPrimitiveParamsFast(targetLink, [PRIM_OMEGA, <0.0,1.0,0.0>, TWO_PI, 0.0 ]);
        }
    }
} 

 

Thanks, yes there is another script on a switch object

integer myswitch;

default
{ 
    state_entry()
    {
        myswitch=FALSE;
        llSetText("Light Switch", <1.0, 1.0, 1.0>, 1.0);
    }

    touch_start(integer total_number)
    {    
       if(myswitch==FALSE)
       {    
       
       //Turn Light Bulb ON
     
       llMessageLinked(LINK_ALL_CHILDREN, 0, "start", NULL_KEY);
       llSetColor(<0.0, 1.0, 0.0>, ALL_SIDES);  
       myswitch=TRUE;
       
       }
       else
      {
          
      //Turn Light Bulb Off
          
      llMessageLinked(LINK_ALL_CHILDREN, 0, "stop", NULL_KEY);
      llSetColor(<1.0, 0.0, 0.0>, ALL_SIDES);  
      myswitch=FALSE;    
      
      }
    
    }
}
 

After watch a the YouTube video 

I was able to duplicate the script in SL for my objects. I am attempting to turn on and off a rotor on a DC motor with the switch. The only problem seem to be that the rotor is rotating around a different point when it is linked? 

[Quistess Alpha]

6 minutes ago, IvyTechEngineer said:

there is another script on a switch object

That video is rather old; nowadays it's common (and better) practice to do things in a single script when possible, as LSL now has functions for directly interacting with linked prims other than the one the script is in. Most notably: llSetLinkPrimitiveParamsFast.

[Fenix Eldritch]

3 hours ago, IvyTechEngineer said:

the rotor is rotating around a different point when it is linked?

In the case of a (presumably) non-physics enabled child prim, it would be spinning around the center of the target prim. If it's appearing to rotate around a different point, then the prim may have had some parameters altered to make it appear off-center (like path cuts or slice). Or perhaps the rotor is mesh with geometry such that its center is not where you might expect. At a glance, you can see where an individual object's center is by selecting it in the edit tool and observing where the move widgets appear (use Edit Linked to select individual child links in a linkset). If the true center of the rotor is not conducive to spinning it, then you can try to edit it if it's a prim. But if it's a mesh, you might be out of luck and may need to recreate the rotor with extra geometry to shift the origin to a position that works with the desired spin effect.

Or did you mean to say it's rotating around a different axis than what you expected? As per the specification on the function's wiki page:

Quote

Link Sets

• If the script is attached to the root prim, the entire object rotates around the region axis.
  • If the object is attached then it rotates around the attachment axis.
• If the script is attached to a child prim, the prim rotates around the local axis.
  • A child prim can rotate around its own axis while the entire object rotates around another axis.

The 2nd main bullet point would apply to your current scenario. In this case the vector axis you specify in the llTargetOmega (or SLPPF) command will not refer to the global axis, but rather the local axis relative to the root prim's orientation. Setting your entire object to be at a zeroed out rotation will be helpful while you experiment to find an appropriate value for the axis vector to supply to your llTargetOmega call.

Edit: And yeah, much of the information in that video has become outdated. See the limits page for more up to date info. Best practices have also advanced. Using three scripts to modify three different prims in the same linkset is less than ideal. Everything in that demo can be easily achieved with one single script. I would recommend you give the LSL Script Efficiency page a quick view, particularly the "Efficient Design" section.

Edited February 8, 2022 by Fenix Eldritch

[IvyTechEngineer]

Rotor rotation problem

[Fenix Eldritch]

Your previous posts indicated that your rotor was part of a linkset, but that gif in your last post shows it's now unlinked and by itself. So I would expect calling llTargetOmega with an axis vector of <0.0, 0.1, 0.0> would make make the rotor spin about the region 's Y axis regardless of any other rotations already applied to the rotor. At least, that's what I am seeing with my own tests. (Unless I've missed something obvious)

So I'm guessing it may be one of two possibilities:

• Either you have accidentally introduced a typo into your script and are spinning about the X axis... since the script you're currently using can't be the one you posted in the original post. Double check your axis vector: make sure the X and Z components are truly zero.
• Or the mesh rotor's natural orientation is somehow causing the confusion. I'm not sure about this, since as an unlinked object, it should spin about the region's Y axis (if your supplied vector is the same). But it wouldn't hurt to try different variations of the axis vector to see which one works out better:
  • <0.1, 0.0, 0.0>
  • <0.0, 0.1, 0.0>
  • <0.0, 0.0, 0.1>

[IvyTechEngineer]

Hi Fenix,

I can get the rotor to spin correctly (around the object's y axis) when it is not linked but when it is linked but when it is linked the object appears to rotate strangely. 

• <0.0, 0.1, 0.0> works fine if unlinked. https://www.ivytechengineering.com/SecondLife/files/armature rotate4a.gif
• <0.0, 0.1, 0.0> doesn't work if linked. https://www.ivytechengineering.com/SecondLife/files/armature rotate4b.gif

Here is the code for the rotor (in the gifs I use a prism or wedge. 

default
{
    state_entry()
    {
        llTargetOmega(<0.0,0.0,0.0>,TWO_PI,1.0);         
    }
    
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(str=="stop")
        {
        llTargetOmega(<0.0,0.0,0.0>,TWO_PI,1.0);
        }
        if(str=="start")
        {
        llTargetOmega(<0.0,0.1,0.0>,TWO_PI,1.0);
        }
    }
}

[Fenix Eldritch]

Then it is as I said previously: child prims have their omega on a local axis - which is relative to the orientation of the root prim of the linkset.

14 hours ago, Fenix Eldritch said:

Or did you mean to say it's rotating around a different axis than what you expected? As per the specification on the function's wiki page:

Quote

Link Sets

• If the script is attached to the root prim, the entire object rotates around the region axis.
  • If the object is attached then it rotates around the attachment axis.
• If the script is attached to a child prim, the prim rotates around the local axis.
  • A child prim can rotate around its own axis while the entire object rotates around another axis.

The 2nd main bullet point would apply to your current scenario. In this case the vector axis you specify in the llTargetOmega (or SLPPF) command will not refer to the global axis, but rather the local axis relative to the root prim's orientation. Setting your entire object to be at a zeroed out rotation will be helpful while you experiment to find an appropriate value for the axis vector to supply to your llTargetOmega call.

 

To help illustrate this, take your linkset as it is now and get the linked rotor spinning. Now, open the edit tool and enable the "Edit Linked" checkbox. Select the root of your linkset and change its rotation in the edit tool. Observe how the spin of the linked rotot changes as soon as you confirm the root's new orientation. This is what you're experiencing. Your object's root is at some arbitrary rotation, so when you attempt to apply llTartetOmega to one of the child links, it is affected by the current rotation of the root.

Try a supplying a vector that uses a different axis, either <0.1, 0.0, 0.0> or <0.0, 0.0, 0.1>.

Or, build your linkset such that the root's orientation is all zeros for XYZ rotation in the edit window. That might help show visually what to expect if you still use the global axis as a guide.

 

 

[IvyTechEngineer]

Thanks, I think I have figured out a solution. If move the object to the say X and Z locations as the linkset origin and make sure the control switch has no rotation then the rotor will spin around the y axis as desired using the script that I have. 

 

[arton Rotaru]

To make a link spin around the Y axis independent of the roots orientation, multiply the links local rotation to the axis vector.

llTargetOmega(<0,1,0> * llGetLocalRot(), TWO_PI, 1.0);

 

[IvyTechEngineer]

3 hours ago, arton Rotaru said:

To make a link spin around the Y axis independent of the roots orientation, multiply the links local rotation to the axis vector.

llTargetOmega(<0,1,0> * llGetLocalRot(), TWO_PI, 1.0);

 

That did the trick, thank you! But for some reason I had to enter        

llTargetOmega(<0,0,0.1> * llGetLocalRot(), TWO_PI, 1.0);

default
{
    state_entry()
    {
        llTargetOmega(<0,0,0> * llGetLocalRot(), TWO_PI, 1.0);         
    }
    
    link_message(integer sender_num, integer num, string str, key id)
    {
        if(str=="stop")
        {
        llTargetOmega(<0,0,0> * llGetLocalRot(), TWO_PI, 1.0);
        }
        if(str=="start")
        {
        llTargetOmega(<0,0,0.1> * llGetLocalRot(), TWO_PI, 1.0);
        }
    }
}

[arton Rotaru]

12 minutes ago, IvyTechEngineer said:

That did the trick, thank you! But for some reason I had to enter        

llTargetOmega(<0,0,0.1> * llGetLocalRot(), TWO_PI, 1.0);

Check the axis on your Rotor object by changing the grid ruler from World to Local, in the build floater. Then tick Edit linked, select the Rotor and it will show it's local axes.

I would also just type the axis vector like so <0.0, 1.0, 0.0> and adjust the spinrate in the actual spinrate field.

Edited February 8, 2022 by arton Rotaru

[IvyTechEngineer]

25 minutes ago, arton Rotaru said:

Check the axis on your Rotor object by changing the grid ruler from World to Local, in the build floater. Then tick Edit linkrd, select the rotor and it will show it's local axes.

I would also just type the axis vector like so <0.0, 1.0, 0.0> and adjust the spinrate in the actual spinrate field.

Thanks, I will try to do what you suggest tomorrow, have class now. I am using the SL Viewer, does it have a ruler? Sorry for the questions but I am still trying to figure stuff out ...  I do have the Firestorm viewer on my PC.

[arton Rotaru]

6 minutes ago, IvyTechEngineer said:

Thanks, I will try to do what you suggest tomorrow, have class now. I am using the SL Viewer, does it have a ruler? Sorry for the questions but I am still trying to figure stuff out ...  I do have the Firestorm viewer on my PC.

It's a drop down menu.

 

[IvyTechEngineer]

1 hour ago, arton Rotaru said:

It's a drop down menu.

 

Ok, I did what you said but my Z axis is actually what the rotor needs to rotate about. 

[IvyTechEngineer]

Onward and upward, now to add some cables to the battery and texture to the battery and I should be done. 

[arton Rotaru]

17 minutes ago, IvyTechEngineer said:

Ok, I did what you said but my Z axis is actually what the rotor needs to rotate about.

Right! With the ruler set to local you can easily find out which axis it actally is you want to rotate about. The little arrow button, besides the drop down, reveals a few more ruler options.

[IvyTechEngineer]

Thanks for the help ... now I need to figure out how to draw those cables in Blender.

[Rolig Loon]

1 hour ago, IvyTechEngineer said:

now I need to figure out how to draw those cables in Blender.

Try this ... 

 

Edited February 10, 2022 by Rolig Loon

[IvyTechEngineer]

On 2/10/2022 at 5:56 PM, Rolig Loon said:

Try this ... 

 

I have been using a similar YouTube video but the mesh tri count is too large I think. Need to figure how to reduce them. 

[IvyTechEngineer]

Ok so I have added some cables to my motor model. The parts of the model I want to connect to in SL were linked together inworld and saved as a DAE file. Then I added 4 cables, but each cable only had two handles and I couldn't figure out how to add more degrees of freedom to the cables. Not sure how to fix it. 

https://pasteall.org/blend/ffb5d2c90b0c44a49f2d44f0d6cab38c

[Rolig Loon]

45 minutes ago, IvyTechEngineer said:

Then I added 4 cables, but each cable only had two handles and I couldn't figure out how to add more degrees of freedom to the cables. Not sure how to fix it. 

You'll have to shape your cables in Blender, before you export them.  As far as SL is concerned, your mesh object is essentially a cube, so it doesn't have any more handles than any other object. You can't make the cables flexible in world.  It's frustrating, but that's life. 

[IvyTechEngineer]

I was able to subdivide the cables to add more handles to contour them a little better. Not sure how to paint them? Also, if I delete the big green box and battery should I try to save each cable as a separate DAE with a texture or try to do everything together?