Jump to content

llSetKeyFramedMotion Unexplained Behavior (I think)


GManB
 Share

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

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

Recommended Posts

If I do this:

framesList = [llEuler2Rot(<30.0, 0.0, 0.0>*DEG_TO_RAD), 1.0];

 llSetKeyframedMotion(framesList, [KFM_DATA,KFM_ROTATION]);

The object rotates 30.0 degrees as expected.

If I, instead, i call KFM with either of these lists:

framesList = [llEuler2Rot(<30.0, 0.0, 0.0>*DEG_TO_RAD), 5.0]; or

framesList = [llEuler2Rot(<30.0, 0.0, 0.0>*DEG_TO_RAD), 225.0/45.0];

Object rotates about 4.7999 degrees.

Object is just a simple rectangular prim. I do change the physics shape type to convex

Any ideas why?

 

 

  • Like 1
Link to comment
Share on other sites

Are there other APIs for motion that I might be missing? I have not yet investigated animations but the motions of avs seems to be relatively smooth (when the sim is lightly loaded) and complex. Or are motions in animations something different than motions for objects?

G

Link to comment
Share on other sites

Animations are client-side and don't result in position updates, while objects in motion (not omega rotation) will be causing updates from the region to the client at frequent intervals. This can cause some jerkiness if there is network delay or server loading, but the avatar animations will not be subject to such delays.

Link to comment
Share on other sites

If we're really only talking about rotation, then llTargetOmega isn't a bad approach to smooth the transition between updating the actual rotation every few seconds (with llSetLinkPrimitiveParamsFast() or the like). I've made a clock's sweep second hand that way that moves very nicely after the first viewer update (so if you look away, it can take those few seconds before the hand jumps to the time and starts moving smoothly... where "few" can be a tradeoff between the size of that first jump and the cost of timer()-driven updates).

I was reminded of that clock because the desired 30 degrees every 5.0 seconds is much like 360 degrees every minute.

Link to comment
Share on other sites

1 hour ago, Profaitchikenz Haiku said:

Animations are client-side and don't result in position updates, while objects in motion (not omega rotation) will be causing updates from the region to the client at frequent intervals. This can cause some jerkiness if there is network delay or server loading, but the avatar animations will not be subject to such delays.

Got it! Thanks. Makes sense.

G

Link to comment
Share on other sites

15 minutes ago, Qie Niangao said:

If we're really only talking about rotation, then llTargetOmega isn't a bad approach to smooth the transition between updating the actual rotation every few seconds (with llSetLinkPrimitiveParamsFast() or the like). I've made a clock's sweep second hand that way that moves very nicely after the first viewer update (so if you look away, it can take those few seconds before the hand jumps to the time and starts moving smoothly... where "few" can be a tradeoff between the size of that first jump and the cost of timer()-driven updates).

I was reminded of that clock because the desired 30 degrees every 5.0 seconds is much like 360 degrees every minute.

Qie,

For constant velocity this seems fine. The swing is a pendulum and so it's velocity, in rl, is never constant. It changes, of course, from max as the bottom of the swing motion to zero at the maximum angular displacement from vertical. It is this constantly changing velocity which I am trying to recreate in sl. My algorithm builds a list of rotations in steps of 0.2 degrees for a full period, bottom to forward max angle, reversing to bottom, then to rearward max angle, reversing to bottom again. For a 20 degree max angle this results in 40 steps. I then iterate calling llSetPPF with the rotation for this step. There is a second list that for each step holds a boolean as to whether to sleep on this iteration. More sleeps, slower velocity. This list is also auto generated at the time when the rotation list is generated.

 

I could imagine something similar with llTargetOmega. Calling it 40 times per period with different velocities. Something to try..

Thanks,

G

Link to comment
Share on other sites

2 hours ago, Qie Niangao said:

Just a note that llSLPPF includes [PRIM_OMEGA], so you don't have to call llTargetOmega directly, but it's an update per call either way.

Also, in case it's useful, there's a wiki page by Dora Gustafson, "Simple Pendulum Motion in 24 Key Frames".

Thanks. I took a deeper look at Dora's algo and see that she keeps the time-per-step constant but changes the angle to simulate change in velocity. This is clever. However, because the algo also manipulates position the inconsistencies in the underlying execution (frame times, number of scripts running, etc.) the whole object jumps around a bit. In the case of my swing the jumpiness is very noticeable where the ropes attach to the structure. In my algo I use only rotation. Have a very small cube as root prim and aligned with the x-axis that passes through the attachment points and use only rotation to rotate the cube.

I am going to see if I modify Dora's algo to compute dT using a value for the pendulum length rather than the actual object's z-axis length and then use only rotation on the small cube.

In the end though, both algo's suffer from the inconsistencies.

 

G

Link to comment
Share on other sites

an effect on client side visuals that is greater than script performance is network lag between the server and the client. Linden try to compensate for this with interpolation on the client

if you haven't already then can see how Linden does this. menu Advanced \ Network \ Velocity Interpolate Objects. To see this easily, disable and walk your avatar

 

Link to comment
Share on other sites

2 hours ago, Mollymews said:

an effect on client side visuals that is greater than script performance is network lag between the server and the client. Linden try to compensate for this with interpolation on the client

if you haven't already then can see how Linden does this. menu Advanced \ Network \ Velocity Interpolate Objects. To see this easily, disable and walk your avatar

 

Thanks Molly!

I've done some some experiments with Dora's KFM algo and mine. Her's seems smoother when the server/net is lightly loaded. When the server gets busy and/or the network latencies are highly variable mine seems smoother. I think the reason is that KFM sets the motion to the next position and rotation and if there is a delay (where I do not know) the motion seems to continue as started in the previous position/rotation. Then things catch up and there is some jerkiness as the swing sort of re-syncs and catches-up. The point is that the position of the whole swing changes and the ropes separate, visibly from the frame. My algo simply sets rotations and not positions and is based on time. Thus, in my case if the script is delayed, due to server/network, the swing stops but doesn't continue unwanted motion.

Well, I just don't know how to proceed... but, I am leaning toward my algo... it gets jerky but only in that it stops motion. The jerkiness of KFM, OTOH, seems less aesthetically, IMHO and in this particular instance, pleasing in times of high server/network over-commitment. 

G

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 1390 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...