Jump to content

llTargetOmega reliable for real rotations?


Phoebe Hazelnut
 Share

You are about to reply to a thread that has been inactive for 2649 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello. I wanted to turn an non-pyhs-object smoothly, so not with llSetRotation periodically. which moves the object in steps, but with llTargetOmega which animates the object smoothly. Now llTargetOmega on non-phys-objects is a client effect, that means it doesn't happen on the server but only visually in the client, read: The object is not really turning physically. That means after stopping llTargetOmega, the object's rotation gets updated from the server and thus is rotated back again like it is physically in world. So, the idea was that I calculate the revolutions/angle the object did, get the "visual" angle and use llSetRotation to make the "visual" rotation physical on the sim. This however doesn't seem to work quite well, either my calculation was wrong or llTargetOmega is not reliable and due to client-lag or something and lets say a target omega by TWO_PI after like 1.5 seconds doesn't really mean that the object has turned in the client view that exact angle. Is it even possible to predict the angle an object turned "visually" in the client to set it physically on the server afterwards?
Link to comment
Share on other sites

If there are 3 clients watching the rotation - every one sees it in a different angle. So it makes no sense to try to match anything with a client angle.

Scripts run on the server and know only things that happen on the server so you are waisting your time here anyways.

Use a physical llTargetOmega or

use llSetKeyframedMotion - this one works the way you want your rotation to work.

Link to comment
Share on other sites

As Nova mentions llSetKeyframedMotion() is the function you should probably look at. It's pretty awesome.

As the wiki page http://wiki.secondlife.com/wiki/LlSetKeyframedMotion mentions: "The following example does the same thing as using llTargetOmega(<0.0,0.0,1.0>,PI,1.0) to make a prim rotate continuously around its Z-axis"

