Wing troubles

I'm having troubles with my pig again. I'm tryng to make his wings flap. As long as the rotation is 0,0,0 I'm good. However when the parent rotation changes the wings go nuts and rotate in strange ways.

Thanks in advance for your assistance.

S

rotation xyz;
vector xyz_angles;
vector angles_in_radians;

default
{
link_message(integer sender_num, integer num, string str, key id)
{
if (str == "flap"
{
xyz_angles = <0,45.0,0>; // Angles as in build menu
angles_in_radians = xyz_angles*DEG_TO_RAD; // Change to Radians
xyz = llEuler2Rot(angles_in_radians); // Change to a Rotation
llSetPrimitiveParams([PRIM_POSITION,llGetLocalPos() + <0.05,0,-0.117>,PRIM_ROTATION,llGetLocalRot()*xyz]);
}
else if (str == "unflap"
{
xyz_angles = <0,-45.0,0>; // Angles as in build menu
angles_in_radians = xyz_angles*DEG_TO_RAD; // Change to Radians
xyz = llEuler2Rot(angles_in_radians); // Change to a Rotation
llSetPrimitiveParams([PRIM_POSITION,llGetLocalPos() + <-0.05,0,0.117>,PRIM_ROTATION,llGetLocalRot()*xyz]);
}
}

}

Positions and rotations on child prims when using llSetPrimitiveParams unfortunately does not work as one would think, and indeed only works at <0,0,0> to do what you want.

Would be much better served using llSetLocalRot() and llSetPos() for what you're trying to do

I've tried that but they don't move smoothly. First they rotate then position. Looks like I'll have tu use a hinge (sigh).

S

I believe this phenomena is discussed here:



...with possible workarounds.

If I understand the intent, with enough torturing of relative rotations, and staying mindful of the bass-ackwards implementation of rotations in child prims (http://jira.secondlife.com/browse/SVC-93), I think one could get llSetPrimitiveParams to work. But possibly simplifying it slightly: one could arrange for the flapping prim's axis of rotation to be at the edge--so as to behave like a "hinge"--by changing it to a sphere and half-dimpling it, then changing it back... then one might not need to change the position, only the rotation.

Yep... the interpolation applied by the client is different for rotations vs. translations. So you see one of the happen faster than the other, which makes the prim jump around, even if you got your math right.

I filed a bug on this a long time ago, but nothing's been done about it AFAIK.

http://jira.secondlife.com/browse/VWR-332

Qie, the cut solutions don't really work with flexi prims, which is what I use in my wings. You can't do the .375/.875 cut because the cut ends up on the wrong axis w.r.t. the flex movement, and I don't remember what happened when I tried the dimple trick, but it didn't work either. I think the flex origin stayed at the original uncut prim's edge, or something like that.

you find the solution for rotating a prim relative to another prims rotation in the lsl wikis.

quaternion rotations can be multiplied or divided by another quaternion rotation to result in a rotation relative to another rotation, or to get the rotation difference. (do not add or substract quaternions)

for linked and root prims there is usually another llFunction that does that automatically.

I remember what happens.... the cuts disappear, they're completely ingored (apparently to prevent recalculating the flexi base or prevent them from having floating apparent bases).... this completely destroyed my wings project which relied on the simpler behavior of rotating a cut prim.

SVC-93 does have the corrected rotation math though, all hail Lex Neva for that work-around

The wings arn't flexi so I ended up cutting them.

Thanks for the help.
S