How can I set Velocity Direction Relative to Prim Rotation?

[Syle Devin]

Hi, I am creating a bowling lane that rezzes the ball on it's own. Currently the lane rezzes and shoots the ball but only in one direction. I am trying to get the lane to shoot the ball in the same direction relative to the lanes rotation.

Right now I am stuck on getting the rotation of the lane, one that I can actually use since the rotation is in radians. I do not know how to work with radians. I tested with llRot2Angle but was not able to get it working. I am thinking that once I get a useable x,y,z, rotation I can come up with an equation for the velocity. Although is there an easier way to do this?  

 

I guess for now, how can I convert the radians to degrees?

 

Thanks!

[Miranda Umino]

To convert radians in degrees :

angle_in_degrees =  RAD_TO_DEG * angle_in_radians ;

To convert degrees in radians :

angle_in_radians =  DEG_TO_RAD * angle_in_degrees ;

 

Or , if you don t use the constants  RAD_TO_DEG and DEG_TO_RAD , think that PI radians = 180 degrees , so

angle_in_degrees =  180 * angle_in_radians  / PI;

angle_in_radians =  PI * angle_in_degrees  / 180.0;

 

A rotation is  the combination of an angle and an axis : the axis of rotation   ( you may get it by llRot2Axis ) and the angle  ( relative this axis .  ( you may get it by llRot2Angle ) 

An another equivalent definition of rotation is the combination of 3 axis : the LOCALS  axis x ,  y and z. You may get them by respectively llRot2Fwd , llRot2Left , llRot2Up 

For instance :

float magnitude =  3.0 ; // speed is 3 meters per seconds
llSetPhysicsMaterial(GRAVITY_MULTIPLIER, 0 , 0, 0, 0); // ignores the gravity llSetStatus(STATUS_PHYSICS, TRUE ); // turns on physics
// moves to a constant velocity in the local X direction and with a speed equals to magnitude( 3meter/second)llSetVelocity(  magnitude * llVecMag(  llRot2Fwd( llGetRot () ) , TRUE );
llSleep(2.0) ; waits 2 seconds before to stop physicsllSetStatus(STATUS_PHYSICS, FALSE ); // turns off physics

 

 

 

 

[Rolig Loon]

Unless you truly need degrees for some reason, it's smarter to stick with radians.  All you need to remember are a three simple geometric rules:

1. There are 2*PI radians in a circle.  So halfway around a circle is PI radians and a quarter of the way around a circle is PI/2 radians.

2. In SL, if you are looking at a rotation in a global (regional) framework, EAST is always ZERO_ROTATION.  So NORTH is PI/2 radians, WEST is PI radians, and SOUTH is 3*PI/2 radians.

3. In SL, if you are looking at a rotation in an object (or avatar's) local framework, FORWARD is always ZERO_ROTATION.  So Straight LEFT is PI/2 radians, BACKWARD is PI radians, and Straight RIGHT is 3*PI/2 radians.

========================

Easy stuff.  In this case, you don't need to even use it, though, because you don't ever need to know exactly how many radians or degrees the ball's velocity vector and the lane are rotated.  You just need to make them the same.

If you want to know the regional rotation of the lane, ask it.  If your script is in the lane's root prim, that's llGetRot().

If you want to rez a ball and give it a velocity in the lane's FORWARD direction, you'll want

llRezAtRoot("Ball",llGetPos() + offset*llGetRot(), velocity * llGetRot(),ZERO_ROTATION,1);

That is, you want to make the ball appear at the lane's root position plus an offset that is rotated in the same direction that the lane is rotated, and you want to give it a velocity that is also rotated in the same direction as the lane is rotated.

You can mess with your velocity vector to make it as big or as small as you wish.  For ease of fiddling, I'd suggest thinking of it as being divided into three parts:

vector velocity = Mass * scale_factor * <1.0,0.0,0.0>;

Mass is the mass of your ball, a constant.  scale_factor is just a number that you play with until you get the ball going the right speed.  And <1.0,0.0,0.0> is a local vector that points in the lane's FORWARD direction.  By rotating FORWARD by llGetRot(), you are guaranteeing that the ball's FORWARD direction of movement will be the same as the lane's own FORWARD.

 

[Syle Devin]

So it was as simple as multiplying velocity by llGetRot. Is there an explanation behind that? Also thank you, I now understand the numbers that I was getting back for llGetRot, the radians I should say. My main objective is now fixed, thanks again. 

 Also thank you Miranda for the explanation of converting radians to degrees. 

 

Edit: So I've run into something else. How come when I multiply velocity by the root objects angle it goes in the forward direction but when I multiply by a different angle the ball's direction is not effected? For example in aiming I got the angle between my avatar and a point that I clicked on the lane. Then I multiplied the velocity by that angle but nothing changed. 

[Aspire Rang]

#1.)  You are not multiplying by an ANGLE  you are multiplying by a ROTATION

 

2.) You are not MULTIPLYING at all,  this is the root of most of the rotation agitation in SL.  you are using the * operator, but it is polymorphic,  it does different things based on what arguments you passd it.

 

When you are dealing with rotations read * as Rotated By  and / as DeRotated By 

 

 

[Syle Devin]

I may be a bit more confused. How does the rotated by work when passing the avatar rotation to the rez velocity? Is it simply saying "x speed" rotated by "x rotation" which would be rotating it by the radians, since it is not angle?

[Dora Gustafson]

---

Syle Devin wrote:

So it was as simple as multiplying velocity by llGetRot. Is there an explanation behind that? Also thank you, I now understand the numbers that I was getting back for llGetRot, the radians I should say. My main objective is now fixed, thanks again. 

 Also thank you Miranda for the explanation of converting radians to degrees. 

 

Edit: 

So I've run into something else. How come when I multiply velocity by the root objects angle it goes in the forward direction but when I multiply by a different angle the ball's direction is not effected? For example in aiming I got the angle between my avatar and a point that I clicked on the lane. Then I multiplied the velocity by that angle but nothing changed. 

---

There is an explanation behind this, but I doubt you will find it simple if you never new quaternions and their use for rotations

Read more here: http://wiki.secondlife.com/wiki/Rotation and link on to quaternion

Be prepared that this is the kind of maths you can't understand with your mind, but the rules formulas and equations are very useful

[Rolig Loon]

---

Syle Devin wrote:

So it was as simple as multiplying velocity by llGetRot. Is there an explanation behind that? [ .... ]

---

Yes, indeed.  To explain it well, I'd have to assume that you have at least a brief introduction to matrix algebra.  In fact, I suggest that you spend a little time on that assignment yourself. Here's a good, friendly place to start >>> http://www.mathsisfun.com/algebra/matrix-multiplying.html

Aspire gave you the basic reason. When you are applying llGetRot() to your position or velocity vector, you are not multiplying, at least not in the same sense that you multiply 2 X 2 to get 4.  You are operating on one matrix (the vector) by applying another matrix (the rotation) to it. The operation is asking, in effect, "What would this vector look like if I turned to look at it from another direction?" You are transforming the vector, putting it in a different frame of reference.

Suppose that your bowling alley is oriented East-West on your sim and that its FORWARD direction (the direction that you want to roll the ball) is East.  Using the rules that I posted before, there are two ways to think about which way the ball should roll.  You could say,"It will roll FORWARD" or you could say, "It will roll EAST."  Those are your two possible frames of reference. 

Now, suppose that we turn the alley so that the lane is North-South and we want the ball to roll North.  In our two frames of reference, we can again say that the ball will either roll "FORWARD" or that it will roll "NORTH".  Both would be correct, but "FORWARD" is a little confusing because it's not the same FORWARD that we used earlier.  If we're going to use that frame of reference, we need to be clearer about which FORWARD we mean. We mean "FORWARD when we are looking NORTH". In other words, we need some way to modify FORWARD --- a function that says "when we are looking NORTH."  That's what the rotation does.  As an equation,

FORWARD, when we are looking NORTH = <1.0,0.0,0.0> * llEuler2Rot(<0.0,0.0,PI/2>);

(Look back at my earlier post to see that <1.0,0.0,0.0> is a FORWARD vector in the local frame of reference and that PI/2 is a quarter turn around a circle.)  The equation says "we're looking at FORWARD from a new direction, turned a quarter of a circle away."  We didn't multiply anything in the conventional sense, we operated on FORWARD to look at it from a new direction. 

To generalize, if I wanted to define FORWARD in any new direction, not just North, I would operate on <1.0,0.0,0.0> with whatever the new rotation was ( llGetRot() ) instead of choosing llEuler2Rot(<0.0,0.0,PI/2>) specifically.

I hope that makes sense, but I know that it will take a lot of playing with functions before your mind accepts it.  That's the way it is for all of us, at least at first.  Rotations are not easy, because they involve thinking of directions in at least two frames of reference at the same time, always asking "What must I do to know which way is FORWARD when I turn?" The best way to learn is to sit down and dig into the matrix algebra until it makes sense. The way most people learn is to just practice solving new rotation puzzles, over and over.  Do whichever method works best for you.

---

Syle Devin continued:

Edit: 

So I've run into something else. How come when I multiply velocity by the root objects angle it goes in the forward direction but when I multiply by a different angle the ball's direction is not effected? For example in aiming I got the angle between my avatar and a point that I clicked on the lane. Then I multiplied the velocity by that angle but nothing changed. 

---

 That's a little trickier.  Again, you want to change FORWARD by rotating the velocity vector to point in a new direction.  You can't use llGetRot() this time, because that's unknown.  All you have to work with is a new target position that isn't in line with the bowling alley's FORWARD any more.  What you need is

rotation New_Rot = llRotBetween( <1.0,0.0,0.0>, llVecNorm(new_target_position - llGetPos() ));

If that's not confusing, I'll be surprised.  I won't take the time to explain it fully, but basically what it says is that you want to start with FORWARD when you are looking straight down the lane and rotate to FORWARD when you are looking along a vector defined by new_target_position - llGetPos().  The function llVecNorm just adjusts the new vector to make it the same scale as <1.0,0.0,0.0>.  It simplifies the calculation.