How can I smoothly step the rotation of a prim in a linkset?

[Miguelito Shilova]

Hello fellow scribblers ...

So I have these two objects in a linkset (I'll call them fins), and the intent is to use llMessageLinked calls from the root script to scripts in each prim, and rotate them on the X axis to specific positions based on the call. On entry, or when 'M' is sent, they should be Left Fin, X rotation = 300, Right Fin X rotation = 60. When 'R' is sent, both move to X rotation = 0. I'm using a llSetLinkPrimitiveParamsFast call and it works fine, but it snaps to position, and I want to control the speed of rotation.

ex ...  llSetLinkPrimitiveParamsFast(LINK_THIS, [PRIM_ROT_LOCAL, llEuler2Rot(<x,0.0,0.0>*DEG_TO_RAD)]);

(x being the specific rotation amount)

I tried stepping the rotation with a Do / While call, but it was erratic in its rotation speed (not smooth at all), and I had no luck getting it to stop where I needed. It would either not move or just continue to spin. The erratic rotation made me think a Do / While call isn't the route to take. Any suggestions on how I can define a rotation speed and smoothly transition from one rotation value to the next? This would call for both clockwise and counterclockwise transitions.

Thanks!

-- Mig

 

[Profaitchikenz Haiku]

Loops are always going to be too fast, this is where a short duration timer will give you a better visual effect. To rotate through 60 degrees I would suggest you first try it in increments of 10 degrees at 0.5 second timer setting.  Shorten the timer interval and see how this makes the rotation appear, and if that still isn't smooth, try 5 degree increments. On things like railway engine spoked wheels I'm using quite a short timer interval but I'm rotating 22.5 degrees at a time, on the basis that the forward motion of the locomotive is going to mask some of the otherwise jerky effect. If (as I suspect) you're making a fish swim then you can probably get away with the same trick.

Edited June 13, 2020 by Profaitchikenz Haiku

[Twisted Pharaoh]

Have you tried the animesh way?

 

[Miguelito Shilova]

5 hours ago, Twisted Pharaoh said:

Have you tried the animesh way?

 

Unfortunately my program doesn't do mesh rigging, and I've just scratched the surface with Blender. I think I'll try Profaitchikenz's suggestion of a timer within the script for my OP, but your suggestion of animesh intrigues me because I'd like to use that for something else. Do you or anyone you know have experience with animesh? If so, I would like to pursue a conversation about assisting with a fairly straightforward application of it.

[animats]

Try using llSetLinkPrimitiveParams instead of llSetLinkPrimitiveParamsFast. You don't want 'fast'. You want to wait for the previous change to complete before the next one starts, which is what regular llSetLinkPrimitiveParams does.

[Qie Niangao]

18 hours ago, Miguelito Shilova said:

the intent is to use llMessageLinked calls from the root script to scripts in each prim

There's rarely any reason to message linked prims, especially not if the objective is to smoothly transition primitive parameters. The messaging overhead isn't huge, but it's not zero, and getting another script to wake up and do something adds yet more variability to the timing. 

4 hours ago, animats said:

Try using llSetLinkPrimitiveParams instead of llSetLinkPrimitiveParamsFast. You don't want 'fast'. You want to wait for the previous change to complete before the next one starts, which is what regular llSetLinkPrimitiveParams does.

To avoid possible confusion: it's just that the built-in delay is so long that changes are likely to have plenty of time to complete; the delay isn't nearly long enough for any kind of handshaking to ensure that one update completes before the next starts. Either way, though, whether relying on the 200 msec delay of the non-Fast llSLPP or some timer-event interval for llSLPPF, it'll work more predictably than a tight loop.

[Twisted Pharaoh]

7 hours ago, Miguelito Shilova said:

Unfortunately my program doesn't do mesh rigging, and I've just scratched the surface with Blender. I think I'll try Profaitchikenz's suggestion of a timer within the script for my OP, but your suggestion of animesh intrigues me because I'd like to use that for something else. Do you or anyone you know have experience with animesh? If so, I would like to pursue a conversation about assisting with a fairly straightforward application of it.

Well I can't say I am experienced with animesh, but I know some bits of Blender. Basically to get you started you can just take the Blender starter cube, add a single bone to it, name that bone mPelvis, and create an animation to make it spin a bit, export it as bvh. Then import that stuff on test server and see if it works when attached to a prim. It is that part that I think it should work but I'm not sure. If the proof of concept works then it will be time to dive deeper. There are plenty tutorials on YT that should help you get started.

 

[Miguelito Shilova]

Quote

There's rarely any reason to message linked prims, especially not if the objective is to smoothly transition primitive parameters. The messaging overhead isn't huge, but it's not zero, and getting another script to wake up and do something adds yet more variability to the timing. 

Hi Qie ... I started down the llMessageLinked route because the main script wasn't reliably calling for the alpha changes or rotations on my 'sail' prims based on the link number. Firestorm would tell me the link number of a prim and I would plug that into the call, but when I ran the script the wrong prims in the linkset would do those alpha and rotation changes. It really didn't make sense because Firestorm would consistently call the same linknum for a given prim, so it wasn't like the numbers were changing on me and I wasn't unlinking/linking them, which of course could change their linknum. I think there is also an advantage with llMessageLinked because I can easily manage different sailing modes (boat tied off, sails up, sails down), since those configs call for different prims to do multiple things depending on the mode. There's probably a more elegant solution to that in a single script ... I'm just not there yet 🙂

I'll try llSLPP instead of llSLPPF with a timer and see how that works ... if it's still sloppy I might look to try something else.

Quote

Basically to get you started you can just take the Blender starter cube, add a single bone to it, name that bone mPelvis, and create an animation to make it spin a bit, export it as bvh. Then import that stuff on test server and see if it works when attached to a prim. It is that part that I think it should work but I'm not sure. If the proof of concept works then it will be time to dive deeper. There are plenty tutorials on YT that should help you get started.

Thanks Twisted ... I'll check out YouTube and try walking this path.

[Twisted Pharaoh]

Look for "low poly rigging" there are 3-5 minutes tutorials. There are also tutorials about exporting to SL, basically there are presets to use. And you should look at tutorials that match your Blender version or you might have some troubles finding the stuff they are talking about.

 

[Profaitchikenz Haiku]

2 hours ago, Miguelito Shilova said:

Firestorm would tell me the link number of a prim

I have often found a difference between the link number of a child as shown in the build floater and the link number as reported by a touch on the child. I would suggested you drop a script in the root that chats out the llDetectedLinkNumber of a touched prim to determine what number to then pass to LinkPrimitiveparams instead of reading from the floater.

Edited June 14, 2020 by Profaitchikenz Haiku

[Kyrah Abattoir]

If you care more about smoothness than precision llTargetOmega is a good choice to rotate a child prim around its own origin.

EDIT: Nevermind it seem precision is important here.

 

I'd recommend to use a spherical lerp between the min/max position and to factor in the length of time that passed since the last update.

Edited June 15, 2020 by Kyrah Abattoir

[Nova Convair]

I see no problem to move/rotate linked prims smoothly. Not that smooth as TargetOmega or KeyFramedMotion but it's not bad if the "scripts run" of the sim isn't ultra low.

The link parameter in llSetLinkPrimitiveParamsFast is for what? The link # of the fin. Nobody needs a 2nd script and messages here.

llSetLinkPrimitiveParamsFast(fin1link, [PRIM_ROT_LOCAL, llEuler2Rot(<x1,0.0,0.0>*DEG_TO_RAD), PRIM_LINK_TARGET, fin2link,PRIM_ROT_LOCAL, llEuler2Rot(<x2,0.0,0.0>*DEG_TO_RAD)]); (move both in sync in a single call)

The link#'s? I personally get the link#'s by name in the script but you can drop a script into the root that uses llDetectedLinkNumber and llDetectedTouchFace and tells you what was touched.

Now the speed. Lets say we want 15 fps and 30° per second and want to rotate it by 45°
Thats 1/15 = 0.067 for the delay between steps
and 45/30 = 1.5 sec and 15 * 1.5 = 22 steps and 30/15 = 2° per step

So you need a loop with SLPPF and add 2° in each step and a llSleep(0.067)
followed by a final SLPPF with the end positions.

Of course the script will be unresponsive in that 1.5 seconds.
If that is a problem you run each step of the loop in a timer event and setup the data in global variables b4 starting the timer.

Euler rotations are a problem in certain scenarios - there is a reason SL uses quarternion rotations. In this case I think it should work though, but I only know it for sure after I tested it 😁
Another option is to use SLERP (you find that in the wiki) that allows transitions between two rotations.

Oh - and it makes no sense to use more than 15 fps. In theory 45 fps is max. possible. But the sim doesn't send 45 updates per second to your viewer. So you dont see most of the 45 steps. If you are lucky you get 15.

Edited June 17, 2020 by Nova Convair