New Way to approach the problem...!

Hi all...

Sorry to revisit this physical rotation thing, but I just thought of a new way to express the issue I am facing...

Imagine for a moment, a bowling pin...

The pin is falling in a direction/rate that I know via REGIONAL reference. I can use llApplyRotationalImpulse(), again in a regional mode... to push the pin back up! This is cool, because I don't need to know what way the pin itself is facing (it's heading)...

BUT what if I want to llApplyRotationalImpulse in such a way as to negate some LOCAL axis... say I want it to fall backward (locally), so I want to negate the rotational impulse that acts against the backward falling of the pin... but since the rotational impulse is acting from a regional frame of reference... I can't simply say:

llApplyRotationalImpulse (<force, 0,0>, FALSE);

because the second argument is NOT a local... it is regional.

This is still the same problem. It makes it much easier if you bring up new points in the same thread so that there is continuity for everyone else and they do not have to go back and forth between threads.

Sometimes, if things get too contorted... it is best to wipe the slate clean, in my experience

maybe so, but you generally use the same slate.

Kayaker understood the issue the first time... you didn't.

Do you have something to contribute, or not?

to your problem? no.

no point in helping people do things the hard way when the easy way would suffice.

which has absolutely nothing to do with cluttering the forum with new threads when the topic is still the same.

please refrain from doing that, thanks.

To refresh everyone's memory; Ryder is the one who started the "Stupid things" thread where he bitched about how stupid LSL was because it was not working for him how he expected, even thou it was working correctly. He then proceeded to bitch at all of us when we pointed this out.

Sorry Ryder, but the same crew is here answering questions, just as we tried to warn you. You really need to go find another Scripting Forum to ask your questions in.

I remember. Sooo...... why waste time reading and responding to his posts?

Wait a minute....

SO... you read post presented to this forum, devoid of complaint or snide remarks... sticking to topic, purely technical in nature...

Then you have the audacity to launch into off topic, sometimes personal/snide rants as your response to this technical issue, while AT THE SAME TIME criticizing the content of other peoples posts? (and not addressing the technical issue, I point out)

Gentlemen. Look in the mirror. Grow up. Stop contaminating threads with non technical responses, personal attacks and other garbage. Just look where YOU have taken this thread. Just look at your "contribution" here. I can appreciate that some of you have been helpful to many people over the years, BUT, that does not give you free reign to be random jerks. If anything you should be meeting higher standards.

You should be ashamed of yourselves in your hypocrisy.

Throwing prims in glass houses... poor form, my friends.

RS

Ah, that was a GREAT thread... that became one of the most in-depth technical explorations of targets/animations/permissions ever seen in the forums (though we had to wait for the riff-raff to clear out so that actual technical discussion could commence).

That was an entire year ago...!

why yes pot, I AM aware of my color... are you?

never mind the logical fallacy of expecting people to be friendly and helpful while simultaneously attempting to insult them AND ignore basic forum etiquette and courtesy.

you were gently urged to use the same thread for the same discussion, you choose to take a position of entitlement, and condescension, and were called on it. you can either demonstrate some new found maturity, and accept the advice given, or continue with your self important rant. However, You will find that you aren't going to be very successful at brow beating anyone here, because most of us are experienced in dealing with impotent temper tantrums.

Hmm. I think some context is missing. I DID miss that other thread, and it's not completely clear from this explanation what is desired.

A linear impulse is a change in momentum (momentum being mass times velocity). A delta (p2-p1), not a rate of change (time derivative). Similarly, a rotational impulse is a change in angular momentum (REAL angular momentum is product of angular velocity and a moment of inertia matrix, but I THINK SL angular momentum is just mass times rotational velocity). Either one may be transformed between coordinate frames (e.g. region coordinates vs. local coordinates) pretty easily in the usual fashion.

SL is a little thin on angular mechanics. While the physics engine may involve some rotational impulses due to scripts and collisions, I think it is a bit light on actual moments of inertia and torques and such. Therefore I'm not sure how well an angular impulse would work to push a bowling pin back upright. You can always test it and let us know what you come up with though, of course.

Hi Hewee,

Well, as it turns out... the rotational impulse works fantastically at keeping things upright... and it's very easy to do... you just impart impulses multiplied against it's delta from upright. When the delta is 0, the impulse will be zero. Works like a charm.

The problem is, when you want to do something more complex than that. Say you want to use impulses, like in the bowling pin example, where you wish to treat one local axis differently... you now need to do the same job, but isolate it to local coordinates, so that you can monkey around as you wish.

But since for physical objects, GetOmega and GetRot (and GetLocalRot) all *seem* to be operating in a regional reference... there is a reference mis-match, so local impulses based on that regional data... well... just won't work.

I somehow need to bridge the gap between GetOmega / GetRot to locally referenced forces.

Can we get there from here?

rs

Of course.

globalVec = localVec*llGetRot()
localVec = globalVec/llGetRot()

apparently Ryder felt the need to write me this 13 minutes AFTER he responded to Hewee...