integer gON; default{    touch_start(integer total_number)    {        gON = !gON;        if (gON)        {            // Make repeated rotations of PI/2 radians, each taking 0.5 seconds            llSetKeyframedMotion([llEuler2Rot(<0.0,0.0,PI/2>), 0.5],[KFM_DATA,KFM_ROTATION, KFM_MODE,KFM_LOOP]);        }        else        {            llSetKeyframedMotion([],[]);        }    }}
Link to comment
Share on other sites

llSetKeyframedMotion can indeed be just the right tool for the job, but I would encourage you to read the caveats for it and for llTargetOmega, to be sure that you understand the limitations of each function.  For example, llSetKeyframedMotion cannot be used on physical objects or attachments, and may not be used in the child prim of a linkset. Also, you cannot use scripts to move any prim in the linkset while the keyframed motion is active, so you need to go through a sometimes tedious process of pausing and then restarting the KFM action if you have a really complex linkset to move.  Depending on your particular installation, these can be serious limitations.  KFM does produce nice, smooth, predictable motion, however.

Link to comment
Share on other sites

The prim equivalency system is what SL members who joined in the past couple of years think of as the "normal" system, where we measure the complexity of an object in terms of land impact units instead of prims.  If you want to use KFM, you need to set your object to physics shape type Complex Hull, rather than Prim.  You can either do that manually, with your editor, or you can assure it by putting a line in the state_entry event of your script:

llSetLinkPrimitiveParams(LINK_THIS,[PRIM_PHYSICS_SHAPE_TYPE,PRIM_PHYSICS_SHAPE_TYPE_CONVEX]);

 Incidentally, there's a simple example of how to use KFM to simulate llTargetOmega in the LSL wiki.

Link to comment
Share on other sites

Thank you. with Complex Hull set it works on the prim however sadly I can't use that. :( It seems pretty laggy and the wheel is jumping around like wild, at least on the sandbox sim where I was. Sometime it's just jiggling and sometimes it just turns a few steps and then suddenly jumps to another angle then it's turning smoothly again just to come back to jumping/jiggling. That's actually worse than just having it move in steps with llSetRot.

Link to comment
Share on other sites

I tried the example from the wiki and indeed it doesn't work. It tries to repeat a 90° turn. So I put 4 or that turns into the parameter list and it still didnt work. Needed to round teh time to 1/45th of a second too. That worked.

Ok this one works for me: (the minimum number of steps for a full rotation is 3 so i used that)

integer gON;float motion_time( float mt){    mt = llRound(45.0*mt)/45.0;    if ( mt > 0.11111111 ) return mt;    else return 0.11111111;} default{    touch_start(integer total_number)    {        gON = !gON;        if (gON)        {            // Make repeated rotations of PI/2 radians, each taking 0.5 seconds            rotation r = llEuler2Rot(<0.0,0.0,TWO_PI/3>);            float t = motion_time (0.75);            llSetKeyframedMotion([r,t, r,t, r,t],[KFM_DATA,KFM_ROTATION, KFM_MODE,KFM_LOOP]);        }        else        {            llSetKeyframedMotion([],[]);        }    }}
Link to comment
Share on other sites

Hm this still has strange display behaviour. The turning jitters but looks smooth when I turn the view. When I zoom in and out it jitters and then occasionaly runs smooth again. Could that have something to do with my viewer fps (between 100 and 200fps depending on how I turned the camera)? 'I never have this weird display with llTargetOmega.

Link to comment
Share on other sites

It probably depends on your computer.  The version on the wiki works for me, and so does Nova's, but I have occasionally seen the sort of behavior you are reporting when I have run KFM scripts on my laptop. That should be a cautionary thought if hyou are writing a script for public use.

Link to comment
Share on other sites

Well yes it's difficult if you have different behaviours on different computers. I got actually quite good performance in sl with around 60 fps in normal filled places and 100-200 in an empty skybox.

 

Here is what I made of Nova's script: Some wheel of fortune like turning thingy. But I always have to adjust my camera back and forth and left and right until it appears smoothly turning.

 

float braking;integer steps;rotation r;float t;vector angle;float motion_time( float mt){    mt = llRound(45.0*mt)/45.0;    if ( mt > 0.11111111 ) return mt;    else return 0.11111111;} default{    touch_start(integer total_number)    {        llSetTimerEvent(0.5);        braking = 1/(llFrand(100.0)+1);        llOwnerSay((string)braking);    }        timer()    {        steps++;        braking = llPow(0.05*steps, 2);        r = llEuler2Rot(<0.0,0.0,TWO_PI/3>);        t = motion_time(braking);        llSetText((string)steps+"\n"+(string)braking, <1,1,1>, 1);        if(braking > 20.0)        {            llSetKeyframedMotion([],[]);            angle = llRot2Euler(llGetRot())*RAD_TO_DEG;            llSetText((string)(angle.z), <1,1,1>, 1);            llSetTimerEvent(0);            steps = 0;        }        else        {            llSetKeyframedMotion([r,t, r,t, r,t],[KFM_DATA,KFM_ROTATION, KFM_MODE,KFM_LOOP]);        }    }}

 

Link to comment
Share on other sites

I made a few tests. Client framerate and settings have no influence as expected. UDP data has no influence too. I can't change my ping of course and that is a bit below 200. (normal for US west coast for me)

For the scripting: I always need to define a full circle in the parameters. No matter if 3 or 8 waypoints. Additionally the times are required to be rounded to 1/45th of a second. Loops work super smooth only if both conditions are fulfilled.

That's good to know. I will not waste time on unstable SL features and keep my old SLPPF movement on some old things.

Link to comment
Share on other sites

The flickering appears with the wiki code, with your original and with my modification so it's probably not the code but the client. Also had that thing on a sandbox and on some rather empty random land. It runs super smooth after I moved my camera around a bit. I wasn't really able to find out when exactly the flickering appears. I also tried to make a screenshot using Print Screen button but while the flickering distorted the wheel creating zig-zag edges, the screenshot looks clean.

(EDIT: The flickering also doesn't disappear when the wheel slows down with my code.)

"keep my old SLPPF movement on some old things"

What's SLPPF?

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 2649 days.

Please take a moment to consider if this thread is worth bumping.

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...