please feel free to point and laugh, I did, especially given where the multiple clearly worded (and even polite) requests to him have led. posters, please take note: this is the sort of behavior that A) clearly gets attention, but B) is really light on results...
(ie any of a dozen regulars could have given the formulas for conversion of vectors (or rotations for that matter) between local and global frames of reference, DAYS ago. [hell, I have a help page that covers all but one case, which I think I'll add now that I've noticed it's missing])

Thanks, Hewee... I already know the basic conversions though...

Something is still not right. In this test, adding the two conversions below, there is somehow an instability in the system. If one removes the conversions, and then changes the local mode of ApplyRotationalImpulse to FALSE... the system is now stable... in a regional reference.

// meant to run in a timed loop

vector myrot = (llRot2Euler(llGetRot()))/llGetRot(); //notice conversion to local
float roll = myrot.x;
float pitch = myrot.y + tilter; //"tilter" is just a way to make an offset
float yaw = myrot.z;
vector myOmega = llGetOmega()/llGetRot(); //notice conversion to local

llApplyRotationalImpulse(<-myOmega.x * mass ,-myOmega.y * mass,0> , TRUE);
llApplyRotationalImpulse( <roll * -mass, pitch * -mass, 0>, TRUE );

But it DOES work fine under one circumstance... IF the prim is facing <0,0,0> to begin with. But changing the heading of the prim produces the instability.

I'm just not seeing where the instability is coming from.

I also notice that GetRot, GetLocalRot, and GetRootRotation all return the same values on this physical prim. What might that be trying to say to me?

Thanks bunches!

Hmm. Good question. Since they are impulses (meaning instantaneous changes, not continuous ones like torques would be), it SHOULDN'T matter what happens between calls. But I notice a couple of things. You are converting to Euler angles, and then both trying to transform them between coordinate systems and performing computations on them. That may not be (probably isn't) doing what you want. I usually advise staying away from Euler angles completely. Unless they have only one non-zero component, they are extremely unlikely to be doing what you think they should be anyway. At LEAST do the coordinate transformation BEFORE converting to Euler angles if you really must use them. Euler angles may be stored in a "vector" in SL, but they are NOT true mathematical vectors and they will NOT transform properly between coordinate systems. Quaternions WILL transform properly.

The other thing I notice is that you are applying two rotational impulses about different axes. I'd think carefully about what you are actually trying to accomplish and instead figure out how to resolve those into one impulse about one axis.

If the prim is at ZERO_ROTATION, its coordinate frame IS the same as the global one. All transformations between the two will be identity transformations (no change), so if there is a problem in your logic--such as trying to transform Euler angles--it won't show up at that particular orientation.


If it is the root prim of the object (always true for single-prim objects), those functions SHOULD always return the same value. In child prims they return the prim's orientation relative to the global coordinate frame, the root prim's coordinate frame, and the root's orientation relative to the global frame, respectively. At least if we ignore attachments. Attachments are whole separate discussion.

Hey Hewee,

So how do I get a true vector of my regional attitude that is not Euler? llRot2Axis()?

So to get to Euler AFTER the conversion to local... I would change the top of the code thus:

vector myrot = llRot2Euler(globalVector/llGetRot()); //conversion to local, now before Euler

And I think Euler is required... how else to I isolate the pitch axis, as needed in the bowling pin example?

It appears that llGetOmega, and a conversion to locals, should be ok.


Thanks ever so much.... fingers crossed... feels like it's close.

I think it is more a question of how you are thinking about a "rotation" (or "orientation". But let's look at the rest of your question and maybe you'll see what I mean.


Well, transforming a rotation of some sort into a local coordinate frame and then calling llRot2Euler() on it should indeed give you Euler angles that express the rotation in your local coordinate system, but let's look at what you propose. In this example, you're transforming a VECTOR into local coodinates, not a rotaiton. So you're going to have a local vector, and you can't just convert a plain vector to a meaningful set of Euler angles. In the previous example, you were taking the rotation of the prim itself and trying to express it in the prim's coordinate system. Well and good, but if you succeed at that, you'll actually always get an identity transformation (in the prim's coordinate system, the prim itself is...well...unrotated). So let's go on to what I think you REALLY want:

Ah ha! There's a concrete question! If by "pitch" you mean the current angle between the pin's local z-axis and straight up (the global z-axis):

rotation currRot = llGetRot();
vector up = llRot2Up(currRot);
float theta = llAcos(up.z);
vector axis = llVecNorm(<0.0, 0.0, 1.0>%up);

where you could get a rotation from "straight up" to the pin's current orientation with 'llAxisAngle2Rot(axis, theta)'.

If instead you mean the component of the prim's current rotational velocity ("omega" that takes it further from the global z-axis rather than rotating it around the global z-axis, try:

vector omega = llGetOmega();
vector othogonalOmegaComponent = <omega.x, omega.y, 0.0>;

Note that both 'axis' above and the vectors here are expressed in the global coordinate system. If you wanted to transform them to the prim's local coordinate system you certainly could as usual. You might find that there is less need to however.

Whoa dude... my brain hurts

Ok... I will digest this... and run a test or two... then get back with, hopefully, good news

With some luck, I will have something fun to give you in game

RS

Hi Hewee,

I am still struggling with the previous post. I see numerous issues still, but I should ask one, hopefully simple(r) question that represents a subset of things being discussed.

I am going to describe an autopilot for an aircraft. It's pitch is controlled. It's roll is controlled. The heading control is turned OFF.

Our aircraft is a floating sculptie cube in the shape of an aircraft, buoyancy 1.0 and the hands of fate have bumped it into some unknown orientation. Fate will bump it occasionally... it's rotation on all axis changing each time.

Using only the repeated force of llApplyRotationalImpulse, how would you nudge the cube/plane, repeatedly, so that it always returns to: Roll of zero (wings level), and a pitch of -10? (nose up slightly), and you ignore its compass heading, affecting it not at all ???

rs

Ah. Okay. A good concrete application. The way I would approach it is like this. We can come up with a desired orientation using the three constraints:

1.) "Heading" remains constant: the local x-axis points in the same horizontal direction; its projection onto the xy-plane is unchanged.

2.) "Roll" is zero: the local y-axis is level (is orthogonal to the global z-axis).

3.) "Pitch" is as described: 10 degrees up from level; this will affect both the local x and z axes, as pitch is logically a rotation about the local y axis.

Now since you want to use angular impulses rather than say llRotLookAt() we can take the "difference" between the desired orientation (rotation) and the prim's current orientation. In other words, find a transformation that when applied to the prim's current orientation will produce the desired one. Given that rotation, we should be able to come up with a required axis and angle about which to rotate, and produce a desired rotational velocity from those.

One more step. To reach the desired angular velocity, it is also necessary to cancel whatever CURRENT angular velocity the object has. So what we really want is a difference between desired and current angular velocity for the impulse.

So here goes. Note the use of vector cross products (using the '%' operator) to find a vector orthogonal to two others.

rotation currRot = llGetRot();
vector currFwd = llRot2Fwd(currRot);

rotation targetRotUnpitched = llRotBetween(<1.0, 0.0, 0.0>, llVecNorm(<currFwd.x, currFwd.y, 0.0>));
rotation pitchRot = llAxisAngle2Rot(<0.0, 1.0, 0.0>, -10*DEG_TO_RAD);
rotation targetRot = pitchRot*targetRotUnpitched;

rotation rotCurrToTarget = targetRot/currRot;
vector axis = llRot2Axis(rotCurrToTarget);
float angle = llRot2Angle(rotCurrToTarget);

// This is designed to act like llMoveToTarget() or llRotLookAt(): reach the
// desired orientation in time 'TAU' in seconds.  This is certainly a place to
// implement your own logic.
vector desiredOmega = (angle/TAU)*axis;

vector currOmega = llGetOmega();
vector impulse = desiredOmega-currOmega;

llApplyRotationalImpulse(impulse);

A couple of things to note:

1.) I was wrong about mass; SL rotational impulses are apparently, in fact, simply a difference in angular velocity. See http://www.lslwiki.net/lslwiki/wakka.php?wakka=llApplyRotationalImpulse

2.) I've tested this. For small deviations from the desired orientation, it works okay for a moment, but then seems wildly unstable. It might just be that this kind of solution is impractical in SL, because of timing and the limitations of the physics engine/simulator. MAYBE with very careful timing you could get it to work all right, but you might unfortunately just have to go with llRotLookAt().

Hi... let's be clear here... heading does not necessarily remain constant... the system should not constrain or act upon heading. It might full well wish to change... but we want to be sure that we are fully decoupled from this.

We want to assume that it may be changing... but really, we don't care one way or the other. Is your design set up that way?

Essentially, we are preparing to fight fate only on pitch and roll... heading we leave to fate.

rs

If I understand your code, you are calculating a force to fire *once* to return the plane sculptie to the desired orientation... yes?

If so, this does not quite describe the scenario... we need repeated firings of llApplyRotationalImpulse... gentle nudges... to push it toward where we want it, recalculating the vector force each time. If you scale the force down, say to 20% of what is needed to get the full result... then nudge it say, every half second... in a few seconds, the approx roll and pitch will be attained.

rs

Actually, I have backed into an interesting question here. For any "one shot" impulse, in a frictionless world... such an event would cause the object to spin forever at those rates... but clearly SL has some friction/buffering. For the one-shot method to work, one would have to understand the friction/buffering very well.

But in the case of the scaled back multi-shot approach, we don't care so much... and understanding the friction/buffering can be empirically approximated, and the system would still work well....

RL example, the Shuttle Columbia broke up due to missing tiles, but in the minutes before it failed totally, that gap in tiles changed the forces acting on the shuttle, wanting to alter it's orientation about all axis... the auto pilot, sampling many times per second, did not care about the origin of the forces, and simply/blindly fought against deviations from the desired attitude with knowledge of rotational rates. Of course that system, in responding, could be a source of instability too... hysteresis, so the rcs impulses had to be dampened to prevent that effect.